[Esip-preserve] Some Thoughts on OPM

[Curt Tilmes]

On 12/10/2010 09:41 AM, Bruce Barkstrom wrote:
> 2.  The nodes in the graph appear to be unstructured, meaning that
> in raw form, all nodes are treated the same.  As a result,
> structural typing of the nodes will have to be introduced from
> "outside" OPM.  As a concrete example, this aspect of OPM would not
> distinguish between different data products or different versions of
> a Data Set from a particular instrument, as well as Data Sets
> produced by different sources that are covering the same data
> observation time interval.

I was just thinking of using OPM as our starting point -- we don't work
"outside" OPM, we derive from it (or at least define relationships to
it).

For example, rather than saying "esp:Granule" (esp = Earth Science
Processing Ontology) is a subset of "owl:Thing", we say it is a subset
of "opm:Artifact", and an "esp:DataTransformationEvent" is a subset of
an "opm:Process", or whatever (which are themselves subsets of
owl:Thing).  There are other ways to handle this we might consider as
well.

Things that understand the semantic relationships between opm:Artifact
and opm:Process will automatically be able to figure out some things
about the relationships between our esp:Granule and
esp:DataTransformationEvent.

Then we go on to define more classes to identify and distinguish
things like "calibration" input from "level 0 data from a spacecraft"
from "lookup table".  Then we can ask questions like "What calibration
technique was used for the data from which the MODIS land surface
reflectance was derived?"

That can turn into a SPARQL query that follows the processing chain
back to the calibration processing step that used a calibration file
as an input, that was produced by some calibration technique.

Once we are 'hooked in' to the OPM ontologies, we can use the W3C
Provenance Volcabulary Mappings and figure out that not only is an
esp:Granule an opm:Artifact, it is also a provenir:data, a
pmlp:Information, and a premis:Object.

When a granule is an input to one of our processing steps, that
relationship can be mapped as an opm:wasDerivedFrom, an opm:used, a
provenir:has_participant, a prv:employedArtifact or prv:usedData, a
pjlj:hasAntecedentList, a premis:linkingObjectIdentifier.

If we hook our granules up to ESDTs which get hooked up to spacecraft,
you can hook into thinks like dbpedia which already has a smattering
of things that it inherited from wikipedia, things like
"dbpedia:Moderate-resolution_Imaging_Spectroradiometer", which can
also be found from dbpedia:MODIS:

http://dbpedia.org/describe/?url=http://dbpedia.org/resource/Moderate-Resolution_Imaging_Spectroradiometer

which is the same as the

yago-res:Moderate-Resolution_Imaging_Spectroradiometer

which the yago (http://www.mpi-inf.mpg.de/yago-naga/yago/) people
already have defined in their ontology as a type of
yago:EarthObservationSatellites and
yago:SpacecraftInstruments.

Curt