Re: Recommendations: URIs

All
 
It seems to me it would be useful if there were some starter sets of instance
URIs for bibliographic works, expressions, and manifestations (using the FRBR
model), or bibliographic resources (using ISBD) - with a separate treatment for
items.
 
Items first: a simple pattern for minting URIs is (domain for holding library) +
(item barcode) if physical, or http URI for digital. (De-)duplication is
generally not an issue for items.
 
For FRBR WEM or ISBD Resource: National bibliographies seem an obvious starting
point (certainly outside of the US). National agencies (e.g. British Library)
could publish URIs for "their" stuff. A simple pattern for minting these URIs
might be (domain for agency) + (local identifier, eg British National
Bibliography number) + {nothing for ISBD Resource instance, "W" for FRBR Work
instance, "E" for FRBR Expression instance, "M" for FRBR Manifestation instance}
e.g. http://bl.info/bnb#1234 (Resource), http://bl.info/bnb#1234W (Work),
http://bl.info/bnb#1234E (Expression), http://bl.info/bnb#1234M (Manifestation).
 
What would actually be published is a set of triples of the form:
 
<WEM/Resource URI> <has BNB number> "BNB number".
 
This would allow other projects to avoid creating duplicate URIs subsequently
linked with OWL equivalence properties.
 
A project would have to know, say, the BNB number ... The same approach could
use other identifiers such as ISBN, etc., although there is significant
ambiguity (not everything has an ISBN, some ISBNs are plain wrong, etc.).
Extending this further, it might be necessary to publish some additional triples
giving further identification data such as title and edition (i.e. a minimal
identification/description set of triples):
 
<WEM/Resource URI> <has title proper> "The title".
<WEM/Resource URI> <has publication date> "2008".
etc.
 
This approach also minimises the quantity of triples that an agency needs to
publish, reduces barriers due to rights issues, and extends the formal role of a
national bibliographic agency in recording, preserving, and disseminating the
publication output of that nation.
 
Also, declaring which URI minting pattern is used will allow projects to mint
future-proof URIs for local stuff.
 
OK, in practice things would not be as straightforward (e.g. national
bibliography numbers referencing Manifestations instead of Expressions or Works,
ISBNs usually reference Manifestations but are often used to reference Works,
etc.).
 
I guess OCLC could use a similar approach on behalf of its members (especially
those who are national agencies).
 
Does this make sense?
 
Cheers
 
Gordon
 
 
 
 


On 28 April 2011 at 04:51 Emmanuelle Bermes <manue@figoblog.org> wrote:

> >
> > We can obviously change the wording. But I still am not sure what we are
> > promoting in terms of prioritizing the creation of URIs. Can we use Tom's
> > wording?
> >
> > "Very broadly, the "library world", along with standards
> > developers such as W3C, FOAF, and DCMI should work on assigning
> > URIs to properties and classes.  But creators of specific
> > Linked Data projects should be concerned first and foremost
> > with _creating_ URIs for their things -- the "instances" about
> > they want to make statements -- then re-use URIs for properties
> > and classes (when possible) in order to make those statements."
>
> +1 for Tom's wording : great summary, as usual ;-)
> Emma
>
>
> >
> > kc
> >
> > Quoting Ed Summers <ehs@pobox.com>:
> >
> >> On Wed, Apr 27, 2011 at 4:24 PM, Thomas Baker <tbaker@tbaker.de> wrote:
> >>>
> >>> I think we're agreeing that "assigning URIs" is a key point
> >>> but that for the sake of readers we need to distinguish "URIs
> >>> for properties and classes" from "URIs for dataset items
> >>> (instances)".
> >>
> >> Nicely put Tom. I second Jeff's recommendation to at least reference
> >> ABox and TBox to ground the more library friendly definitions wherever
> >> that may happen: glossary, etc.
> >>
> >> //Ed
> >>
> >>
> >
> >
> >
> > --
> > Karen Coyle
> > kcoyle@kcoyle.net http://kcoyle.net
> > ph: 1-510-540-7596
> > m: 1-510-435-8234
> > skype: kcoylenet
> >
> >
> >
>