search

Semantic-Observations / obs-models

Alignment of semantic observation models
3 stars 0 forks source link

Data: Fill in Sargasso Sea Lipids semantic annotation template #41

Open amoeba opened 8 years ago

amoeba commented 8 years ago

@mpsaloha, the semantic annotation template for the Sargasso Sea Lipids dataset is created but needs to be filled in with appropriate classes. The semantic annotation template is at:

https://github.com/Semantic-Observations/obs-models/blob/master/examples/sargasso-sea-lipids.csv

We think we have the Observations marked up correctly with the right set of hasContext statements. We need help filling in concepts for Entity, Characteristic, Standard for each of the measurements. Could you please take a look?

The dataset metadata is at http://www.bco-dmo.org/dataset/3584 which describes the dataset in detail. See 'Parameters' under 'More Information about this dataset' for details on parameters.

If I can help at all to make things go faster please let me know. I'd be happy to schedule a call to talk about the file format, for example.

The table below lays out the attributes (column names) and the concepts they're currently mapped to.

Note: domain is a made-up namespace geo is http://www.w3.org/2003/01/geo/

attribute Entity Characteristic Standard
cast TODO TODO TODO
date owl-time:Instant TODO TODO
time owl-time:Instant TODO TODO
lat geo:Point pato:PATO_0000140 geo:lat
lon geo:Point pato:PATO_0000140 geo:lon
prmax TODO oboe-characteristic:Pressure oboe-standard:Bar
depth TODO pato:PATO_0001595 oboe-standard:Length
press envo:ENVO_00002149 oboe-characteristic:Pressure oboe-standard:Bar
temp envo:ENVO_00002149 pato:PATO_0000146 oboe-standard:Celsius
sal envo:ENVO_00002149 oboe-characteristic:MassPerMass oboe-standard:PracticalSalinityUnit
potemp envo:ENVO_00002149 oboe-characteristic:PotentialTemperatureCharacteristic oboe-standard: oboe-standard:Celsius
sigma_0 envo:ENVO_00002149 oboe-characteristic:VolumetricDensity oboe-standard:KilogramPerMeterCubed
O2_ml_L envo:ENVO_00002149 oboe-characteristic:VolumePerVolumne oboe-standard:MilliliterPerLiter
fluor envo:ENVO_00002149 oboe-characteristic:pato:PATO_0000018 TODO
PAR envo:ENVO_00002149 TODO oboe-standard:MicroeinsteinsPerMeterSquaredPerSecond
beam_cp envo:ENVO_00002149 TODO oboe-standard:NumberPerMeterSquared
trans envo:ENVO_00002149 TODO oboe-standards:Percent

We could use help editing and adding to the above table.

amoeba commented 8 years ago

Updated the above table with the best guesses I have so far.

mpsaloha commented 8 years ago

Bryce-- the GeoSPARQL spec might have some of the geospatial entities that you need. For time stuff, there are some xsd datatypes that could be used? Or I believe a W3C time ontology?

dr-shorthair commented 8 years ago

Yes - for Time, use OWL-Time http://www.w3.org/2006/time, e.g. http://www.w3.org/2006/time#Instant (though also see http://www.semantic-web-journal.net/content/time-ontology-extended-non-gregorian-calendar-applications-0)

For location, it is recommended not to have separate columns for (x,y) since (a) they are not independent of each other (b) also need a CRS to interpret position properly.

GeoSPARQL https://en.wikipedia.org/wiki/GeoSPARQL embeds strings formatted as GML or WKT for geometry. GeoJSON is another obvious candidate.

amoeba commented 8 years ago

Thanks @mpsaloha and @dr-shorthair.

I'm happy with using an instance of OWL-Time's #Instant class for the subject of OBOE:ofEntity statement for the date and times in this dataset. What about Characteristics and Standards for these values? The values for date are like '20110315' and time are '1639'. Are there standards for these encodings of dates and times? I saw some standards for other types of dates/times in your paper, like years-before-present, but none that would work with this dataset which uses european dates (YYYYMMDD) and one form military time (HHMM).

