Problem creating ontology that uses OWL and SKOS simultaneously
Henrique
I would like to work with OWL and SKOS in the same project.
However, if I create a Model:SKOS and Lexicalization:RDFS project
so, when I try to create a Scheme in the Vocbench interface, it throws the error:
http://www.w3.org/2000/01/rdf-schema is not a valid lexicalization model
I don't know why this error appears.
But on the other hand if I create a Model:SKOS and Lexicalization:SKOS project
the previous error no longer appears when creating the Scheme
However, if I create a project like Model:SKOS and Lexicalization: SKOS
and insert the following elements:
1) the class :MyClass defined as owl:Class
2) the scheme :MyScheme defined as skos:ConceptScheme
3) the concept :MyConcept defined as skos:Concept and linked to :MyScheme
4) the property :myProperty defined as owl:ObjectProperty
which binds the rdfs:domain to :MyClass
and the rdfs:range for the :MyScheme (entered manually because it doesn't appear in the options)
5) the individual :myIndividual belonging to :MyClass
When I ask to link :myIndividual through the :myProperty, VocBench throws the following error:
Resource http://dados.com/onto#MyScheme is not reachable in the current tree.
In my understanding, this error doesn't make sense because all elements involved are associated with owl and therefore are part of the same tree:
- :MyClass is an owl:Class which is an owl:Thing
- :myProperty is an owl:ObjectProperty
- :MyScheme is a skos:ConceptScheme which is an owl:Class
Note: my ontology where the error occurred is much larger. I created the one above just to make it easier to investigate the problem.
This exported ontology is attached.
I really appreciate if anyone can help me.
Best regards,
Henrique.
Roland Wingerter
Resource http://dados.com/onto#MyScheme is not reachable in the current tree.
skos:prefLabel "MyScheme"@en .
rdfs:range :MyScheme;
rdfs:domain :MyClass .
Roland Wingerter
http://www.w3.org/2000/01/rdf-schema is not a valid lexicalization model
Tiziano Lorenzetti
The fix will be included in the next release that will be out probably within the end of this month or in April.
--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/053f329d-4e02-46e5-86a4-98c6ed216652n%40googlegroups.com.
Roland Wingerter
Henrique
@Tiziano, at the moment, to get out of this error, I opted to use the project as Model:SKOS and Lexicalization:SKOS, and it's working fine.
I'll wait for the next version of VB.
@Roland, I really appreciate your recommendation about letting ontology separate from data. I agree and, in fact, I have already made this separation in the case I'm working on. In this test example that I sent in the previous message, I purposely put everything together, as I was suspicious that this could be the cause of the problem...
As for your warning that ":MyScheme a skos:ConceptScheme" is an individual, I confess that I was surprised and confused, because I thought it had the same behavior as a class, when we wrote "<X> a owl:Class", <X> is not an individual.
So I went to study the complete SKOS reference to learn a little more (https://www.w3.org/TR/skos-reference/).
Then I realized you're right, and elements that are of type skos:Concept and skos:ConcepScheme are indeed individuals.
I also ended up discovering that SKOS is excessively flexible, and accepts things like:
<MyConcept> rdf:type skos:Concept , owl:Class .
<MyScheme> rdf:type skos:ConceptScheme , owl:Ontology .
Well, let's go...
to facilitate the exposition of my problem, I created a simplified and very small example of a domain ontology that corresponds to a small piece of the one I am producing.
It is an OWL ontology with some SKOS elements to represent lists of terms.
Attached is the image of the design model.
This ontology represents institutions that are located in a given location and are classified according to a list of administrative category terms.
Attached is also a TTL file, referring to the operational ontology, generated by VB.
I opted to leave the :AdminstrativeCategory conceptual schema as a skos:ConceptScheme
If I put this conceptual schema as a subclass of skos:ConceptSheme I would lose the possibility of it being treated by the VB interface as a schema, where I can select the concepts that belong to it.
I had to put the range associated with the :hasAdministrativeCategory property as skos:Concept.
That way the errors no longer appear. But I wonder if it really was the best choice.
I realized that for the VB interface to recognize the concepts that are associated with each conceptual schema, it is necessary to place them as skos:topConceptOf of the conceptual schema.
I didn't understand why, because, according to the SKOS specification, only the concepts considered "topmost in the hierarchical relations for that scheme" should receive this attribution.
Sorry for the long text, but I'm just learning about all this and I want to take advantage of your great experience and, above all, your availability and goodwill to help!
Best Regards,
Henrique.
Armando Stellato
Dear Henrique,
+1 (and even +2, +3…) on SKOS being exaggeratedly flexible. Interoperability shouldn’t be traded for Flexibility, especially in the Semantic Web.
However, the kind of flexibility I don’t like is when too much is left to the person modeling the domain, because it means losing shared semantics and thus interoperability and machine understandability.
The (general) modeling example you report, however, is not the case: this is because the only problem there lies in an object being both an instance of a class, and a class itself, which requires punning in a reasoner.
So this is more about your modeling choice and what you can expect from a reasoner, but these are clearly documented in OWL and SKOS specs and the semantics are clear.
Just as a matter of personal taste, but then it really goes from case to case, I consider the case to have a mixed object usually given by the combination of different modeling needs (e.g. you have an OWL ontology, a SKOS thesaurus, and you want that a scheme from the thesaurus is referenced by the same URI of a class in the ontology). Usually, in a single modeling environment, you may first consider if what you need is really a thesaurus and not an ontology.
What you said about your experiment with :AdministrativeCategory reveals a problem in the modeling choice, not a limit of VB3 (which can handle such interwoven OWL/SKOS mixes)
Is what you need a scheme or a class for your individuals? It’s too long to go back now on a SKOS course but, in short, as a scheme, you could attach concepts to it through the skos:inScheme and skos:topConceptOf relation. This is used to “build up” a hierarchy that has loose semantics. And the charatcteristic of this hierarchy is to be “artificial”. You don’t need to reflect reality in it. If you are building a “buying advice” hierarchy for a online seller, you may put the concepts lens and objective as narrowers of the concept camera. Is this correct in reality? If the broader/narrower for you reflects an IS-A relationship, obviously it is not, but if you want the hierarchy to reflect a “buying recommendation tree” so that one that buys a camera is suggested to buy an objective as well, then yes you can do it. SKOS is very clear on the loose semantics of broader/narrower. Take them only as artificial properties for developing a tree for whatever purpose you might need.
If you need only to classify some individuals as instances of :AdministrativeCategory , you definitely do not need a scheme; just create the :AdministrativeCategory class. Indeed, most possibly, you don’t need to use SKOS at all.
Not to throw my papers at anyone :-) but here you can find an extended discussion about OWL vs SKOS
The issue in your example (not from the point of view of what you want to obtain, which I discussed here above) from the mere technical point of view of how VB interprets your coding, is that you want a skos:ConceptScheme (an instance of it) to be both an instance of skos:ConceptScheme (you didn’t do, but that’s what you want when you say you want it to be treated as an instance of skos:ConceptScheme) and a subclass of skos:ConceptScheme (what you did).
If you wanted :AdministrativeCategory to be both a class and a concept scheme, you should make it …both a class and a concept scheme ;-) that is
:AdministrativeCategory a owl:Class .
:AdministrativeCategory a skos:ConceptScheme . (not subclass!)
This would work in VB, because then you declared :AdministrativeCategory as a concept scheme.
However, again, this is the technical solution, but most probably you don’t need it as, if you had any instance to use for that, I would suppose you wanted them either as concepts belong to the scheme or as instances of the class. Unless you wanted different “membership” for different objects, some as instances of it and some as concepts belonging it. This, however, I find pretty uncommon as a case, that’s why I say this happens usually if one has to somehow harmonize two different models, with one being SKOS and the other being OWL
Indeed, your case (as I see from your picture) would demand for something even more specific, because you have an enumeration, and OWL provides support for enumerations in a much nicer way:
https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Enumeration_of_Individuals
One more thing: your “I realize that etc…” is not correct. VB3 is just complying 100% with the SKOS semantics. These demand all top concepts to be bound to a scheme with the skos:topCOnceptOf. At the same time, it demands that all concepts in the scheme (even narrower ones) are bound to the scheme through skos:inScheme. And, no, you cannot infer the membership of a concept to a scheme because some of its broaders belong to the scheme (pls check here: https://www.w3.org/TR/skos-reference/#L2577 )
If you just build a scheme through VB3’s UI you will see that it works, but not because VB3 is planting some specific requirement of its; on the contrary, because VB is facilitating the user in writing correct code without they caring too much about it.
I hope it helps and clarifies, have a nice Sunday!
Kind Regards,
Armando
P.S: please don’t misunderstand me, I hope this doesn’t sound nasty at all: this mailing list is about VocBench3, not OWL/SKOS modeling. I totally understand this msg of yours comes from the misunderstanding that some things were strangely not possible in VB or that its UI had some special requirements or limitations (which is not the case). However, in general, I encourage staying on the focus of a specific issue with “how-to-do this in VB3” rather than how should I model this. Sometimes the boundary between the two is subtle, especially if one is new to the RDF world (that’s why we are always available as in such case), but to the purpose of sparing some of our free time devoted to this list, let’s try to keep the topic and explanations tighter to the topic of the list ;-)
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/1a059d22-1d36-449b-9cb7-b7b46293d33bn%40googlegroups.com.
Henrique
I agree with the purpose of this forum, which is to discuss aspects related to VB. I'm sorry the discussion took a different path ;-|
I promise the discussion about modeling is ending here :-)
So, in closing, a few points:
1. About the use of skos:topConceptOf I really had misunderstood the specification of skos. Thanks for your explanation!
2. I am aware that in the relationship between :Institution and :AdministrativeCategory there could be an IS-A relationship, considering AdministrativeCategory as a class. But it is not the purpose of my ontology to focus on this aspect.
The administrative category of the institution is just a mere detail of an ontology that tries to represent a reality that goes in another conceptual direction.
In other words, this administrative category is not relevant to the model, and could even be omitted, or simply be transformed into a String attribute of the Institution class.
The idea of using skos:Concept and skos:ConceptScheme was to simplify it to have a vocabulary that could only represent this list of terms that classify the institution's administrative category.
On the other hand, as you suggested, using owl's enumeration support does not seem to me to be a solution that brings simplicity to future information retrieval. In that respect (and I could be wrong) I believe that skos is more accessible/simple for search engines and information retrieval systems than owl enumerations. Also, I find it easier to establish an interoperable link between a skos:Concept instance from my vocabulary with an equivalent concept belonging to an external vocabulary. On the other hand, making this connection interoperable with elements of an owl enumeration, I don't know if it's usual.
3. The way the TTL code is (which was sent in the previous email) it seems correct to leave the :AdministrativeCategory declared as an instance of skos:ConceptScheme. In addition, the hasAsministrativeCategory property was configured with the skos:Concept range.
:hasAdministrativeCategory a owl:ObjectProperty;
rdfs:range skos:Concept;
rdfs:domain :Institution .
This way, the VB interface is working fine showing correctly the concepts belonging to the conceptual scheme, and without that error caused when I put a:AdministrativeCategory as skos:range.
Also, this implementation is compatible with the design model (picture from previous email).
4. About your article (http://art.uniroma2.it/publications/docs/2012_JIA_Dictionary,%20Thesaurus%20or%20Ontology%20Disentangling%20Our%20Choices%20in%20the%20Semantic%20Web%20Jungle.pdf)
Congratulations, because it is good, introductory and super didactic for the relationship between OWL and SKOS. On this subject, I only knew the W3C recommendation https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html which, despite having many examples, is less didactic.
Thanks again!
Best Regards,
Henrique.
Armando Stellato
Dear Henrique,
I agree with the purpose of this forum, which is to discuss aspects related to VB.
I'm sorry the discussion took a different path ;-|
I promise the discussion about modeling is ending here :-)
No worries, like I said, I understand that sometimes the boundary between explaining what you are doing and what is an issue with VB is blurred, or at least, can be blurred because if everything was clear, maybe there was not question at all to ask :-)
So, in closing, a few points:
1. About the use of skos:topConceptOf I really had misunderstood the specification of skos. Thanks for your explanation!
2. I am aware that in the relationship between :Institution and :AdministrativeCategory there could be an IS-A relationship, considering AdministrativeCategory as a class. But it is not the purpose of my ontology to focus on this aspect.
Technically (and to the purpose of good terminology), it’s not an IS-A, at least not between :AdministrativeCategory and :Institution, but I understand what you mean: you could create owl classes named after the “instances” of the :AdministrativeCategory. Those classes could be disjoint and represent a partition of the Institution class. Whether their union is a larger concept than :Institution or fitting exactly the :Institution one is your choice, e.g. if you name a class :PrivateInstitution it’s clear it will be (more precisely, it is meant to be) a rdfs:subClassOf :Institution
The administrative category of the institution is just a mere detail of an ontology that tries to represent a reality that goes in another conceptual direction.
In other words, this administrative category is not relevant to the model, and could even be omitted, or simply be transformed into a String attribute of the Institution class.
The idea of using skos:Concept and skos:ConceptScheme was to simplify it to have a vocabulary that could only represent this list of terms that classify the institution's administrative category.
On the other hand, as you suggested, using owl's enumeration support does not seem to me to be a solution that brings simplicity to future information retrieval. In that respect (and I could be wrong) I believe that skos is more accessible/simple for search
engines and information retrieval systems than owl enumerations. Also, I find it easier to establish an interoperable link between a skos:Concept instance from my vocabulary with an equivalent concept belonging to an external vocabulary. On the other hand,
making this connection interoperable with elements of an owl enumeration, I don't know if it's usual.
Well, this is a very specific assumption. If we take it as-is, we could throw out ontologies out of the window :-)
If, in your environment, you already have systems working with thesauri, if the usage of your data can be managed through them that way etc… then ok, you can do it in SKOS.
So, in general, then you will see:
- There is no problem to have a (n instance of) skos:Concept have a property having range on an enumeration.
- Pls note that there is nothing forbidding you from having an enumeration (which is the only way to make it…an enumeration) made of…(again, instances of) skos:Concepts! The elements of the enumeration do not need to be “minted” specifically for the enumeration. This way you keep the scheme/concepts model you adopted, but you have a formal range restricted to three entities.
- Viceversa, you can set the range to be on a set of skos:Concepts being a member of an owl restriction classifying all concepts belonging to a certain scheme (VB3 nor probably any other tool will show you that, unless showing ranges based on the outcome of a reasoner, so the user will have to manually select the scheme each time). Formally it is correct, but it doesn’t sound any “simpler” than the above though (it involves an owl:Restriction, which is normally not parsed by editing tools, rather by reasoners).
- Again, if you want, you could use a double mechanism making a resource both a scheme and a class, with the elements being (they need to be) both members of it as a scheme and instances of it as a class. Not my fav, it mixes classes and individuals, but it works.
3. The way the TTL code is (which was sent in the previous email) it seems correct to leave the :AdministrativeCategory declared as an instance of skos:ConceptScheme. In addition, the hasAsministrativeCategory
property was configured with the skos:Concept range.
:hasAdministrativeCategory a owl:ObjectProperty;
rdfs:range skos:Concept;
rdfs:domain :Institution .
This way, the VB interface is working fine showing correctly the concepts belonging to the conceptual scheme, and without that error caused when I put a:AdministrativeCategory as skos:range.
Also, this implementation is compatible with the design model (picture from previous email).
Sure, that is ok. This is subsumed by what replied to point 3 (containing further – different, or refining this one – possibilities), so I do not add anything more.
4. About your article (http://art.uniroma2.it/publications/docs/2012_JIA_Dictionary,%20Thesaurus%20or%20Ontology%20Disentangling%20Our%20Choices%20in%20the%20Semantic%20Web%20Jungle.pdf)
Congratulations, because it is good, introductory and super didactic for the relationship between OWL and SKOS. On this subject, I only knew the W3C recommendation
https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html which, despite having many examples, is less didactic.
I’m glad it was useful, that was also the intention of the article, as it followed a presentation I had in China thought for people working with thesauri and having these same doubts.
Enjoy the modeling!
Kind Regards,
Armando
Roland Wingerter
Henrique
Once again I am very grateful for your generosity and willingness to want to help me! And I'm sorry for the delay in replying, because I had a busy week here…besides that I needed time to read and go over your answer and the material that Roland suggested to me.
About the transformation of :AdministrativeCategory as a class, which you two suggested to me, either to create PublicState, PublicFederal and Private instances, or even to relate it through a Generalization with the Institution class, despite being a viable idea with the use only OWL elements, it doesn't seem to be a good choice for my specific case, because as I explained before, this entity that represents the administrative category has little importance in the ontology.
Thus, I insist on the idea that SKOS is a representation system that is widespread in the world and manages to solve in a simpler way the categorization of ontology elements as being of type skos:Concept, instead of being owl:NamedIndividual. They are elements that don't need the status of Class, but on the other hand, they are not simple enough to be relegated to a Literal String type. Therefore, a skos:Concept type, in my understanding, would be a more suitable solution for this case.
This ontology that I passed on in the message was exaggeratedly reduced in all aspects so that it would be easier to describe my question about using SKOS to represent a list of terms in an ontology already constituted by OWL entities. Furthermore, I recall that all my doubts originated from the mistake I made in placing an element of type skos:ConceptScheme in the rdfs:range of an owl:ObjectProperty, and VocBench did not accept it (and it shouldn't accept it anyway! After the explanation of Roland made it clear to me that it was an instance, not a Class)
As for being restricted to only three elements (PublicState, PublicFederal and Private), this is not a problem for the context of my representation. Because there are n terms that will not be modified in the future. On the other hand, it will happen that some concepts are used in other vocabularies (skos:ConceptScheme) in the same ontology.
Regarding the case of not being able to define a specific set of skos:Concept for an rdfs:range to be interpreted by the interface, I understand that this could indeed be a problem and waste time for the user who needs to enter this data manually selecting the respective schema. But I don't think this is a relevant problem if we consider that we can have a specific external interface for data entry, which correctly provides the available options. Otherwise, if the data input comes from an already established database, the mapping system for RDF (for example the GraphDB that I use) can fulfill this role.
About the idea of making the resource a conceptual schema and a class at the same time, yes, it seems like an idea that works. But, I find this confusing and prefer not to.
Furthermore, I particularly find the idea of defining an entity to be, at the same time: owl:Class, owl:NamedIndividual and skos:Concept very confusing.
This happens many times in the https://www.michaeldebellis.com/post/owlsynonyms example:
As in this case:
:Person a owl:Class, owl:NamedIndividual, skos:Concept;
rdfs:subClassOf :Mammal;
skos:broader :Mammal .
@Roland, about the use of "rdfs:seeAlso dbr:Federal_University_of_Espírito_Santo", yes I already knew and have used it a lot, and sometimes owl:sameAs, to semantically enrich the data associated with my ontologies. I also make use of owl:equivalentProperty and owl:equivalentClass to strengthen interoperability. And Vocbench supports all of this very well!
To be honest I'm satisfied with what I did in the last code I sent (sorry for the stubbornness rsss). But it came out clean with good readability, it fit the model and it worked in VocBench!!
By the way, I used Protégé for a few years (always for academic/didactic purposes) and I always found it confusing and unstable in many ways… When I discovered Vocbench (at one of ISKO London's remote events at the time of the COVID-19 pandemic ) I was surprised by a much more orthogonal interface and without many of the confusions and inaccuracies that Protégé works. So, you two, and the entire VocBench team, are to be congratulated for participating, maintaining and moving forward with this project that is so useful for society!! As far as possible I have been trying to promote VocBench, mainly with my students, in the Postgraduate Master's course in Information Science at my university.
Best regards,
Henrique.
Armando Stellato
Dear Henrique,
thanks for the kind words and appreciation!
About the modeling, well, that’s a goal for us: different perspectives and preferences but also, more objectively, different boundary conditions (e.g. interfaces for your end-user tool that are not necessarily model-driven, and a general tendency towards SKOS for support) may lead to different modeling choices. The goal is scored if VB3 enables and properly supports them all, and it seems it did :-)
Kind Regards,
Armando
P.S: I want to break a lance in favor of Protégé. The system has a very different philosophy, tailored specifically for OWL ontologies, and not necessarily represented in RDF (OWL 2 introduced a syntax of its own that is not based on RDF). VocBench has a different approach, tailored basically for (RDF) data and then featuring, on top of that, support for different semantic and lexical models: RDFS, OWL, SKOS (/XL), OntoLex and EDOAL, and obviously for supporting any kind of generic RDF dataset. As you are more into SKOS, clearly you found the right tool for you :-)
From: vocben...@googlegroups.com <vocben...@googlegroups.com>
On Behalf Of Henrique
Sent: Friday, March 17, 2023 6:33 AM
To: vocbench-user <vocben...@googlegroups.com>
Subject: Re: [vocbench-user] Re: Problem creating ontology that uses OWL and SKOS simultaneously
Dear Armando and Roland
--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
vocbench-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/eeb6c958-97fd-4af1-847d-20cb129c7408n%40googlegroups.com.