Sorry for the previous message due to the flip of fingers using iPhone.  I'm checking into suggestions made by Thom Hickey.  Please bear with me for the learning curve. 

Thanks a lot!

Amanda    
 




On Feb 9, 2012, at 14:50, "Hickey,Thom" <[log in to unmask]> wrote:

> I like actionable URIs as identifiers, but agree that the creator of the
> identifier may be better left out of the URI.
>
> PURLs and VIAF IDs are examples of identifiers that use a domain name
> specific to themselves, not the agency maintaining them (in both cases
> OCLC). 
>
> The separate domain names make them much cooler.
>
> --Th
>
> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of Juha Hakala
> Sent: Thursday, February 09, 2012 8:53 AM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] The German National Library's response
>
> Hello,
>
> Karen Coyle wrote:
>
>> Juha, thanks for the info regarding IETF activity. The issue I see
> with
>> URNs is not the structure but the minting: should libraries begin to
>> link their data I see a need for thousands or even tens of thousands
> of
>> identifiers (hundreds of thousands?) when we figure out a way to make
>> library holdings available to the linked data space. Surely we'll need
>
>> at least an identifier for each library. At least URIs piggy-back on
> the
>> domain system, which already exists.
>
> Yes, a lot of identifiers will be needed. And if someone prefers to use
> URNs for this purpose, RFC 3188bis (the revised namespace registration
> request for National Bibliography Numbers, NBNs) makes it clear that
> these identifiers can be assigned to data elements as well.
>
> Where these URN:NBNs resolve to and what kind of services they will be
> able to support will depend on the technical infrastructure available.
>>
>> Definitely, this gives us something to think about, and I have no
> doubt
>> that we could develop some kind of naming/identifying system to carry
>> this data. Obviously the first step is to figure out what we need to
>> identify, a kind of requirements study.
>
> Yes; and in addition we may need to consider what kind of services the
> identified things require.
>
>> What I dislike about the persistent identifier is that you lose the
> link
>> to the originating agency that you have in the URI. That might be just
> a
>> "human thing" - that I feel better when looking at the URI that I can
>> see WHO is responsible.
>
> A persistent identifier may show the originating agency as well. Whether
>
> they do or don't, depends on the identifier system used. With URN:NBN
> the namespace specific string (the identifier part of the URN) may be
> semantic, if that is the preference of the organization assigning those
> identifiers. But in the long run it may not be a good idea to include
> the originating agency into the identifier, since organisations (and
> even more so, their domain names) may be more short-lived than the
> things they create. Cool URIs, just like semantic identifiers, may tell
> who originated the resource, but there is a good chance that they do not
>
> tell who is currently responsible for keeping the resource available. A
> different method for finding this out must be available.
>
> ARKs, of course, give you both, at least in
>> theory. Is anyone using the "?" feature of ARKs that lets you query
> for
>> that information? Should such info be part of our best practices?
>
> I don't know if the "?" and "??" features of ARK are in use, and if so,
> by whom. John Kunze may be able to tell that. But I do think that
> providing this functionality in a PID system is a good idea, and will
> "lend" it into the URN system (in case John doesn't mind ;-)). Although
> the practical implementation in the URN system will probably be an
> option of retrieving preservation metadata / rights metadata about the
> resource.
>
> Revised version of the URN syntax (RFC2141bis) allows the use of <query>
>
> and <fragment>. <query> will never be part of the URN, but it could be
> used to carry service-related information. For example, this base URN:
>
> http://urn.fi/URN:ISBN:978-952-10-7612-1
>
> provides the user the default service (splash page describing the
> resource, and providing a link to the book), but this URN:
>
> http://urn.fi/URN:ISBN:978-952-10-7612-1?I2C
>
> will supply descriptive metadata about the resource in the default
> format, provided that the resolution service knows how to deal with the
> service request in <query> (I2C = URI to resource description).
>
> In the context of linked data, we might be interested in enabling for
> instance retrieval of the definition of a concept in the chosen language
>
> (?ENG for English, ?SWE for Swedish, and so on). Whatever linking
> mechanisms are used (PIDs, cool URIs or something else) they should
> enable us to do whatever needs to be done.
>
> Links are an essential feature in linked data, and we should plan
> carefully the implementation of this functionality - and not take for
> instance the functionality cool URIs are currently providing as the
> predetermined basis for our work.
>
> All the best,
>
> Juha
>>
>> kc
>>
>>>
>>>>> - what should the URI resolve to?
>>>
>>> URN-related RFCs are currently being revised (see
>>> http://datatracker.ietf.org/wg/urnbis/). I am currently writing a new
>>> version of RFC 2483, which specifies the resolution services URN can
>>> provide. In the present RFC 2483 the list of services is fixed. RFC
>>> 2483bis will be based on the idea that IANA should establish a
> registry
>>> of informal and formal resolution services. Then URN user communities
>>> could register new services at will (and parameters to these
> services,
>>> for instance for requesting descriptive metadata about the resource
> in
>>> different formats).
>>>
>>> Existing persistent identifier systems provide a diverse set of
>>> services. With ARK, for instance, it is possible to check the
>>> preservation commitment of the organisation holding a resource. I
> don't
>>> know if the PID systems will become more homogeneous in this respect
> in
>>> the future.
>>>
>>> Nobody knows what the URIs utilized within this initiative should
>>> resolve to, but I am sure that the mechanism to be built should be
>>> flexible so that it can be adjusted to meet the future needs we don't
>>> foresee yet.
>>>
>>> Best regards,
>>>
>>> Juha
>>>
>>>>>
>>>>> That kind of thing.
>>>>>
>>>>
>>>> Does anyone know an answer to any of these questions? Therefore, I
>>>> think, no URI is better than no URI at all. Use brief and simple and
>>>> easily memorized codes for vocabularies like the terms in 337-338,
> and
>>>> use IDnumbers for names and subjects and titles.
>>>> Any implementation can easily relate them to all sorts of URIs that
> may
>>>> be in current use or follow best practice or resolve to something
>>>> useful for the purpose at hand. Verbal terms need changes and are
>>>> language-bound, URLs are perishable, only codes and numbers are
> robust,
>>>> easy to handle, and versatile.
>>>>
>>>> B.Eversberg
>>>
>>
>
> --
>
>  Juha Hakala
>  Senior advisor, standardisation and IT
>
>  The National Library of Finland
>  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
>  Email [log in to unmask], tel +358 50 382 7678