osdu:bbox is not properly defined

[VladimirAlexiev]

A bounding box is a structure of 2 points or 4 numbers.
But it is defined as a single number:

osdu:bbox rdf:type owl:DatatypeProperty ;
	rdfs:range xsd:decimal ;

Then it is used like this:

osdu:GeoJSONPolygon rdf:type owl:Class ;
	rdfs:subClassOf [
		a owl:Restriction ;
		owl:onProperty osdu:bbox ;
		owl:minQualifiedCardinality "4"^^xsd:nonNegativeInteger ;
		owl:onClass xsd:decimal ;
	] ;

So in instance data you may have this:

<myGeoJSONPolygon> osdu:bbox 1,2,3,4

But RDF multivalued properties don't keep order between the values. So if you try to fetch it with SPARQL:

select * {
  <myGeoJSONPolygon> osdu:bbox ?bbox

you'll get the coordinates in random order.

[ana-tudor]

Thanks for the catch on this important issue. This has been corrected in our latest commit of the ontology. osdu:bbox is renamed to osdu:hasBBox now has a range of an object named osdu:BBox. osdu:BBox may use the property osdu:hasPoint with range osdu:Point, which may use the properties osdu:hasValue for unordered value arrays, or osdu:xCoordinate and osdu:yCoordinate for specified coordinate values.

[VladimirAlexiev]

Is this really fixed?

• hasValue will return 2 coordinates in random order, which seems fatal to me.
• hasPoint will return 2 Points in random order, which may be ok if you don't care which is which corner... But to check what falls into the bbox, you'd need to sort them.

More to the point: isn't it best to use the GeoSPARQL standard (#5), which is supported by most semantic repositories?
GeoSPARQL geometries are indexed in special geospatial indexes, so finding all points (or other features) within a bbox is a very fast operation: you don't need to enumerate all points and check them one by one.

[ana-tudor]

Correct, osdu:hasPoint will return the defining Points of the bbox in an arbitrary order. Each Point object, in order to correctly specify its ordered 2D coordinates, can use osdu:xCoordinate and osdu:yCoordinate. osdu:hasValue does not have to be used with a Point object, and is likely often not the correct property to use there, but if a user would like to specify a Point object with 1 dimension, osdu:hasValue could be appropriate there.

We are looking into integrating the GeoSPARQL standard that you suggested, but as we were primarily focusing on directly supporting the existing OSDU schema structure, the GeoSPARQL standard may not be completely applicable.