[openbiblio-dev] Example Book RDF data from BL, Birth/Death dates, example

William Waites william.waites at okfn.org
Tue Oct 26 14:05:51 UTC 2010

On Tue, Oct 26, 2010 at 02:22:36PM +0100, Ben O'Steen wrote:
> <bibo:Book rdf:about="http://example.org/book/ABookUID">
>     <dcterms:title>Wave mechanics and molecular biology</dcterms:title>
>     <dcterms:contributor>
>       <!-- person/UUID is intended to be glopbally unique -->
>       <rdf:Description rdf:about="http://example.org/agent/AnAgentUID">
>         <rdf:type rdf:resource="foaf:Person"/>
>         <foaf:name>Broglie, Louis de</foaf:name>
>         <!--- 1892-1987   NEEDS TO BE ENCODED, see below -->
>       </rdf:Description>
>     </dcterms:contributor>

Would be nice if we could somehow distinguish between creator
and contributor. But I know from previous dealings with MARC21
that this is hard.

>     <dcterms:publisher>
>       <rdf:Description
> rdf:about="http://example.org/agent/AnotherAgentUID">
>         <rdf:type rdf:resource="foaf:Organisation"/>
>         <foaf:name>Addison-Wesley</foaf:name>
>       </rdf:Description>
>     </dcterms:publisher>

I would call this a foaf:Agent generally (which may also be a
foaf:Organisation but presumably could also be a foaf:Person
in the case of manuscripts, zines, etc).

>     <dcterms:issued>1966</dcterms:issued>
>     <dcterms:language
> rdf:datatype="http://purl.org/dc/terms/ISO639-2">eng</dcterms:language>

How equivalent is this construction to the one the BL uses? 
It's definitely more concise but the BL one is more "standard" DC.

>     <!-- should this also be 'extracted' like publisher/author? -->
>     <dcterms:isPartOf>
>       <rdf:Description>
>         <rdfs:label>Addison;Wesley international series in
> biology</rdfs:label>
>       </rdf:Description>
>     </dcterms:isPartOf>

I think the answer is, yes it should be extracted because I think
a common query is going to be "show me all of the books in this

>     <dcterms:identifier>
>       <rdf:Description>
>         <AUTHORITY rdf:resource="http://www.bl.uk"/>
>         <bibo:identifier>009023285<bibo:identifier>
>       </rdf:Description>
>     </dcterms:identifier>

I would prefer a dedicated predicate here, e.g.

	foo:blid rdfs:subClassOf bibo:identifier;
            authority <http://www.bl.uk>.

	book foo:blid "009023285".

Or even better,

	book foo:blid <http://purl.org/xyz009023285>.

>     <dcterms:identifier>GB6617301</dcterms:identifier>

Why not bibo:identifier? (May as well go whole hog...)

>     <!-- if this record had a ISBN:
>     <bibo:isbn10>1234567891</bibo:isbn10>
>     -->

Would prefer a URI here, particularly because we might want to
annotate the ISBN... So

        book bibo:isbn10 <urn:isbn:1234567891>.	

> Should we model this as an event (like http://vocab.org/bio) such that
> each life extent works out to something like (switching to N3 as I only
> did the above in RDF/XML to match the incoming record.)

I think we should. This is very similar I did in the original

> agent:AnAgentUID 
>     a foaf:Person
>     ; foaf:name "Broglie, Louis de"
>     ; bio:event [ a bio:Birth
>                   ; bio:principal agent:AnAgentUID
>                   ; bio:date "1892"
>                 ]

I think "bio:principal" here might be redundant, but apart from that...

The only other thing I would suggest -- and I think you are doing this
anyways, is minting URIs for the original records... Which are just 
identified with blank nodes in the source and having an opmv povenance
block that links these new records to it.

Saw in another mail of yours which I can't find now a question of whether
opmv:used could refer to a select statement, the answer is I don't think
so. It must refer to an artefact frozen in time. However you could
describe the nature of the process in those terms. An "evolution 
pattern" as described in this recent paper [0] that operates on the
sources specified with opmv:used to produce the resulting artifact.


[0] http://www.informatik.uni-leipzig.de/~auer/publication/EvoPat.pdf

More information about the openbiblio-dev mailing list