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. > On Apr 6, 2021, at 10:59 AM, David Price <[email protected]> wrote: > > > >> On 6 Apr 2021, at 15:22, Irene Polikoff <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. >> >>> On Apr 6, 2021, at 10:04 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite >>> Users <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> 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..? >>> >>> > > 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 [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/31FFC7EA-C74F-4AB3-BEA5-0AEF86C1EAAA%40topquadrant.com >> >> <https://groups.google.com/d/msgid/topbraid-users/31FFC7EA-C74F-4AB3-BEA5-0AEF86C1EAAA%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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/B6CE685A-6339-4B3D-8113-7A4A21839D5A%40topquadrant.com > > <https://groups.google.com/d/msgid/topbraid-users/B6CE685A-6339-4B3D-8113-7A4A21839D5A%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/3144652D-AD59-4177-850F-2559440BE4FC%40topquadrant.com.
