W3C home > Mailing lists > Public > public-swd-wg@w3.org > June 2007

Re: [SKOS] chatting on SKOS concepts and ontology classes (was Re: ISSUE-26: SimpleExtension proposal)

From: Daniel Rubin <rubin@med.stanford.edu>
Date: Fri, 08 Jun 2007 03:24:12 -0700
Message-Id: <>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: SWD WG <public-swd-wg@w3.org>

At 01:36 AM 6/8/2007, Antoine Isaac wrote:

>Daniel Rubin a écrit :
>>At 08:42 AM 6/6/2007, Antoine Isaac wrote:
>>>Hi Daniel,
>>>>>>Perhaps it would be helpful if you provided 
>>>>>>the formal definition of "Concept." Is this 
>>>>>>the same thing as a "Term?" Clearly, there 
>>>>>>is a difference between actual things and the way we talk about things.
>>>>>OK, roughly copy-pasting from wikipedia. Not 
>>>>>fully satisfied, but at least we have a 
>>>>>glimpse of the difference of level between the two notions:
>>>>>A concept is an abstract idea or a mental 
>>>>>symbol, typically associated with a 
>>>>>corresponding representation in language or 
>>>>>symbology, that denotes all of the objects 
>>>>>in a given category or class of entities, 
>>>>>interactions, phenomena, or relationships between them
>>>>So if I understand correctly, concepts are 
>>>>things in people's heads, NOT things that exist in reality.
>>>Let's say yes (because of course I consider 
>>>that everything which happens in my head and 
>>>that I communicate to others has some form of reality ;-)
>>>>Terms are labels for talking about either 
>>>>things in reality or concepts, yes?
>>>Mmmh, yes and no. If you look closely at the quotation I made:
>>>>>A "term" is a word, word pair, or word 
>>>>>group, that is used in specific contexts for a specific meaning.
>>Yes, but that "meaning" refers to what--a 
>>concept, or anything that word(s) represent? 
>>ie, this definition seems to be describing 
>>words in a dictionary. For example, "at the" 
>>would qualify as a "term" by your definition.
>You're right. The definition I quoted is 
>imprecise (but how to explain term in one 
>sentence? I clearly don't have time to review 
>all textbooks for that now). So let's consider, 
>taking your words, that "meaning" refer to some 
>concept. And that this is quite closely related 
>to what happens in a dictionary, indeed.
>>I had always thought that thesauri comprised 
>>terms that referred to "things" that people 
>>describe in a domain of discourse, such as "bookstore," etc.
>Yes. But be careful: thesauri do dot mandatorily 
>comprise concepts that refer to things people 
>describe: in a library (and many other places 
>where one uses a thesaurus), a thesaurus will 
>include a "car" subject, but nobody will want to 
>describe cars there. Notice that this is an 
>important difference with ontologies: if you 
>have a "car" class in an ontology, it is indeed 
>expected to be used in description of cars.
>>>you can see that there is slightly more to a 
>>>term than just a label. This "meaning load" is 
>>>actually what allowed people from thesaurus 
>>>community to speak about "broader term" and 
>>>"related term" for links that in SKOS we say 
>>>to exist between concepts (skos:broader and skos:related)
>>>This is the reason why I want to avoid the use 
>>>of "term" in Guus' proposal about relationship 
>>>between label. I prefer the more neutral 
>>>"lexicalization" (lexicalization does only say 
>>>that the word is related to some concept, not 
>>>that it carries a part of meaning with it)
>>This sounds to me like you are describing 
>>*language* and not *things* that people want to 
>>talk about in a domain of discourse.
>Cf my remark above. Yes, SKOS is mainly focused 
>on what you call the language level, because it 
>does not assume the existence of instances in 
>real world for the concepts defined with it. 
>There is not even a beginning of a problem when 
>introdcuing "unicorn" as a SKOS concept, for example.

And what I'm saying is that SKOS should enable 
people to make it explicit whether they are 
talking about things or language--this is 
necessary for interoperability. If you say SKOS 
enables this already, then we should assert a 
best practice for people to make the distinction 
explicit with SKOS constructs. I want to 
know  whether the "car" entity in my ontology is 
related to the "car" lexicalization in your thesaurus.

