[Esip-preserve] Some Thoughts on OPM

[Bruce Barkstrom]

No objection - only note was that we were going to have
to extend the ontology, which is what I meant by bringing
things in from "outside" OPM.

Eventually, we're going to have to do some thinking about
the scaling that goes with this approach.  As far as I can
tell, the scaling for traversing the graph is still linear with
the number of nodes.  If all the granules in ESDIS get
included, we're going to have several hundred million items,
including files and jobs - not to mention the possibility of
subsets (fragments) of files.

There is also the small matter of dealing with aliases and
other kinds of semantic heterogeneity.

Oh well, just makes life interesting.

Bruce B.

On Fri, Dec 10, 2010 at 11:10 AM, Curt Tilmes <Curt.Tilmes at nasa.gov> wrote:

> 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
> _______________________________________________
> Esip-preserve mailing list
> Esip-preserve at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-preserve
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-preserve/attachments/20101210/134d1bbf/attachment-0001.html>