Hi Michel,
> On 14 Apr 2021, at 10:43, 'Bohms, H.M. (Michel)' via TopBraid Suite Users > <[email protected]> wrote: > > In NL we have eg: > > https://bp4mc2.org/profiles/#skos-toepassingsprofiel-voor-begrippenkaders > <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 [email protected] <mailto:[email protected]> > Location <http://www.tno.nl/locations/DTS> > > > <image005.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 David Price > Verzonden: woensdag 14 april 2021 11:25 > Aan: [email protected] <mailto:[email protected]> > Onderwerp: Why SKOS in ontologies? Was Re: [topbraid-users] best practise > name space in multiple languages? > > 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 > > -- > 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/F7DEF80F-2471-41E8-8A51-DFF5239464C0%40topquadrant.com > > <https://groups.google.com/d/msgid/topbraid-users/F7DEF80F-2471-41E8-8A51-DFF5239464C0%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/d47d46a4b4de4866a319124d1a45615b%40tno.nl > > <https://groups.google.com/d/msgid/topbraid-users/d47d46a4b4de4866a319124d1a45615b%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]. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/95A9965B-834C-4E23-AB38-0A50D8418EC8%40topquadrant.com.
