best practise name space in multiple languages?

[Bohms, H.M. (Michel)]

In case I have the same specification on different modelling levels:

• Skos
• Rdfs
• Rdfs+owl
• Rdfs+shacl

 

Is there some best practice  for the name space?

 

(compare same name space for different serializations but now for different languages used…).

 

I now have ie:

 

# baseURI: https://w3id.org/def/nen2660-rdfs

 

But I got the comment that just:

# baseURI: https://w3id.org/def/nen2660

 

was preferred.

 

But then I have 4 variants (actually 12: all in rdf/xml, turtle and json-ld) specifying for the same name space.

 

Thx for advice,

Michel

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location   This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

[Holger Knublauch]

Hi Michel,

First we should make sure that the users of your models understand the distinction between namespaces and graph URIs. You can of course use the same namespace (e.g., https://w3id.org/def/nen2660#) in multiple graphs. What you are probably referring to is the Graph URI under which the models will be downloaded from on the Web.

For the RDFS part, assuming this merely declares classes, properties and their relationships, I suggest they should be found at the URI that is like the namespace (except maybe without the #). Then, the OWL version could be at a URI ending with nen2660-owl and the SHACL version could be at nen2660-shacl, and both would have owl:imports statements to the RDFS Graph URI. OWL is typically pretty strict about what is allowed in the models, e.g. to preserve the OWL DL logic. On the other hand, SHACL is quite relaxed if a graph also contains OWL axioms - they will simply be ignored. So in theory the SHACL graph may owl:import the OWL version too.

Using owl:imports will make sure that declarations are not repeated across files, and therefore don’t risk running out of sync, e.g. if someone changes the RDFS classes only in one file.

I don’t know enough about how the SKOS version is different to comment on that. I would find it rather confusing if a resource is a class in one graph but a SKOS concept in another.

The topic of RDF/XML vs Turtle etc is another dimension, typically solved using HTTP content negotiation. All serialisations would be accessible from the same server URLs yet the server would return different results depending on what accept header the client requests.

Holger

On 6 Apr 2021, at 6:20 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

In case I have the same specification on different modelling levels:

• Skos
• Rdfs
• Rdfs+owl
• Rdfs+shacl

 

Is there some best practice  for the name space?

 

(compare same name space for different serializations but now for different languages used…).

 

I now have ie:

 

# baseURI: https://w3id.org/def/nen2660-rdfs

 

But I got the comment that just:

# baseURI: https://w3id.org/def/nen2660

 

was preferred.

 

But then I have 4 variants (actually 12: all in rdf/xml, turtle and json-ld) specifying for the same name space.

 

Thx for advice,

Michel

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

<image001.gif>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

-- 
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/8c5728fd3b8b45cd8ca17055b8df9688%40tno.nl.

[David Price]

A few comments following on from what Holger said and adding a question:

On 6 Apr 2021, at 12:22, Holger Knublauch <hol...@topquadrant.com> wrote:

Hi Michel,

First we should make sure that the users of your models understand the distinction between namespaces and graph URIs. You can of course use the same namespace (e.g., https://w3id.org/def/nen2660#) in multiple graphs. What you are probably referring to is the Graph URI under which the models will be downloaded from on the Web.

For the RDFS part, assuming this merely declares classes, properties and their relationships, I suggest they should be found at the URI that is like the namespace (except maybe without the #).

Yes, please don’t include the # as the idea of a fragment identifier is already confusing enough, not to mention the # vs / discussion.

Then, the OWL version could be at a URI ending with nen2660-owl and the SHACL version could be at nen2660-shacl, and both would have owl:imports statements to the RDFS Graph URI.

If possible, perhaps see if you can use a server that handles file types so you don’t have to do the “different URI” thing. You may also consider making these available in an “online graph database” so classes, properties, etc. can be properly dereferenced and queried using SPARQL.

Also, please remember:

- you’ll have users who do like me: I refuse to use RDF/XML as is about 3-5 times slower, far harder to read as a human and so the first thing I do with any RDF/XML encoding I get is convert it to TTL in Composer. If it’s giant I do occasionally use N-triples too.

- It is very misleading to have XML or JSON-LD in the URI of a graph stored as TTL 

- and far more confusing to find one in a graph database which has no concept of file encoding at all.

What we usually do in customer projects is to use the nature of the artefact rather than the language as part of the namespace (actually also the folder structure in Composer). The use of different modelling languages can change the “meaning” (e.g. inferences) in some cases and not everything in the same language has the same nature. We usually start a project with an “Ontology Architecture” document/presentation (should have a better name since not all are ontologies) that defines these things so we have a common understanding from the outset.

I’m not aware of an industry best practice, but assuming the four you mention are all models of data, then we might use something like ‘taxonomy', ‘schema' (or 'data-model'?), ‘ontology' and ‘shapes'. As I mentioned, in most customer cases that is not the complete list because not all only OWL artefacts define an ontology (e.g. some are 'alignment-ontology' (aka ‘mapping') or even data-driven 'mappings' with a different purpose/nature) and some SHACL artefacts define ‘transforms’ (in the ETL sense), not ‘shapes' (again, a different purpose/nature).

I’m not aware of an industry best practice. I’m just explaining what we’ve found of practical value in customer projects where we use multiple language, where different artefacts in the same language play different roles and where the only folks involved are ourselves and the customer staff. That said, if I was to put a public project on GitHub for a standards community this is the approach I’d follow as IMO the “nature of the thing approach” helps implementors as well as ontologists.

Definitely document whatever you decide, in an easily noticed README at a minimum.

OWL is typically pretty strict about what is allowed in the models, e.g. to preserve the OWL DL logic.

On the other hand, SHACL is quite relaxed if a graph also contains OWL axioms - they will simply be ignored. So in theory the SHACL graph may owl:import the OWL version too.

Yes, see Q below.

Using owl:imports will make sure that declarations are not repeated across files, and therefore don’t risk running out of sync, e.g. if someone changes the RDFS classes only in one file.

Exactly! Maintenance is always a concern - and most people ignore it until it causes a huge problem later in life (unfortunately, too often in someone else’s life).

I don’t know enough about how the SKOS version is different to comment on that. I would find it rather confusing if a resource is a class in one graph but a SKOS concept in another.

The case where I regularly see this is if the artefact being defined is “master data” or a “reference data library”. If the OWL is really just a large hierarchy of classes with annotation properties and no restrictions, then I have seen those be published as OWL and as SKOS with the same URIs. That does mean you should not mix the two, of course. 

Scenarios where either language might be used include supporting semantic/faceted search and where a class in an ontology has a property like “external classification” or “<x>_ category” or “<x>_group” (e.g. the property range is almost just an enumeration).

The topic of RDF/XML vs Turtle etc is another dimension, typically solved using HTTP content negotiation. All serialisations would be accessible from the same server URLs yet the server would return different results depending on what accept header the client requests.

Holger

On 6 Apr 2021, at 6:20 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

In case I have the same specification on different modelling levels:

• Skos
• Rdfs
• Rdfs+owl
• Rdfs+shacl

 

Is there some best practice  for the name space?

Question - Does the RDFS/OWL import and build on the RDFS? That seems logical to me so just wondering. Even the SHACL could import and build on the RDFS (and perhaps even the RDFS/OWL). That way the “class” would have the same URI all the time and you’d just be saying more/different things about it as the languages allow more to be said and the rationale for the different namespaces might be clarified a bit.

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9C404919-EDE6-4E6A-B1EA-98AB888E8E03%40topquadrant.com.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

In bold

 

 

om what Holger said and adding a question:

On 6 Apr 2021, at 12:22, Holger Knublauch <hol...@topquadrant.com> wrote:

 

Hi Michel,

 

First we should make sure that the users of your models understand the distinction between namespaces and graph URIs. You can of course use the same namespace (e.g., https://w3id.org/def/nen2660#) in multiple graphs. What you are probably referring to is the Graph URI under which the models will be downloaded from on the Web.

 

For the RDFS part, assuming this merely declares classes, properties and their relationships, I suggest they should be found at the URI that is like the namespace (except maybe without the #).

 

Yes, please don’t include the # as the idea of a fragment identifier is already confusing enough, not to mention the # vs / discussion.

 

Ø    Sure, I wont use a # (or /) in the name space

Then, the OWL version could be at a URI ending with nen2660-owl and the SHACL version could be at nen2660-shacl, and both would have owl:imports statements to the RDFS Graph URI.

 

If possible, perhaps see if you can use a server that handles file types so you don’t have to do the “different URI” thing. You may also consider making these available in an “online graph database” so classes, properties, etc. can be properly dereferenced and queried using SPARQL.

 

Ø    THAT is exactly the intended case: publish somewhere with content-negotiation for the serializations. But now the issue is not on the syntax but on different language-variants used. Ie should I have another uri for a skos:Concept Bridge and a rdfs:Class Bridge …. Or use the same uri having it differently typed in different ontologies….

 

Also, please remember:

 

- you’ll have users who do like me: I refuse to use RDF/XML as is about 3-5 times slower, far harder to read as a human and so the first thing I do with any RDF/XML encoding I get is convert it to TTL in Composer. If it’s giant I do occasionally use N-triples too.

 

Ø    Idea is Turtle and JSON-LD

 

- It is very misleading to have XML or JSON-LD in the URI of a graph stored as TTL 

 

Ø    Surely I will not do that. But again issue is now: should their be x-owl and x-shacl in the name…..

 

 

- and far more confusing to find one in a graph database which has no concept of file encoding at all.

 

What we usually do in customer projects is to use the nature of the artefact rather than the language as part of the namespace (actually also the folder structure in Composer). The use of different modelling languages can change the “meaning” (e.g. inferences) in some cases and not everything in the same language has the same nature. We usually start a project with an “Ontology Architecture” document/presentation (should have a better name since not all are ontologies) that defines these things so we have a common understanding from the outset.

 

I’m not aware of an industry best practice, but assuming the four you mention are all models of data, then we might use something like ‘taxonomy', ‘schema' (or 'data-model'?), ‘ontology' and ‘shapes'. As I mentioned, in most customer cases that is not the complete list because not all only OWL artefacts define an ontology (e.g. some are 'alignment-ontology' (aka ‘mapping') or even data-driven 'mappings' with a different purpose/nature) and some SHACL artefacts define ‘transforms’ (in the ETL sense), not ‘shapes' (again, a different purpose/nature).

 

Ø    For now we plan: SKOS, RDFS & SHACL

Ø    So the issue is:

Ø    Option1: one Bridge URI: nen2660:Bridge a skos:Concept in one, nen2660:Bridge a rdfs:Class in another and nen2600:Bridge a NodeShape in a third.

Ø    So the same bridge idea is typed in three ways…, where the prefix is always the same, or

Ø    Option2: same but now diff. prefix uri (…../nen2660-skos, …./nen2660-rdfs, ……nen2660-shacl) resulting in actually 3 bridge ideas…..(that can be related…ie a relation from the rdfs class to the skos concept via rdfs:seeAlso etc.)

 

I’m not aware of an industry best practice. I’m just explaining what we’ve found of practical value in customer projects where we use multiple language, where different artefacts in the same language play different roles and where the only folks involved are ourselves and the customer staff. That said, if I was to put a public project on GitHub for a standards community this is the approach I’d follow as IMO the “nature of the thing approach” helps implementors as well as ontologists.

 

Definitely document whatever you decide, in an easily noticed README at a minimum.

OWL is typically pretty strict about what is allowed in the models, e.g. to preserve the OWL DL logic.

On the other hand, SHACL is quite relaxed if a graph also contains OWL axioms - they will simply be ignored. So in theory the SHACL graph may owl:import the OWL version too.

 

Yes, see Q below.

 

 

Using owl:imports will make sure that declarations are not repeated across files, and therefore don’t risk running out of sync, e.g. if someone changes the RDFS classes only in one file.

 

 

Exactly! Maintenance is always a concern - and most people ignore it until it causes a huge problem later in life (unfortunately, too often in someone else’s life).

I don’t know enough about how the SKOS version is different to comment on that. I would find it rather confusing if a resource is a class in one graph but a SKOS concept in another.

 

The case where I regularly see this is if the artefact being defined is “master data” or a “reference data library”. If the OWL is really just a large hierarchy of classes with annotation properties and no restrictions, then I have seen those be published as OWL and as SKOS with the same URIs. That does mean you should not mix the two, of course. 

 

Ø    Hmmm not mixt: aren they just multiple typed: ie something is a skos concept, an rdfs class and a shack shape at the same time…or will that result in problems..?

 

Scenarios where either language might be used include supporting semantic/faceted search and where a class in an ontology has a property like “external classification” or “<x>_ category” or “<x>_group” (e.g. the property range is almost just an enumeration).

 

The topic of RDF/XML vs Turtle etc is another dimension, typically solved using HTTP content negotiation. All serialisations would be accessible from the same server URLs yet the server would return different results depending on what accept header the client requests.

 

Holger

 

On 6 Apr 2021, at 6:20 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

In case I have the same specification on different modelling levels:

• Skos
• Rdfs
• Rdfs+owl
• Rdfs+shacl

 

Is there some best practice  for the name space?

 

Question - Does the RDFS/OWL import and build on the RDFS? That seems logical to me so just wondering. Even the SHACL could import and build on the RDFS (and perhaps even the RDFS/OWL). That way the “class” would have the same URI all the time and you’d just be saying more/different things about it as the languages allow more to be said and the rationale for the different namespaces might be clarified a bit.

 

Ø    YES, that is what I would like….

Ø    People start in skos

Ø    Extend the skost concept in rdfs

Ø    Extend further in shacl for the constraints

Ø    All about the same bridge

Ø    So if I want that…what name space do I need for the concepts, classes and shapes (for the same thing)

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/0F9383B1-E7E6-484C-97DA-7AA0F8BB4F95%40topquadrant.com.

[Irene Polikoff]

There is definitely no problems for a resource to be both a class and a shape. In fact, this is very convenient and used by TopBraid by default. In SHACL specification it is discussed as implicit targeting.

As far as a resource being both a skos:Concept and a class and/or, potentially even a property - it depends. If people are using these resources as reference data and will never have instances, then, yes, it is better to have them as simply concepts, not classes. In this case, they should never use the SKOS graph with instances together with any of the graphs that define models. So, there should be no problems.

[David Price]

First, remember that SKOS is an ontology written using OWL - it’s not a language like OWL or SHACL. skos:Concept is itself an OWL class.  I’m 99% sure I read that SKOS is OWL Full which is part of why it shouldn’t be mixed with OWL over which you want to run a DL reasoner. 

We cannot say that mixing will *definitely* result in a problem in all cases since we don’t know what tools are to be used or exactly how they behave, but far safer to keep these things separate if DL reasoning tooling is meant to be enabled.  For example, taxonomy-based applications built using SKOS would not typically enable a DL reasoner to be run over the concept hierarchy so mixing is less of a problem in that scenario.

That said, reasoning issues could be avoided with sensible partitioning of the graphs containing the various statements so that the user can control whether the DL tool ever sees the skos. Graph partitioning is also an approach some use when they need pure OWL logic statements beyond DL, but can make use of a DL reasoner over a subset of their RDF.

Cheers,

David

--
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/31FFC7EA-C74F-4AB3-BEA5-0AEF86C1EAAA%40topquadrant.com.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Irene Polikoff]

To summarize, without knowing all the details of your plans and requirements, we recommend something along the following lines:

• Do not have separate graph URIs for serializations. It is the same graph, irrespective of the serialization. Your server should generate/provide different serializations.
• Do use separate graph URIs for graphs with different semantics that would target different software platforms and use cases:
• RDFS only graph - targeting environments that only support RDFS
• OWL graph - targeting environments that work with OWL, include in it RDFS graph, use the same URIs for classes and properties as RDFS
• SHACL graph - targeting environments that work with SHACL, you can include either RDFS or OWL graphs without any issues for such tools. I would simply make classes defined in the RDFS graph instances of node shapes.
• SKOS graph - targeting environments and use cases that are SKOS centric. 
• You have an option to use the same resource URIs as in the above graphs and simply give them a different type. In this case, do not include any of the graphs above. Depending on your use cases, keeping the URIs may be important e.g., these resources are used as reference data helping to connect things. There are many examples where you can find a graph with something like ex:s ex:snomed <URI of the SNOMED resource> and no other info about the SNOMED resource is available - only the incoming links. In other words, it is simply used as a shared term with no commitment to specific semantics.
• Or you could give the concepts different URIs. If so, you need to decide if you want to keep a link to the class and why. If yes, you have more decisions to make:
• Should you include any of the graphs above (if so, probably RDFS graph) or simply make a reference to the class resources using its URI?
• What property to use for linking? I think PROV has something like derivedFrom. You could also use skos:relatedMatch or rdfs:seeAlso or create your own property. EDG has edg:mapsToClass, edg:mapsToProperty and edg:mapsToPropertyShape. Note that sometimes properties also need to become concepts e.g., in the SKOS version of FIBO.
• Should you have a separate graph dedicated to just storing links? This would be something like EDG Crosswalks.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/B6CE685A-6339-4B3D-8113-7A4A21839D5A%40topquadrant.com.

[Bohms, H.M. (Michel)]

 

Dear Holger

 

One more question on this.

 

• Indeed serialization is other dimension related to server negotiation etc.
• Skos variant is special: totally different beasts (instance versus class etc.) so indeed separate namespace/prefix (we dicided for rdfs:isDefinedBy to make links between them; in practice you see many other relations used).
• Lets focus on name spaces for rdfs/owl/shacl variants, let’s assume variant: owl & shacl both importing rdfs (not: shacl importing owl)
• Even more focus: rdfs & shacl only (forget about owl for now)

Below you propose a different prefix/ns for the shacl-variant (nen2660-shacl).

 

Now the question. Would it be somehow possible to use the same name space for both rdfs and shacl?

(think you state that too below…)

 

So having two files/graphs having the same name space, one stating the rdfs stuff, the other the shacl.

 

Then I guess you need a mechanism to merge the two files/graphs other then owl:import (imports does not make sense since it is logical and the ontology would import itself)?

 

Thx again (for your patience…),

michel

 

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9C404919-EDE6-4E6A-B1EA-98AB888E8E03%40topquadrant.com.

[Holger Knublauch]

On 9/04/2021 6:31 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote:

 

Dear Holger

 

One more question on this.

 

• Indeed serialization is other dimension related to server negotiation etc.
• Skos variant is special: totally different beasts (instance versus class etc.) so indeed separate namespace/prefix (we dicided for rdfs:isDefinedBy to make links between them; in practice you see many other relations used).
• Lets focus on name spaces for rdfs/owl/shacl variants, let’s assume variant: owl & shacl both importing rdfs (not: shacl importing owl)
• Even more focus: rdfs & shacl only (forget about owl for now)

Below you propose a different prefix/ns for the shacl-variant (nen2660-shacl).

 

Now the question. Would it be somehow possible to use the same name space for both rdfs and shacl?

(think you state that too below…)

 

So having two files/graphs having the same name space, one stating the rdfs stuff, the other the shacl.

Yes we do this in our EDG namespace, which is split across dozens of files, but they all declare resources from the edg: namespace. Namespaces and graph URIs are relatively separate topics, so any graph can declare resources from any namespace.

 

Then I guess you need a mechanism to merge the two files/graphs other then owl:import (imports does not make sense since it is logical and the ontology would import itself)?

I don't understand this argument - we use owl:imports between the edg: files without problems.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2d7063d8c78e4ceeacf219a6efcd5ae5%40tno.nl.

[Bohms, H.M. (Michel)]

Ok,….my misunderstanding becomes clearer…😊

 

Typically i used up till now owl:imports referencing other name spaces

 

Do I understand now that the import can also be a (sub)graph/file saying something about a name space?

 

If both rdfs and shacl variant have name space say https://w3id.org/nen2660/def , what would the owl:imports statement look like in the shacl variant file?

 

 

Guess I used up till now some assumptions on name space uri versus graph uri that I now better have to differentiate….

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/88c0b9e2-43a1-8896-8014-eb9c6076748d%40topquadrant.com.

[David Price]

Hi Michel,

I

On 9 Apr 2021, at 09:52, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Ok,….my misunderstanding becomes clearer…😊

 

Typically i used up till now owl:imports referencing other name spaces

 

Do I understand now that the import can also be a (sub)graph/file saying something about a name space?

 

If both rdfs and shacl variant have name space say https://w3id.org/nen2660/def , what would the owl:imports statement look like in the shacl variant file?

Guess I used up till now some assumptions on name space uri versus graph uri that I now better have to differentiate….

I’ll simply a bit, but a good way to think about it is that the concept of the named graph (with name being a Graph URI) is actually what owl:imports references.  A named graph may define classes/properties that use any number of namespaces, made simpler by using prefixes for the namespaces.

A named graph with Graph URI like https://w3id.org/nen2660/shapes is not the same thing as a concept of Namespace URI like https://w3id.org/nen2660#.   From the Turtle Primer:

prefix rdfs:, namespace URI: http://www.w3.org/2000/01/rdf-schema#

Note that it calls the non-local name of a full URI a "namespace URI” so I should probably be doing that too.

Technically, there is zero relationship between the graph URI and namespace URI. The named graph can be http://anything.at.all and define classes and properties using http://michel.com# as the namespace URI. That much difference may confuse people, so it’s not usually recommended but it’s fine technically.

All the classes/properties of interest can then use the same namespace URI, even if they are managed in different named graphs

So,  https://w3id.org/nen2660#Class1 an rdfs:Class can be in  https://w3id.org/nen2660/schema graph and  https://w3id.org/nen2660#NodeShape2 a SHACL NodeShape can be in  https://w3id.org/nen2660/shapes graph. 

Both graphs as TTL would state 

@prefix nen2660: <https://w3id.org/nen2660#> . 

so you’d see nen2660:Class1 and nen2660:NodeShape2 and so things are is consistent wrt writing SPARQL queries, for example, over the schema/shapes and over the data.

Then https://w3id.org/nen2660/shapes owl:imports  https://w3id.org/nen2660/schema  so NodeShape2 can refer to Class1.

Tooling often supports a “Default Namespace” for a graph exactly to simplify the separation of the Graph URI from the namespace URI.

This separation also supports versions of ontologies. So, for example named graphs http://standard.iso.org/mystandard/edition1 and http://standard.iso.org/mystandard/edition2 

can both contain 

http://standard.iso.org/mystandard/MyClass a rdfs:Class .   

with no problem.

Cheers,

David

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location   <image001.gif> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8a9a60a8eb764b77b8ef459b1b2cf2e4%40tno.nl.

[Irene Polikoff]

Yes, exactly.

To simplify it even more:

• There are graphs and they have identity - graph URI. owl:imports statements refer to the graph URIs.
• A graph contains a set of triple statements about some resources. These resources also have identity - URIs of resources.
• URIs are formed by combining some namespace with a local name.
• There is no requirement for the namespace used to form the URI of a graph to be the same as the namespace(s) used to form URIs of resources that participate in the triple statements in a graph. 
• In many cases, it is a good practice for resources to use the same namespace as the graph - at least resources that are subjects in the triples contained in a graph. 
• However, there are also significant exceptions and you can see examples of this all over the place.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/BBA9F9BC-4FC5-41AF-82DA-D467A259BF5F%40topquadrant.com.

[Bohms, H.M. (Michel)]

Thx David /Irene for the explanations…

 

I never had the need to clearly differentiate the 2 types of uri’s.

 

An important ‘exception’ seems indeed when you want to somehow combine complementary rdfs/owl/shacl stuff for the same logical thing in different graphs (sep. of concerns).

 

I am writing a small piece of text on this for our nen2660 spec (that will be reused for cen tc442 SML).

I hope you can have a quick look soon to see if I understood you right.

 

Thx a lot! michel

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/DBA3E432-6A7A-488B-BF51-0D92A08B9604%40topquadrant.com.

[Bohms, H.M. (Michel)]

I forgot, one more subissue wrt the naming of the different graph uri’s involved:

 

https://w3id.org/nen2660/rdfs 

 

versus

 

https://w3id.org/nen2660-rdfs  

the latter also corresponding to the filename: nen2660-schema.ttl

 

any principle difference/pros/cons?

 

thx

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/BBA9F9BC-4FC5-41AF-82DA-D467A259BF5F%40topquadrant.com.

[Bohms, H.M. (Michel)]

Correction:

 

I forgot, one more subissue wrt the naming of the different graph uri’s involved:

 

https://w3id.org/nen2660/rdfs 

 

versus

 

https://w3id.org/nen2660-rdfs  

the latter also corresponding to the filename: nen2660-rdfs.ttl

 

any principle difference/pros/cons?

 

thx

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location   This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2562c82d85c24216862d659615a59a90%40tno.nl.

[David Price]

On 12 Apr 2021, at 11:04, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Correction:

 

I forgot, one more subissue wrt the naming of the different graph uri’s involved:

 

https://w3id.org/nen2660/rdfs 

 

versus

 

https://w3id.org/nen2660-rdfs  

the latter also corresponding to the filename: nen2660-rdfs.ttl

 

any principle difference/pros/cons?

Personally, I would use nen2660-rdfs.ttl in either case because if the TTL file gets separated from the "folder structure", then the name still matches and is clear. I map URIs into a folder structure to manage local RDF artefacts. For example, I have a folder called “standards” with sub-folders www.w3c.org, standard.iso.org, www.omg.org, etc. and make their sub-folder following the URI structure so  /<something>/ means a  sub-folder called ’something’. However, sometime you have to put things together and you want the filename itself to be “safe” to combine with graphs from other project/standards.

Cheers,

David

 

thx

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

<image001.gif> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

Van: 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> 
Verzonden: maandag 12 april 2021 11:36
Aan: topbrai...@googlegroups.com
Onderwerp: RE: [topbraid-users] best practise name space in multiple languages?

 

I forgot, one more subissue wrt the naming of the different graph uri’s involved:

 

https://w3id.org/nen2660/rdfs 

 

versus

 

https://w3id.org/nen2660-rdfs  

the latter also corresponding to the filename: nen2660-schema.ttl

 

any principle difference/pros/cons?

 

thx

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

<image001.gif> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8049a331cfb74aeda05450db476bb061%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

Thx David, I will follow that recommendation!

 

My piece of standards text + example now reads:

 

“

8.6 Combination of language bindings

 

In practice, there will often be a need for a combination of language bindings. In the most extensive case, this concerns (always 1 or more):

• SKOS scheme;
• RDFS (basic) ontology (importing the SKOS scheme);
• OWL ontology (importing the RDFS ontology);
• SHACL graph (importing the RDFS ontology).
  • FOOTNOTE: Could possibly also be the OWL ontology because SHACL simply ignores the OWL aspects. This is not the other way around: the OWL ontology should not import the SHACL graph because OWL is more strict.

Because a SKOS concept is very different from an ontology / graph element, it is important to keep them logically separated (with other 'name spaces') and to link them together.

This linking is done by means of the rdfs:isDefinedBy relationship. Because RDFS, OWL and SHACL cover complementary aspects, the same logical 'name space' can be used here.

Something can be typed at the same time as an rdfs:Class, an owl:Class and a sh:NodeShape. Its logical URI remains the same.

"Physically", they are always kept apart in separate files/graphs with their own file name / graph URI that is also used in the import statements.

 

When combining language bindings, it is therefore important to make a clear distinction between logical name space URIs (often abbreviated with prefixes) and the more physical graph URIs that are typed as an owl:Ontology (having single language bindings, these often coincide and a tool can generate a logical name space from the ontology URI).

 

Appendix C, the implementation of this standard, has been set up exactly according to these guidelines. An example of this for the combination SKOS, RDFS and SHACL:

 

In nen2660-skos.ttl:

 

@prefix nen2660-skos: <https://w3id.org/nen2600-skos/def#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://w3id.org/nen2660-skos a skos:ConceptScheme ;

  owl:imports <http://www.w3.org/2004/02/skos/core> .

nen2660-skos:PhysicalObject a skos:Concept ;

  skos:definition "Is something that possibly or actually exists in space and time, perceivable through the senses"@en ;

  skos:prefLabel "Physical object"@en .

In nen2660-rdfs.ttl:

 

@prefix nen2660: <https://w3id.org/nen2660/def#> .

@prefix nen2660-skos: https://w3id.org/nen2660-skos/def# .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://w3id.org/nen2660-rdfs/def> a owl:Ontology ;

  owl:imports <https://w3id.org/def/nen2660-skos> .

nen2660:PhysicalObject a rdfs:Class ;

  rdfs:isDefinedBy <https://w3id.org/nen2660-skos/def/PhysicalObject> .

In nen2660-shacl.ttl:

 

@prefix nen2660: <https://w3id.org/nen2660/def#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

@prefix sh: <http://www.w3.org/ns/shacl#> .

@prefix dash: <http://datashapes.org/dash#> .

<https://w3id.org/def/cbnl-shacl> a owl:Ontology ;

  owl:imports <https://w3id.org/nen2660-rdfs/def> ;

  owl:imports <http://datashapes.org/dash> .

nen2660:PhysicalObject a sh:NodeShape ;

  sh:property [

      sh:path nen2660:hasPart ;

      sh:or (

          [

            sh:class nen2660:PhysicalObject ;

          ]

          [

            sh:class rdfs:Container ;

          ]

        ) ;

    ] .

“

 

Thx for a final check! Michel

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/AEB78EA8-5B27-4A70-9AB0-EA3284937C73%40topquadrant.com.

[David Price]

On 12 Apr 2021, at 11:54, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Thx David, I will follow that recommendation!

 

My piece of standards text + example now reads:

 

“

8.6 Combination of language bindings

In my experience, a “language binding” is a set of the same general requirements expresses in different programming languages (e.g. Java and C++). I’d use the term “models” or perhaps “representations” rather than "language binding”. I’ve also seen cases where bodies publish both an OWL RDF Semantics/OWL Full and also an OWL Direct Semantics/OWL DL ontology for the same topic. That’s another reason not to distinguish only by “language binding” and use “representations” or “models”.

 

In practice, there will often be a need for a combination of language bindings. In the most extensive case, this concerns (always 1 or more):

• SKOS scheme;
• RDFS (basic) ontology (importing the SKOS scheme);
• OWL ontology (importing the RDFS ontology);

If you import RDFS, which imports SKOS then you have SKOS “OWL Full” visible in your OWL DL if that’s what you’ve defined, which could potentially cause reasoner issues. Maybe that’s not a concern in your usage scenario.

• SHACL graph (importing the RDFS ontology).
  • FOOTNOTE: Could possibly also be the OWL ontology because SHACL simply ignores the OWL aspects. This is not the other way around: the OWL ontology should not import the SHACL graph because OWL is more strict.

Because a SKOS concept is very different from an ontology / graph element, it is important to keep them logically separated (with other 'name spaces') and to link them together.

But from above and example below it seems SKOS is being imported.

This linking is done by means of the rdfs:isDefinedBy relationship.

Also, comparing “SKOS concept” and “ontology / graph element” sounds odd. Maybe …   “Because SKOS is an ontology itself, not a language, and is not designed for reasoning, it is recommended not to make SKOS visible in an OWL Ontology where a DL reasoner might be used. In these published representations (or models?), the relationship between a SKOS Concept and a related OWL Class representing the same “thing” is documented using rdfs:isDefinedBy."

Because RDFS, OWL and SHACL cover complementary aspects, the same logical 'name space' can be used here.

Something can be typed at the same time as an rdfs:Class, an owl:Class and a sh:NodeShape. Its logical URI remains the same.

"Physically", they are always kept apart in separate files/graphs with their own file name / graph URI that is also used in the import statements.

 

When combining language bindings, it is therefore important to make a clear distinction between logical name space URIs (often abbreviated with prefixes) and the more physical graph URIs that are typed as an owl:Ontology (having single language bindings, these often coincide and a tool can generate a logical name space from the ontology URI).

Suggest not adding more adjectives - IMO “logical” and “physical” are not really accurate. There is no such thing as a “logical name space” in RDF, there’s only a Namespace URI which is separate from a Graph URI, and the W3C specs explain those ideas just fine. When the audience is RDF-literate, I align my terminology with the standard terminology to avoid confusion. Just paraphrasing what the actual W3C spec says, is often a good idea - along with a reference/link to the spec in your document.

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/39ed8b97335846f9b56085613101b1fc%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

 

Thx David, see in red

 

On 12 Apr 2021, at 11:54, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

Thx David, I will follow that recommendation!

 

My piece of standards text + example now reads:

 

“

8.6 Combination of language bindings

 

In my experience, a “language binding” is a set of the same general requirements expresses in different programming languages (e.g. Java and C++). I’d use the term “models” or perhaps “representations” rather than "language binding”. I’ve also seen cases where bodies publish both an OWL RDF Semantics/OWL Full and also an OWL Direct Semantics/OWL DL ontology for the same topic. That’s another reason not to distinguish only by “language binding” and use “representations” or “models”.

 

Ø    See your point, but this is the terminology used so far. Mainly to differentiate between language variants on the one hand and formats/serialisations on the other.

Ø    Idea is to map an independent data language (having concepts, attributes, relations, constraints, …) to several specific concrete RDF-based languages like RDFS, OWL,… (others see also: XML/XSD, UML, JSON, etc.)

Ø    Furthermore: OWL. The L being from Language

 

In practice, there will often be a need for a combination of language bindings. In the most extensive case, this concerns (always 1 or more):

• SKOS scheme;
• RDFS (basic) ontology (importing the SKOS scheme);
• OWL ontology (importing the RDFS ontology);

 

If you import RDFS, which imports SKOS then you have SKOS “OWL Full” visible in your OWL DL if that’s what you’ve defined, which could potentially cause reasoner issues. Maybe that’s not a concern in your usage scenario.

•  
• SHACL graph (importing the RDFS ontology).

• FOOTNOTE: Could possibly also be the OWL ontology because SHACL simply ignores the OWL aspects. This is not the other way around: the OWL ontology should not import the SHACL graph because OWL is more strict.

Because a SKOS concept is very different from an ontology / graph element, it is important to keep them logically separated (with other 'name spaces') and to link them together.

 

But from above and example below it seems SKOS is being imported.

 

• Is there a way out? (think I have to import the skos scheme to be able to define the rdfs:isDefinedBy relations towards the concepts…???)
  
  

This linking is done by means of the rdfs:isDefinedBy relationship.

 

Also, comparing “SKOS concept” and “ontology / graph element” sounds odd. Maybe …   “Because SKOS is an ontology itself, not a language, and is not designed for reasoning, it is recommended not to make SKOS visible in an OWL Ontology where a DL reasoner might be used. In these published representations (or models?), the relationship between a SKOS Concept and a related OWL Class representing the same “thing” is documented using rdfs:isDefinedBy."

 

• Better ? : “skos:Concept instance” iso “SKOS concept”

 

Because RDFS, OWL and SHACL cover complementary aspects, the same logical 'name space' can be used here.

Something can be typed at the same time as an rdfs:Class, an owl:Class and a sh:NodeShape. Its logical URI remains the same.

"Physically", they are always kept apart in separate files/graphs with their own file name / graph URI that is also used in the import statements.

 

When combining language bindings, it is therefore important to make a clear distinction between logical name space URIs (often abbreviated with prefixes) and the more physical graph URIs that are typed as an owl:Ontology (having single language bindings, these often coincide and a tool can generate a logical name space from the ontology URI).

 

Suggest not adding more adjectives - IMO “logical” and “physical” are not really accurate. There is no such thing as a “logical name space” in RDF, there’s only a Namespace URI which is separate from a Graph URI, and the W3C specs explain those ideas just fine. When the audience is RDF-literate, I align my terminology with the standard terminology to avoid confusion. Just paraphrasing what the actual W3C spec says, is often a good idea - along with a reference/link to the spec in your document.

 

• Ok, I’ll stick to Namespace URI versus Graph URI only

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/DC46D67A-9480-4B01-B7BB-3F36D258889A%40topquadrant.com.

[Irene Polikoff]

Agree with David’s comments. I would change

Because a SKOS concept is very different from an ontology / graph element, it is important to keep them logically separated (with other 'name spaces') and to link them together.

This linking is done by means of the rdfs:isDefinedBy relationship. Because RDFS, OWL and SHACL cover complementary aspects, the same logical 'name space' can be used here.

Something can be typed at the same time as an rdfs:Class, an owl:Class and a sh:NodeShape. Its logical URI remains the same.

"Physically", they are always kept apart in separate files/graphs with their own file name / graph URI that is also used in the import statements.

To

Because the semantic intent of the SKOS concepts is fundamentally different from that of the ontological/schema resources that describe shape of the data and/or serve as the basis for reasoning over data, it is important to keep URIs of the SKOS concepts distinct from the URIs of the similarly named schema resources by using a different namespace. For reference,  SKOS concepts are linked to the corresponding ontology resources using the rdfs:isDefinedBy relationship.

Because RDFS, OWL and SHACL are not fundamentally different and cover complementary aspects of defining semantics, the same URIs can be used for resources defined using RDFS only, RDFS plus OWL and RDFS plus SHACL. A resource can be typed at the same time as an rdfs:Class, an owl:Class and a sh:NodeShape. The ontologies represented in RDFS, OWL and SHACL are captured in their own graphs and can, therefore, be used independently from each other. 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/DC46D67A-9480-4B01-B7BB-3F36D258889A%40topquadrant.com.

[David Price]

On 12 Apr 2021, at 13:49, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

Thx David, see in red

 

On 12 Apr 2021, at 11:54, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

Thx David, I will follow that recommendation!

 

My piece of standards text + example now reads:

 

“

8.6 Combination of language bindings

 

In my experience, a “language binding” is a set of the same general requirements expresses in different programming languages (e.g. Java and C++). I’d use the term “models” or perhaps “representations” rather than "language binding”. I’ve also seen cases where bodies publish both an OWL RDF Semantics/OWL Full and also an OWL Direct Semantics/OWL DL ontology for the same topic. That’s another reason not to distinguish only by “language binding” and use “representations” or “models”.

 

Ø    See your point, but this is the terminology used so far. Mainly to differentiate between language variants on the one hand and formats/serialisations on the other.

Ø    Idea is to map an independent data language (having concepts, attributes, relations, constraints, …) to several specific concrete RDF-based languages like RDFS, OWL,… (others see also: XML/XSD, UML, JSON, etc.)

Ø    Furthermore: OWL. The L being from Language

I understand the intent. As I mentioned, I’ve seen many bodies/organisations do this and am reporting the terminology I’ve seen (and what I’ve used when making standards). The use I’ve seen for this term is closer to the definition in Wikipedia (https://en.wikipedia.org/wiki/Language_binding). Of course, feel free to ignore any advance. What is important is that your audience understands, perhaps because you’ve defined your definition of that term somewhere.

 

In practice, there will often be a need for a combination of language bindings. In the most extensive case, this concerns (always 1 or more):

• SKOS scheme;
• RDFS (basic) ontology (importing the SKOS scheme);
• OWL ontology (importing the RDFS ontology);

 

If you import RDFS, which imports SKOS then you have SKOS “OWL Full” visible in your OWL DL if that’s what you’ve defined, which could potentially cause reasoner issues. Maybe that’s not a concern in your usage scenario.

•  
• SHACL graph (importing the RDFS ontology).

• FOOTNOTE: Could possibly also be the OWL ontology because SHACL simply ignores the OWL aspects. This is not the other way around: the OWL ontology should not import the SHACL graph because OWL is more strict.

Because a SKOS concept is very different from an ontology / graph element, it is important to keep them logically separated (with other 'name spaces') and to link them together.

 

But from above and example below it seems SKOS is being imported.

 

• Is there a way out? (think I have to import the skos scheme to be able to define the rdfs:isDefinedBy relations towards the concepts…???)
  

I may have misunderstood your use of this predicate. I checked the W3C spec and it says:

5.4.2 rdfs:isDefinedBy

rdfs:isDefinedBy is an instance of rdf:Property that is used to indicate a resource defining the subject resource. This property may be used to indicate an RDF vocabulary in which a resource is described.

A triple of the form:

S rdfs:isDefinedBy O

states that the resource O defines S. It may be possible to retrieve representations of O from the Web, but this is not required. When such representations may be retrieved, no constraints are placed on the format of those representations. rdfs:isDefinedBy is a subproperty of rdfs:seeAlso.

The rdfs:domain of rdfs:isDefinedBy is rdfs:Resource. The rdfs:range of rdfs:isDefinedBy is rdfs:Resource.

So, are you referencing the Graph URI of the OWL graph from the RDFS, for example? If so, it’s just copy and paste of the URI for that value. If not (i.e. it is Concept -> Class), then this is perhaps a slightly unexpected use of that property although the spec does say “may”.  FWIW if the Concept and Class URIs are the same, is any link between them actually needed?

I looked more closely at the example below, and am confused. I see:

@prefix nen2660-skos: <https://w3id.org/nen2600-skos/def#> .

<https://w3id.org/nen2660-skos a skos:ConceptScheme ;
  owl:imports <http://www.w3.org/2004/02/skos/core> .
nen2660-skos:PhysicalObject a skos:Concept ;

And

@prefix nen2660: <https://w3id.org/nen2660/def#> .

<https://w3id.org/nen2660-rdfs/def> a owl:Ontology ;
  owl:imports <https://w3id.org/def/nen2660-skos> .
nen2660:PhysicalObject a rdfs:Class ;

Which shows there are two different URIs for the idea of a “PhysicalObject” in  SKOS and OWL. If you never mix the two, then I don’t think that’s needed. I know Holger thought that was odd, but I think in your specific usage scenario it makes sense as you just consider these as different “language bindings” for various statements about exactly the same “thing”.

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/36df2c1c09724cf0a89deba0bf186c74%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

Wrt to final remark:

 

 

The whole idea is that there are 2 URIs: one for the skos:Concept instance and o0ne for the rdfs/owl:CXlass instance (or sh:NodeShape)…..

 

And these can be related via rdfs:isDefinedBy

 

Like in the example: in the rdfs variant:

 

nen2660:PhysicalObject a rdfs:Class ;

  rdfs:isDefinedBy <https://w3id.org/nen2660-skos/def/PhysicalObject> .

 

of even better (changed that):

 

nen2660:PhysicalObject a rdfs:Class ;

  rdfs:isDefinedBy nen2660-skos:PhysicalObject .

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/57BDC353-C7F6-4541-AED3-80ECD02B6EC2%40topquadrant.com.

[Bohms, H.M. (Michel)]

Thx changed that (incl. inverse google translate NL 😊)

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/DAE16A3C-00D3-4A88-9F8A-A0652305759F%40topquadrant.com.

[Bohms, H.M. (Michel)]

Small ones related, just checking

 

1

A baseURI (line 1 comment) is a synonym for a graph URI, right ? (no subtle difference?)

 

2

File names are completely independent from graph uris (/ name space uris), right?

 

(maybe making things dereferenceable ie identification becoming localization is all in the mapping right?)

 

 

Thx again, michel

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/e377e2f556084c8f9302cb8cbdd61827%40tno.nl.

[Holger Knublauch]

On 13 Apr 2021, at 5:28 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Small ones related, just checking

 

1

A baseURI (line 1 comment) is a synonym for a graph URI, right ? (no subtle difference?)

Yes, the #baseURI comment in Turtle files is TopBraid’s convention so that it doesn’t need to scan the whole file to learn the graph URI.

 

2

File names are completely independent from graph uris (/ name space uris), right?

Yes, although usually the main part of the file name resembles the last segment of the graph URI.

 

(maybe making things dereferenceable ie identification becoming localization is all in the mapping right?)

Yes, usually the content negotiation allows you to map different file names.

Holger

 

 

Thx again, michel

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

<image001.gif> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

Van: 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> 
Verzonden: maandag 12 april 2021 16:05
Aan: topbrai...@googlegroups.com
Onderwerp: RE: [topbraid-users] best practise name space in multiple languages?

 

Thx changed that (incl. inverse google translate NL 😊)

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

<image001.gif> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/635b4ea3d4f24369a58d1bcc758a61f7%40tno.nl.

[Bohms, H.M. (Michel)]

Thx all clear!

 

For 2: that does not hold in my case because of the “def” fragment…but I guess not an issue…

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/215DAC52-0B62-451A-B9A9-E35ED986BBD0%40topquadrant.com.

[Bohms, H.M. (Michel)]

I forgot one, well a one earlier discussed that I do not understand 😊

 

David you said earlier: when importing a skos scheme in an owl ontology this makes the owl, owl full (if I am right) influencing the reasoning etc.

 

But if we use diff name space uris, the same resources are not becoming an instance (of skos:Concept) AND a class, so there is no ‘owl punning’ situation.

 

Why do we still obtain OWL Full then?

 

Ps

In https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html

 

It says: This pattern effectively treats SKOS and OWL universes as separate, and uses a completely separate vocabulary in each case. Because it does this, it is compatible with OWL DL.

 

This pattern involves another name (mountainclass) iso using another name space uri….isnt the effect the same? Ie isn’t it just another way to not “crossing the SKOS and OWL streams” as they call it there?

 

I would hope that having a diff name space would be  a better way of making the name space uri different than changing the actual name (X skos concept and xClass class feels a bit clumsy)

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Holger Knublauch

Verzonden: dinsdag 13 april 2021 09:35

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/215DAC52-0B62-451A-B9A9-E35ED986BBD0%40topquadrant.com.

[David Price]

Hi Michel,

First, the SKOS standard actually says it is OWL Full:

https://www.w3.org/TR/skos-reference/

The SKOS data model is formally defined in this specification as an OWL Full ontology [OWL-SEMANTICS]. SKOS data are expressed as RDF triples [RDF-CONCEPTS], and may be encoded using any concrete RDF syntax (such as RDF/XML [RDF-XML] or Turtle [TURTLE]). For more on the relationships between SKOS, RDF and OWL, see the next sub-section below.

I did not try to figure out why, just taking the spec at its word.

I decided to try and understand more about this scenario before commenting more so made a tiny example, and it did not clear things up for me. So, apologies for the long email and I don’t expect a reply. Just wanted to point out how confusing this scenario is to me and suggest that others may also be confused.

It seems the idea is that there is single “thing/idea/set” represented by an instance of SKOS Concept and a different instance that is an OWL Class. What does that mean to a human? To a machine? How would users be instructed to use them together in this scenario? What’s the added value? 

I made a little ontology where a PhysicalObject isPartOf PhysicalObject - with the related skos.

Let’s assume there are two kinds of PhysicalObject. Then you get this I assume:

I assume SKOS imported into OWL means you’re making instances of OWL classes in an an OWL-based tool, with the SKOS imported, and so I make a car with an engine that are instances of the OWL Classes, and use isPartOf. Don’t know if there is also a parallel set of relations in the SKOS version or not (not in my example). 

As you can see, the SKOS concepts add a parallel set of instances that that have an annotation relation to the classes. Is it being suggested to make EngineAA also rdf:type nen-skos:Engine? If so, the OWL reasoner thinks the Engine Concept and the Engine Class are completely unrelated. <x> rdf:type <Concept> will tell it to infer <Concept> rdf:type OWL Class, so add nen-skos:Engine rdf:type owl:Class in this case. The reasoner does not know about skos:broader so does not go up the hierarchy to find other possible properties, etc. Looking at this example, I do not think the DL reasoner will “complain”, just pun, but I can’t see how it can do anything useful with the Concepts, so to me the value remains unclear from a technical/tool point of view. 

FWIW if the <Concept> rdf:type OWL Class gets stored when other “useful” inferences get stored, then there will be two classes with the same labels, etc. but different URIs. I’ll guess that users of any model-driven app will have problems when that happens (e.g. they’ll see “duplicated” classes), and the specific set of classes the see will vary depending on the actual instances of data that exist when the inference happens. Different datasets based on the same ontology behaving differently sounds confusing to users.

I guess I can see some added value if there’s a lot of human documentation in the SKOS that is not in the OWL and doing this means a tool can show that to the human (i.e. using the SKOS as a dictionary, not a model). Note that if that’s the idea, then the isDefinedBy is better if in the reverse direction … the Class isDefinedBy the Concept. I do not think that’s the plan though from the discussion. 

I guess you could SPARQL over this structure and show OWL instance of classes as if they were instances of the nen-skos Concepts, but again what’s the value of that? Why not just query the Classes directly?

If you read the SKOS spec there are good documentation sections about relation to OWL, etc. It does say you can use SKOS and OWL together, but that the SKOS is in no way a knowledge representation of a domain of discourse. What it does say is:

To make the "knowledge" embedded in a thesaurus or classification scheme explicit in any formal sense requires that the thesaurus or classification scheme be re-engineered as a formal ontology. In other words, some person has to do the work of transforming the structure and intellectual content of a thesaurus or classification scheme into a set of formal axioms and facts. This work of transformation is both intellectually demanding and time consuming, and therefore costly. Much can be gained from using thesauri, etc., as-is, as informal, convenient structures for navigation within a subject domain. Using them as-is does not require any re-engineering and is therefore much less costly. In addition, some KOS are, by design, not intended to represent a logical view of their domain. Converting such KOS to a formal logic-based representation may, in practice, involve changes which result in a representation that no longer meets the originally intended purpose. 

Maybe the audience for these various language bindings are developers of advanced semantic/linked data applications and can make use of this combination of artefacts. However, it seems the “intellectually demanding and time consuming” work of making an ontology is something you’ve already done, and in that case the SKOS is not really useful except perhaps as documentation for human consumption. If that’s the case, could you not just copy the documentation into the ontology to get that value?

I’ve not been part of a project that used this approach, so perhaps there’s something I don’t understand and that’s fine. However, I will suggest being sure your user community does understand as IMO this is not a simple idea and seems to result in some odd potential problems.

If a decision has been made to do this, I suggest several very complete example datasets be created to show the user community how this idea is to be used and how the pieces are supposed to fit together, along with some good words to explain the added value.  Also, I suggest running reasoners over those examples and saving the inferences to show users/developers the results.

Cheers,

David

On 13 Apr 2021, at 09:09, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

I forgot one, well a one earlier discussed that I do not understand 😊

 

David you said earlier: when importing a skos scheme in an owl ontology this makes the owl, owl full (if I am right) influencing the reasoning etc.

 

But if we use diff name space uris, the same resources are not becoming an instance (of skos:Concept) AND a class, so there is no ‘owl punning’ situation.

 

Why do we still obtain OWL Full then?

 

Ps

In https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html

 

It says: This pattern effectively treats SKOS and OWL universes as separate, and uses a completely separate vocabulary in each case. Because it does this, it is compatible with OWL DL.

 

This pattern involves another name (mountainclass) iso using another name space uri….isnt the effect the same? Ie isn’t it just another way to not “crossing the SKOS and OWL streams” as they call it there?

 

I would hope that having a diff name space would be  a better way of making the name space uri different than changing the actual name (X skos concept and xClass class feels a bit clumsy)

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8394546a74ad462291a4d2ffcefa6fad%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Irene Polikoff]

Here is some related discussion http://ceur-ws.org/Vol-432/owled2008eu_submission_22.pdf

In addition to notes, I suspect the range of SKOS:memberList property to be an issue.

In my experience, however, people do not intentionally use SKOS and OWL representation of the same concepts together. Rather, a SKOS version is provided for tools that can’t deal with ontologies but may need to use a simple thesaurus/taxonomy e.g., for document tagging and search.

On Apr 13, 2021, at 8:02 AM, David Price <dpr...@topquadrant.com> wrote:



Hi Michel,

First, the SKOS standard actually says it is OWL Full:

https://www.w3.org/TR/skos-reference/

The SKOS data model is formally defined in this specification as an OWL Full ontology [OWL-SEMANTICS]. SKOS data are expressed as RDF triples [RDF-CONCEPTS], and may be encoded using any concrete RDF syntax (such as RDF/XML [RDF-XML] or Turtle [TURTLE]). For more on the relationships between SKOS, RDF and OWL, see the next sub-section below.

I did not try to figure out why, just taking the spec at its word.

I decided to try and understand more about this scenario before commenting more so made a tiny example, and it did not clear things up for me. So, apologies for the long email and I don’t expect a reply. Just wanted to point out how confusing this scenario is to me and suggest that others may also be confused.

It seems the idea is that there is single “thing/idea/set” represented by an instance of SKOS Concept and a different instance that is an OWL Class. What does that mean to a human? To a machine? How would users be instructed to use them together in this scenario? What’s the added value? 

I made a little ontology where a PhysicalObject isPartOf PhysicalObject - with the related skos.

<Screen Shot 2021-04-13 at 10.55.04.png>

Let’s assume there are two kinds of PhysicalObject. Then you get this I assume:

<Screen Shot 2021-04-13 at 11.11.53.png>

I assume SKOS imported into OWL means you’re making instances of OWL classes in an an OWL-based tool, with the SKOS imported, and so I make a car with an engine that are instances of the OWL Classes, and use isPartOf. Don’t know if there is also a parallel set of relations in the SKOS version or not (not in my example). 

<Screen Shot 2021-04-13 at 11.16.09.png>

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/DDD14342-04A0-4EB0-8F0F-250C3A0D64BC%40topquadrant.com.

[Bohms, H.M. (Michel)]

Thx

wrt intentions: think earlier link: https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html

Gives clues in two directions.

 

(Their “solution” however having skos:Concept X and rdfs:Class Xclass (to keep stream separate) feels unnatural.

Hence a same name but diff. name space  to obtain different name space uris feels more logical.)

 

Will study your link, I like already the title 😊

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/65AAACBF-4D18-4097-A9A8-9C8AD1463FDD%40topquadrant.com.

[Bohms, H.M. (Michel)]

Thx for you extensive considerations!

 

1. You say: “It seems the idea is that there is single “thing/idea/set” represented by an instance of SKOS Concept and a different instance that is an OWL Class. What does that mean to a human? To a machine? How would users be instructed to use them together in this scenario? What’s the added value? “

 

Well, this is what we see a lot in practice! People are making thesauri and other people are making more semantic structures. The first group of people do not need all the rdfs/owl/shacl knowledge and can focus on the terms used in the domain. The other way round people can make owl ontologies for reasoning, shacl for data verifications and still reuse the same terms/definitions/skos-examples etc. The right separation of concerns so to say.

 

So in nen/cen we want to define common patterns for people to do it in the same way. Promote splitting skos/rdfs/owl/shacl for instance and relate them in common ways.

 

For instance: we tell them: use rdfs:isDefinedBy to relate a class to a skos concept (where the definition can be found). You actually used it the other way round in your example. Guess also possible…but good to agree.

 

2. You say: Is it being suggested to make EngineAA also rdf:type nen-skos:Engine?

No for skos we focus on terms for classes/shapes: no individuals (well, only reference individuals we use for enumeration type items). In the latter case we use skos:broader not rdf:type.

 

3. You say: I guess I can see some added value if there’s a lot of human documentation in the SKOS that is not in the OWL and doing this means a tool can show that to the human (i.e. using the SKOS as a dictionary, not a model). Note that if that’s the idea, then the isDefinedBy is better if in the reverse direction … the Class isDefinedBy the Concept. I do not think that’s the plan though from the discussion. 

That is exactly the idea!

 

4. You say: I guess you could SPARQL over this structure and show OWL instance of classes as if they were instances of the nen-skos Concepts, but again what’s the value of that? Why not just query the Classes directly?

Yes that is the way we foresee: the rdfs/owl/shacl will not have say skos:prefLabel and skos:definition….its split off in the skos scheme part that is maximally reused.

5. You say: Maybe the audience for these various language bindings are developers of advanced semantic/linked data applications and can make use of this combination of artefacts. However, it seems the “intellectually demanding and time consuming” work of making an ontology is something you’ve already done, and in that case the SKOS is not really useful except perhaps as documentation for human consumption. If that’s the case, could you not just copy the documentation into the ontology to get that value?

Well, I just see it happening in practice. And I can see the point: clearly splitting the term-stuff from the semantic stuff, it gives maybe some more right focus to people. So that is why we also want to support this separation in the nen/cen.

On the other hand, I agree with you, when starting semantic and adding the definition, examples, labels, etc. all there could also work.

Seems there could be some FULLish trouble introduced so I will further investigate with Irene’s link.

 

Thx again michel

 

 

 

 

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/DDD14342-04A0-4EB0-8F0F-250C3A0D64BC%40topquadrant.com.

[Bohms, H.M. (Michel)]

Hi Irene, David,

 

I had  a look at the paper you mentioned below, some observations:

 

1.

OWL is OWL1 (given 2008) so the owl punning situation might be different now (more is allowed)

 

2. As indicated there, the OWLfullness comes from properties that can be datatype and object property at the same time.

It’s a bit unclear for me how that exactly works, guess related too forms like:

 

“

skos:member

  rdf:type rdf:Property ;

  rdf:type owl:ObjectProperty ;

…”

 

Or indeed maybe even worse:

 

“

skos:memberList

  rdf:type rdf:Property ;

  rdf:type owl:FunctionalProperty ;

  rdf:type owl:ObjectProperty ;

…“

 

On the other hand I would say: both state it is an object property, not that is can be a datatypeproperty….or aren’t those disjuct perse ? so that the rdf:property typing can still make it an datatype property?

 

3.

Anyway, it seems “our” solution is also here the typical way out. Keeping skos and non-skos stuff separate. Ie not using the special skos properties at the non-skos class level violating the owl punning rules to stay within owl-dl. Now also having different namespaces for skos and non-skos (th: and on:), and not different names as in my reference earlier (X and Xclass).

They propose an skos:as i.s.o. rdfs:isDefinedBy (in the inverse direction) to relate the worlds.

(that one never made it)

 

So thx for the link, although not fully clear is strengthens me that there are indeed use cases and that there are solutions…and that our solution seems not that bad.

 

Finally jus FYI a latest update of the section planned for cen-sml (“nen2660” still to be replaced by “sml”):

 

“

x.y  Combination of language bindings

 

In practice, there will often be a need for a combination of language bindings. In the most extensive case, this concerns (always 1 or more):

• SKOS concept scheme;
• RDFS (basic) ontology (imports the SKOS concept scheme);
• OWL ontology (imports the RDFS ontology);
• SHACL graph (imports the RDFS ontology).

Since the semantic intent of the SKOS concepts is fundamentally different from that of the ontological resources describing the semantics of the data and/or serving as the basis for reasoning about data, it is important to distinguish the name space URIs from the SKOS concepts of the name space URIs of the ontology resources by using a different name space. The ontological items are linked to the corresponding SKOS items using the existing rdfs:isDefinedBy relationship.

 

Since RDFS, OWL and SHACL are not fundamentally different and cover complementary semantic aspects, the same name space URIs can be used mutually for resources defined 1) with RDFS only, 2) with RDFS plus OWL and 3) with RDFS plus SHACL. A resource can be typed as an rdfs:Class, an owl:Class and a sh:NodeShape at the same time. The ontologies represented in RDFS, OWL and SHACL are recorded in their own graphs with their own graph URI and can therefore be used independently of each other and import each other.

 

When combining language bindings, it is therefore important to make a good distinction between 'name space URIs' (often abbreviated with prefixes) and 'graph URIs' (also known as base URIs) that can be characterized as an owl:Ontology (in case of single language binding “name space URIs” and “graph URIs” are often the same and a tool can, for example, generate a “name space URI” from a “graph URI” as the default name space).

 

Filenames are totally independent of the name space and count URIs.

 

Appendix X, the Linked Data implementation of this standard, has been set up exactly according to these guidelines. An example of this for the combination SKOS, RDFS and SHACL (in Turtle format):

 

In nen2660-skos.ttl:

 

@prefix nen2660-vocab: <https://w3id.org/nen2600/vocab#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://w3id.org/nen2660/vocab> a skos:ConceptScheme ;

  owl:imports <http://www.w3.org/2004/02/skos/core> .

nen2660-vocab:PhysicalObject a skos:Concept ;

  skos:definition "Is something that possibly or actually exists in space and time, perceivable through the senses"@en ;

  skos:prefLabel "Physical object"@en .

In nen2660-rdfs.ttl:

 

@prefix nen2660: <https://w3id.org/nen2660/def#> .

@prefix nen2660-skos: <https://w3id.org/nen2660/vocab#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://w3id.org/nen2660-rdfs/def> a owl:Ontology ;

  owl:imports <https://w3id.org/def/nen2660/vocab> .

nen2660:PhysicalObject a rdfs:Class ;

  rdfs:isDefinedBy nen2660-vocab:PhysicalObject .

In nen2660-shacl.ttl:

 

@prefix nen2660: <https://w3id.org/nen2660/def#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

@prefix sh: <http://www.w3.org/ns/shacl#> .

@prefix dash: <http://datashapes.org/dash#> .

<https://w3id.org/nen2660-shacl/def> a owl:Ontology ;

  owl:imports <https://w3id.org/nen2660-rdfs/def> ;

  owl:imports <http://datashapes.org/dash> .

nen2660:PhysicalObject a sh:NodeShape ;

  sh:property [

      sh:path nen2660:hasPart ;

      sh:or (

          [ sh:class nen2660:PhysicalObject ; ]

          [ sh:class rdfs:Container ; ]

        ) ;

    ] .

“

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability

T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Irene Polikoff

Verzonden: dinsdag 13 april 2021 15:07

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/65AAACBF-4D18-4097-A9A8-9C8AD1463FDD%40topquadrant.com.

[David Price]

On 14 Apr 2021, at 08:54, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Hi Irene, David,

 

I had  a look at the paper you mentioned below, some observations:

 

1.

OWL is OWL1 (given 2008) so the owl punning situation might be different now (more is allowed)

 

2. As indicated there, the OWLfullness comes from properties that can be datatype and object property at the same time.

It’s a bit unclear for me how that exactly works, guess related too forms like:

 

“

skos:member

  rdf:type rdf:Property ;

  rdf:type owl:ObjectProperty ;

…”

 

Or indeed maybe even worse:

 

“

skos:memberList

  rdf:type rdf:Property ;

  rdf:type owl:FunctionalProperty ;

  rdf:type owl:ObjectProperty ;

…“

 

On the other hand I would say: both state it is an object property, not that is can be a datatypeproperty….or aren’t those disjuct perse ? so that the rdf:property typing can still make it an datatype property?

 

3.

Anyway, it seems “our” solution is also here the typical way out. Keeping skos and non-skos stuff separate. Ie not using the special skos properties at the non-skos class level violating the owl punning rules to stay within owl-dl. Now also having different namespaces for skos and non-skos (th: and on:), and not different names as in my reference earlier (X and Xclass).

They propose an skos:as i.s.o. rdfs:isDefinedBy (in the inverse direction) to relate the worlds.

(that one never made it)

 

So thx for the link, although not fully clear is strengthens me that there are indeed use cases and that there are solutions…and that our solution seems not that bad.

IMO the use cases in that link are not like your situation. This still looks to me like a solution looking for a problem. You’ve created the ontologies, there is a one-to-one class/concept mapping and so the SKOS really adds nothing to apps using the ontology. FWIW removing the SKOS import is the first thing I would do if asked to provide an implementation of these models in EDG in a customer project as it would just confuse our model-driven app users.

 

Finally jus FYI a latest update of the section planned for cen-sml (“nen2660” still to be replaced by “sml”):

 

“

x.y  Combination of language bindings

 

In practice, there will often be a need for a combination of language bindings. In the most extensive case, this concerns (always 1 or more):

• SKOS concept scheme;
• RDFS (basic) ontology (imports the SKOS concept scheme);

Note that SKOS is an OWL ontology, and so this makes whatever you import SKOS into at least owl-like (i.e. the content of this combination is no longer only RDFS).

• OWL ontology (imports the RDFS ontology);
• SHACL graph (imports the RDFS ontology).

Since the semantic intent of the SKOS concepts is fundamentally different from that of the ontological resources describing the semantics of the data and/or serving as the basis for reasoning about data, it is important to distinguish the name space URIs from the SKOS concepts of the name space URIs of the ontology resources by using a different name space. The ontological items are linked to the corresponding SKOS items using the existing rdfs:isDefinedBy relationship.

 

Since RDFS, OWL and SHACL are not fundamentally different and cover complementary semantic aspects, the same name space URIs can be used mutually for resources defined 1) with RDFS only, 2) with RDFS plus OWL and 3) with RDFS plus SHACL. A resource can be typed as an rdfs:Class, an owl:Class and a sh:NodeShape at the same time. The ontologies represented in RDFS, OWL and SHACL are recorded in their own graphs with their own graph URI and can therefore be used independently of each other and import each other.

 

When combining language bindings, it is therefore important to make a good distinction between 'name space URIs' (often abbreviated with prefixes) and 'graph URIs' (also known as base URIs) that can be characterized as an owl:Ontology

(in case of single language binding “name space URIs” and “graph URIs” are often the same and a tool can, for example, generate a “name space URI” from a “graph URI” as the default name space).

Usually, these are different e.g. the Graph URI is http://a.b.c/schema and the Namespace then adds a # or a / 

I find the practice of making them the same value very confusing to people, as they then think Namespace URI and Graph URI are the same concept. I would NOT write in a README anything giving people the idea that’s a good idea.

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/5769bff159c04bfda4cfa95845f759d2%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[David Price]

Hi TB users,

The discussion with Michel caused a question to pop into my mind and I hope to get some customer feedback here.

I see customers/bodies use SKOS to define what turn out to be simple lists of standard class instances that are then used in an ontology. My question is - Why?

OWL enumerated classes provide the same standard-instance capability, but without the added “clutter” in your ontology when you import SKOS. The number of completely empty, never-to-be-used cases of Collection, Concept Scheme, etc. appearing as classes in ontologies has become surprising to me.

Can anyone who’s been part of making this kind of decision in your ontologies please explain Why?  Among other possible reasons, a few I could think of might be:

• Is it that the UI for creating them is simpler?
• Is it that these standard instances are seen as being somehow improved by having a not-well-defined tree structure available via broader/narrower?
• Is it that you’re using a standard that’s done this and you’d be happy with any solution that supports defining standard instances? i.e. perhaps a SKOS-to-enumerated-class importer for these situations would be a useful tool?
• Is that you really have use cases like described here: https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html. ?
• Is it really just that you prefer/need the SKOS annotation properties, even for classes, instances, etc? (I like them and have local a skos-annotations-only.ttl I reuse)

We are always looking for real-world user scenarios wrt improving EDG, and so you can also think of this as a requirements gathering/feature request exercise.

It may be there are some EDG feature or UI changes we could make. It may be that a How-To video on our Web site explaining this approach and how to best execute it in EDG would be useful. I don’t know but thought it worth asking the requirements question to see how prevalent this is and why it happens.

Cheers,

David

“

x.y  Combination of language bindings

 

In practice, there will often be a need for a combination of language bindings. In the most extensive case, this concerns (always 1 or more):

• SKOS concept scheme;
• RDFS (basic) ontology (imports the SKOS concept scheme);
• OWL ontology (imports the RDFS ontology);
• SHACL graph (imports the RDFS ontology).

Since the semantic intent of the SKOS concepts is fundamentally different from that of the ontological resources describing the semantics of the data and/or serving as the basis for reasoning about data, it is important to distinguish the name space URIs from the SKOS concepts of the name space URIs of the ontology resources by using a different name space. The ontological items are linked to the corresponding SKOS items using the existing rdfs:isDefinedBy relationship.

 

Since RDFS, OWL and SHACL are not fundamentally different and cover complementary semantic aspects, the same name space URIs can be used mutually for resources defined 1) with RDFS only, 2) with RDFS plus OWL and 3) with RDFS plus SHACL. A resource can be typed as an rdfs:Class, an owl:Class and a sh:NodeShape at the same time. The ontologies represented in RDFS, OWL and SHACL are recorded in their own graphs with their own graph URI and can therefore be used independently of each other and import each other.

 

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

