Dataset Registration

Printer-friendly version

Datasets, Observation Datasets, and Observation-Invariant Datasets


An observation dataset is a collection of values from one or more measurements. An observation-invariant dataset (OID) is an observation dataset where the dataset content is the result of one or more measurements, where all of the measurements occur during a single observation.

General Instructions

This page describes a seven-stage process for creating metadata about observation-invariant datasets. Please read the general instructions below carefully before you engage in creating metadata. The general instructions provide you with valuable information for completing the metadata registration process.

On the creation of a metadata document

The instructions on this page show how to create a document with metadata about datasets. The metadata about your dataset is expected to be encoded in RDF/Turtle format[link to Turtle Specification], and to be included in the document being created if the metadata are not currently available in the Lake George Regional Knowledge Base (LGR-KB). You will need to systematically follow the seven steps below, and for each step assure that only metadata currently missing from the LGR-KB is included in the document being created, and that metadata already in LGR-KB is properly reused. By submitting SPARQL queries against LGR-KB (example queries are provided for each step in this page), you can verify which metadata are already available in the LGR-KB, which metadata are missing in the LGR-KB, and which metadata need to be added to the RDF/Turtle document. In each one of the seven steps, you are expected to tweak the turtle templates provided to address your needs, and to add the tweaked turtle back to the document that you are creating.

Use this [link] to see an example of a document of a complete turtle document created using the instructions in this page.