GeoSPARQL looks sufficient for the OBOE:ofEntity. Would the subject of the oboe:ofEntity statement be a geosparql:Feature? That's pretty vague. And what about the characteristic being measured or the standard being used to make that measurements (lat, lon)? I've been looking for a NamedIndividual called something like "Decimal degrees north of the equator" for the Characteristic and "DegreesLatitude" for the standard but have had no luck.

Here are example triples for an observation of date+time, with missing values written out as '???':

[]
    oboe:hasMeasurement [
        oboe:hasValue '20110315' ;
        oboe:ofCharacteristic [
            a ???
        ] ;
        oboe:usesStandard [
            a ???
        ] ;
    ] , [
        oboe:hasValue '1639' ;
        oboe:ofCharacteristic [
            a ???
        ] ;
        oboe:usesStandard [
            a ???
        ] ;
    ]
    oboe:ofEntity [
        a <owl-time:Instant>
    ] ;
 a oboe:Observation .

And here's what I have for the observation of lat+lon, again with missing values written out as '???':

[]
    oboe:hasMeasurement [
        oboe:hasValue '33.002' ;
        oboe:ofCharacteristic [
            a ???
        ] ;
        oboe:usesStandard [
            a ???
        ] ;
    ] , [
        oboe:hasValue ' -64.005' ;
        oboe:ofCharacteristic [
            a ???
        ] ;
        oboe:usesStandard [
            a ???
        ] ;
    ]
    oboe:ofEntity [
        a <owl-time:Instant>
    ] ;
 a oboe:Observation .

Any ideas?

robgur commented 8 years ago

Would it be so bad to use dwc:latitude and dwc:longitude for the latlon pairs? On Oct 5, 2015 3:21 PM, "Bryce Mecum" notifications@github.com wrote:

Thanks @mpsaloha https://github.com/mpsaloha and @dr-shorthair https://github.com/dr-shorthair.

I'm happy with using an instance of OWL-Time's #Instant class for the subject of OBOE:ofEntity statement for the date and times in this dataset. What about Characteristics and Standards for these values? The values for date are like '20110315' and time are '1639'. Are there standards for these encodings of dates and times? I saw some standards for other types of dates/times in your paper, like years-before-present, but none that would work with this dataset which uses european dates (YYYYMMDD) and one form military time (HHMM).

GeoSPARQL looks sufficient for the OBOE:ofEntity. Would the subject of the oboe:ofEntity statement be a geosparql:Feature? That's pretty vague. And what about the characteristic being measured or the standard being used to make that measurements (lat, lon)? I've been looking for a NamedIndividual called something like "Decimal degrees north of the equator" for the Characteristic and "DegreesLatitude" for the standard but have had no luck.

Here are example triples for an observation of date+time, with missing values written out as '???':

[] oboe:hasMeasurement [ oboe:hasValue '20110315' ; oboe:ofCharacteristic [ a ??? ] ; oboe:usesStandard [ a ??? ] ; ] , [ oboe:hasValue '1639' ; oboe:ofCharacteristic [ a ??? ] ; oboe:usesStandard [ a ??? ] ; ] oboe:ofEntity [ a owl-time:Instant ] ; a oboe:Observation .

And here's what I have for the observation of lat+lon, again with missing values written out as '???':

[] oboe:hasMeasurement [ oboe:hasValue '33.002' ; oboe:ofCharacteristic [ a ??? ] ; oboe:usesStandard [ a ??? ] ; ] , [ oboe:hasValue ' -64.005' ; oboe:ofCharacteristic [ a ??? ] ; oboe:usesStandard [ a ??? ] ; ] oboe:ofEntity [ a owl-time:Instant ] ; a oboe:Observation .

Any ideas?