Hi David

 

1.

I will discuss your view on use cases in the group.

And whether an alternative might be better (like having a separate rdfs schema with the skos properties/annotations not using skos:Concept instances)

 

2.

Wrt your last comment on ns uri <> graph uri….ok if that is not ok I have to change…

 

I thought the / or # only came in with the porefix independent of the uri itself…..

 

Eg I now have for my own (NL) spec:

 

“

De gehanteerde ‘name spaces’ URI’s:

¾                https://w3id.org/nen2660/vocab

¾                https://w3id.org/def/nen2660/def

Met prefixen:

¾                nen2660-vocab   https://w3id.org/nen2660/vocab#

¾                nen2660                  https://w3id.org/def/nen2660/def#

Met graaf URI’s (default voor vocab, 3 subgrafen voor def):

¾                https://w3id.org/nen2660/vocab (bestand: nen2660-skos.ttl)

¾                https://w3id.org/nen2660-rdfs/def (bestand: nen2660-rdfs.ttl)

¾                https://w3id.org/nen2660-owl/def (bestand: nen2660-owl.ttl)

¾                https://w3id.org/nen2660-shacl/def (bestand: nen2660-shacl.ttl)

 

so I guess I have to change the graph uris to (?):

 

Met graaf URI’s (default voor vocab, 3 subgrafen voor def):

