In bold
om what Holger said and adding a question: On 6 Apr 2021, at 12:22, Holger Knublauch <hol...@topquadrant.com<mailto: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#<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 <topbraid-users@googlegroups.com<mailto:topbraid-users@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) Cheers, David (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.bo...@tno.nl<mailto:michel.bo...@tno.nl> 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 topbraid-users+unsubscr...@googlegroups.com<mailto:topbraid-users+unsubscr...@googlegroups.com>. 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 topbraid-users+unsubscr...@googlegroups.com<mailto:topbraid-users+unsubscr...@googlegroups.com>. 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>. 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-users+unsubscr...@googlegroups.com<mailto:topbraid-users+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/0F9383B1-E7E6-484C-97DA-7AA0F8BB4F95%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/0F9383B1-E7E6-484C-97DA-7AA0F8BB4F95%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 topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b95566c20049447eab26e088611fda38%40tno.nl.
