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:44:58 -0600
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>
Message-Id: <6B92AE98-251C-4C79-9237-06ED745FA976@ihmc.us>
To: Antoine Isaac <aisaac@few.vu.nl>

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 GMT

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