— Reply to this email directly or view it on GitHub https://github.com/Semantic-Observations/obs-models/issues/41#issuecomment-145637696 .

dr-shorthair commented 8 years ago

@amoeba - OWL-Time is really only necessary if you want to mix Intervals and Instants, and have safe ordering relationships (temporal topology) preserved, and that requires a non-standard 'temporal reasoner' anyway.

If you only need time-instants, then two helpful types are built-in to OWL2 - xsd:dateTime and xsd:dateTimeStamp http://www.w3.org/TR/owl2-quick-reference/#Built-in_Datatypes . The lexical form of xsd:dateTime is described in the XSD spec: http://www.w3.org/TR/xmlschema11-2/#dateTime which includes the following example

2002-10-10T12:00:00−05:00 (noon on 10 October 2002, Central Daylight Savings Time as well as Eastern Standard Time in the U.S.) 
which is equal to 2002-10-10T17:00:00Z, 
which is five hours later than 2002-10-10T12:00:00Z

Note that the punctuation characters are mandatory, and only the final of the seven (!) sub-fields is optional, though omitting the timezone is not recommended and there is a shorthand 'Z' for UTC in place of +00.00 at the end.

xsd:dataTimeStamp makes the timezone indicator mandatory, which is stongly recommended. Since the whole reason for going to OWL is to get the reasoning support, you shouldn't undermine ordering by omitting the timezone.

There are other time and data types in XSD, but those are not built in to OWL.

@amoeba - yes, I guess

oboe-core:Entity owl:equivalentClass geosparql:Feature .

unless you want to limit oboe-core:Entity to biological things, in which case it would be a rdfs:subClassOf relationship instead. Assuming that the tabulated location of the Observation is actually the location of the Entity being observed, then indeed it requires that the coordinates be associated with this individual, presumably using geosparql:hasGeometry .

@robgur - depends on the extent to which we want to limit ourselves to DWC. We may want to use something more rigorous as the canonical form, and transform out to DWC for applications that expect DWC.

I know it is tempting to apply the KISS principle and just use RDF properties for lat and lon (this is what DWC and also W3C Geo do) but on only slightly deeper investigation it is a false economy, for the following reason: position is inherently a vector quantity, so lat and lon values are not independent of each other, and any non-trivial spatial operation requires the two (or three) coordinates to be used together. At the very least this requires math which is beyond a standard OWL reasoner or SPARQL engine, and in the general case requires coordinate transformations as well, which requires CRS's and CRS engines.

In addition, many spatial positions are recorded in coordinate systems with axes other than lat, lon, but you can't easily generalize the RDF tags, and remember also that ordering of properties is not a strong point in RDF. The consensus in the geo community is that position needs its own data-type, and a spatial engine to process it. Hence GeoSPARQL.

mbjones commented 8 years ago

@amoeba @robgur @dr-shorthair Regarding Simon's comments, I fully agree in theory that what he describes is the best way to create things de novo.

However, in this case, we are modeling existing data structures, in which there is a column of data in a file or database with the name 'lat' and which represents the latitude portion of a point -- the very purpose of the annotation is to take this data structure with no or weak semantics and annotate it in order to explicitly state that column 3 is a 'Latitude' and, combined with the column 4 'lon' which is a Longitude, the two make up a concept of an observation of a spatial point. So, I think we do need a Concept for latitude and one for longitude, as well as one for SpatialPoint. We'll also need defined concepts for other means of representing spatial measurements, such as UTM x and y coordinates that we commonly find in data columns.

dr-shorthair commented 8 years ago

OK - if you want tags 'lat' and 'lon', find them here:

http://www.w3.org/2003/01/geo/wgs84_pos#lat http://www.w3.org/2003/01/geo/wgs84_pos#long also http://www.w3.org/2003/01/geo/wgs84_pos#alt and http://www.w3.org/2003/01/geo/wgs84_pos#lat_long

No point in doing anything new. In this context,

