Let me just add that a URI datatype is useful not just for external references, but it is also useful for local references as well, e.g. instead of cf:grid_mapping being a string that is the name of a local variable, it would be a URI that points to a local variable (i.e. probably still that same variable name). Seemingly a minor distinction, but it allows a clean mapping into an object-oriented framework for information in netcdf files. LIke RDF, or Java Beans, or ...
Benno On Tue, Oct 21, 2008 at 11:24 AM, Benno Blumenthal <[EMAIL PROTECTED]> wrote: > Hello All, > > This is heading directly towards where I was trying to steer > common_concept in particular (Trac Ticket #24), and where the > namespace discussion went more generally (Trac Ticket #27). There is > a need for a framework for using namespaces in netcdf, both with the > attributes (so attributes can be explicitly placed in different > conventions, not the issue here per se), and attribute values (so that > attributes can point to URI's identifying concepts). My short > version of this is that cf:standard_name is a property that points to > a single controlled vocabulary (i.e. a string chosen from a list), > while the proposed cf:common_concept is a property that points to > concepts identified with URI's (e.g. namespace plus value). > > standard_name's could have URI's as well (Roy Lowry has assigned > opaque URI's to all the standard names, MMI has assigned more readable > URIs to many of the standard_names (e.g. cf:air_temperature), CF could > very well get a URN space of its own which will allow it to create > some definitive URIs, which lets us relate cf:standard_name's to other > vocabularies (Roy has done this as well), and would let us write down > relationships between standard_names (Roy is working on this). > > The attribute namespace problem is easier, and we discussed a couple > of possible solutions which we hope to sort out by actually > implementing them. namespaces for values seems trickier at the > moment, because netcdf (unlike DAP) does not have a URI datatype, and > so even if one had a list of namespaces specified as id #24, one would > not be sure which string-valued properties have been > namespace-abbreviated without reading through some document that > describes each property in the convention, a level of sophistication > in the reading software we would like to avoid. Of course, one does > not need to abbreviate -- a URN in particular should be quite readable > in its entirety. > > Benno > > On Mon, Oct 20, 2008 at 3:22 PM, John Graybeal <[EMAIL PROTECTED]> wrote: >> Seth, >> >> That's an entertainingly close description of the semantic interoperability >> framework [1] and workshop [2] that MMI is proposing and offering for marine >> and related environmental sciences. (apologies for the plug, but it sure >> seemed relevant) So you'll have my full support for that concept. >> >> The interesting and subtle distinction between MMI's approach, and what I >> think you're implying is that there would be a single authority (CF) tying >> together all those names (e.g., using the CF aliases to bring the names from >> different namespaces together). There are two ways to do that, but I don't >> think aliases or a 'single authority' (in the way you imply it) is the right >> model. >> >> I think a better model is to consider the CF standard names one of the major >> namespaces, to which many other vocabularies can be mapped. Then, modify >> the CF standard to allow the specification of a term from any namespace >> (since many terms may not be appropriate to the CF vocabulary; see my >> comment on CF scope in the last post); this is a proposal I've been >> back-burnering for about 9 months now. Finally, CF can accept any or all >> well-framed names that are in any of these namespaces, or can even alias to >> them, through manual or semi-automated processes. >> >> Under this model, CF has a mind share on solving this problem with a >> particular approach, but CF users can take advantage of other approaches. CF >> doesn't have to take on the 'vocabulary publication and mediation' task for >> the entire community, but can pick and choose its own targets for inclusion >> in the CF vocabulary (and the targets will be much more conspicuous and >> contextually defined). >> >> There are multiple complexities that arise as you start trying to make this >> concept (mine, yours, or CF's) work -- I like to think our MMI plans know >> about 85% of the issues in a fully operational but basic system -- and it >> isn't clear whether you'll want many organizations serving the results, or >> relatively few. But the model can put a lot more precise naming and mapping >> capability into action in a very short period of time (we hope to go live in >> a matter of weeks), and should make clear the difference in scope between >> what CF is currently addressing, and what needs to be accommodated. >> >> Having said all that, I would like CF's model of "meaningful, coherent, >> well-structured names" to be a paradigm that is maintained. If one group >> uses opaque codes, I would rather not see CF start including those just >> because they are acceptable to some. One of CF's big strengths is the >> "instant interoperability" you get from recognizing and understanding the >> name. >> >> John >> >> >> [1] http://marinemetadata.org/semanticframeworkconcept (many of the planned >> concepts are not fully documented yet) >> [2] http://marinemetadata.org/events/oossi (sign up soon if you want good >> hotel rates!) >> >> On Oct 20, 2008, at 11:40 AM, Seth McGinnis wrote: >> >>>> I don't know if this is supportive or not, but the "sheer number of >>>> groups bringing new requirements" is an issue that I don't think CF has >>>> realistically addressed. >>> >>> >>> With regard to the standard names problem, here's a perhaps-mad idea from >>> someone standing on the sidelines. I don't think this idea has been floated >>> before, but I may have missed it. >>> >>> Where I'm coming from: I'm the data manager for a modeling project >>> (NARCCAP, http://narccap.ucar.edu) that's using the CF standard. I don't >>> generate or use any of the project's data, I'm just in charge of checking it >>> to make sure it's properly formatted and trying to make things usable for >>> the community that will use the data. From my perspective, the really >>> important thing about standard names is that if two different files have a >>> variable with the same standard name, it means (1) they're talking about the >>> same thing, and (2) a user can go somewhere and look up the definition and >>> the canonical units. The fact that the name has passed through an approval >>> process is entirely incidental. >>> >>> So... why not just let any group that wants to define a set of standard >>> names for their community do so, as long as they're willing to also take >>> charge of publishing a Standard Name Table for it? >>> >>> Essentially, it would be creating namespaces. The only mechanism that >>> would need to be added would be some way of noting which namespace the name >>> comes from and the URL of the corresponding Standard Name Table. So, for >>> example, maybe for chemical names, all the standard names would all start >>> with "iupac:" and somewhere in the global attributes for the file you'd have >>> "standard_namespaces = (default: >>> cf-pcmdi.llnl.gov/cf-standard-name-table.xml, chem: >>> www.iupac.org/cf/standard-names-3.0.xml)". Or something like that. >>> >>> Each community can manage its own namespace. There's already a mechanism >>> in place (aliases) that could be extended to handle cases where there are >>> two different names for one thing. And if you end up with two names for the >>> same thing with different dimensions or slightly different definitions, >>> that's fine, because that situation already exists in the single table. >>> (Rain, for example, can be defined as a mass flux per unit area >>> (precipitation_flux) or as an accumulated depth >>> (lwe_thickness_of_precipitation_amount). They're different ways of talking >>> about the same physical thing. So this is not a new problem for the user.) >>> >>> Put some bounds on the representational domain that the default standard >>> name table will handle, delegate everything else to whoever in that >>> community wants to deal with it, and no matter how many groups come to CF >>> with new standard names, the system can handle it. Right? >>> >>> Cheers, >>> >>> --Seth >>> >>> ---- >>> Seth McGinnis >>> [EMAIL PROTECTED] >>> NARCCAP Data & User Community Manager >>> Associate Scientist >>> ISSE / NCAR >>> ---- >>> _______________________________________________ >>> CF-metadata mailing list >>> CF-metadata@cgd.ucar.edu >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> >> John >> >> -------------- >> John Graybeal <mailto:[EMAIL PROTECTED]> -- 831-775-1956 >> Monterey Bay Aquarium Research Institute >> Marine Metadata Interoperability Project: http://marinemetadata.org >> >> _______________________________________________ >> CF-metadata mailing list >> CF-metadata@cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> > > > > -- > Dr. M. Benno Blumenthal [EMAIL PROTECTED] > International Research Institute for climate and society > The Earth Institute at Columbia University > Lamont Campus, Palisades NY 10964-8000 (845) 680-4450 > -- Dr. M. Benno Blumenthal [EMAIL PROTECTED] International Research Institute for climate and society The Earth Institute at Columbia University Lamont Campus, Palisades NY 10964-8000 (845) 680-4450 _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata