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 > On 14 Apr 2021, at 10:24, David Price <[email protected]> wrote: > > 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 > <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 > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/FBB9CFC0-9187-4CE1-AD33-EAC7155E0EEF%40topquadrant.com.