geosparql:SpatialObject owl:equivalentClass http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing . geosparql:Feature rdfs:subClassOf http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing . oboe-core:Entity rdfs:subClassOf http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing . http://www.w3.org/2003/01/geo/wgs84_pos#Point rdfs:subClassOf geosparql:Geometry .

dr-shorthair commented 8 years ago

Looking again at the treatment of position: do you have to use a measurement to capture every attribute in OBOE? If so, then you will probably need to use one of these: http://www.opengis.net/def/axis/ogc/1.0/ http://www.opengis.net/def/axis/EPSG/0/ (this list is unfriendly, sorry - not my system)

amoeba commented 8 years ago

Do you mean 'every attribute' in the sense that saying '-64.005' is a <http://www.w3.org/2003/01/geo/wgs84_pos#long> is insufficient for understanding it and that it really has multiple implicit attributes or do you mean 'attribute' in the sense of 'a column in the tabular dataset'?

dr-shorthair commented 8 years ago

I mean does every column in the table have to be treated the same in OBOE? Are oboe measurements the only place to put data? Most geospatial models treat time and space differently, unless the method used to determine them is interesting.

mbjones commented 8 years ago

Yes, time and space are treated uniformly in OBOE like other measurements, and there are no separate fields for time and space even though they are common measurement types for context, along with biological taxonomy.

amoeba commented 8 years ago

Worked on this some more:

Columns: 'lat' and 'lon'

wernerkuhn commented 8 years ago

Excuse my superficial remark from a probably uninformed perspective: do we really want to base our semantics on that definition of the PATO ‘position' class you quote? It could come straight out of a French philosophy text translated into English (if I may say so). I am not blaming you for this, but hoping we can find something better. What exactly do we need there?

--  Werner 

On December 10, 2015 at 2:12:25 PM, Bryce Mecum (notifications@github.com) wrote:

Worked on this some more:

Columns: 'lat' and 'lon'

Entity I went ahead and used geo:Point because that's the more specific (compared to geo:SpatialThing or geo:Feature). I also created the alignment triple:

geo:SpatialThing rdfs:subClassOf oboe-core:Entity

Characteristic

I wanted something like x:location. PATO has a 'position' class (ontobee link) which is defined as

A spatial quality inhering in a bearer by virtue of the bearer's spatial location relative to other objects in the vicinity.

so I also added the alignment triple:

pato:PATO_0000140 rdfs:subClassOf oboe-core:Characteristic

Standard

I was looking for something about decimal degrees lat/lon. Measurements of position are much more complicated than this but I think finding something about decimal degrees is enough. The definition of geo:latitude and geo:longitude specify decimal degrees.

Still working on this the Standard.

— Reply to this email directly or view it on GitHub.

amoeba commented 8 years ago

Thanks for chiming in @wernerkuhn. I am likely the least experienced with these things so I welcome the feedback.

I went with PATO's 'position' simply because I finally found something that I thought could work and we've been using PATO for other parts of this example. From a practical perspective, I am happy to change it.

Since I'm looking for something compatible with oboe:Characteristic (via a subclass or equivalentclass) that we can use for the concept of theoboe:Characteristic being measured when we report decimal latitude or longitude. How specific we get is up for debate. oboe:Characteristics for other columns in this dataset include:

wernerkuhn commented 8 years ago

I understand and am all for a practical solution. But why would an ontology of phenotypes be a useful source for location vocabularies? What alternatives do we have?

--  Werner 

On December 10, 2015 at 4:00:30 PM, Bryce Mecum (notifications@github.com) wrote:

Thanks for chiming in @wernerkuhn. I am likely the least experienced with these things so I welcome the feedback.

I went with PATO's 'position' simply because I finally found something that I thought could work and we've been using PATO for other parts of this example. From a practical perspective, I am happy to change it.

Since I'm looking for something compatible with oboe:Characteristic (via a subclass or equivalentclass) that we can use for the concept of theoboe:Characteristic being measured when we report decimal latitude or longitude. How specific we get is up for debate. oboe:Characteristics for other columns in this dataset include:

