Exactly. Until Included no graph is visible in a user collection, regardless of whether that referenced graph is a collection or deployed/uploaded RDF file.My bad there is one last thing that you said that i want to confirm that i understood properly.
>> Settings, Includes will now show your ontologies under the “Other” category. I think i understand that now. This essentially entail, that a user will create a collection, and in the setting include section, will be able to see what has been uploaded in the workspace. In other words they will have access once they import the FILE in their working collection (whatever that collection is)
>> That said, with two ontologist it see like just using the EDG server and workflows would work for your situation. Your two experts can share workflows and test them before committing them to the production copy allowing the “users” to see the result. Again, "to see the results" here means via the include.
I can see that what i tested is slightly different from what you suggested with the include. That's because my intent was never to serve files that will feed into other collection that users would be working on. Hence i did not understand the statement at first.
Anyway, this has been very useful. I believe I understand better EDG Server Scope. On Saturday, March 23, 2024 at 6:42:14 PM UTC David Price wrote:
Thank you for the instruction
I did not fully understand this >> Settings, Includes will now show your ontologies under the “Other” category.
Questions:
1) can we use the option - Send Projects to Another Server
No, you must do as I described.
Your Studio cannot be configured in the same manner as your EDG server or the git repo. Of course, there are other possibilities.. just described one.
Cheers David
I have tried it, but keep failing, it seems like i am not entering the right address ? What should be the address or any other pre-requisite for that option to work ? I am using https://server-address/edg/. and using my admin credential. Yet it is failing. I'm also selecting the relevant subset of file i want to send.
2) Working with EDG Server directly, unfortunately is not an option for multiple reasons unfortunately.
3) Something that seem problematic with your approach, is that we work with Files in EDG Studio.
- If i create a folder to put my TTL in the same git repo and project, then i will have multiple files with the same BaseURI which TopBraid Product typically do not like. - Moreover The Upload Option also requires that the folder contains a .project file otherwise it rejects the upload. - Once the upload is done, it seems we have to use the option create ontology from Existing Files to actually see the upload. And that's a problem because that import transform things in a way we don't want to. For instance our ontology separate shapes from class, and when using that function, the collection created add shapes to the class directly i.e. making all our class nodeshape and keeping the separate shape too, and we end up with the wrong thing.
Hence does not work for us. Isn't a way to import your ontology without modyfing it, so long it follow all the standard given that it is developped with Files on Studio
On Saturday, March 23, 2024 at 10:04:47 AM UTC David Price wrote:
>> There is no single best practice for deployment. It depends on who is responsible for what, the skills of the team, how many are on the ontogists team, are external staff often used, how often ontologies need to change, how tightly controlled/regulated the organization is, etc.
We have currently 2 experts ontologist working on models on studio and collaborating via Git. Our goal is simply to upload the work of the ontologist as frequently as necessary to EDG Server, and have developers and product owners consult the only. It support data contract discussion between all the parties involved in the project. Ideally we wanted to go through git integration, but it seems that it does not work since the File Asset Type has been removed from EDG Server. Would have been nice to keep it as read only at least. From what i have red online, it seems we only have the manual upload possible as in extra step but git push. But we are not sure here exactly what are the exact steps to follow.
No external staff, the ontology currently is in active development, but very soon about to settle and expected to change not that frequently. In term of control/regulation, we are establishing the practice at the moment. s,
Seems like using Server Admin, Project Upload when your team gets to a “stable release” would work. Here’s a process we use for some customers that works for us:
- make a folder in git called something like myontologies.topbraidlive.org (call it what you want but adopt a convention and follow it)
- put your TTLs in the folder making sure they have rdf:type owl;Ontology statements
- zip the folder when ready to deploy to server
- Project Upload (from then on I usually use a the “Delete old project option and always completely replace everything, but that’s up to you, update is available)
- Settings, Includes will now show your ontologies under the “Other” category.
That said, with two ontologist it see like just using the EDG server and workflows would work for your situation. Your two experts can share workflows and test them before committing them to the production copy allowing the “users” to see the result. Workflows are not 100% equivalent of git branches, but not a million miles away. If you are using git as a kind of backup or as shared corporate knowledge, then after the commit the ontologist can just Export RDF sorted TTL and update the git repo.
Cheers, David
On Friday, March 22, 2024 at 6:25:54 PM UTC David Price wrote:
| Collections *are* the "user data” created and changed by users of an EDG server, assuming they have the right role/permissions. Ok, then in that logic, why would a user be allowed to create a collection of type ontology ? This feels more like a software system by your definition. They should only be able to create instance data no? Instance of ontology or simply taxonomy. But i can also understand that as the technology itself, difference between instance data and schema data can be blur sometime.
If an EDG user is an ontologist, then classes and properties are user data (i.e. data created by an EDG user).
Sometimes an ontology is the end product for some EDG users.
Sometimes the ontologies are used by a different set of EDG users to create instances in a Data Graph, for example.
EDG is flexible … and the EDG UI is almost all "model-driven” driven by the fact that ontologies are also a kind of data. The all workflow thingy, feels to me like collaborative ontology editing.
Workflows are for editing anything in EDG collections, not just ontologies.
In any case at this point, I would like to be able to deploy the ontologies we create with EDG Studio to EDG Server, not for user to edit user data (on top of it), but simply to consult the ontologies. What the best workflow for that ? doesn't the Git integration enable that ?
There is no single best practice for deployment. It depends on who is responsible for what, the skills of the team, how many are on the ontogists team, are external staff often used, how often ontologies need to change, how tightly controlled/regulated the organization is, etc.
Cheers, David
On Sunday, March 10, 2024 at 11:10:13 AM UTC Maatary Okouya wrote:
Understood. thank you
On Sunday, March 10, 2024 at 9:45:04 AM UTC David Price wrote:
Then what is really the rational for having files and collection ? I work with studio mostly, Files are perfect for me. I just want to make sure that i fully graps the philosophy here. Files did not exist in previous version, why was it added ?
Put simply, Studio/Files is how developers/ontologists deliver a software system, and Collections are how users create and manage data using that software system.
Studio was built for EDG server-supporting developers, ontologists, etc. who need to build and test ontologies, scripts, etc. before they get deployed to an EDG server as a “project” for use by the users of that EDG server.
Files is a feature for those developers that understands SPARQL, SHACL, etc. and so is better than using an external source code editor on TTL files, for example. Files is not intended to be a feature available on operational EDG servers due to security and system support/uptime risks.
The graphs deployed to an EDG server as a “project” are not “user data” so we don’t want users changing them.
Collections *are* the "user data” created and changed by users of an EDG server, assuming they have the right role/permissions. On Saturday, March 9, 2024 at 3:15:12 PM UTC David Price wrote:
“wrapping” files is not a good way to think about this. The EDG behaviour between collections and files is normal owl:imports.
EDG Files contain a named graph. So do collections, and collections can include (i.e. owl:imports) a graph that happens to be in a file or a collection.
If you change graph in a File at any point in time, then those changes are visible immediately in all including collections (accepting that caches may need to be refreshed for any currently in-use collections via a page reload for example).
FYI there are a few “special” files in EDG - api.ttl files contents are made visible via a software mechanism rather than owl:imports. These usually contain SPARQL Functions, for example, which are really “software” not "data model” or “data”. See
which is part of
Cheers, David Hi,
When wrapping Files, into EDG Collection. Does it become a completely separate entity e.g. ontology, or the two can be kept in sync, as in what change on files is propagate to the ontology wrapped ?
I guess my question is about understanding the intended behavior
--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to [email protected]
---
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 [email protected].
--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to [email protected]
---
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 [email protected].
--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to [email protected]
---
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 [email protected].
--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to [email protected]
---
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 [email protected].
--
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to [email protected]
---
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 [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/62a5a17e-2347-43d1-9ac7-0d32ba627f1en%40googlegroups.com.
The topics of this mailing list include TopBraid EDG and related technologies such as SHACL.
To post to this group, send email to [email protected]
---
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 [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/E1C84369-3265-4F64-A6E8-01DFA0B2A653%40topquadrant.com.
|
