- From: Daniel Rubin <rubin@med.stanford.edu>
- Date: Fri, 08 Jun 2007 03:24:12 -0700
- 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
>(http://www.w3.org/2006/07/SWD/wiki/SkosDesign/RelationshipsBetweenLabels/ProposalThree)
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.
>Cheers,
>
>Antoine
>>
>>>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.
>>>[snip]
>>>>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.
>>
>>
>>>Cheers,
>>>
>>>Antoine
>>
>>
>
Received on Friday, 8 June 2007 10:24:21 UTC