Closed riccardoAlbertoni closed 3 years ago
@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.
They have the same range and usage notes as locn:geometry. But semantic geo data is by no means my area of expertise.
@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 https://github.com/w3c/dxwg/pull/1303 , as discussed in https://github.com/w3c/dxwg/issues/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].
@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.
@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]).
Yes, this would clear things up for me.
Yes, this would clear things up for me.
The relevant revision will be dealt with via PR https://github.com/w3c/dxwg/pull/1360 (yet to be merged).
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
)
@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.
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'.
It seems this issue is addressed by the merged PR, shall we close it? any objections?
Thank you.
I guess this should also apply to
dcat:bbox
anddcat:centroid
.Originally posted by @init-dcat-ap-de in https://github.com/w3c/dxwg/issues/1293#issuecomment-829866295