[open-bibliography] New BNB sample data available

Antoine Isaac aisaac at few.vu.nl
Thu Feb 3 21:46:57 UTC 2011


Hi Jeff,

As this coordination issue is complex indeed, this was not handled in SKOS. Instead it relies on specific extensions to be designed--this is MADS/RDF [1] is made for, in fact!

Antoine

[1] http://www.loc.gov/standards/mads/rdf/


> It would be nice if the constructed heading could have references to the component LCSH concepts.
>
> It seems unfortunate that skos:OrderedCollection and skos:Concept are disjoint. If they weren't, then the component concepts could be listed in a skos:memberList. Barring that, I could imagine a new SKOS property like this to expression the coordination:
>
> skos:coordinates a owl:ObjectProperty ;
> 	rdfs:domain skos:Concept ;
> 	rdfs:range skos:OrderedCollection .
>
> Jeff
>
>> -----Original Message-----
>> From: public-lld-request at w3.org [mailto:public-lld-request at w3.org] On
>> Behalf Of Antoine Isaac
>> Sent: Thursday, February 03, 2011 1:54 PM
>> To: open-bibliography at lists.okfn.org; public-lld
>> Subject: Re: New BNB sample data available
>>
>> Hi Corine,
>>
>> [ I'm ccing the library linked data list: this begins to smell like
>> real *linked* data that has tricky LD issues ;-)  ]
>>
>> It's really great if BNB explicitly includes links to LD sources like
>> LCSH!  It deserves feedback indeed...
>>
>> The way you make the connection puzzles me a bit, though. Taking the
>> following example:
>>
>>     <rdf:Description>
>>       <dcterms:title>London fragments : a literary
>> expedition</dcterms:title>
>>       <dcterms:alternative>Londoner Fragmente.
>> English</dcterms:alternative>
>> [...]
>>       <dcterms:subject>
>>         <rdf:Description>
>>           <skos:inScheme
>> rdf:resource="http://id.loc.gov/authorities#conceptScheme" />
>>           <skos:prefLabel>Görner, Rüdiger--Travel--England--
>> London.</skos:prefLabel>
>>           <rdf:type
>> rdf:resource="http://www.w3.org/2004/02/skos/core#Concept" />
>>         </rdf:Description>
>>       </dcterms:subject>
>>       <dcterms:subject>
>>         <rdf:Description
>> rdf:about="http://id.loc.gov/authorities/sh2008107012#concept">
>>           <skos:inScheme
>> rdf:resource="http://id.loc.gov/authorities#conceptScheme" />
>>           <skos:prefLabel>Literary landmarks--England--
>> London.</skos:prefLabel>
>>           <rdf:type
>> rdf:resource="http://www.w3.org/2004/02/skos/core#Concept" />
>>         </rdf:Description>
>>       </dcterms:subject>
>>
>>
>> I have tried in the past to exploit the record data and make connection
>> between with existing concepts from other sources, and of course there
>> are many problems (because of pre-coordination, or just because of
>> typos or label changes in the considered KOS).
>> So I understand why you define "on-the-fly" (and "in-the-data") the
>> concepts that you can't find in the LCSH linked data. And I think this
>> is a reasonable solution.
>>
>> What puzzles me is the second subject, for which you could recognize an
>> existing concept from id.loc.gov. Here you duplicate the data, by
>> copying some info you have. I'd have expected
>> <dcterms:subject
>> rdf:resource="http://id.loc.gov/authorities/sh2008107012#concept">
>> alone.
>>
>> Here you are in effect duplicating data that is served on id.loc.gov.
>> Is it to give some minimum data that you want to provide applications
>> with, so that they would not have to go and fetch data from id.loc.gov,
>> a sort of "data cache"?
>>
>> Also, is it generated only from the original book record at BL only? If
>> yes, there are two risks:
>>
>> - that your data is less complete than the one of other services [1],
>> but still it lets your data consumer think that this it is complete. In
>> which case, these consumers could decide to have their services not
>> follow their nose to the more complete data, which could be harmful to
>> everyone.
>>
>> - that your data conflicts with the reference one. This is in fact the
>> case, as your prefLabel ends with a period ("Literary landmarks--
>> England--London.") while the ones at id.loc.gov do not [2]. Ok, here I
>> am quite nitpicking, but there could be cases where the mismatch is
>> bigger.
>>
>> Best,
>>
>> Antoine
>>
>> [1] e.g., if you don't have skos:broader that id.loc.gov has for LCSH
>> concepts, or the xml:lang tag with "en" for your skos:prefLabel
>> [2] http://id.loc.gov/authorities/sh2008107012.rdf
>>
>>> ---------------------------------------------------------------------
>> -
>>>
>>> Message: 1
>>> Date: Tue, 1 Feb 2011 16:19:41 -0000
>>> From: "Deliot, Corine"<Corine.Deliot at bl.uk>
>>> Subject: [open-bibliography] New BNB sample data available
>>> To:<open-bibliography at lists.okfn.org>
>>> Message-ID:
>>> 	<19BB7EB59CBC594D8DD9F3ACA1EB24A201538E6A at w2k3-bspex2.ad.bl.uk>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> This is to let you know that there are two new sample data files
>>> available from our website
>>>
>>> http://www.bl.uk/bibliographic/datasamples.html
>>>
>>>
>>>
>>> The first file is an updated version of the BNB in RDF/XML. The
>>> substantive change is that the conversion now carries over the MARC
>>> country code for the place of publication.
>>>
>>>
>>>
>>> The second file is based on the same conversion but includes links to
>>> linked data sources: LCSH in SKOS, MARC country and language codes,
>>> Dewey info, Lexvo, GeoNames and the RDF Book Mashup.
>>>
>>>
>>>
>>> Feedback welcome.
>>>
>>>
>>>
>>> Cheers
>>>
>>>
>>>
>>> Corine
>>>
>>>
>>>
>>>
>>>
>>> Corine Deliot
>>>
>>> Metadata Standards Analyst
>>>
>>> British Library
>>>
>>> Boston Spa, Wetherby
>>>
>>> West Yorkshire LS 23 7BQ
>>>
>>
>





More information about the open-bibliography mailing list