Open dr-shorthair opened 5 months ago
RFC on this. GPS receivers are both Features and Sensors. When does it make sense to omit the observedProperty to leverage the ontology a bit more? Examples don't seem to agree about this.
Assuming:
<EM506N5GPS> rdfs:subClassOf sosa:Sensor, geo:Feature ;
rdfs:label "EM-506N5"@en ;
sosa:observes <EM506N5GPS>; # or geo:Geometry, TBD
ssn-system:hasOperatingRange :_NormalOperatingRange/1;
ssn-system:hasSystemCapability :_gpsCapability ;
sosa:implements <Procedure/1> ;
ssn-system:hasSystemCapability <IBSTH2HumiditySensorCapability>
<mygps/1> a _EM506N5GPS, sosa:FeatureOfInterest .
then the current 'stock' solution using the old W3C points should be:
<mygps/location/1> a sosa:PropertyOfInterest, sosa:ObservableProperty;
rdfs:comment "The location of the GPS."@en ;
ssn:isPropertyOf <mygps/1> .
<observation/1> rdf:type sosa:Observation ;
sosa:madeBySensor <mygps/1> ;
sosa:usedProcedure <Procedure/1> ;
sosa:hasFeatureOfInterest <mygps/1> ;
sosa:resultTime "2017-06-20T21:49:18+00:00"^^xsd:dateTime ;
sosa:observedProperty <mygps/location/1> ;
sosa:hasSimpleResult [
a geo:Point ;
geo:lat 43.664469;
geo:long -79.392449;
geo:alt 100;
] .
which is good, I can use the same solution if geosparql is only used as a datatype:
<mygps/location/1> a sosa:PropertyOfInterest, sosa:ObservableProperty;
rdfs:comment "The location of the GPS."@en ;
ssn:isPropertyOf <mygps/1> .
<observation/1> rdf:type sosa:Observation ;
sosa:madeBySensor <mygps/1> ;
sosa:usedProcedure <Procedure/1> ;
sosa:hasFeatureOfInterest <mygps/1> ;
sosa:resultTime "2017-06-20T21:49:18+00:00"^^xsd:dateTime ;
sosa:observedProperty <mygps/location/1> ;
sosa:hasSimpleResult "Point (-79.392449 43.664469 100)"^^geosparql:wktLiteral;
However if we try to fully support GeoSparql (Which I think we need to):
<mygps/location/1> a sosa:PropertyOfInterest, sosa:ObservableProperty;
ssn:isPropertyOf <mygps/1> .
<observation/1> rdf:type sosa:Observation ;
sosa:madeBySensor <mygps/1> ;
sosa:usedProcedure <Procedure/1> ;
sosa:hasFeatureOfInterest <mygps/1> ;
sosa:resultTime "2017-06-20T21:49:18+00:00"^^xsd:dateTime ;
sosa:hasSimpleResult [
<result/1> rdf:type geo:Geometry ;
geosparql:asWKT "Point (-79.392449 43.664469 100)"^^geosparql:wktLiteral;
] .
# Must keep geoSparql happy.
<mygps/1> geo:hasGeometry <result/1> .
which is a bit odd since the observedProperty sits there with no relationship to the GeoSparql Feature or Geometry. Some examples ignore features outright; is this ok?
sosa:hasSimpleResult
must be a literal. [ ... ]
is a blank node representing an Object.
So in your example above,
sosa:hasSimpleResult [
a geo:Point ;
geo:lat 43.664469;
geo:long -79.392449;
geo:alt 100;
] ;
is incorrect since it has an Object value, not a literal.
To use geo:Point
you must go with sosa:hasResult
.
However, the point of this issue #190 was to note that, in place of
sosa:hasResult [
a geo:Point ;
geo:lat 43.664469;
geo:long -79.392449;
geo:alt 100;
] ;
or
sosa:hasResult [
rdf:type geo:Geometry ;
geosparql:asWKT "Point (-79.392449 43.664469 100)"^^geosparql:wktLiteral ;
] ;
you can use the datatypes defined in GeoSPARQL directly - e.g.
sosa:hasSimpleResult "Point (-79.392449 43.664469 100)"^^geosparql:wktLiteral ;
hasSimpleResult
allows a literal to appear as the result of an Observation.GeoSPARQL describes five
rdfs:Datatype
s for encoding geometry in a string -See https://docs.ogc.org/is/22-047r1/22-047r1.html#_bb4d8d49-bdd2-47b0-948e-4894fbd40469
We need examples showing these.