Files only available from Studio

[Matt Goldberg]

Hello-

We upgraded to 7.8.1 and I just noticed that Files is missing from EDG. Your documentation mentions that Files is now only available from Studio. Why was that change made? Now it isn't really possible to tweak files that come with the product by default, and since those folders aren't considered "Projects" you can't modify them in Studio and send them to EDG from there.

Matt Goldberg 

[Holger Knublauch]

Hi Matt,

We took that out for security concerns. Changing system files should be the last resort and is strongly discouraged. I would like to understand which parts of our platform are not sufficiently configurable so that you needed to resort to editing system files? (There is ui:override)

Thanks for clarifying

Holger

--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to topbrai...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b8b611c0-0ba9-49ac-908d-6fc394feb9a4n%40googlegroups.com.

[Matt Goldberg]

There are a few situations where it was useful. First relates to updating QUDT, which was briefly discussed in this thread: https://groups.google.com/g/topbraid-users/c/3t44aIHgXuM/m/pNVC-u_pAgAJ

If I wanted to maintain a separate copy of QUDT as asset collections there might be collisions between the graph URIs of the files and the external URIs of the Asset Collections which could cause some confusion. But the versions included can't be deleted or modified (easily) without Files since it is not in a project. 

Additionally, sometimes tweaks need to be made to those files to fix certain issues. For example, we use and/or import several ontologies that import some of the common ontologies included with EDG. Some of these don't meet all of the default constraints EDG has, so I have been replacing those files with fixed versions to prevent those errors from occuring anywhere they're imported. DCTERMS is an example of this; importing DCTERMS as-is will result in ~25 SHACL warnings about classes in DCTERMS not having a named superclass. I suppose I could have another asset collection or file in a project that imports DCTERMS and adds those things, but that's another level of complexity and indirection that I'd rather not have. If it was the case that the included common ontologies were a project, it would be trivial to update them and push them from Studio.

Hope that makes sense.

Matt Goldberg 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/F0B7EC53-3064-4290-A2E2-B13C6114BC89%40topquadrant.com.

[Holger Knublauch]

Ok thanks, Matt. I can certainly understand these problems with the pre-bundled files. I guess for QUDT we may have convinced you (before) to switch to asset collections, as this allows you to use different versions as they come out.

But for the other bundled files such as dcterms the situation is not as easy. I just tried terms and indeed I see the warnings that you mention. This is not ideal and I wonder how to address this. Any solution that requires patching existing files is fragile. I guess you have found the work-around to add the missing triples already.

To me this still sounds better than having to edit graphs that technically do not contain those extra triples. And even if you try to bypass the lack of the file editing through SPARQL injection or ADS, it still sounds fragile, error prone and would not work in cases like Data Platform where multiple copies exist in a network. And having to redo these changes after each TopBraid update is also not ideal.

So what would be better solutions:

1) We could move all these external graphs into a separated project that users can delete/replace.

2) We could try to include modernized versions that better interact with SHACL. But in the case of dcterms, would people really want to see all these extra root classes under owl:Thing? Should they go under rdfs:Resource, or an artificial superclass? The choice should be up to the users.

To help me scope the problem: Which other graphs are we talking about, specifically?

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGyojU3eGPc13dxBEh%2B4E2D3CTKKiLVvnUFmkb8KO5x%3DLDRw8w%40mail.gmail.com.

[David Price]

QUDT releases have version numbers in the URIs for their named graphs. So customers can load and use any release they want into EDG.

We have a ticket in our services team to upgrade the DC and DC Terms collections, so hopefully the situation there will improve for the 8.0 release. Turns out many public ontologies used then for class definitions, etc.

Holger - I like option 1) very much. Different ontologies, annotations, etc are considered “common” in different industries and a “separate project” approach would even allow us to deliver, for example, an EDG Life Sciences vs EDG Finance project with tailored common graphs pre-included in the future.

Cheers,

David

UK +44 (0) 7788 561308
US +1 (336) 283-0808‬

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/61A542D2-BFFD-4A40-9328-55A3B44D306E%40topquadrant.com.

[Matt Goldberg]

I agree, putting all the common/external ontologies in a project that could be tweaked would work for me.