It is recommended that your RDF/Turtle document starts with the code below, which includes a definition of namespaces used in the Turtle examples in this page. Namespaces are used to simplify the use of long URIs. For example, the foaf ontology (http://xmlns.com/foaf/0.1/) defines a concept person (http://xmlns.com/foaf/0.1/Person). Alternatively, one can use the prefix command to define the 'foaf' namespace, and then use 'foaf:Person' to refer to the Person's concept from the foaf ontology.

@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix foaf:  <http://xmlns.com/foaf/0.1/> .
@prefix hasneto:  <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix vstoi: <http://jefferson.tw.rpi.edu/ontology/vsto-instrument.owl#> .
@prefix oboe: <http://ecoinformatics.org/oboe/oboe.1.0/oboe-core.owl#> .
 
# Step 1 - OBOE Entities and Characteristics
 
# Step 2 - Detector Models and Detectors
 
# Step 3 - Instrument Models and Instruments
 
# Step 4 - Platform Models and Platforms
 
# Step 5 - Deployments
 
# Step 6 - Observations
 
# Step 7 - Datasets

On the use of the terms 'instruments', 'detectors' and 'sensor'

In HASNetO, the ontology that we use to encode metadata into the LGR-KB, we do not have a concept called 'Sensor' because we have noticed that sometimes the term is used to refer to detectors, sometimes to instruments, and very often to the combination of detectors and instruments. We have also noticed that in less sophisticated settings, it is not trivial to separate detectors from instruments. For instance, in ordinary weather stations, a thermometer is a single gadget that has an internal, non-detachable detector, and it is also a instrument since it is capable of processing detector's signals and interpreting it as a numerical value. Our goal is to register both detectors and instruments. For sophisticated instruments, it is more obvious that detectors and instruments are distinct hardware components, and thus easier to conceptually map them into HASNetO concepts. For ordinary instruments, we would like to make explicit the fact that sensors may have detectors although one may not be able to see the detectors as detachable hardware components.

On the use of object models and the actual objects

Dataset metadata often includes information about many abstract objects like 'air' and concrete objects like an instrument. When registering metadata that includes information about concrete objects, it is very important for the person doing the registration, i.e., you, to make a distinction between information related to objects and information related to object's classes. For example, let say that we have an instrument that it is often called a "Brinkman Electromagnetic Flow Meter." If we stop think a bit more about the instrument, we will note that "Bringkman Electromagnetic Flow Meter" may be the name of the model of the instrument, and that most of the things that we know about the instrument are in fact knowledge about the model of the instrument rather than the instrument itself. For example, the resolution and accuracy of the instrument are the resolution and accuracy of any instrument of that model. Thus, resolution and accuracy are so-called class properties. In contrast, the serial number is an example of an instance property, because every distinct instrument of the model "Bringkman Electromagnetic Flow Meter" may have a unique serial number.

In this metadata registration process, we will be dealing with objects like platforms, instruments and detectors, as well as with platform models, instrument models, and detector models, and making this distinction between object models and actual objects is important because we do not want object properties to be registered as object model properties and vice-versa.

On the way the metadata process is designed

A sensor network is composed of platforms, instruments and detectors, where detectors are connected to instruments, and instruments are deployed at platforms. The registration process suggested in this page goes from detectors' registration (Step 2) to instruments' registration (Step 3) to platform's registration (Step 4). This order, however, is not that important, and if you prefer, it should be okay to execute the registrations of these sensor network's components in a reverse order (from Step 4 to Step 2). What is important, however, is that Steps 2, 3, and 4 are completed before deployment's registration (Step 5).

What happens when my Turtle document is complete?

We ask you to email your turtle document to Paulo Pinheiro (pinhep@rpi.edu). Once Paulo receives a document, he will manually review the document. If needed, Paulo contact you back if he has questions about the document being submitted. Otherwise, he will publish the document at http:jefferson.tw.rpi.edu/kb, and load the document into the Lake George Regional Knowledge Base (LGR-KB). Once the knowledge included in your Turtle document has been loaded into LGR-KB, you should be able to re-execute the queries in this page and verify yourself if your knowledge has been properly added to LGR-KB.




Step 1: Register OBOE entities and characteristics of OID measurements

Observations are of concrete "things", that we are generically calling OBOE entities, and they can be physical features (like air, stars or water), biological entities (like micro-organisms, tissue samples or fish), etc. Measurements are characteristics of OBOE entities, where a characteristic is defined as a property of an OBOE entity that can be measured and assigned values. In this step of OID registration, we need to verify that Jefferson's KB has knowledge about the following: an entity that has been observed, the characteristics of the entity that have been measured, and that we know for each measured characteristic, what is its entity.

Step 1.1: Identify or register entity of interest

Query for registered entities, and verify that the data in your dataset are of characteristics of these entities. It is very likely that your entity of interest is already registered. For example, say that your OID is about water transparency, where "water" is the entity and "water transparency" is the characteristic. In this case, you need to look in the Jefferson's KB for an entity "water" (or some subclass of OBOE entity that is about "water"), a characteristic "transparency", and assure that "transparency" is associated with "water" by a hasneto:hasCharacteristic predicate.

Now execute query 1.1 below to look for an OBOE entity "water".

QUERY Example 1.1 [Execute]

select ?class where
{ ?class rdfs:subClassOf+ <http://ecoinformatics.org/oboe/oboe.1.0/oboe-core.owl#Entity>.  
}

Query Example 1.1 (Alternate version with labels and descriptions) [Execute]

select ?entity ?label ?desc where
{ ?entity rdfs:subClassOf+ <http://ecoinformatics.org/oboe/oboe.1.0/oboe-core.owl#Entity>.
  OPTIONAL {
     ?entity rdfs:label ?label;
             <http://purl.org/dc/elements/1.1#description> ?desc.
 
  }  
}

A partial view of Query 1.1 results shows the following:

http://ecoinformatics.org/oboe/oboe.1.0/oboe-chemistry.owl#Carbon
http://ecoinformatics.org/oboe/oboe.1.0/oboe-chemistry.owl#Water
http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#Watershed
http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#DrainageBasin
http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#WaterBody
http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#Water
http://ecoinformatics.org/oboe/oboe.1.0/oboe-biology.owl#SubadultStageFish
http://ecoinformatics.org/oboe/oboe.1.0/oboe-biology.owl#SmoltStageFish
http://ecoinformatics.org/oboe/oboe.1.0/oboe-biology.owl#Smolt

OBOE has indeed more than one OBOE entity that is about Water. This means that we need to further inspect our knowledge base to verify if a given concept is the one suitable for our OIDs. The following query lists the superclasses of http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#Water allowing us to make a decision.

QUERY Example 1.2 [Execute]

select ?superclass where
{ <http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#Water> rdfs:subClassOf+ ?superclass.  
}

The result of Query 1.2 shows the following results:

http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#HydrologicF...
http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#PhysicalFea...
http://ecoinformatics.org/oboe/oboe.1.0/oboe-core.owl#Entity

http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#Water may be the correct entity for our OID since we know that our dataset is about hydrologic features of Lake George.

Now, let say that we repeat the procedure above looking for "air" instead of "water", and we come to the conclusion that OBOE does not have an entity "air" and that "air" should be a subclass of OBOE's http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#Atmospheric.... In this case, the following turtle code shows us how to specify our entity of interest. This is the point in the dataset registration process when turtle examples, like the one below, may be tweaked for your needs and added into the turtle document that you are creating. Since this is a turtle related to Step 1, you may want to add your version of the turtle code below the Step 1's comment in your document.

TURTLE Template 1.1

:air
   rdfs:subClassOf <http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#AtmosphericFeature>;
   hasneto:hasName "air";
.

Step 1.2: Identify or register characteristic of interest

Queries 1.3 and 1.4 below help us identify how much work we need to register our characteristic of interest. Query 1.3 lists the characteristics registered in Jefferson's KB.

QUERY Example 1.3 [Execute]

select ?class where
{ ?class rdfs:subClassOf+ <http://ecoinformatics.org/oboe/oboe.1.0/oboe-core.owl#Characteristic>.  
}

Query 1.4 shows us a list of all entities paired with their registered characteristics (and the superclasses of listed entities and characteristics). From Query 1.4, one may verify whether a characteristic listed in Query 1.3 still needs to be associated with a registered entity.

QUERY Example 1.4 [Execute]

prefix hasneto: <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#>
select ?entity ?superent ?characteristic ?superchar where
{ ?entity rdfs:subClassOf+ <http://ecoinformatics.org/oboe/oboe.1.0/oboe-core.owl#Entity>. 
  ?entity rdfs:subClassOf ?superent.
  OPTIONAL { ?entity hasneto:hasCharacteristic ?characteristic.
             ?characteristic rdfs:subClassOf ?superchar. }  
}

Lets say that the entity "AtmosphericFeature" and characteristic "Temperature" are registered, and that neither entity "Air" nor its characteristic "Air Temperature" are registered. Turtle statements to register air and air's temperature are below:

TURTLE Template 1.2

:air
   rdfs:subClassOf <http://ecoinformatics.org/oboe/oboe.1.0/oboe-environment.owl#AtmosphericFeature>;
   hasneto:hasCharacteristic  :airTemperature;
   hasneto:hasName "air";
.
 
:airTemperature
   rdfs:subClassOf <http://ecoinformatics.org/oboe/oboe.1.0/oboe-characteristics.owl#Temperature>;
   hasneto:hasName "air temperature";

It may be the case that an entity of interest is registered but that one or more of the characteristics of interest are not registered. For instance, let assume that "air" is registered but that "Temperature" characteristic is not. In this case, you will need to register only the characteristic, and the fact that the new characteristic is of the existing :air entity. Turtle Example 1.3 is a simplified version of Turtle Example 1.2 since the definition of the :air concept is just enhanced with the new fact that :air has :airTemperature characteristic.

TURTLE Template 1.3

:air
   hasneto:hasCharacteristic  :airTemperature;
.
 
:airTemperature
   rdfs:subClassOf <http://ecoinformatics.org/oboe/oboe.1.0/oboe-characteristics.owl#Temperature>;
   hasneto:hasName "air temperature";
.




Step 2: Register detectors associated with OID

Measurements in a dataset may come from one or more detectors. Within the Jefferson Project, we expect detectors generating OIDs to be registered. You need to query for registered detectors, and verify if the data in your dataset are from listed detectors. The following SPARQL query lists registered detectors and their corresponding models.
Detectors not included in the query output need to be added. If models of detectors of interest are not listed, they may also need to be registered.

Step 2.1: Register detector’s model

QUERY Example 2.1 [Execute]

prefix vstoi: <http://jefferson.tw.rpi.edu/ontology/vsto-instrument.owl#>
select ?detector ?superdetector where
{ ?detector rdfs:subClassOf+ vstoi:Detector.  
   ?detector rdfs:subClassOf ?superdetector.
}

You may skip this step if the model of a detector of interest is already registered. If not, you will need to register the model including the association between the model and characteristics related to your detector of interest. Let say that detector model "HMP155" of maker "Vaisala" needs to be registered and that this model is used to measure air temperature. By executing Query Example 1 you may see that the URI for air temperature is ":airTemperature" (if the characteristic of interest is not listed, you may need to revisit Step 1). The following example shows the turtle fragment required to register the model and corresponding characteristic.

TURTLE Template 2.1

:vaisalaHMP155
   rdfs:subClassOf vstoi:Thermometer;
   hasneto:hasName "Vaisala HMP155";
   hasneto:detectsCharacteristic :airTemperature;
.

Step 2.2: Register detector

QUERY Example 2.2 [Execute]

prefix vstoi: <http://jefferson.tw.rpi.edu/ontology/vsto-instrument.owl#>  
prefix hasneto: <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#>  
select ?detector ?modelName ?characteristic where 
{ ?detectorModel rdfs:subClassOf+ vstoi:Detector. 
  ?detector a ?detectorModel. 
  ?detectorModel hasneto:hasName ?modelName.
  OPTIONAL { ?detectorModel hasneto:detectsCharacteristic ?characteristic. }
}

At this point, we assume that the turtle for the model of the detector being registered is already created. For example, lets say that we need to register a detector of model "Vaisala HMP155" with serial number "000000." From Turtle Example 3, we know that the URI for the model is ":vaisalaHMP155". If the model was already registered you can rerun Query Example 2 to verify the URI of the detector's model. In this case, the following Turtle code will be used to register the HMP155 detector with serial number "000000".

TURTLE Template 2.2

:vaisalaHMP155-SN000000
   a :vaisalaHMP155;
.




Step 3: Register instrument associated with OID

Measurements in an OID come from one instrument. Within the Jefferson Project, we expect that instruments used during the generation of OIDs need to be registered. We expect registered instrument models to be subclasses of http://jefferson.tw.rpi.edu/ontology/vsto-instrument.owl#Instrument. Query for registered instruments, and verify if the data in your OID are from listed instruments.

Step 3.1: Identify or register the instrument’s model

Use Query 3.1 to list registered instrument models, and verify if the data in your OID are from instruments of listed instrument models.

QUERY Example 3.1 [Execute]

prefix vstoi: <http://jefferson.tw.rpi.edu/ontology/vsto-instrument.owl#>  
select ?instrument ?superinstrument where
{ ?instrument rdfs:subClassOf+ vstoi:Instrument.  
   ?instrument rdfs:subClassOf ?superinstrument.
}

You may skip this step if the model of an instrument of interest is already registered. If not, you will need to register the model. Let say that we need to register an instrument model of maker named "Vaisala" with model number "AW310." The following example shows the turtle fragment required to register the model.

TURTLE Template 3.1

:vaisalaAW310
   rdfs:subClassOf vstoi:Instrument;
   hasneto:hasName  "Vaisala AW310";
.

Step 3.2: Register instrument

Query for registered instruments, and verify if the data in your OID are from listed instruments.

QUERY Example 3.2 [Execute]

prefix hasneto: <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#>  
prefix vstoi: <http://jefferson.tw.rpi.edu/ontology/vsto-instrument.owl#>  
select ?instrument, ?modelName where 
{ ?instrumentModel rdfs:subClassOf+ vstoi:Instrument. 
  ?instrument a ?instrumentModel. 
  ?instrumentModel hasneto:hasName ?modelName.}

At this point in the OID registration process, we assume that the turtle for the model of the instrument being registered has already been created. We further assume the need to register an instrument of model "Vaisala AW310" with serial number "000000." From Turtle Example 5, we know that the URI for the model is ":vaisalaAW310". If the model was already registered you can rerun Query Example 2 to verify the URI of the detector's model. In this case, the following Turtle code will be used to register the AW310 instrument with serial number "000000".

TURTLE Template 3.2

:vaisalaAW310-SN000000
   a :vaisalaAW310;
.




Step 4: Register platform associated with OID

Measurements in OIDs come from instruments that were deployed at a given platform and made available to execute measurements. Within the Jefferson Project, we expect platforms where instruments can be deployed to be registered. Query for registered platforms, and verify if the platform that was used by the instrument generating your OID is registered.

Step 4.1: Identify or register platform’s model

QUERY Example 4.1 [Execute]

prefix hasneto: <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#>  
prefix vstoi: <http://jefferson.tw.rpi.edu/ontology/vsto-instrument.owl#>  
select ?platformModel, ?modelName where 
{ ?platformModel rdfs:subClassOf+ vstoi:Platform. 
  ?platformModel hasneto:hasName ?modelName.}

You may skip this step if the model of a platform of interest is already registered. If not, you will need to register the model. Let say that we need to register a Cessna 172 airplane as a platform The following example shows the turtle fragment required to register the model.

TURTLE Template 4.1

:cessna172
   rdfs:subClassOf vstoi:Platform;
   hasneto:hasName  "Cessna 172";
.

Step 4.2: Register platform instance

QUERY Example 4.2 [Execute]

prefix hasneto: <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#>  
prefix vstoi: <http://jefferson.tw.rpi.edu/ontology/vsto-instrument.owl#>  
select ?platform, ?modelName where 
{ ?platformModel rdfs:subClassOf+ vstoi:Platform. 
  ?platform a ?platformModel. 
  ?platformModel hasneto:hasName ?modelName.}

At this point in the OID registration process, we assume that the turtle for the model of the platform being registered has already been created. We further assume the need to register a platform of model "Cessna 172" with serial number "000000." From Turtle Example 5, we know that the URI for the model is ":cessna172". If the model was already registered you can rerun Query Example 2 to verify the URI of the platform's model. In this case, the following Turtle code will be used to register the Cessna 172 instrument with serial number "000000".

TURTLE Template 4.2

:cessna172-SN000000
   a :cessna172;
.

Step 4.3: Register platform instance location

(instructions for this step will be added next week)




Step 5: Register deployment associated with OID

So far, we have verified either that the Jefferson's KB has knowledge about instruments, detectors and platforms, or that RDF/Turtle was created with missing knowledge. This means that Jefferson's KB will eventually have knowledge about the main components of the Jefferson's sensor network. What is not in the Jefferson's KB yet is the knowledge about how the sensor network components are connected to each other over time. These connections are defined at deployment time, and as such, deployment metadata needs to be captured and collected every time an instrument is deployed and undeployed. Below we illustrate how this knowledge is going to be encoded in RDF/Turtle.

Step 5.1: Verify if deployment's metadata exists or if it needs to be registered

Let say that we want to document a deployment D1 of instrument :aw310-SN000000 at platform :genericTower in the period between 10am and 11am on March 12, 2013 is registered. The following query will list all past and current deployments, and by visual inspection, one may verify that D1 is :dp1.

QUERY Example 5.1 [Execute]

prefix hasneto: <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#>  
select ?deployment ?instrument ?platform ?startTime ?endTime where 
{ ?deployment a <http://jefferson.rpi.edu/ontology/vsto-instrument.owl#Deployment>. 
  ?deployment hasneto:hasInstrument ?instrument.
  ?platform hasneto:hasDeployment ?deployment.
  ?deployment hasneto:startedAtTime ?startTime.
  OPTIONAL { ?deployment hasneto:endedAtTime ?endTime. }
}

Query Example 5 may be tweaked to restrict the responses, and thus facilitate the search for deployments of interest. For example, Query Example 6 below shows how to query for all deployments of instrument :vaisalaAW310-SN000000. Other query variations could restrict the name of the platform instead of the instrument, could restrict both the instrument and the platform, and could even restrict restrict to current deployments of a given instrument on a given platform.

QUERY Example 5.2 [Execute]

prefix hasneto: <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#>  
prefix kb: <http://jefferson.tw.rpi.edu/kb/jp-kb#>
select ?deployment ?platform ?startTime ?endTime where 
{ ?deployment a <http://jefferson.rpi.edu/ontology/vsto-instrument.owl#Deployment>. 
  ?deployment hasneto:hasInstrument kb:vaisalaAW310-SN000000.
  ?platform hasneto:hasDeployment ?deployment.
  ?deployment hasneto:startedAtTime ?startTime.
  OPTIONAL { ?deployment hasneto:endedAtTime ?endTime. }
}

If the deployment related to our dataset is already registered, we can skip to Step 6 to register the observation related to our OID.

Step 5.2: Deployment registration

:dp1 is a W3C PROV activity that has a startedAtTime value, and optionally an endedAtTime value. If endedAtTime value is unavailable, :dp1 is assumed to be an ongoing activity. If :dp1 has an endedAtTime value, its startedAtTime must occur either before or at the same time its endedAtTime occurred. Below we show a RDF/Turtle example of a deployment.

TURTLE Template 5

:dp1
      a vstoi:Deployment;
      hasneto:hasInstrument :vaisalaAW310-SN000000;
      hasneto:hasDetector    :vaisalaWMT52-SN000000;
      hasneto:hasDetector    :vaisalaHMP155-SN000000;
      prov:startedAtTime  "2014-02-10T01:01:01Z"^^xsd:dateTime;
      prov:endedAtTime    "2014-02-17T01:20:02Z"^^xsd:dateTime;
.

Long time periods

HASNetO startedAtTime and endedAtTime are data properties of type xsd:dateTime. HASNetO allows specifications of long periods of time like months and years as long the date/time constraints above are respected. This means, for example that the “Year of 2013” or the “Month of March, 2013” can be represented as follows:

Example on how to specify a deployment for the Year of 2013

:dp1 prov:startedAtTime  "2013-01-01T00:00:00Z"^^xsd:dateTime;
        prov:endedAtTime    "2013-12-31T23:59:59Z"^^xsd:dateTime.

Example on how to specify a deplyment for the month of March, 2013

:dp1 prov:startedAtTime    "2013-03-01T00:00:00Z"^^xsd:dateTime;
       prov:endedAtTime      "2013-03-31T23:59:59Z"^^xsd:dateTime.

Step 5.3: Register agent (person/organization/software) responsible to deployment

(At the moment, we will provide brief instruction on how to query for agents. Further instructions for this step will be added next week)

Query 5.3 below lists organizations with sub-organizations currently registered in the Jefferson's knowledge base.

QUERY Example 5.3 [Execute]

prefix foaf:    <http://xmlns.com/foaf/0.1/>
SELECT  ?org ?orgname ?suborg ?suborgname WHERE { 
    ?suborg foaf:actedOnBehalfOf ?org.
    ?org a foaf:Organization.
    ?org foaf:name ?orgname.
    ?suborg a foaf:Organization.
    ?suborg foaf:name ?suborgname.  
}

Query 5.4 below lists people registered in the Jefferson's knowledge base and their organizations.

QUERY Example 5.4 [Execute]

prefix foaf:    <http://xmlns.com/foaf/0.1/>
SELECT  ?person ?name ?organization WHERE { 
    ?person a foaf:Person .
    ?person foaf:givenName ?name.
    ?person foaf:actedOnBehalfOf ?organization.
}




Step 6: Register observation associated with dataset

Lets say that we want to register an observation that occurred during deployment :dp1, which was registered in Step 5. By inspecting the start and end times of observations associated with :dp1, one may conclude whether the observation of interest has been registered or the observation of interest needs to be registered. The following query lists all observations related to :dp1.

QUERY Example 6.1 [Execute]

prefix hasneto: <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#>  
prefix kb: <http://jefferson.tw.rpi.edu/kb/jp-kb#>
select ?observation ?startTime ?endTime where 
{ kb:dp1 hasneto:hasObservation ?observation. 
  ?observation prov:startedAtTime ?startTime.
  OPTIONAL { ?observation prov:endedAtTime ?endTime. }
}

Instead of looking for deployments and observations, Query 6.2 leverages the fact that both deployments and observations are subclasses of W3c PROV's Activity.

QUERY Example 6.2 [Execute]

select ?activityType ?activity where 
{ 
   ?activityType rdfs:subClassOf+ <http://www.w3.org/ns/prov#Activity>.
   OPTIONAL { ?activity a ?activityType. } 
}

Now lets assume that :dp1 has one associated observation named :obs1 that is not the observation associated with our OID because, for example, the configuration parameters of the instrument are not the same as the observation associated with our OID. The following code shows how to register our observation of interest. It its important to note that we would also add the newly registered observation, i.e., observation :obs2, to our deployment :dp1. In that case, the hasneto:hasObservation statement can be added as in the example below, or in the block of statements related to :dp1.

TURTLE Template 6

:obs2 
    a <http://ecoinformatics.org/oboe/oboe.1.0/oboe-core.owl#Observation>;
     hasneto:ofEntity hasneto:wind;
     prov:startedAtTime    "2014-02-15T01:01:01Z"^^xsd:dateTime;
     prov:endedAtTime    "2014-02-17T01:01:01Z"^^xsd:dateTime;
.
 
:dp1
     hasneto:hasObservation :obs2;
.

Step 6.1: Register agent (person/organization/software) responsible to observation

(instructions for this step will be added next week)

Step 6.2: Register instrument/detector inputs (e.g., calibration data, configuration parameters) used during observation

(instructions for this step will be added next week)




Step 7: Register OID metadata in Jefferson's KB

Within the Jefferson project, we expect every OID from our sensors: to have a unique URI defined as a HASNetO Dataset; and to associated with a registered observation. Query Example 8 list known datasets with their associated observations and deployments. From the query results, one may verify if a given dataset has been registered. In practical terms, we expect the list of datasets to grow to a point where exploring a full list of registered datasets would be impractical.

QUERY Example 7 [Execute]

prefix hasneto: <http://jefferson.tw.rpi.edu/ontology/hasneto.owl#>  
select ?dataset ?observation ?deployment where 
{ ?dataset a  hasneto:Dataset. 
  ?dataset prov:wasGeneratedBy ?observation. 
  ?deployment hasneto:hasObservation ?observation. }

The turtle template below shows how to assign :dset2 as the URI of our OID of interest. The turtle further specify that :dset2 is associate with observation :obs2 created in Step 6 above.

TURTLE Template 7

:dset2 
    a vstoi:Dataset;
    prov:wasGeneratedBy  :obs2;

The dataset metadata registration process is complete, congratulation!