- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 06 Nov 2009 11:32:10 -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 2:23 PM, Kingsley Idehen wrote: > >> 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. > Pat, > real things. Hmmm. As opposed, I presume, to not-real things? So is > Sherlock Holmes a real thing? He is, after all, a Person. How about > the quantity of gravel that I recently ordered to have delivered to my > driveway next weekend? Not the gravel, you understand, but the > *quantity* of that gravel. Is that a real thing? I have an urgent, > real, need to talk about it in communications with others over the Web. As I said, this is a subjective moniker, not necessarily one I subscribe to etc.. > >> >> 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). > > If it is about different names for the same thing, why does that not > work everywhere? (It does.) > >> >> Desperately trying to reconcile specs and general language en route >> to clarity etc. > > Me too. BUt Im also trying to preserve the small amount of clarity > that we have managed to achieve. So at this point the clarity we have is still fundamentally this: Different Names for the Same Thing. Beyond that, it gets problematic etc.. Kingsley > > Pat > > >> >> 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 >> >> >> >> >> > > ------------------------------------------------------------ > 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 Friday, 6 November 2009 16:32:49 UTC