w3c / sdw-sosa-ssn

Repository of the Spatial Data on the Web Working Group for the SOSA/SSN vocabulary
7 stars 5 forks source link

Example: GeoSPARQL literal as a SimpleResult #190

Open dr-shorthair opened 5 months ago

dr-shorthair commented 5 months ago

hasSimpleResult allows a literal to appear as the result of an Observation.

GeoSPARQL describes five rdfs:Datatypes 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.

oldskeptic commented 3 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?

dr-shorthair commented 2 months ago

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 ;