- 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