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

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

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Sun, 08 Nov 2009 18:29:05 +0100
Message-ID: <4AF6FFE1.7060103@few.vu.nl>
To: Pat Hayes <phayes@ihmc.us>
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>
Pat Hayes a écrit :
> 
> 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?


Yes.


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


Not even then... If C1 is the legacy concept, and C2 the new one, they would have different management info, perhaps different notes/definitions attached to them, semantic relations (broader/narrower/related) to different concepts...
So I would advise against using sameAs in such a concept.
sameAs would be rather used in case where different identification schemes have been created for one concept, as in [1]



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


Yes. Of course one can argue that it is a necessary condition, but not a sufficient one. 

By the way, Pat, I hope that the example [1] can shed a bit more light in your quest for what a SKOS concept is. Especially you can look at how the dcterms:created and dcterms:modified are used.
I guess that the general idea of Murano glass did not come into existence at 1986-02-11T00:00:00-04:00.
SKOS concepts are very practical entities, almost "documents" (albeit very specific, controlled documents) about more general ideas. And of course these things can exist for persons, eg. [2].

Antoine

[1] http://id.loc.gov/authorities/sh85055118.rdf
[2] http://stitch.cs.vu.nl/vocabularies/rameau/ark:/12148/cb11944615b

> 
> 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 Sunday, 8 November 2009 17:29:49 GMT

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