pato:Depth oboe:Pressure oboe:VolumetricDensity oboe:MassPerMass oboe:VolumePerColume etc — Reply to this email directly or view it on GitHub.

amoeba commented 8 years ago

There are other options, but nothing I've found refers to the concept of location (which is closer to what I want). If others think it's okay, we could use:

wernerkuhn commented 8 years ago

So, what is it that you want? A location relative to another entity or a position in a coordinate reference system? Or both or something else?

--  Werner 

On December 10, 2015 at 4:22:50 PM, Bryce Mecum (notifications@github.com) wrote:

There are other options, but nothing I've found refers to the concept of location (which is closer to what I want). If others think it's okay, we could use:

We could use wgs_84:SpatialThing: "Anything with spatial extent, i.e. size, shape, or position. e.g. people, places, bowling balls, as well as abstract areas like cubes." http://www.w3.org/2007/uwa/context/location.owl#Position -- Not really sure what this ontology is I didn't find anything in GeoSPARQL — Reply to this email directly or view it on GitHub.

amoeba commented 8 years ago

I'd be happy if I found something like "Where something is in space". I don't think we need to get as specific as CRS's.

But I don't think I know enough about what the implications are of choosing one concept over another. As I understand it, we're marking up these datasets and running SPARQL queries over them. I assume any poor choices in doing this part would come up when we write/run our queries and we could edit the above list as needed.

I'm eager to see what other think about what we've been talking about here. Thanks for bringing this up.

amoeba commented 8 years ago

@mpsaloha I'm having trouble tracking down an oboe:Characteristic for the potential temperature of water. I did find this:

<!-- http://ecoinformatics.org/oboe-ext/sbclter.1.0/oboe-sbclter.owl#PotentialTemperatureWater -->

    <owl:Class rdf:about="#PotentialTemperatureWater">
        <rdfs:subClassOf rdf:resource="#PhysicalOceanographic"/>
        <rdfs:subClassOf rdf:resource="#TemperatureType"/>
    </owl:Class>

Any thoughts?

dr-shorthair commented 8 years ago

I'm a bit unclear about the namespaces you are using here Bryce. The W3C Basic Geo vocabulary http://www.w3.org/2003/01/geo/ contains the classes SpatialThing, Point and the properties location, lat, long, (also lat_long, alt) There is no 'latitude' or 'longitude'. But the predicate 'location' might fit your bill.

OGC GeoSparql http://www.opengis.net/ont/geosparql contains classes SpatialObject, Feature, Geometry and many properties, including hasGeometry, defaultGeometry GeoSparql does not have specific named coordinates, because it allows any CRS to be used, which involve different axis names like easting and northing as well as latitude and longitude.

amoeba commented 8 years ago

Thanks for the catch. I had intended to reference the http://www.w3.org/2003/01/geo/ for Point, lat, and lon as I thought it was sufficient for our needs. Sorry for the confusion.

dr-shorthair commented 8 years ago

This all does underline, however, the issues I was raising. Treating 'latitude' and 'longitude' as scalar values is customary, but incorrect. Coordinate values are not independent of each other, or of the coordinate reference system in use. These components are strictly axes of a CRS. Widespread availability of GPS has made life easier for the user, but if semantics is our game, then we need to be careful.

amoeba commented 8 years ago

Is observation modeling even capable of handling this nuance though? We need to mark up the observation-level semantics for each column in our data independent of one another I feel like we're stuck with this because of that restriction.

dr-shorthair commented 8 years ago

I see what you are doing here. The input is just two columns. In the output you are lifting it to a 2-D point. The W3C Geo vocabulary kinda captures common practice, as encouraged by GPS, but is inadequate if any other CRS is involved (e.g. UTM coordinates, British National Grid, etc). Much historic data will be using various customary coordinate systems, often Transverse Mercator, taken from paper maps. So it might be a false economy to adopt W3C since it is not universally applicable, particularly for historic data.

