Closed Antoine-Zimmermann closed 1 year ago
In fact, there are 2 issues here:
As far as I'm concerned, the 1st one is the most important and even non-negotiable. The second is open for debates but would be nice to have.
When creating the dataset for the Create an Organization
motivating scenario on Regulation, I faced a possible first difficulty when using the HMAS ontology separated in different namespaces. I had to 'instantiate' (not sure if the term is correct) Agents whose are members of an Organization. The Turtle code I ended up with was
@prefix ex: <http://example.org/> .
@prefix hmas: <https://purl.org/hmas/core#> .
@prefix hreg: <https://purl.org/hmas/regulation#> .
ex:Alice a hmas:Agent ;
hreg:isMemberOf :SL_Logistics .
I had to define 2 prefixes hmas
and hreg
because the terms comes from different namespaces of the HMAS ontology. I thought it inelegant and difficult to grasp that both originate from the same ontology. I would prefer the following Turtle code which seems cleaner and less clumsy.
@prefix ex: <http://example.org/> .
@prefix hmas: <https://purl.org/hmas#> .
ex:Alice a hmas:Agent ;
hmas:isMemberOf :SL_Logistics .
I know there are many other aspects to take into account when deciding to have a single or multiple namespaces. I just wanted to report my first experience and difficulty when using the multi-namespace HMAS ontology.
Exactly right! We need more feedback from users to make better design decisions.
--AZ
Le 23/11/2022 à 18:57, Luis Gustavo Nardin a écrit :
When creating the dataset for the
Create an Organization
motivating scenario on Regulation, I faced a possible first difficulty when using the HMAS ontology separated in different namespaces. I had to 'instantiate' (not sure if the term is correct) Agents whose are members of an Organization. The Turtle code I ended up with was@prefix ex: <http://example.org/> . @prefix hmas: <https://purl.org/hmas/core#> . @prefix hreg: <https://purl.org/hmas/regulation#> . ex:Alice a hmas:Agent ; hreg:isMemberOf :SL_Logistics .
I had to define 2 prefixes
hmas
andhreg
because the terms comes from different namespaces of the HMAS ontology. I thought it inelegant and difficult to grasp that both originate from the same ontology. I would prefer the following Turtle code which seems cleaner and less clumsy.@prefix ex: <http://example.org/> . @prefix hmas: <https://purl.org/hmas#> . ex:Alice a hmas:Agent ; hmas:isMemberOf :SL_Logistics .
I know there are many other aspects to take into account when deciding to have a single or multiple namespaces. I just wanted to report my first experience and difficulty when using the multi-namespace HMAS ontology.
-- Antoine Zimmermann ISI - Institut Henri Fayol École des Mines de Saint-Étienne 158 cours Fauriel 42023 Saint-Étienne Cedex 2 France Tél:+33(0)4 77 42 66 03 https://www.emse.fr/~zimmermann/
+1 for slash uris
Do you have something to add @FabienGandon ?
During the heartbeat meeting we think that should be quickly (1-2min) just to be sure that we agree all about the current namespace structure. (2min)
Fabien : "Let's try ! We are researchers !"
The current IRIs are following the scheme:
Proposal
I suggest that we use instead:
An ontology module would look like this:
Dereferencing strategy
When dereferencing
hmas:Agent
, we can redirect tohmas:core
for instance, but we could also, afterwards, change this to dereference to a single term definition. Having a single term definition would allow us to use hash IRIs to lead to a specific section of the term specification, such ashmas:Agent#example
to get usage examples; orhmas:Agent#history
to see the history (at which version the term was introduced, revisions, etc.); orhmas:Agent#meta
for additional metadata, such as to which issues this relates, who is the creator of the term, what actors of the community supported the term, how often the term is used in such and such index of usage, etc.Further justification
So far, we do not need these extra hash IRIs, nor do we need to dereference to distinct files for different terms, because we have few terms, few modules, few versions, few people in the community. But when the community grows, and more issues, more versions, more terms, more modules, more applications will be available, it will not be a good time to change the identifiers that everyone will have been using for a while. If we are stuck with hash IRIs and a single file forever, the whole endeavour is probably doomed to fail.
About a single namespace for all terms: When multiple modules will emerge and more terms will appear, it will be horrendous to remember in which module a term is defined. In fact, chances are that we ourselves will have to debate on where to put a term. By having the term in a single namespace, we can even change the module where it is defined at a later stage, without changing the IRI.
More justification from other people
These days, there has been a long discussion thread on the Semantic Web mailing list about the merrits of slash IRIs for vocabularies and ontologies. The are many interesting arguments on both sides of the debate, but frankly the proponents of the slash IRIs are much more convincing. In fact, the arguments are not really about hash vs. slash but rather about dereferencing terms individually vs. always dereferencing the whole ontology (or module).