¾                https://w3id.org/nen2660/vocab#  (bestand: nen2660-skos.ttl)

¾                https://w3id.org/nen2660-rdfs/def#  (bestand: nen2660-rdfs.ttl)

¾                https://w3id.org/nen2660-owl/def#  (bestand: nen2660-owl.ttl)

¾                https://w3id.org/nen2660-shacl/def#  (bestand: nen2660-shacl.ttl)

I used without # since I just lookedat/copied:

 

<https://w3id.org/def/nen2660-rdfs>

  a owl:Ontology ;

 

thx michel

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6BFA84CE-D739-4F17-AC4C-91BED5755A01%40topquadrant.com.

[David Price]

On 14 Apr 2021, at 10:28, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

I thought the / or # only came in with the porefix independent of the uri itself…..

No, the # or / is part of the Namespace URI.

From the Turtle Primer:

The full triples notation requires that URI references be written out completely, in angle brackets, which, as the example above illustrates, can result in very long lines on a page. For convenience, the Primer uses a shorthand way of writing triples (the same shorthand is also used in other RDF specifications). This shorthand substitutes a qualified name (or QName) without angle brackets as an abbreviation for a full URI reference . A QName contains a prefix that has been assigned to a namespace URI, followed by a colon, and then a local name. The full URIref is formed from the QName by appending the local name to the namespace URI assigned to the prefix. So, for example, if the QName prefix foo is assigned to the namespace URI http://example.org/somewhere/, then the QName foo:bar is shorthand for the URIref http://example.org/somewhere/bar. Primer examples will also use several "well-known" QName prefixes (without explicitly specifying them each time), defined as follows:

prefix rdf:, namespace URI: http://www.w3.org/1999/02/22-rdf-syntax-ns#

prefix rdfs:, namespace URI: http://www.w3.org/2000/01/rdf-schema#

prefix dc:, namespace URI: http://purl.org/dc/elements/1.1/
prefix owl:, namespace URI: http://www.w3.org/2002/07/owl#
prefix ex:, namespace URI: http://www.example.org/ (or http://www.example.com/)
prefix xsd:, namespace URI: http://www.w3.org/2001/XMLSchema#

Cheers,

David

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

In NL we have eg:

 

https://bp4mc2.org/profiles/#skos-toepassingsprofiel-voor-begrippenkaders

 

a profile for LD application for the government.

(you have to follow or explain why not…)

 

It has an integral role for skos.

 

 

Small fragment (google) translation:

 

2. SKOS Application profile for conceptual frameworks

 

Concepts make it clear which "topics of conversation" there are. In a system catalog terms are formally defined, each definition being built up according to strict rules. The essence is that every concept in a particular domain is explained in terms of other concepts. Those concepts are also limited until every concept that needs explanation has been defined. Ultimately, the concepts remain, the meaning of which is assumed to be automatic. In a logical model these are called axioms. This creates an axiomatic conceptual framework for each domain. This conceptual framework can be regarded as a more-less specified description of the institutional reality of the domain.

 