dr-shorthair commented 8 years ago

Above you wrote "I don't think we need to get as specific as CRS's." If everyone was using GPS with the same settings, maybe. But is this the case?

wernerkuhn commented 8 years ago

Also, how are you dealing with place names? I think the underlying issue here is not just different reference systems, and possibly 1/2/3 dimensions, but that we need to have a way of annotating one or more columns together as encodings of location. 

--  Werner 

On December 11, 2015 at 10:39:15 AM, Simon Cox (notifications@github.com) wrote:

I see what you are doing here. The input is just two columns. In the output you are lifting it to a 2-D point. The W3C Geo vocabulary kinda captures common practice, as encouraged by GPS, but is inadequate if any other CRS is involved (e.g. UTM coordinates, British National Grid, etc). Much historic data will be using various customary coordinate systems, often Transverse Mercator, taken from paper maps. So it might be a false economy to adopt W3C since it is not universally applicable, particularly for historic data.

— Reply to this email directly or view it on GitHub.

dr-shorthair commented 8 years ago

And regarding CRS: datum shifts can affect locations by 100s metres. Australia had a datum shift in 1994 which moved most by ca. 200m

amoeba commented 8 years ago

It would be a very poor assumption to assume everyone used the same GPS settings. However.

We're limited to what's in the data and metadata. For this Sargasso dataset, the only think we know is that there is a string which reads "-112.12" and it is in a column called 'longitude'. I'm doing the rest of the inference about what that string means. We aren't given the Standard by which the value was measured against we should (1) do something with few assumptions and (2) do something that will be least wrong most of the time.

robgur commented 8 years ago

We absolutely need datum.

On Fri, Dec 11, 2015 at 1:43 PM, Simon Cox notifications@github.com wrote:

And regarding CRS: datum shifts can affect locations by 100s metres. Australia had a datum shift in 1994 which moved most by ca. 200m

— Reply to this email directly or view it on GitHub https://github.com/Semantic-Observations/obs-models/issues/41#issuecomment-164014535 .

amoeba commented 8 years ago

(Minor correction to my above). Here's what this dataset specifies about its lat and lon parameters:

lon: http://www.bco-dmo.org/dataset-parameter/26425 lat: http://www.bco-dmo.org/dataset-parameter/26426

Edit: Which leads up to http://vocab.nerc.ac.uk/collection/P09/current/LONX/

dr-shorthair commented 8 years ago

Yes - the limitation is in the input data. I think this is in the OBOE model, which does not couple columns or provide CRS information. So the question is what assumptions can be built in to the algorithm that lifts it into a different vocabulary/ontology. Primarily, if or when we can use richer concepts like geo:Point (which implies WGS84) or geosparql:Geometry (which requires an explicit CRS). It'll probably be on a dataset-by-dataset basis, so this should be built into the process.

amoeba commented 8 years ago

I think that's great, and also necessary. For simpler data like the weight of things, we're able to completely specify the semantics with a Characterstic of Weight and a Standard of, e.g., Kilograms such that when another value in another dataset has Weight values measured against a Standard of Pounds, we can convert between the two with near-perfect accuracy.

Leaving latitude and longitude without this same degree of treatment would be inconsistent with how we treat other attributes. I'm open to suggestions.

mbjones commented 8 years ago

@dr-shorthair wrote: "OBOE model, which does not couple columns"; in my perspective, coupling columns is exactly what OBOE does, and why an OBOE Observation is composed of multiple Measurements. Given a data set that has two variables (lat, lon) that are described in natural language metadata as a paired latitude and longitude value, OBOE allows us to describe these as a single Observation that represents a Point that has the requisite information to be machine-parseable. Our challenge I think is using the right vocabulary to indicate just how the lat and lon values that we find in our data files are related to these Observations. In this particular data set, we need OWL classes for the following general concepts: Latitude, Longitude, Point, Datum, CRS. Which classes from which OWL vocabularies should we use for those?