As for other ontologies that have similar issues: I think FOAF and DC do, but I'll have to check when I get back to work. 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/D2235572-50AE-4E71-AB6A-47CC1A07951D%40topquadrant.com.

[Tim Smith]

I have also dealt with these issues before.  I favor option 1 as a solution. 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGyojU26UFpVWHUnWYMZn5tZ13NY4Um6s9%2BGjm3op65e2%3DHwKw%40mail.gmail.com.

[steveray...@gmail.com]

Actually, QUDT only has the major version (currently 2.1) in the graph URIs, and that hasn't changed in a few years. Furthermore, the individual Units, QuantityKinds, etc. do not have a version in their URIs, so there are still problems with collisions between the built-in units and loading a more recent release. 

[Holger Knublauch]

On 9 Mar 2024, at 7:34 pm, steveray...@gmail.com <steveray...@gmail.com> wrote:

Actually, QUDT only has the major version (currently 2.1) in the graph URIs, and that hasn't changed in a few years. Furthermore, the individual Units, QuantityKinds, etc. do not have a version in their URIs, so there are still problems with collisions between the built-in units and loading a more recent release. 

I guess such collisions are not the fault of the namespace developers. There is no need to change the URIs of all resources with each version. Programming languages/APIs also don't do that as this would break things all the time. Instead, users need to be clear about which version they "compile against".

Anyway, I have recorded a development ticket to look into moving these external graphs into a dedicated workspace project, and that project could then be deleted and replaced via project upload. I just need to identify which graphs we are talking about. Maybe QUDT should also be moved into that new project.

The timing is good (now-or-never) as we are just about to finish our work on TopBraid 8 which will have various other changes to the workspace anyway.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b7f165db-3581-418b-8cdf-509fa6e28a9cn%40googlegroups.com.

[Steveraysteveray]

I think moving QUDT into the dedicated project would be a great idea. 

 

- Steve

On Mar 10, 2024, at 8:50 AM, Holger Knublauch <hol...@topquadrant.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/D9B67B20-74BF-4B08-83B3-3F5117453C52%40topquadrant.com.

[Holger Knublauch]

Ok, I am on it. One question (to everyone) though: it seems that the Base URI Management page can already be used to delete individual files, even from system projects. Why cannot that be used, followed by project upload, to install custom versions of these graphs?

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/855C1E4F-E5E7-4923-929F-28EAC213B538%40gmail.com.

[Matt Goldberg]

I suppose it technically could, but it might require exporting the graph first to make edits and it would require manually deleting each file individually every time there was an upgrade instead of just pushing a project. 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/BDE0F6DD-D29A-4F56-B263-FCE84678EC47%40topquadrant.com.

[Holger Knublauch]

Ok, and with the custom "External" project, you could just maintain your own copy and replace it in one go?

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CAGyojU3W9ZkE%3DEjHMvfY1TOkoiX%3DJJOmU7sJHiuLLjk0tiKCJA%40mail.gmail.com.

[Steve Ray]

I do have one request, since you are going to be building this new external project anyway, and that is to upgrade your copy of QUDT to the latest release. It is much improved. Feel free to send us feedback if there are aspects that conflict with EDG in any manner.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9666D071-2E11-4EB9-9476-E26BB448CA15%40topquadrant.com.

[Matt Goldberg]

Exactly. The copy we maintain could either replace the existing file or we could have a separate project with our copy of several files and the other files would be deleted.

I did just realize- the files that aren't projects aren't included in backups, correct? So how would moving some external vocabularies into a project interact with that?  

[Holger Knublauch]

On 19 Mar 2024, at 1:05 am, Matt Goldberg <mgbe...@gmail.com> wrote:

Exactly. The copy we maintain could either replace the existing file or we could have a separate project with our copy of several files and the other files would be deleted.

I did just realize- the files that aren't projects aren't included in backups, correct? So how would moving some external vocabularies into a project interact with that?  

Our backup service does include files, except for system projects. The new "External" project that we are adding for 8.0 will not count as a system project and therefore will be backed up. It also means that when replaced it will be backed up. To me this sounds like the right approach.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9f2b0554-0775-4cc3-bb26-5099144b16afn%40googlegroups.com.