| 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. The all workflow thingy, feels to me like collaborative ontology editing.
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 ? 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: > >> >> On 10 Mar 2024, at 06:35, Maatary Okouya <[email protected]> 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. >> >> Cheers, >> David >> >> UK +44 (0) 7788 561308 <+44%207788%20561308> >> US +1 (336) 283-0808 <(336)%20283-0808> >> >> >> 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 >>> >>> >>> https://archive.topquadrant.com/doc/latest/ext/process.html#working-with-extension-files >>> >>> which is part of >>> >>> https://archive.topquadrant.com/doc/latest/ext/index.html >>> >>> Cheers, >>> David >>> >>> UK +44 (0) 7788 561308 <+44%207788%20561308> >>> US +1 (336) 283-0808 <(336)%20283-0808> >>> >>> On 9 Mar 2024, at 14:29, Maatary Okouya <[email protected]> wrote: >>> >>> 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]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/topbraid-users/80f75b5d-564c-4c2b-ae3e-923be77f3a8an%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/topbraid-users/80f75b5d-564c-4c2b-ae3e-923be77f3a8an%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> >> -- >> 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/188d2eea-dd43-479a-b646-eba1ac4a4452n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/topbraid-users/188d2eea-dd43-479a-b646-eba1ac4a4452n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- 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/0fce4b0b-295a-431f-b07a-5de98c5bcc8bn%40googlegroups.com.
