- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Thu, 05 Nov 2009 23:01:39 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- CC: Neubert Joachim <J.Neubert@zbw.eu>, Simon Reinhardt <simon.reinhardt@koeln.de>, SKOS <public-esw-thes@w3.org>, Pat Hayes <phayes@ihmc.us>, dbpedia-discussion@lists.sourceforge.net
Kingsley, >>>> Sorry for causing some misunderstanding: My point was not that you >>>> SHOULD use skos:Concept. What I rather wanted to say is that it does >>>> no harm and that it's already in use for named entites. This point >>>> arises from the suggestion to use skos:exactMatch/closeMatch. These >>>> properties are sub-sub-properties of skos:semanticRelation, which >>>> entails that subject and object of these properties are instances of >>>> skos:Concept (since skos:Concept are domain and range for >>>> skos:semanticRelation). >>>> >>>> The great advantage of skos:exactMatch/closeMatch (over owl:sameAs) >>>> is that their semantic doesn't smush the resources with all their >>>> properties (like the administrative properties you mentioned). >>> Joachim, >>> >>> What do you mean by "smush" are you referring to the union expansion >>> that results from combing data from all the data sources in the >>> owl:sameAs relation? I pose my question with the skos:exactMatch >>> description page URL [1] for context. I see Transitivity and >>> Symmetry, which are factors re. decision making by reasoners re: >>> union expansion based on participants in the relation. Note, by >>> "union expansion" I mean the union of all data associated with the >>> data items in the relation. >>> >>> Primarily, I just want clarification about "smushing", relative to >>> the property definition exposed by the skos:exactMatch URI, more >>> than anything else. Thus, far I've simply assumed that >>> skos:exactMatch and owl:sameAs have similar implementation mechanics >>> re. union expansion, >> >> >> Just to clarify it, in case the mails that came after have not done >> it: using skos:exactMatch should *not* lead to attributing to the two >> resouces that it relates the union of all data that is attached to them. >> >> I don't understand why transitivity and symmetry alone would allow a >> reasoner to infer such "smushing/union expansion". Let's consider a >> ex:connectedByARoad property. I can perfectly make it transitive and >> symmetric, and yet all the towns that this property relates are not >> one and the same. > Sure, but the relation you use is neither "owl:sameAs" nor > "skos:exactMatch". I think the subtle item here is that the property > labels do actually matter. ex:connectedByARoad in no way conveys > co-reference. Er, yes. My comment was havily influenced by your "which are factors re. decision making by reasoners". Labels are not such a factor, so I inferred you were only basing your claim on the formal semantic axioms. > BTW - your analogy is basically similar to a Transitivity > example I put out re. SKOS and DBpedia a few weeks ago [1] :-) :-) > I think your other response re. Ms. Obama goes back to the Subject > Matter/Heading delineation which I believe is the overarching focal > point of of SKOS (classification by phenotype so to speak). Its about > concept schemes and the hierarchies that may exist within and across > schemes in different data spaces. Whereas, with "owl:sameAs" we are > dealing with similar issues, but the orientation feeds of a genotype, so > to speak. As long as you're ok with the fact that there can be concepts/subject matters that are corresponding to persons (even though they would not be persons themselves), I'm ok... Antoine [snip] >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *Von:* Simon Reinhardt [mailto:simon.reinhardt@koeln.de] >>>> *Gesendet:* Do 05.11.2009 17:35 >>>> *An:* Neubert Joachim >>>> *Cc:* Richard Cyganiak; dbpedia-discussion@lists.sourceforge.net; >>>> SKOS; Pat Hayes >>>> *Betreff:* Re: AW: [Dbpedia-discussion] Using DBpedia resources as >>>> skos:Concepts? >>>> >>>> Hi >>>> >>>> Neubert Joachim wrote: >>>> > In my eyes, it's completely ok to use skos:exactMatch or >>>> skos:closeMatch >>>> > in a situation like this (I did it myself for the STW Thesaurus for >>>> > Economics mapping to dbpedia). >>>> > > Thesauri and classifications are not restricted to abstract >>>> concepts. >>>> > Some thesauri deal explicitly with individual things, e.g. the widely >>>> > used Getty "Thesaurus of Geographic Names" or "Union List of Artist >>>> > Names". Other thesauri (like STW) have sections (or facets, as >>>> Leonard >>>> > put it) on geografic names along with others containing "pure" >>>> concepts. >>>> > SKOS, as I understand it, is intended to cover all this and to be >>>> used >>>> > beyond strict class hierarchies or class/individual dichotomies. >>>> >>>> While I agree that using real-world entities for classification is >>>> ok I don't think this means you have to declare them to be >>>> (skos:)concepts. The "has subject" relationship in FRBR [1] for >>>> example can link a work to a concept but also to places, people, >>>> events, other works, etc. So in this case you can use real-world >>>> entities to classify the work (to state what its subjects are) but >>>> that doesn't mean you declare all those entities to be conceptual. >>>> >>>> So in my eyes there's still value in keeping (skos:)concepts and >>>> other things apart. Concepts to me are closer to classes than to >>>> individuals. And as Dan pointed out concepts have administrative >>>> data attached - they get created and changed etc. so they're >>>> basically units of organisation. >>>> >>>> I'd therefore prefer using the UMBEL terms or something else for >>>> aligning real-world entities and concepts. >>>> >>>> > By the way, some of the SKOS properties (especially the >>>> > prefLabel/altLabel/hiddenLabel semantics) can be useful in a broad >>>> range >>>> > of applications. Eg. dbpedia itself could be used as a great >>>> source for >>>> > synonym candidates by mapping the resources to skos:Concept and the >>>> > labels for dbpedia:redirect resources to skos:altLabel. >>>> >>>> Yup, it has a lot of useful annotation terms. They are all declared >>>> to be annotation properties and deliberately don't have skos:Concept >>>> in their domain. So you can use them on anything which is great! >>>> >>>> Regards, >>>> Simon >>>> >>>> >>>> [1] http://archive.ifla.org/VII/s13/frbr/frbr_current5.htm#5.2 - >>>> scroll down to "5.2.3 Subject Relationships" >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day trial. Simplify your report design, integration and >>>> deployment - and focus on what you do best, core application coding. >>>> Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Dbpedia-discussion mailing list >>>> Dbpedia-discussion@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion >>>> >>> >>> >> >> > >
Received on Thursday, 5 November 2009 22:02:12 UTC