dr-shorthair commented 8 years ago

Yes, but it couples them all. Here we need a specific subset of columns (the coordinates) to be coupled in a specific way (to create a vector quantity, i.e. position, using a specific CRS).

The strict 'OBOE' method for specifying position should probably be a separate oboe:Observation for position. This would connect both the method (e.g. GPS, triangulation, estimation from a map) and the CRS to the set of coordinates, and this observation could then provide context for the other observations relating to thematic properties. In GIS-land position or geometry is treated differently to other properties for essentially this reason - it involves coordinates that are coupled using special rules (involving coordinate reference systems). The OGC reference model calls the other 'thematic properties'. OBOE does not appear to make this distinction.

I guess the Sargasso Sea dataset doesn't do this. Making the position just a set of scalar columns was a shortcut in the original data, and price we have to pay now ...

mbjones commented 8 years ago

OBOE allows coupling of just a subset of columns. In this case, we would have an OBOE:Observation for just the Point, and other OBOE:Observations for other sets of columns that have linked dependencies.

For the Sargasso Sea data, the fact that those real numbers represent a Point is simply implied and not explicit. CSV data in general has almost no semantics attached, and these cross-variable relationships are common (not just for spatial data, but for all types of data). That's what we are trying to make explicit with these annotations.

dr-shorthair commented 8 years ago

I think we just said the same thing :)

dr-shorthair commented 8 years ago

To finish that thought: I suggest that the conversion from the spreadsheet should create at least two oboe:Observations per row - one for the position information (lat, long) which will allow the coordinates to be explicitly coupled, and linked to the positioning procedure and CRS if known, and one for all the rest of the properties (measurements). The former provides context for the latter.

dr-shorthair commented 8 years ago

Now I looked at the ttl, and can see that is essentially what you have done ... I think ... sorry for the confusion. Nice work. Now I'm embarrassed for arguing a point that had already been made. But also motivated to generate the equivalent using om-lite. Watch this space.

wernerkuhn commented 8 years ago

Is time treated as a non-observation?

--  Werner 

On December 14, 2015 at 9:29:23 PM, Simon Cox (notifications@github.com) wrote:

Now I looked at the ttl, and can see that is essentially what you have done ... I think.

— Reply to this email directly or view it on GitHub.

dr-shorthair commented 8 years ago

Bryce has modeled it so that time and date are also measurements, that are members of observations which provide context for the thematic observations.

wernerkuhn commented 8 years ago

Good, thank you!

--  Werner 

On December 14, 2015 at 9:57:41 PM, Simon Cox (notifications@github.com) wrote:

Bryce has modeled it so that time and date are also measurements, that are members of observations which provide context for the thematic observations.

— Reply to this email directly or view it on GitHub.

dr-shorthair commented 8 years ago

However - in O&M there is a 'SamplingPoint' class, which has a 'shape' property whose value is a spatial position. i.e. if you model the Cast as a sampling point, then its location is not an observation. If you do wish to record the procedure used to determine position, then you can model that information as part of an observation, but O&M promotes some properties so this isn't necessary if the application does not require it.

As I noted in the O&M standard "The observation could be considered to carry “property-level” instance metadata" and "the details of the observation event are primarily of interest in applications where an evaluation of errors in the estimate of the value of a property is of concern" - with the corollary that if the errors in position are not important , then you don't need to model it as the result of an observation.

I've just added an example which records the same data that Bryce used (Sargasso Sea lipids) but using OML - see https://github.com/Semantic-Observations/obs-models/blob/master/examples/sargasso-sea-lipids-oml.ttl I modelled the dataset as a collection of collections of collections - an overall collection, containing a collection for each cast with a sampling point giving the location of the cast, which in turn contains a collection for each depth, which contains an observation per observable. I think this works nicely.