- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Tue, 09 Nov 2010 23:56:10 +0100
- To: "Tillett, Barbara" <btil@loc.gov>
- CC: 'Ross Singer' <ross.singer@talis.com>, "Young,Jeff (OR)" <jyoung@oclc.org>, public-lld <public-lld@w3.org>
> And what is the advantage of having the two URIs rather than maintaining a single source for the person and getting to the relationship data in other ways? Some people do get uncomfortable with that kind of mixing [1]. Personally I'm quite relaxed, though :-) >Or is it that there is only one set of descriptive data and the two URIs associated with that data to use as appropriate? (Am I understanding correctly how this works?) Exactly! Antoine [1] http://lists.w3.org/Archives/Public/public-esw-thes/2009Nov/0000.html (better viewed in all the thread's splendor: http://lists.w3.org/Archives/Public/public-esw-thes/2009Nov/thread.html ) :-) > -----Original Message----- > From: rxs@talisplatform.com [mailto:rxs@talisplatform.com] On Behalf Of Ross Singer > Sent: Tuesday, November 09, 2010 5:33 PM > To: Tillett, Barbara > Cc: Young,Jeff (OR); public-lld > Subject: Re: VIAF contributor model > > There are two resources modeled: > > http://viaf.org/viaf/111894442/#skos:Concept > > and > > http://viaf.org/viaf/111894442/#foaf:Person > > (well, obviously there are more than that minted at: > http://viaf.org/viaf/111894442/rdf.xml) > > the first would appropriate for biographies of Bob Dylan, etc. the latter for works by him. > > -Ross. > > On Tue, Nov 9, 2010 at 5:11 PM, Tillett, Barbara<btil@loc.gov> wrote: >> I still remain concerned that by using SKOS for names of persons and >> corporate bodies, there is either an explicit or implied "is the >> subject of" relationship going on for the person/corporate body being >> described with respect to some work. Am I wrong? - Barbara Tillett >> >> >> >> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On >> Behalf Of Young,Jeff (OR) >> Sent: Tuesday, November 09, 2010 5:05 PM >> To: public-lld >> Subject: RE: VIAF contributor model >> >> >> >> Thanks for all the feedback. Sorry for my lag following up. >> >> >> >> VIAF still needs to deliver more substance to fulfill its potential, >> but the next release should improve interoperability while adding >> support for foaf:Organization/rdaEnt:CorporateBody. Mockups of Jane >> Austen and Die deutsche Nationalbibliothek are attached. >> >> >> >> As suggested back at the start of this thread, SKOS will play a core >> infrastructure role in the next release. Each contributor will be >> modeled as a skos:ConceptScheme and every contributed record will be >> modeled as a skos:Concept in the contributor's scheme. The contributed >> concept URIs coined by VIAF will be based on the contributor's >> "record" ID and will behave by redirecting to the VIAF cluster to >> which it is matched (which could change over time). >> >> >> >> Here is a test system URI for a contributed SELIBR record (207420) to >> demonstrate: >> >> >> >> http://test.viaf.org/viaf/sourceID/SELIBR|207420#skos:Concept >> >> >> >> Tangent: IMO, Library Linked Data authority systems in the future >> SHOULD be based on skos:ConceptScheme/skos:Concept and we're starting >> to see this with LCSH and SELIBR. I suspect that ANY >> skos:ConceptScheme could potentially be viewed as an "authority >> system" and clients should be able to use them as such without assuming any architecture or domain model dependencies. >> >> >> >> For VIAF contributors that choose to follow the SKOS model in their >> own domains, VIAF should map to their URIs using owl:sameAs. You can >> observe this in the attached example for Jane Austen involving SELIBR: >> >> >> >> <http://viaf.org/viaf/sourceID/SELIBR%7C207420#skos:Concept> >> >> skos:inScheme<http://viaf.org/authorityScheme/SELIBR> ; >> >> owl:sameAs<http://libris.kb.se/resource/auth/207420#concept> . >> >> >> >> I suspect there will be some concern that VIAF is coining "alias" >> URIs, but I would argue that intentional HTTP URI aliases play a >> *functional role* in Linked Data by decentralizing information *about* >> the thing. SELIBR can deliver its information about "the thing" from >> its URI and VIAF can deliver more (especially linking) information >> from its URI. The information may come from different perspectives and >> yet the players mutually agree it's the same "real world" thing they're describing. >> >> >> >> The solution for the http://www.w3.org/TR/skos-reference/#S14 >> integrity constraint for skos:prefLabel on "clusters" is still unclear >> to me and thus won't be addressed in the next release. (Sorry.) The >> custom properties viaf:hasEstablishedForm and viaf:hasXRefAlternate >> properties will continue to be used for now although the use cases for them are unclear. >> >> >> >> Nevertheless, I want to align the VIAF ontology with SKOS/SKOSXL >> wherever possible and so the viaf:Heading class will be upgraded to >> skosxl:Label in the ontology like so: >> >> >> >> viaf:Heading rdfs:subClassOf skosxl:Label . >> >> >> >> In deference to FRSAD, the next release of VIAF will continue to treat >> labels (i.e. viaf:Headings) as 1st class identifiable resources at the >> expense of using plain literals. Without practical use cases, I'm >> uncomfortable with this choice. >> >> >> >> Jeff >> >> ________________________________ >> Please consider the environment before printing this email. >> >> Find out more about Talis at http://www.talis.com/ shared innovationT >> >> Any views or personal opinions expressed within this email may not be >> those of Talis Information Ltd or its employees. The content of this >> email message and any files that may be attached are confidential, and >> for the usage of the intended recipient only. If you are not the >> intended recipient, then please return this message to the sender and >> delete it. Any use of this e-mail by an unauthorised recipient is prohibited. >> >> Talis Information Ltd is a member of the Talis Group of companies and >> is registered in England No 3638278 with its registered office at >> Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB. >> > >
Received on Tuesday, 9 November 2010 22:56:07 UTC