TERN loc ontology not needed

[nicholascar]

The TERN Geometry class, https://w3id.org/tern/ontologies/loc/Geometry, is defined as a subclass of geo:Geometry but imposes no additional required properties*, thus it's not needed.

The purpose of tern:Geometry seems to be to indicate that a Geometry could/should have a geometry type, indicated by dcterms:type, but this can be realised by just using that property on a regular geo:Geometry instance.

The TERN Geometry also includes a Shape to ensure that, if dcterms:type is present, then it must be of type sh:IRI but again, this Shape can be defined for geo:Geometry.

So: remove the tern:Geometry class but retain the Shape! This will improve ease of use since we just have a GeoSPARQL Geometry but you may type it.

Likewise, tern:LineString, tern:Point & tern:Polygon are not needed as they can be replaced with the SF classes they subclass.

* sure, it says to use only WKT for the geometry literal but GeoSPARQL has conversion functions defined

[nicholascar]

Actually Point seems to be the only TERN class with much going on - depth, elevation etc.

There is a conflict in tern:Point:

• wgs:lat -- exactly 1 (WGS84 only)
• wgs:long -- exactly 1 (WGS84 only)

and yet:

• geo:asWKT (inherited) -- exactly 1 with the allowance of use of non-WGS84 WKT values.

We do have data using WGS84, GDA94 and GDA2020 CRSes...

[edmondchuc]

Initially, tern-loc is just a combination of Basic Geo (WGS84) and GeoSPARQL for TERN's purposes. The usage of tern-loc may not be required once the TERN Ontology shapes have been separated and relaxed (https://github.com/ternaustralia/ontology_tern/issues/56 and https://github.com/ternaustralia/ontology_tern/issues/63).

Actually Point seems to be the only TERN class with much going on - depth, elevation etc.

I do see some value with tern:Point and tern:Geometry. Some enhancements in my mind:

• tern-loc:coordinateUncertainty on tern-loc:Geometry - a way to represent uncertainty/error (plus/minus) in metres.
  • http://rs.tdwg.org/dwc/terms/coordinateUncertaintyInMeters
  • https://github.com/ternaustralia/ontology_tern-loc/issues/1
• tern-loc:Geometry CRS property
  • tern-loc:crs - coordinate reference system - OGC IRI
• tern-loc:Point defines its own latitude and longitude properties - CRS provided by the property in its superclass Geometry
  • tern-loc:lat - decimal latitude
  • tern-loc:long - decimal longitude

You can now have multiple points in different coordinate reference systems (filter by tern-loc:crs).

These additions also make it easier to integrate with more traditional systems such as PostGIS (no need to parse and tokenise the GeoSPARQL WKT literal.

And it would resolve what you said about the conflict below.

There is a conflict in tern:Point:

• wgs:lat -- exactly 1 (WGS84 only)
• wgs:long -- exactly 1 (WGS84 only) and yet:
• geo:asWKT (inherited) -- exactly 1 with the allowance of use of non-WGS84 WKT values.

[nicholascar]

In discussion with @edmondchuc:

• probably GeoSPARQL's standard Geometry class can be used unchanged so probably no need for a term:Geometry
• likewise for LineString, Point & Polygon classes: probably SimpleFeatures classes can be used
• a separation of Shapes from Ontology (as per Issue #56) will allow things like a requirement for Point instances to have certain properties and this will further allow direct use of SF Point etc. with those Shapes
  • it's likely BDR and TERN can develop different Shape files for geometries like points, e.g.:
    • BDR Point instances MUST have coordinates expressed within a WKT literal
    • TERN Point instance MUST have coordinates with lat & long properties (which can be plain wsg properties)
• additional properties not specified in GeoSPARQL such as elevation/depth can be used directly with GeoSPARQL Geometry instances. If require or other constraints, this is a Shapes job, not an ontology job, as point above.
• Some geometry properties for precision and so on now exist in GeoSPARQL 1.1, see the Standard Properties for Geometry section
  • these should cover tern-loc:coordinateUncertainty and the "metric" versions of those properties are "in metres"

[dr-shorthair]

I would agree with this.

There are two key approaches to developing a domain ontology

1. create all new classes and relationships, then align them with external vocabs, but use the local names and namespace
2. re-use external vocabs by preference, and only create new classes and relationships where existing ones don't exist

Style 2. ends up looking messier as it involves lots of namespaces, while 1. looks much cleaner. But if you want to surface the alignment, in order to support 'standard' queries etc, then re-using existing namespaces is probably a good idea.

Under style 2. you should only create new classes if they have additional properties and constraints - not otherwise.

Now where SHACL fits in all this is the question. I tend to see SHACL as a way to introduce rules on classes for a specific context. You can have different SHACL shapes for different applications on the same classes. So SHACL rules that go beyond the original definitions do not imply a new class. Others see SHACL as a replacement for OWL, so any SHACL rules that go beyond the OWL axiomatization would imply new classes.

I don't think the rules are hard and fast - it is a policy decision for TERN which way to go.

[smguru]

@dr-shorthair @nicholascar @edmondchuc probably make sense to use Style 2 approach.

[dr-shorthair]

re-using existing namespaces is probably a good idea.

particularly for properties, which are very important in queries.