- From: Pat Hayes <phayes@ihmc.us>
- Date: Fri, 6 Nov 2009 10:44:58 -0600
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, John Graybeal <jbgraybeal@mindspring.com>, Neubert Joachim <J.Neubert@zbw.eu>, Simon Reinhardt <simon.reinhardt@koeln.de>, SKOS <public-esw-thes@w3.org>
On Nov 5, 2009, at 2:51 PM, Antoine Isaac wrote: > Hi Kingsley, > >> 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? > > > > Well, as Leonard just put it, there can perfectly concepts for > persons (as part of authority files in Libraries, for example). > You could have a skos:Concept Mrs_Obama with a Library A as > dc:creator, and another Concept Michelle_Obama created by Library B. > Using owl:sameAs between those is certainly not ideal, as you end up > with one resource being created by two different agents, and > probably at different times, and so on. exactMatch fits that case. > If I follow this and your previous post, then sameAs will almost never be true in the SKOS world, correct? The only case I can think of would be where a library puts a new indexing system in place (for its existing records), and retains the old one for legacy reasons, with sameAs links between the old and new indices. That is, co-reference between items in thesauri (both referring to FLOTUS) is irrelevant to identity of the *concepts*. Do I have this more or less right? Pat > Antoine > > >> 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 >>> >>> >>> >>> >>> >>> > > ------------------------------------------------------------ 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
Received on Friday, 6 November 2009 16:46:00 UTC