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 [email protected]<mailto:[email protected]> Location<http://www.tno.nl/locations/DTS> [cid:[email protected]]<http://www.tno.nl/> 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: [email protected] <[email protected]> Namens Irene Polikoff Verzonden: vrijdag 9 april 2021 14:13 Aan: [email protected] Onderwerp: Re: [topbraid-users] best practise name space in multiple languages? 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. On Apr 9, 2021, at 6:32 AM, David Price <[email protected]<mailto:[email protected]>> wrote: Hi Michel, I On 9 Apr 2021, at 09:52, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <[email protected]<mailto:[email protected]>> 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#<https://w3id.org/nen2660>. From the Turtle Primer: prefix rdfs:, namespace URI: http://www.w3.org/2000/01/rdf-schema#<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<http://anything.at.all/> and define classes and properties using http://michel.com#<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<https://w3id.org/nen2660/Thing1>#Class1<https://w3id.org/nen2660/Thing1> an rdfs:Class can be in https://w3id.org/nen2660/schema graph and https://w3id.org/nen2660<https://w3id.org/nen2660/Thing2>#NodeShape2<https://w3id.org/nen2660/Thing2> a SHACL NodeShape can be in https://w3id.org/nen2660/shapes graph. Both graphs as TTL would state @prefix nen2660: <https://w3id.org/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/<http://standard.iso.org/mystandard/MyClass>MyClass<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 [email protected]<mailto:[email protected]> Location<http://www.tno.nl/locations/DTS> <image001.gif><http://www.tno.nl/> 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: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Namens Holger Knublauch Verzonden: vrijdag 9 april 2021 10:42 Aan: [email protected]<mailto:[email protected]> Onderwerp: Re: [topbraid-users] best practise name space in multiple languages? On 9/04/2021 6:31 pm, 'Bohms, H.M. (Michel)' via TopBraid Suite Users wrote: Dear Holger One more question on this. 1. Indeed serialization is other dimension related to server negotiation etc. 2. 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). 3. Lets focus on name spaces for rdfs/owl/shacl variants, let’s assume variant: owl & shacl both importing rdfs (not: shacl importing owl) 4. 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 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 [email protected]<mailto:[email protected]> Location<http://www.tno.nl/locations/DTS> <image001.gif><http://www.tno.nl/> 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: [email protected]<mailto:[email protected]> <[email protected]><mailto:[email protected]> Namens Holger Knublauch Verzonden: dinsdag 6 april 2021 13:22 Aan: [email protected]<mailto:[email protected]> Onderwerp: Re: [topbraid-users] best practise name space in multiple languages? 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#<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 <[email protected]<mailto:[email protected]>> wrote: In case I have the same specification on different modelling levels: 1. Skos 2. Rdfs 3. Rdfs+owl 4. 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 [email protected]<mailto:[email protected]> Location<http://www.tno.nl/locations/DTS> <image001.gif><http://www.tno.nl/> 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 [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8c5728fd3b8b45cd8ca17055b8df9688%40tno.nl<https://groups.google.com/d/msgid/topbraid-users/8c5728fd3b8b45cd8ca17055b8df9688%40tno.nl?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9C404919-EDE6-4E6A-B1EA-98AB888E8E03%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/9C404919-EDE6-4E6A-B1EA-98AB888E8E03%40topquadrant.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2d7063d8c78e4ceeacf219a6efcd5ae5%40tno.nl<https://groups.google.com/d/msgid/topbraid-users/2d7063d8c78e4ceeacf219a6efcd5ae5%40tno.nl?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/88c0b9e2-43a1-8896-8014-eb9c6076748d%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/88c0b9e2-43a1-8896-8014-eb9c6076748d%40topquadrant.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8a9a60a8eb764b77b8ef459b1b2cf2e4%40tno.nl<https://groups.google.com/d/msgid/topbraid-users/8a9a60a8eb764b77b8ef459b1b2cf2e4%40tno.nl?utm_medium=email&utm_source=footer>. 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 [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/BBA9F9BC-4FC5-41AF-82DA-D467A259BF5F%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/BBA9F9BC-4FC5-41AF-82DA-D467A259BF5F%40topquadrant.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/DBA3E432-6A7A-488B-BF51-0D92A08B9604%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/DBA3E432-6A7A-488B-BF51-0D92A08B9604%40topquadrant.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/ec76967462d24b8096996bf12cd0e043%40tno.nl.