SKOS is used to describe concepts. SKOS is on the apply or explain list in the Netherlands.

 

Each concept is represented by a skos: concept.

Each domain has its own conceptual framework. The conceptual framework for a particular domain is represented by a skos: ConceptScheme.

Concepts can be organized in collections. A collection is represented by a skos: collection.

Concepts in different domains can be linked through appropriate mechanisms. This connection of concepts between domains creates a cohesion of coherent conceptual frameworks. This system of coherent conceptual frameworks can be seen as the knowledge base for a system catalog.

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location   This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

--

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/F7DEF80F-2471-41E8-8A51-DFF5239464C0%40topquadrant.com.

[Bohms, H.M. (Michel)]

Ok, thx, changed to:

 

 

 

De gehanteerde prefixen & ‘name space URI’s’:

¾                nen2660-vocab   https://w3id.org/nen2660/vocab#

¾                nen2660                 https://w3id.org/def/nen2660/def#

Met ‘graaf URI’s’ (default voor vocab, 3 subgrafen voor def):

¾                https://w3id.org/nen2660/vocab# (bestand: nen2660-skos.ttl)

¾                https://w3id.org/nen2660-rdfs/def# (bestand: nen2660-rdfs.ttl)

¾                https://w3id.org/nen2660-owl/def# (bestand: nen2660-owl.ttl)

