[Apologies if this has already been considered and is out of scope.]
In looking at example NetCDF files I can see cases where attribute values could reasonably be interpreted as something other than string values. Should this be supported by NetCDF-LD?
For example, consider the following (from sresa1b_ncar_ccsm3-example.nc available from NetCDF Examples):
float tas(time, lat, lon) ;
tas:missing_value = 1.e+20f ;
tas:standard_name = "air_temperature" ;
Since the CF term missing_value
is defined as having the type of the variable it is applied to then it would be reasonable for that first CDL attribute declaration to be mapped to the statement:
:tas cf:missing_value '1.e+20f'^^xsd:float .
Should NetCDF-LD support this? Mapping to a fixed type would be relatively easy to specify by e.g. allowing an rdfs:range
declaration as part an alias definition. Supporting the CF convention that the type should match that of the variable it is applied to would be harder. That would need some additional vocabulary machinery in the alias declarations such as:
cf:missing_value dct:identifier 'missing_value';
bald:valueType bald:typeOfBaseVariable .
Now consider the second attribute in the sample tas:standard_name
. In CF a standard_name
is just a string so a simple attribute mapping would be perfectly reasonable:
:tas cf:standard_name "air_temperature" .
However, in the interests of semantic grounding one could imagine users wishing to link to terms to in an agreed vocabulary resource. So if cfsn
were the prefix for a vocabulary server containing descriptions of standard names then it might be desirable to be able to map to:
:tas cf:standard_name cfsn:air_temperature .
Should NetCDF-LD allow users to specify such a mapping?
If so it could also be achieved through additional vocabulary machinery in the alias definition:
cf:standard_bname dct:identifier 'standard_name';
bald:valueType rdfs:Resource ;
bald:valueBase cfsn: .
I could imagine that, even if desirable in the abstract, the complexity of specifying and implementing such machinery could be beyond the point of diminishing returns for at least the first version. However, it seemed worth at least asking the question.
/cc @marqh @skwlilac