- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 05 Nov 2009 15:23:53 -0500
- To: Pat Hayes <phayes@ihmc.us>
- CC: John Graybeal <jbgraybeal@mindspring.com>, Neubert Joachim <J.Neubert@zbw.eu>, Simon Reinhardt <simon.reinhardt@koeln.de>, SKOS <public-esw-thes@w3.org>
Pat Hayes wrote: > > On Nov 5, 2009, at 1:25 PM, John Graybeal wrote: > [SNIP] >> Which suggests "owl:sameAs works better for Named Entitites" is not >> a good practice to follow, doesn't it? > > Agree, this dictum makes no sense at all. Yes, but Named Entities has become a moniker (totally subjective of course) for People, Places and other so called real things. Thus, owl:sameAs between two Concepts (which have URIs) is absolutely fine, but this then begs the question: when specifically does one use "skos:exactMatch" etc? Based on my response John (few minutes ago), I am assuming that the partitioning of so called Named Entities and Subject Matter Concepts was the line of delineation sought in SKOS which is about Subject Matter/Heading style Concept Schemes? Personally, owl:sameAs works absolutely fine for a Person, Document, or Subject Matter Concept or Heading, as long as its about different Names for the same Thing (in the eyes of the claim maker). Desperately trying to reconcile specs and general language en route to clarity etc. Kingsley > > Pat Hayes > >> >> John >> >> >> >> On Nov 5, 2009, at 1029, Kingsley Idehen wrote: >> >>> Neubert Joachim wrote: >>>> Hi Simon, >>>> 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, but their use targets vary i.e. skos:exactMatch >>> works better for Concept Schemes (where the world view assumes Named >>> Entities e.g., "People" aren't Concepts) while owl:sameAs works >>> better for Named Entities (people, places, and other typical real >>> more things, so to speak). >>> >>> >>> Links: >>> >>> 1. >>> http://linkeddata.uriburner.com/about/html/http/www.w3.org/2004/02/skos/core%01exactMatch >>> >>> >>> Kingsley >>>> [SNIP] >>>> .. >>>> Cheers, Joachim >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *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 >>>> >>> >>> >>> -- >>> >>> >>> Regards, >>> >>> Kingsley Idehen Weblog: >>> http://www.openlinksw.com/blog/~kidehen >>> President & CEO OpenLink Software Web: http://www.openlinksw.com >>> >>> >>> >>> >>> >> >> >> -------------- >> I have my new work email address: jgraybeal@ucsd.edu >> -------------- >> >> John Graybeal <mailto:jgraybeal@ucsd.edu> >> phone: 858-534-2162 >> Development Manager >> Ocean Observatories Initiative Cyberinfrastructure Project: >> http://ci.oceanobservatories.org >> Marine Metadata Interoperability Project: http://marinemetadata.org >> >> > > ------------------------------------------------------------ > IHMC (850)434 8903 or (650)494 3973 > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32502 (850)291 0667 mobile > phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes > > > > > > -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President & CEO OpenLink Software Web: http://www.openlinksw.com
Received on Thursday, 5 November 2009 20:24:27 UTC