A definitive identifier would consolidate usage around that URL, enhancing the user experience. That's the key advantage.
Which order to follow is 6 of one, half a dozen of another; one does not have to happen before the other does.
Today we have the resources provisioned at URLs, which is good. If/when CF wants to have a definitive domain for their URLs, they will register that domain.
At that point, it would be straightforward to do any of the following, which have similar value and visibility to the community:
A) Use apache redirects to point to the external resolver of choice (simplest but slightly less transparent to the user)
B) Add the vocabulary, under the newly definitized namespace, to an external resolver that supports native name spaces (as MMI does) and *then* use apache redirects to point to the external resolver.
B.1) The external resolver could be made to look like CF namespace for that vocabulary, or could be served remotely into the CF site.
C) Host the vocabularies locally in the CF namespace (which is trivial at one level, but involves many policy and technical choices)
Since at that point there will almost certainly be multiple hosts providing/resolving CF terms (not counting CF itself), it will be useful to semantically unify the CF terms in different repositories (CF:termA sameAs NERC:termB sameAs MMI:termC). That easily enough resolves ambiguity/duplication for semantically aware users.
So technologically things are surprisingly good. The hard part is that CF will have to decide how it wants to satisfy needs (like versions) within its namespace. Taking the versioning example, the NERC team went down one path, then found a better one for their primary users. In MMI we picked yet another way, which supports both NERC's first path, and a 'versionless' term -- and could later match NERC's approach. Which is best for CF? To be discussed, I would say. There are many other strategic questions of that sort.
So I'm not feeling much urgency for the definitive namespace, because I don't know that CF is ready to tackle all the related questions, and the existing semantic solutions are pretty viable so far. But if you are, by all means give it a shot. (I'm OK with your name, though I find myself typing these names a lot, so I prefer shorter domains and minimal special characters. Your mileage may vary!)
John
On Jun 18, 2013, at 09:51, "Hedley, Mark" <mark.hedley at metoffice.gov.uk> wrote:
> Hello John
>
> many thanks for your input
>
> I agree that the mmisw service provides significant capabilities by publishing the CF standard name vocabulary and other vocabularies
>
> I think that the key aspect I would like the CF community to adopt is the definitive identifier for a CF standard name. I would like CF to make a long term commitment to a universal resource identifier scheme which can be used as the definitive source for standard names
>
> I like:
> http://def.cfconventions.org/standard_name/
> but it is not crucial that this is the solution, what I require i a solution the CF have committed to.
>
> Following on from this commitment is the question of how the relevant resources are provisioned so that these URIs resolve to useful content.
>
> I would like to concentrate on discussion and agreement on these URIs first, then address the provision of resources. I believe your thoughts are focused on the resource provision, so they feel like a good conversation to come back to if we get success on the first step.
>
> Does this seem a reasonable approach?
>
> all the best
> mark
>
> From: John Graybeal [graybeal at marinemetadata.org]
> Sent: 14 June 2013 20:07
> To: Hedley, Mark
> Cc: CF Metadata List
> Subject: Re: [CF-metadata] publishing standard names
>
> Mark,
>
> While there is a close relationship between NERC and CF, they are not the only two mechanisms publishing CF terms. The MMI vocabulary server, http://mmisw.org/orr, also publishes CF standard name vocabulary and term URIs.
>
> The URI for the entire vocabulary is http://mmisw.org/ont/cf/parameter, or if you want specifically the version 23 vocabulary,http://mmisw.org/ont/cf/20130603T200127/parameter. It does not have the CF namespace directly; however, we have mechanisms by which we could alias terms to/from a CF namespace. (Your sub-domain suggestion is a good one for CF.)
>
> Each standard name also exists in MMI as an individual resource, for example http://mmisw.org/ont/cf/parameter/air_temperature (or in versioned form, http://mmisw.org/ont/cf/20130603T200127/parameter/air_temperature).
>
> Many of your querying and resolution proposals are already satisfied with this service. The vocabularies can be published in multiple forms; SPAQRL queries are supported (e.g., http://mmisw.org/ont/?form=json&sparql=SELECT ?s ?p ?o WHERE {?s ?p ?o. } LIMIT 20), where the output form is specified as json, csv, or html (see examples page at http://mmisw.org/ont/sparql.html); and while I haven't constructed a query by vocabulary lately, given a few moments this weekend I will steal/demonstrate examples in that category.
>
> Please consider the MMI server for your existing needs, and perhaps they are a good fit for long-term CF goals as well.
>
> John
>
>
>
>
>
> On Jun 13, 2013, at 09:14, "Hedley, Mark" <mark.hedley at metoffice.gov.uk> wrote:
>
>> Thank you for the reminder Roy, I should have posted this a while back
>>
>> I have written a paper on publishing standard names which I think might provide some of the required functionality for the community.
>>
>> It would be very useful for me and work I am involved in.
>>
>> The paper is attached. I invite feedback on this proposal
>>
>> many thanks
>> mark
>>
>>
>>
>> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of Lowry, Roy K. [rkl at bodc.ac.uk]
>> Sent: 13 June 2013 14:50
>> To: Ajay Krishnan - NOAA Affiliate; cf-metadata at cgd.ucar.edu
>> Subject: Re: [CF-metadata] standard_name_vocabulary attribute
>>
>> Hello Ajay,
>>
>> If I've got it right, your example is a URL for a single standard name. The version numbers refer to versions of the whole list and so including the version number in a reference to a single standard name causes the standard name to inherit the version number of the list of which it is a member. Trouble is that most standard names are members of more than one list version but the standard name is exactly the same in each of these versions. Consequently, a given standard name ends up with multiple URIs. In version 1 of the vocabulary server we run (NERC Vocabulary Server or NVS) we made the mistake of list members inheriting the version numbers of their parent lists and learned the hard way the problems it causes for operational systems. Versioning in the current version of NVS (V2)has been done differently with list member and list versioning totally decoupled and the versioning information explicitly excluded from list member URIs.
>>
>> I am aware of work underway by Mark Hedley at the UK Met Office to provide URLs for Standard Names in a CF namespace that follow linked data principles by resolving into usable XML (SKOS RDF) documents. I'm not sure how far this work has progressed, so I'll leave it Mark to say more on the list if he feels he's ready.
>>
>> Cheers, Roy.
>>
>>
>>
>> From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of Ajay Krishnan - NOAA Affiliate [ajay.krishnan at noaa.gov]
>> Sent: 13 June 2013 13:44
>> To: cf-metadata at cgd.ucar.edu
>> Subject: [CF-metadata] standard_name_vocabulary attribute
>>
>>
>> Hi,
>>
>> There seems to be some ambiguity about the usage of the standard_name_vocabulary attribute. Based on the link below, the right value would be to use something like CF 1.6
>> http://www.unidata.ucar.edu/software/netcdf-java/formats/DataDiscoveryAttConvention.html#standard_name_vocabulary_Attribute
>>
>> Is that the right usage or should we reference the version of the cf-standard-name-table like v1..v23 etc.?
>>
>> Any info on this would be much appreciated.
>>
>> Thanks,
>> Ajay
>> <publishingStandardNames.pdf>_______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> ---------------
> John Graybeal
> Marine Metadata Interoperability Project: http://marinemetadata.org
> graybeal at marinemetadata.org
>
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
---------------
John Graybeal
Marine Metadata Interoperability Project:
http://marinemetadata.org
graybeal at marinemetadata.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130618/d56de07c/attachment.html>
Received on Tue Jun 18 2013 - 12:19:54 BST