>>To me, lexicalization is about the way tokens 
>>can appear, but what they *represent* is what 
>>belongs in the thesauri, represented as "terms" 
>>(how they can appear in languages could be a property of the term).
>Yes, this analysis of lexicalization as tokens 
>(I call them labels) is pretty fitting what I 
>wanting to use, even clarifying it ;-)
>Bout don't forget that what thesauri 
>traditionally call "terms" are in SKOS approach 
>to be represented as instances of skos:Concept!

As above, SKOS should enable people to make 
explicit what they are talking about for 
interoperability--clearly, thesauri "terms" are not the same as "Concepts".

>In Current SKOS there is nothing between the 
>concept and its appearance in language (label). 
>And what traditional thesauri denote as term 
>relationship (that are indeed conceptual 
>relationship, as "broader term") is modelled in 
>SKOS using concept links (skos:broader)

"broader" and "narrower" are relations that 
should be used to connect only "terms" (aka 
lexicalizations). People should use different 
relations for concepts (e.g., subclass-of, etc)

>To add to this mutual clarification process: as 
>said, nothing like a "term" appears now in 
>current SKOS, it only popped up in the 
>discussion because of loosely wording used in 
>the proposals for solving the 
>RelationshipBetweenLabels issue. [and of course 
>I share a great deal of responsability for that 
>:-(] Hence my will to replace"term"by 
>"Lexicalization" (or by anything more neutral 
>than "term") in Guus' proposal 

It's clear to me now that thesauri and ontologies 
talk about two different sorts of 
things--lexicalizations vs things (in reality or 
not). We need to describe these differently with SKOS.

>>>>>>>Notice however that if there is a modeling 
>>>>>>>distinction, there is no exclusion. You 
>>>>>>>can have skos:Concepts (my:Car rdf:type 
>>>>>>>skos:Concept) that are also RDFS/OWL 
>>>>>>>classes (ex:Car rdf:type rdfs:Class) so 
>>>>>>>that you can create 'objects' which are 
>>>>>>>classified under it (ex:danielsCar 
>>>>>>>rdf:type ex:car). This would be needed by 
>>>>>>>a range of applications (including RadLex) 
>>>>>>>that require using SKOS features to define 
>>>>>>>conceptual entities that are actually classes in ontologies.
>>>>>>I'm confused by this statement. You say you 
>>>>>>can have skos:Concepts (my:Car rdf:type 
>>>>>>skos:Concept) that are also RDFS/OWL 
>>>>>>classes (ex:Car rdf:type rdfs:Class)--how 
>>>>>>can it be that a concept is also something tangible such as a car?
>>>>>I'm not saying that a concept can be 
>>>>>tangible as a car, I'm saying that a concept 
>>>>>can be associated to a set of things (its 
>>>>>extension), that is, interpreted as a class (just as introduced in [1]).
>>>>>[1] http://www.w3.org/TR/rdf-schema/#ch_classes
>>>>Sorry, but I do not understand how a concept 
>>>>can be interpreted as a class. I can 
>>>>understand that skos:Concept can have 
>>>>relations to other things, such as 
>>>>rdfs:Class, but that is not the same thing as 
>>>>saying that the concept is interpreted as a 
>>>>class. Or perhaps I don't understand exactly what you are saying above.
>>>Well, a concept (understood here as the 
>>>general 'concept' notion, not only SKOS one) 
>>>can have an intensional interpretation (its 
>>>'meaning', definition: "has 4 wheels etc.") 
>>>and an extensional interpretation (the objects 
>>>it categorizes: my car, your car, the neighbour's car).
>>>It is true that SKOS deals only with the first 
>>>aspect: it does not anticipate what could be 
>>>the instances of a skos:Concept, and its 
>>>definition belongs primarily to the informal 
>>>realm (text definitions, labels, semantic 
>>>links which interpretation can be rather fuzzy like 'broader')
>>>On the other hand, OWL deals primarily with 
>>>the extensional aspects. Semantics of class 
>>>are indeed based on the possible instances of 
>>>this class. For example, if you say that the 
>>>class Car is a subClassOf class 
>>>TransportationMeans, you say that all 
>>>instances of the first (concrete cars) are instances of second.
>>And what I am saying is that there is a 
>>community of people creating OWL ontologies who 
>>want to use skos for interoperability with terminologies.
>I think that even if this is the direction 
>opposite to the one I demonstrated, this is 
>still quite the same concern. If you have
>my:aorta rdf:type owl:Class
>you can just assert
>my:aorta skos:prefLabel "aorta"
>And bang, it is now also an instance 
>skos:Concept, compatible with other 
>terminologies. You can say my:aorta skos:broader 
>his:BloodyThingsInbody, assuming that this is a 
>concept define in someone else's terminology.

Yes, but as I say above, if something is a 
skos:Concept, it could be a lexicalization or it 
could be an entity--two very different things.

>>>>>No. Here I want to say *an* owl:Class can be 
>>>>>*a* skos:Concept (ex:Car rdf:type owl:Class, ex:Car rdf:type skos:Concept)
>>>>Saying that *an* owl:Class can be *a* 
>>>>skos:Concept doesn't sound correct 
>>>>semantically to me. Can you give me an example of this?
>>>I agree that it sounds weird, but nothing actually prevents it!
>>>Look at the class:
>>>my:Car [ a owl:Class; rdfs:subClassOf my:TransportationMeans]
>>>You can actually add a SKOS triple like
>>>my:Car skos:prefLabel "car"
>>>And then, by virtue of RDFS semantics (and 
>>>because the rdfs:domain of the skos:prefLabel 
>>>property is skos:Concept) it also becomes a skos:Concept!
>>Perhaps we should have skos:Entity then in skos to avoid such problems?
>1. Personnally I don't see this as a problem. It 
>is more a feature, illustrating how SKOS and OWL 
>can live together when it is needed.
>2. Trying to clarify your proposal: skos:Entity 
>would refer to the concepts that denote "real 
>things", in the sense that they have instances, 
>and therefore can be considered as classes in ontologies?

Yes, and skos:Concept would be "lexicalizations". 
Perhaps we should rename skos:Concept to 
skos:Lexicalization. Then it would be clear 
whether people's tokens are entities or terms.

>And you would have something like skos:Entity 
>rdfs:subClassOf skos:Concept? With some rule 
>saying that all instances of skos:Entity are also instances of owl:Class?

I'd say instances of skos:Entity are instances of 
owl:Class. But skos:Entity and skos:Concept (I 
prefer skos:Lexicalization) are siblings.

>I don't feel it's a necessary step (because 
>there is compatibility between OWL and SKOS, as 
>I've demonstrated) but if you feel that this 
>could make things a lot clearer for users of 
>SKOS interested in ontologies (or vice versa) 
>then I *warmly welcome it* as a proposal and am 
>ready to help you formalizing it.

I think it would make things a lot clearer. And I 
think widespread adoption of SKOS will hinge on 
being clear in addition to being pertinent to people's needs.

>>>This trick has the disavantage to make your 
>>>knowledge base OWL full: you have an instance 
>>>of an OWL class (my:Car, as an instance of 
>>>skos:Concept) which is considered as a class 
>>>(my:Car as an instance of owl:Class).
>>>>>>It's fine if skos wants to stay restricted 
>>>>>>to how people "talk about things", but 
>>>>>>there needs to be a formal way of relating 
>>>>>>that to ontologies that contain classes 
>>>>>>representing the things themselves and that 
>>>>>>also want to talk about how they are named. That's what's going on in RadLex.
>>>>>Ok, so I suppose that you have 
>>>>>radlex:BloodVessel, which is an instance of 
>>>>>skos:Concept. And you want to say that you 
>>>>>will have ex:aorta as an instance of blood 
>>>>>vessel, i.e. ex:aorta rdf:type radlex:BloodVessel, don't you?
>>>>BloodVessel would be an instance of 
>>>>owl:Class. I don't know how you would relate this to skos:Concept.
>>>>Then the big thing to clarify is how to 
>>>>handle OWL ontologies where you have 
>>>>instances of owl:Class--how to relate this to skos:Concept?
>>>I hope to have demonstrated at least that this was possible.
>>>Be aware however that I played the devil's 
>>>advocate here, and that I would not generally 
>>>advocate this solution, unless in specific 
>>>cases, those where SKOS concepts can be 
>>>associated to these very precise class interpretation.
>>>Especially I think it does not apply to all 
>>>the cases where the SKOS concepts should only 
>>>be used in statements involving 
>>>skos:subject-like properties ("this book is 
>>>about blood vessels") and not be used in 
>>>rdf:type-like statements ("aorta is a blood vessel").
>>Ideally, skos should permit both types of statements.
Received on Friday, 8 June 2007 10:24:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:50 UTC