Problem visualising ontology folders in Mentor Workspace

[otellomaria]

Version: 0.3.8

Mentor does not show any ontology in the workspace, or only shows the content of the first folder in the workspace. For example, the following code-workspace file:

{                                                                                                   
    "folders": [
        {
            "path": "../../../ontologies/dbt-tooling"
        },
        {
            "path": "../../../ontologies/ies-building"
        },
        {
            "path": "../../../ontologies/ies-common"
        },
        {
            "path": "../../../ontologies/ontology-composer"
        },
        {
            "path": "examples"
        }
    ]
}

Shows the folder names in the same order in the VSCode Explorer:

---

However, the Mentor workspace shows no RDF documents, as the first folder does not contain any:

---

If I change the order of the folders and the first one contains RDF files, the following happens.

---

---

Note that now the workspace only shows the content of the folder examples, and that I can select a graph with <workspace:/simple_ontology.ttl>. Even if the other RDF files are not shown in the Mentor workspace, I can still select a graph using a path relative to one of the other folders, e.g. <workspace:/src/data/simple_1.ttl>

This behaviour seems to depend on how the folders in the VSCode workspace are loaded, and in which order. Hence, when I create a folder that contains all the folders I want to see in my workspace and load it as the sole folder in my workspace, e.g.

{                                                                                                   
    "folders": [
        {
            "path": "mentor_debug"
        }
    ]
}

where the folder content is:

$ ls mentor_debug/
dbt-tooling  examples  ies-building  ies-common  ontology-composer

Then the Explorer correctly shows all those folders as sub-folders of mentor_debug:

---

And the Mentor workspace shows the individual folders containing RDF files:

---

In this case, the graph contains the name of the folder e.g. <workspace:/examples/simple_ontology.ttl>, but this only happens because the "container" folder is ignored. In my opinion, the code-workspace` file should deal with relative paths, while Mentor should parse every path in the workspace and expose a "relative" path for graph selection. I hope this helps!

[faubulous]

@otellomaria Thank you for providing the example workspace files!

I managed to replicate your issues and added support for workspaces to the workspace tree. It now displays the data in the same way the regular explorer does.

However, with regards to the workspace: URIs there's an issue: If we were to resolve these URIs relative to the current workspace folders, then these URIs would not be portable in the repository anymore. They would work in workspace A but not in workspace B.

I tend to resolve workspace: URIs always to the repository root and have the auto-complete provide the paths only to the files in the currently active workspace. This would keep the URIs independent of the selected workspace and thus make them work in all workspaces in the repository, rather than only in one.

What do you think?

[otellomaria]

Hi Seb, thanks for addressing this issue. I don't get the issue with the URIs. What do you mean by having different workspaces in a repository? I see the workspace as a virtual root folder that exposes subfolders (being them repos or not), hence the URIs should be defined relative to the workspace root.

To make a practical example, a workspace defined by:

    "folders": [
        {
            "path": "../../example1"
        },
        {
            "path": "example2"
        },
        {
            "path": "repository"
        }
    ]
}

Should result in the following (made-up) URIs:

workspace:/example1/test1.ttl
workspace:/example2/test2.ttl
workspace:/repository/src/test3.ttl

[faubulous]

Yes, you are right. However, when you view the folder without an explicit .code-workspace file, then the first URI will be invalid. Same goes for this situation:

    "folders": [
        {
            "path": "example1"
        },
        {
            "path": "a/b/example2"
        }
    ]
}

The following workspace URI will only be valid and work when you are viewing the repo from the explicit .code-workspace:

SELECT * FROM <workspace:/example2/test2.ttl> WHERE { ?s ?p ?o . }

When viewing it without opening a workspace then the URI would be:

workspace:/a/b/example2/test2.ttl

In addition to this you can place a .code-workspace file anywhere in a repository, making the queries in that folder only work when viewed from the explicit workspace. If you view if without opening the workspace then they won't work.

So, in a multi-root workspace environment the current workspace: URIs become unstable.

[faubulous]

I currently see two options:

1. Make workspace URIs relative to the repository root.
This would work when your .code-workspace file is in the repository root and contains no relative references outside the project folder. In this case, having the .code-workspace files in the root would require no changes - but - the IRIs would have to be resolved to the actual file location in the project root folder which creates a discrepancy between what you see in the explorer and what you write in the queries..

{
    "folders": [
        {
            "path": "example1"
        },
        {
            "path": "a/b/example2"
        }
    ]
}

Queries for example2/test.ttl would then be completed into the original URI, regardless of the workspace used:

SELECT * FROM <workspace:/a/b/example2/test.ttl> WHERE { ?s ?p ?o . }

Apart from introducing a discrepancy between the virtual workspace folders and the 'physical' layout, it also requires
manual input when a .code-workspace is not located in the repository root. We would need to add the relative path to the project root for this translation to be correct in this case.

However, this would provide an attack vector where someone could provide a relative path outside of the active repository. This can be dealt with but still needs to be considered.

2. Introduce a workspace id into the URI scheme
Introduce the workspace id into the URI scheme. E.g. like this:

workspace://my-workspace/example2/test.ttl

Then, if the workspace id does not match the active workspace id we show an error/warning message to indicate that the queries might not work. I like this because we can tell people what's going on.

But.. it also means that SPARQL queries which are scoped for a specific workspace can only be executed in the assigned workspace. We loose some flexibility here and cannot simply switch from the default workspace to another and run the same queries there.

A workspace URI without an explicit workspace ID (which is the default now) would then look like this:

workspace:///example2/test.ttl

However, the currently used URIs could be parsed into this format as well.

I like this idea better because it's more predictable and portable. However, at the cost of convenience.

@otellomaria Do you have any other ideas?