⇐ ⇒

[CF-metadata] unique identifiers

From: Godin, Michael <Godin>
Date: Thu, 22 Mar 2007 12:18:33 -0700

Building on Luis's suggestion of "doing it right", perhaps a reasonable namespace for CF-Metadata standard names is:

http://www.cfconventions.org/documents/cf-standard-names/current/cf-standard-name-table.html

Which allows one to append "#" and a standard name to get a unique reference within the document. For the air_density example, the following URL will direct most browsers to the air_density entry in the table (which offers more information about the entry -- unless it has been deprecated to an alias):

http://www.cfconventions.org/documents/cf-standard-names/current/cf-standard-name-table.html#air_density

However, will the above URL be in existence for the foreseeable future? Perhaps not -- but the likelihood of some other group appropriating the cfconventions.org domain and populating an identical path with contradictory information is probably quite low. So it seems like a reasonably safe namespace URI; one that will be self-describing to human readers in the immediate future, and will be unique into the foreseeable future. I just wish it was shorter!

Mike

-----Original Message-----
From: cf-metadata-bounces at cgd.ucar.edu [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Luis Bermudez
Sent: Thursday, March 22, 2007 11:20 AM
To: Jonathan Gregory
Cc: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] unique identifiers

Brian, et al.

I agree with Brian about the best approach for humans, which is pattern very much use in the Semantic Web.

2 points:

a) About unintelligible identifier: "Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource." http:// www.w3.org/TR/webarch/#uri-opacity .
But a little help in the URI construct about its semantics is good for all.

b) Resolvability of URLs
"Although many URI schemes are named after protocols, this does not imply that use of such a URI will necessarily result in access to the resource via the named protocol" http://www.w3.org/TR/webarch/ #dereference-uri

"although many URI schemes (e.g. URLs) are named after protocols, this does not imply that use of these URIs will result in access to the resource via the named protocol. URIs are often used simply for the sake of identification" http://www.ietf.org/rfc/rfc3986.txt

So we can use URLs only for identification. But common if we do it right (resolvable URL) - this will be easier for everyone.


-Luis


On Mar 22, 2007, at 10:40 AM, Jonathan Gregory wrote:

> Dear John
>
> The argument appears to be than an unintelligible identifier (i.e.
> one without
> semantic content) is good because it is in itself meaningless, so you
> have to look it up to find out what it means, whereas if you use
> intelligible names, you might be misled by misunderstand them. Is that
> right? I appreciate that this is rational, but I'm not convinced it is
> the most helpful approach for humans. That would be an argument
> against self-describing netCDF files, for example. It would argue that
> the metadata in the files should be totally cryptic to humans, so that
> you had the use the latest version of an approved translator to tell
> you what it means. That has some attraction, but I'm not sure it
> really solves the problem. The translator will use its own idioms,
> which the human user will get used to, and if a new version of the
> translator gives new meanings to the words it uses, you are back in
> the same problem.
> It seems to me better to admit that one always has be careful at some
> level, and use names that have some apparent meaning.
>
> Best wishes
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata


_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Mar 22 2007 - 13:18:33 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