geosparql 1.1 BFO mapping of geo:Geometry yields unsatisfiable classes

[alanruttenberg]

geo:Geometry subClassOf: 'spatiotemporal region' geo:Geometry equivalentClasses: 'spatial region'

together, make 'spatial region' subclassOf 'spatiotemporal region'. But spatial region and spatiotemporal region are continuants and occurrants respectively, and those are disjoint.

I wasn't sure how it would be concluded that:

Note that this mapping is also inherited from geo:Geometry being an equivalent class of obo:BFO_0000006

The skos:note on Geo:Geometry says

Geo:Geometry can be used as a representation of the shape, extent or location of a Feature, or can exist as a self-contained entity. [my emphasis]

with the definition:

A coherent set of direct positions in space. The positions are held within a Spatial Reference System (SRS)."

I don't think these are consistent with each other, as least insofar as BFO is concerned. Shapes and extents would be BFO qualities, and locations are independent continuants, which are disjoints. To my reading, a geo:Geometry would be an information content entity. Information entities are the sorts of things that represent, or are about, other things. There's nothing problematic about different instances of a class of information entities being about different sorts of things.

As an aside, speaking to the wording of the definition, what would an incoherent set of positions in space be?

.

[nicholascar]

Thanks for the investigation @alanruttenberg! I'll look into this shortly.

[dr-shorthair]

Hmm. Yes, the temporal bounds on a spatiotemporal region force it to be a BFO occurrent. However, geometry and geography people would see it just as a 4D generalization of spatial region. It is on that basis that spatial region subclassOf spatiotemporal region seems OK.

I'm a big fan of the continuant vs. occurrent split, but it leads to this claim of inconsistency, which feels a little wrong.

[alanruttenberg]

Hi,

I wrote the axiomatization (FOL and OWL) for BFO 2020. After working for a long time in biomedical ontology, I'm now working in geospatial ontology and recently started exercising GeoSPARQL.

To your point, one of the distinguishing features of occurrents are that they are things that have temporal parts, which continuants don't. There are ontologies that adopt the four dimensional perspective, but it has problems if you try to use it alone. BFO's approach lets you take advantage of aspects of both the 3D + time and the 4D perspectives in a single framework.

One of the things BFO strives towards is avoiding is dividing ontology according to the perspectives of one or another discipline. There's one world out there, not one each for geospatial people, industrial people, operations people, biology people... Looking at the bigger picture, data from many disciplines needs to be worked with as a whole and having ontologies take different, incompatible, perspectives makes that hard.

So, I have a general interest in this but also potentially, as part of my current job, some time that I could devote to towards getting aligned. Are you interested in arranging a call so I hear about what you are trying to accomplish with the mapping, I can answer questions about BFO theory, and we can see if there's an opportunity for collaboration?

[nicholascar]

I'm a big fan of the continuant vs. occurrent split

Yeah, this is hard for spatio-temporal things. I've just removed the spatio-temporal mapping for now - see the PR #363 - but noted working it out for real is future work.

Are you interested in arranging a call so I hear about what you are trying to accomplish with the mapping

Sure! We've pretty much run out of time on GeoSPARQL 1.1 but we are rolling over into GeoSPARQL 1.2 and possibly 2.0. GeoSPARQL 2.0 will likely be a more major revision and might tackle things like 3D spatial and spatio-temporal more comprehensively. It might not even retain the name "GeoSPARQL" since more generalised work is not necessarily "geo" and the standard extends beyond SPARQL (extensions).

If you @alanruttenberg, could review that update I just made and see if it's ok for at least an imminent GeoSPARQL 1.1 release, we might aim discussion at 1.2+. It should be fine as I mostly adopted your suggestions!