Re: Recommendations: URIs

Quoting "gordon@gordondunsire.com" <gordon@gordondunsire.com>:


> 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".

Doesn't this result in there being multiple bnb numbers for the same  
work and the same expression?

Alex Haffner demonstrated a flow chart of the Europeana process at the  
meeting in Cologne last year that was in two steps: the first looked  
just like this, and the second was where they merged works and  
expressions and assigned those new "merged" URIs. So you'd have

W123  ->  WXX
E123  ->  E99
M123

W789  -> WXX
E789  -> E88
M789

Well, it would be easier to explain on paper than in email, but you  
probably get the drift. I actually like the idea of the WEM having  
non-merged and merged identifiers -- although that's based on system  
management functions rather than the data model. The non-merged IDs  
can be local, while the merged ones will be ideal for sharing.  
(Hmmm,,, got to think about that some more.)

kc

>  
> 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
>> >
>> >
>> >
>>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Friday, 29 April 2011 16:37:08 UTC