¾                https://w3id.org/nen2660-shacl/def# (bestand: nen2660-shacl.ttl)

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability

T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens David Price
Verzonden: woensdag 14 april 2021 11:41
Aan: topbrai...@googlegroups.com
CC: Opgenoort, Rik <rik.op...@crow.nl>; Kronemeijer, Redmer <redmer.kr...@crow.nl>; Bart Bink <ba...@bink.nu>
Onderwerp: Re: [topbraid-users] best practise name space in multiple languages?

 

 

--

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/71D1477B-766D-4035-8730-90B7E5FF27CB%40topquadrant.com.

[David Price]

On 14 Apr 2021, at 10:49, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Ok, thx, changed to:

 

 

 

De gehanteerde prefixen & ‘name space URI’s’:

¾                nen2660-vocab   https://w3id.org/nen2660/vocab#

¾                nen2660                 https://w3id.org/def/nen2660/def#

Met ‘graaf URI’s’ (default voor vocab, 3 subgrafen voor def):

¾                https://w3id.org/nen2660/vocab# (bestand: nen2660-skos.ttl)

¾                https://w3id.org/nen2660-rdfs/def# (bestand: nen2660-rdfs.ttl)

¾                https://w3id.org/nen2660-owl/def# (bestand: nen2660-owl.ttl)

