Ranges for dcat:bbox and dcat:centroid

[riccardoAlbertoni]

Range changed from rdfs:Literal to locn:Geometry via #1303. The corrections will appear in the next PWD.

Thank you.

I guess this should also apply to dcat:bbox and dcat:centroid.

Originally posted by @init-dcat-ap-de in #1293 (comment)

[andrea-perego]

@init-dcat-ap-de ,

Properties dcat:bbox and dcat:centroid are meant to be used only with literals, and are therefore also explicitly defined as owl:DatatypeProperty's.

[init-dcat-ap-de]

They have the same range and usage notes as locn:geometry.
But semantic geo data is by no means my area of expertise.

[andrea-perego]

@init-dcat-ap-de said:

They have the same range and usage notes as locn:geometry.

The range and usage note of dcat:bbox and dcat:centroid are indeed still the same, but those of locn:geometry have been modified via PR #1303 , as discussed in #1293

See https://w3c.github.io/dxwg/dcat/#Property:location_geometry

Range: locn:Geometry

Usage note:

The range of this property (locn:Geometry) allows for any type of geometry specification. E.g., the geometry could be encoded by a literal, as WKT (geosparql:wktLiteral [GeoSPARQL]), or represented by a class, as geosparql:Geometry (or any of its subclasses) [GeoSPARQL].

[init-dcat-ap-de]

@andrea-perego not sure if this is just a missunderstanding. I understood your post from 3 days ago as an argument, why bbox and centroid should remain with a range of rdfs:Literal.

But they have the same usage note as locn:geometry had previously, which stated that the range was "intentionally generic, with the purpose of allowing different geometry encodings."

The reason to switch the range to locn:Geometry was: locn:Geometry is more generic than rdfs:Literal. The following statements would be valid:

<AnneFrank_3> a dcat:Dataset ;
  dcterms:spatial [
    a dcterms:Location ;
    dcat:centroid <http://geohash.org/u173znse00r> ;
  ] .

So we should either change their range to locn:Geometry or change the usage notes so that they say that one is exspected to use a WKT literal.

[andrea-perego]

@init-dcat-ap-de said:

@andrea-perego not sure if this is just a missunderstanding. I understood your post from 3 days ago as an argument, why bbox and centroid should remain with a range of rdfs:Literal.

But they have the same usage note as locn:geometry had previously, which stated that the range was "intentionally generic, with the purpose of allowing different geometry encodings."

Exactly. The original usage note for the three properties was referring to rdfs:Literal as range, and therefore we have not seen the need of changing it for dcat:bbox and dcat:centroid.

Based on what you say, it seems that the note is not clear enough about the fact that dcat:bbox and dcat:centroid are supposed to be used only with literals:

The range of this property is intentionally generic, with the purpose of allowing different geometry encodings. E.g., the geometry could be encoded as WKT (geosparql:wktLiteral [GeoSPARQL]).

Note that here with "generic" we mean that, by specifying rdfs:Literal as range, we are not prescribing any specific datatype (e.g., geosparql:wktLiteral, geosparql:gmlLiteral, geosparql:geoJSONLiteral).

I wonder whether revising the note as follows may help clarify this point:

The range of this property (rdfs:Literal) is intentionally generic, with the purpose of allowing different geometry literal encodings. E.g., the geometry could be encoded as a WKT literal (geosparql:wktLiteral [GeoSPARQL]).

[init-dcat-ap-de]

Yes, this would clear things up for me.

[andrea-perego]

Yes, this would clear things up for me.

The relevant revision will be dealt with via PR #1360 (yet to be merged).

[dr-shorthair]

Possibly of interest here is that GeoSPARQL is adding geo:hasCentroid and geo:hasBoundingBox properties - specialization of geo:hasGeometry.

The range of hasCentroid is a Point (e.g. sf:Point) and of hasBoundingBox is a box (e.g. sf:Envelope)

[chris-little]

@riccardoAlbertoni @andrea-perego Apologies for commenting from a position of relative ignorance: Can a dcat:bbox encompass both Axis Aligned BBOX, as commonly used in 2D mapping, and Object Oriented BBOX, as commonly used in 3D modelling and 2/3D computer graphics?
I have assumed that a dcat:bbox is not necessarily the unique minimal BBOX for a feature of interest.

[dr-shorthair]

Chris - BBox is conventionally aligned to cartesian axes, and implemented with two coordinates corresponding to the lower and upper vertices of the box - see the GeoSPARQL links above. I think you would surprise people with any more novel interpretation, which would probably be unhelpful for general 'interoperability'.

[riccardoAlbertoni]

It seems this issue is addressed by the merged PR, shall we close it? any objections?