- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Sun, 08 Nov 2009 18:29:05 +0100
- 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 UTC