¾                https://w3id.org/nen2660-shacl/def# (bestand: nen2660-shacl.ttl)

IMO the Graph URI and the Namespace URI are best kept different so nobody gets confused. It is also the case that you may define constructs in any namespace in a graph and so there is really zero relation required between them.

So, I’d suggest this for your Graph URIs (no #):

Met ‘graaf URI’s’ (default voor vocab, 3 subgrafen voor def):

¾                https://w3id.org/nen2660/vocab (bestand: nen2660-skos.ttl)

¾                https://w3id.org/nen2660-rdfs/def (bestand: nen2660-rdfs.ttl)

¾                https://w3id.org/nen2660-owl/def (bestand: nen2660-owl.ttl)

¾                https://w3id.org/nen2660-shacl/def (bestand: nen2660-shacl.ttl)

As I explained earlier there are cases supporting versions of ontologies with the same classes defined - you may eventually need  https://w3id.org/nen2660/v1/vocab and https://w3id.org/nen2660/v2/vocab to both contain https://w3id.org/nen2660/vocab/PhysicalObject concept. In the engineering world where apps are audited (e.g. Aircraft design and manufacture), there are situations where there is a hard requirement for very strictly managed change to all apps, so versions are needed in the ontologies Graph URIs. The ontology provider can offer both a versioned release with v1, v2, etc. in the Graph URI and an un-versioned release with no v1, etc. in the Graph URI that is always the latest-and-greatest. That way implementors can choose “always the latest” or “a specific version”.

The main point is to separate the Graph URI from Namespace URI in your thinking, and maintain that separation in the artefacts themselves.

Cheers,

David

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

<image001.gif>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

 

Van: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens David Price
Verzonden: woensdag 14 april 2021 11:41
Aan: topbrai...@googlegroups.com
CC: Opgenoort, Rik <rik.op...@crow.nl>; Kronemeijer, Redmer <redmer.kr...@crow.nl>; Bart Bink <ba...@bink.nu>
Onderwerp: Re: [topbraid-users] best practise name space in multiple languages?

 

 

On 14 Apr 2021, at 10:28, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

 

I thought the / or # only came in with the porefix independent of the uri itself…..

 

No, the # or / is part of the Namespace URI.

 

From the Turtle Primer:

 

The full triples notation requires that URI references be written out completely, in angle brackets, which, as the example above illustrates, can result in very long lines on a page. For convenience, the Primer uses a shorthand way of writing triples (the same shorthand is also used in other RDF specifications). This shorthand substitutes aqualified name (or QName) without angle brackets as an abbreviation for a full URI reference . A QName contains a prefix that has been assigned to a namespace URI, followed by a colon, and then a local name. The full URIref is formed from the QName by appending the local name to the namespace URI assigned to the prefix. So, for example, if the QName prefix foo is assigned to the namespace URI http://example.org/somewhere/, then the QName foo:bar is shorthand for the URIrefhttp://example.org/somewhere/bar. Primer examples will also use several "well-known" QName prefixes (without explicitly specifying them each time), defined as follows:

prefix rdf:, namespace URI: http://www.w3.org/1999/02/22-rdf-syntax-ns# 
prefix rdfs:, namespace URI: http://www.w3.org/2000/01/rdf-schema# 
prefix dc:, namespace URI: http://purl.org/dc/elements/1.1/ 
prefix owl:, namespace URI: http://www.w3.org/2002/07/owl# 
prefix ex:, namespace URI: http://www.example.org/ (or http://www.example.com/)
prefix xsd:, namespace URI: http://www.w3.org/2001/XMLSchema#

 

Cheers,

David

 

 

UK +44 (0) 7788 561308

US +1 (336) 283-0808

 

-- 
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/71D1477B-766D-4035-8730-90B7E5FF27CB%40topquadrant.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/be42ca7c28bb4be3aeb984164725ebcd%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

Thx and indeed we might want versioned graph uri’s!

 

Now:

 

De gehanteerde prefixen & ‘name space URI’s’:

¾                nen2660-vocab   https://w3id.org/nen2660/vocab#

¾                nen2660                  https://w3id.org/def/nen2660/def#

Met ‘graaf URI’s’ (default voor vocab, 3 subgrafen voor def):

¾                https://w3id.org/nen2660/vocab (bestand: nen2660-skos.ttl)

¾                https://w3id.org/nen2660-rdfs/def (bestand: nen2660-rdfs.ttl)

¾                https://w3id.org/nen2660-owl/def (bestand: nen2660-owl.ttl)

¾                https://w3id.org/nen2660-shacl/def (bestand: nen2660-shacl.ttl)

 

happy with that “solution” for now, let’s see what the use case question brings us as “problem” 😊

 

 

One more:

From the above the process of obtaining a default name space uri from the graph uri would be:

ns-uri := g-uri + #

 

and I know see that is exactly what happens in tbc when you click the chain….:

 

 

thx

 

gr michel

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/63EB21FE-8C4B-4834-82DF-0098F8A73888%40topquadrant.com.

[David Price]

Hi Michel,

On 14 Apr 2021, at 10:43, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

In NL we have eg:

 

https://bp4mc2.org/profiles/#skos-toepassingsprofiel-voor-begrippenkaders

Appreciate this,- I guess my question is really to the people who made this decision.

 

a profile for LD application for the government.

(you have to follow or explain why not…)

 

It has an integral role for skos.

 

 

Small fragment (google) translation:

 

2. SKOS Application profile for conceptual frameworks

 

Concepts make it clear which "topics of conversation" there are. In a system catalog terms are formally defined, each definition being built up according to strict rules. The essence is that every concept in a particular domain is explained in terms of other concepts. Those concepts are also limited until every concept that needs explanation has been defined. Ultimately, the concepts remain, the meaning of which is assumed to be automatic. In a logical model these are called axioms. This creates an axiomatic conceptual framework for each domain. This conceptual framework can be regarded as a more-less specified description of the institutional reality of the domain.

 

The above is an odd statement. There are no axioms in SKOS. Maybe I don’t understand their intent. If I read the statement correctly, it is a misunderstanding of what SKOS is and does - or maybe it’s just Google translate’s fault. The SKOS spec actually says:

1.3. SKOS, RDF and OWL

The elements of the SKOS data model are classes and properties, and the structure and integrity of the data model is defined by the logical characteristics of, and interdependencies between, those classes and properties. This is perhaps one of the most powerful and yet potentially confusing aspects of SKOS, because SKOS can, in more advanced applications, also be used side-by-side with OWL to express and exchange knowledge about a domain. However, SKOS is not a formal knowledge representation language.

To understand this distinction, consider that the "knowledge" made explicit in a formal ontology is expressed as sets of axioms and facts. A thesaurus or classification scheme is of a completely different nature, and does not assert any axioms or facts. Rather, a thesaurus or classification scheme identifies and describes, through natural language and other informal means, a set of distinct ideas or meanings, which are sometimes conveniently referred to as "concepts". These "concepts" may also be arranged and organized into various structures, most commonly hierarchies and association networks. These structures, however, do not have any formal semantics, and cannot be reliably interpreted as either formal axioms or facts about the world. Indeed they were never intended to be so, for they serve only to provide a convenient and intuitive map of some subject domain, which can then be used as an aid to organizing and finding objects, such as documents, which are relevant to that domain.

SKOS is used to describe concepts. SKOS is on the apply or explain list in the Netherlands.

SKOS describing concepts is fine. It’s when it gets mixed with OWL Classes, axioms, etc. that it has no meaning in a landscape where meaning may be important, and so can cause issues.

 

Each concept is represented by a skos: concept.

Each domain has its own conceptual framework. The conceptual framework for a particular domain is represented by a skos: ConceptScheme.

Concepts can be organized in collections. A collection is represented by a skos: collection.

Concepts in different domains can be linked through appropriate mechanisms. This connection of concepts between domains creates a cohesion of coherent conceptual frameworks. This system of coherent conceptual frameworks can be seen as the knowledge base for a system catalog.

In this case it appears they are using SKOS with PROV-O to track provenance and documents about assets/things. Maybe that is only for human consumption so not really a problem. 

I will note that the PROV-O ontology itself does not use SKOS. It seems they thought PROV-O might be useful to a reasoner as the spec even talks about it almost being within the OWL-RL profile apart from 5 axioms.

DCAT does use SKOS though, and that makes sense in that you may want a “loosely defined taxonomy" to help humans (not machines) categorise and find datasets - that’s not a scenario in a rigorous discipline like found in many engineering/science apps, and so does not require correct semantics/formal definition.

Again, thanks for the pointer - interesting.

Cheers,

David

 

 

Dr. ir. H.M. (Michel) Bohms Scientist Specialist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location

<image005.gif>

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/d47d46a4b4de4866a319124d1a45615b%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[David Price]

Hi TB users,

Just thought I’d add that I am not suggesting that using a reasoner is of primary importance to most LD/Semantic user scenarios.

I’m really trying to understand why a specific ontology (SKOS) is being used for something that seems to be included directly in both the OWL and SHACL languages out-of-the-box.

Cheers,

David

[robatki...@gmail.com]

There is another reason to use SKOS as a view for Class models (which a form of polymorphism known as OWL "punning" apparently)

SKOS preserves direct parent/child inheritance irrespective of the entailment regime.  RDFS subClassOf does not allow you to identify the immediate parent, and this is not relevant to the set theory aspect of reasoning. Actual models have explicit semantic intent - as evidenced by the desire to build class heirarchies.   If you fully entail RDFS everying is a subclass of itself and every other ancestor in tree.

I feel that SKOS is playing the role of a "shape" for conceptual hierarchies that may be further described in OWL ..

[David Price]

On 14 Apr 2021, at 12:30, robatki...@gmail.com <robatki...@gmail.com> wrote:

There is another reason to use SKOS as a view for Class models (which a form of polymorphism known as OWL "punning" apparently)

SKOS preserves direct parent/child inheritance irrespective of the entailment regime.  RDFS subClassOf does not allow you to identify the immediate parent, and this is not relevant to the set theory aspect of reasoning. Actual models have explicit semantic intent - as evidenced by the desire to build class heirarchies.   If you fully entail RDFS everying is a subclass of itself and every other ancestor in tree.

Hi Rob,

Thanks for the reply. The separation of broader and broaderTransitive (which is inferred from broader) is useful - makes sense.

I feel that SKOS is playing the role of a "shape" for conceptual hierarchies that may be further described in OWL ..

So you mix SKOS hierarchies and OWL hierarchies in apps? Is it possible to point to or provide a small example/snippet?

Do you every use/query broaderTransitive (which works more like rdfs:subClassOf it seems)?

Cheers,

David

--
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/70fc5922-bd00-4295-8e8c-5e1cc241f977n%40googlegroups.com.

[robatki...@gmail.com]

https://www.opengis.net/def/schema/hy_features/hyf/HY_Catchment

is an example of a SKOS view of a OWL model, entailed by SPIN rules.

the OWL model will soon be available via Content Negotiation by profile (dealing with a bit of a regression after an update ) 

experimenting with combined views - e.g.

https://w3id.org/demeter/agri/agriIntervention

makes a T-Box ontology navigable via SKOS but shows OWL model. Just need to deal with the blank nodes more elegantly.

I'm also exploring how this can be most elegantly handled in EDG - but its ability to build class trees make it less important, provided that data is _not_ entailed using RDFS.  The challenge is how to "have your cake and eat it too" with entailments :-)