W3C home > Mailing lists > Public > public-esw-thes@w3.org > November 2009

Re: [Dbpedia-discussion] Using DBpedia resources as skos:Concepts?

From: Pat Hayes <phayes@ihmc.us>
Date: Fri, 6 Nov 2009 10:23:20 -0600
Cc: John Graybeal <jbgraybeal@mindspring.com>, Neubert Joachim <J.Neubert@zbw.eu>, Simon Reinhardt <simon.reinhardt@koeln.de>, SKOS <public-esw-thes@w3.org>
Message-Id: <F605EE95-1E1A-45C0-A903-F535C5CE73FE@ihmc.us>
To: Kingsley Idehen <kidehen@openlinksw.com>

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.

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.

>
> 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.

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
Received on Friday, 6 November 2009 16:24:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:39:05 GMT