tis 2007-10-23 klockan 15:08 +0200 skrev Salokhe, Gauri (KCEW):
> Hi Douglas,
> The idea is to register the urn. This way we will be able to use it
> "officially" but from most of the comments received so far it seems that we
> should not even take that path!
> Given that we should not define a new URN, we will then stick to the
> dcterms:URI scheme, which will of course result in:
> <dc:identifier scheme="dcterms:URI"> http://www.fao.org </dc:identifier>
> <dc:identifier scheme="dcterms:URI"> 550e8400-e29b-41d4-a716-446655440000
This is not a valid URI. Did you mean to use the urn:uuid: scheme?
> We would like cleaner way of making a distinction between the two than
> checking if one has http or not.
> The idea behind a code like "FAO-ITA-FDNDGRTDNTNS" was to allow those who
> will not use our forms (which will automatically create this code based on
> the filled metadata) to have a possibility to generate the code manually. We
> realize, however, that this is not the optimal way.
Generally, I think you shouldn't rely too much on how identifiers are
constructed, as long as they are unique (and optimally, dereferencable
> thanks again for the useful feedback.
> -----Original Message-----
> From: DCMI Identifiers Community [mailto:[log in to unmask]] On
> Behalf Of Douglas Campbell
> Sent: 19 October 2007 03:29
> To: [log in to unmask]
> Subject: Re: Question of identification.. URN vs. URI
> Hi Gauri,
> Just a couple of points about your second question.
> You can use "urn:ags:" for internal use, but it's not an official URN (it
> doesn't use an official URN namespace), see:
> The nice thing about using
> <dc:identifier scheme="dcterms:URI">...
> for both is anyone can process the metadata easily as dcterms:URI is well
> understood, whereas with
> <dc:identifier scheme="ags:URN">
> anyone who wanted to process it would need to work out what an "ags:URN" is.
> Unfortunately I don't have any suggestions for the identifier itself - still
> thinking through those issues myself.
> One thing I was wondering is how do you work out what someone else's URN
> would be, you'd need to know the exact form of the name they were using to
> form the URN code from. Would be a case of looking it up in the registry
> (and hoping they had already defined it)?
> >>> "Salokhe, Gauri (KCEW)" <[log in to unmask]> 19/10/07 04:44:43
> >>> >>>
> I thought I might start of the discussion (not sure how many people re on
> this list) with a question on Identifiers
> We are currently trying to define a schema to describe organizations. The
> architecture is distributed  and we would like to thus have a unique
> identifier for each organization. In this architecture the data describing an
> organization are stored in a file as an XML description based on a specific
> application profile, and access to these distributed files is facilitated by
> a central registry file. Theoretically, the Registry File could just consist
> of a list of URLs, with no need for unique identifiers, since the URLs,
> though not permanent, are unique. Using this approach, the dc:identifier
> element would be used for the URL of the website and only the URLs of the
> descriptions would be stored in the Registry file.
> However, assigning a unique identifier to an organization allows us to:
> * change the URL of the record without creating a second entry in the
> registry file;
> * (to a certain extent) avoid duplication;
> * performing faster harvesting;
> * most important of all, create and maintain relations between the records
> (impossible with URLs since they can change).
> Since it was decided to implement relations between the organizations (and
> their parts: divisions, departments, branches etc.), the dc:relation element
> was included with nested DCTERMS elements for describing different types of
> relations with other records (organizations). Using this approach, one of the
> elements of the metadata set had to contain a unique and permanent -
> therefore location-independent - identifier. The unique number is generated
> by taking the acronym, location of the organization, combined with 12
> consonants taken from the name of the organization (six from each side). The
> last "action" is done to disambiguate between, for example,
> University of Agriculture Athens
> University of Agriculture Faisalabad
> Given all this, we would generate a sample URN as follows:
> Food and Agriculture Organization of the United Nations
> Rome, Italy
> would be: urn:ags:org:FAO-ITA-FDNDGRTDNTNS
> Now, we I have here two questions:
> 1) Is there a more simple way of generating a unique identifier given the
> "distributed" architecture (plus lack of URLs on part of some organizations)?
> 2) can we use
> <dc:identifier scheme="AGS:URN">
> <dc:identifier scheme="DCTERMS:URI"> http://www.fao.org/ </dc:identifier>
> where AGS refers to the "Agricultural Metadata Element Set" namespace
> We discovered that the guidelines at  it is not even necessary to specify
> a different scheme: URI should be good both for URLs and URNs, and then the
> first letters of the id (urn: or http:) should identify the protocol or
> scheme or whatever. But this would be more difficult to parse in XML than
> specifying a different scheme.
> Thanks in advance for your time!
>  A Distributed Architecture for Harvesting Metadata Describing
> Organizations in the Agriculture Sector
>  http://www.w3.org/TR/uri-clarification/
> This e-mail is intended for the addressee only and may contain information
> which is subject to legal privilege. The contents are not necessarily the
> official view or communication of the National Library of New Zealand. If you
> are not the intended recipient you must not use, disclose, copy or distribute
> this e-mail or any information in, or attached to it. If you have received
> this e-mail in error, please contact the sender immediately or return the
> original message to the National Library by e-mail, and destroy any copies.
> The National Library does not accept any liability for changes made to this
> e-mail or attachments after sending.
> All e-mails have been scanned for viruses and content by security software.
> The National Library reserves the right to monitor all e-mail communications
> through its network.
<[log in to unmask]>
Plus ça change, plus c'est la même chose