The domain of geometry properties / dataset spatial metadata

[FransKnibbe]

We are seeing the Geometry class being fleshed out with new properties, which I think is a Good Thing. But some of those properties could also be properties of geometry collections. For example a reference to a CRS, or an indication of spatial resolution. Geometry instances could defer those specifications to more general dataset metadata, which makes sense if those properties are the same for all geometries in a dataset. The properties could still be made accessible trough a backlink to the dataset, for example using void:inDataset. So one thing we could do is not limit the domain of new Geometry properties to Geometry only. Or we could try to find out if we can state and ensure equivalence between Geometry properties and terms in other ontologies that are focused on metadata for spatial datasets (e.g. GeoDCAT-AP). Anyway, I think it would be undesirable to have the possibility of expressing same thing at instance and datasetlevel with slightly different meanings at both levels. Semantic harmonisation is also a Good Thing.

[nicholascar]

I am interested in GeoSPARQL data packaging so I've added an "extended example" PR that shows one way of collecting Features (and their Geometries) in FeatureCollection instances within DCAT Dataset` instances: PR #161.

properties could still be made accessible trough a backlink to the dataset, for example using void:inDataset

I know and love VoID! It was I who was responsible for getting VoID back online twice in the last half decade... I think that VoID provides great RDF dataset packaging and statistics for RDF multi-graphs, however for basic cataloguing, the basic metadata of DCAT (title, created date, etc.) is most appropriate, so the example I've proposed uses DCAT for whole dataset stuff.

I encourage you, or anyone else, to propose extended examples that show VoID packaging. You might indicate the benefits of VoID in particular, perhaps to know more about the quantity of RDF in the dataset?

You could present a set of Geometry instances as a VoID/DCAT Dataset but there are surely properties that might pertain to a collection of Geometries that are lesser than a whole dataset. This case is what the GeometryCollection proposal could cater for: you could have multiple GeometryCollection instances within a VoID/DCAT Dataset, or linked to Features etc.

You could also dual-class something as both a GeometryCollection and a VoID/DCAT Dataset. This would allow to dataset-level packaging but also for the data to be understood as Geometries (and not Feature or other things).

For comparison, in my new Extended Examples PR #161, I use a structure of:

• (DCAT) Dataset
  • FeatureCollection
    • Feature

This matches the OGC API: Features structures.

If we introduce a GeometryCollection object, we could have both:

• (VoID or DCAT) Dataset
  • GeometryCollection
    • Geometry

and

• (VoID or DCAT) Dataset
  • Feature
    • FeatureCollection
      • GeometryCollection
        • Geometry

Or other intermediate aggregators and combinations.

In conclusion: anyone is free to package Features or Geometries with VoID or DCAT or similar but there's value in *Collection objects too.

[nicholascar]

I propose that we don't do any more packaging of spatial data in GeoSPARQL 1.1 than the already included *Collection classes.

[nicholascar]

Conceptual linking between GeoSPARQL and Simple Features for classes like GeometryCollection will be defined in the response to Issue #203.

[jabhay]

@FransKnibbe , we're taking this out of 1.1. Would be keen on your comments/response to whether we should implement this in a further revision or not.

[ebremer]

We are seeing the Geometry class being fleshed out with new properties

@FransKnibbe is there a preferred method for proposals for new geometry properties? Is there any references for what people are proposing? I have a strong interest in GeoSPARQL for non-geo purposes but I need some additional properties to support my use cases.

[situx]

Hello @ebremer

thanks for your interest in contributing to GeoSPARQL. You can simply open a Github issue with the properties you would like to see added to GeoSPARQL. We will discuss it in our by-weekly GeoSPARQL calls and give you feedback in the issue directly. If we like your proposal, we will create a pull request to add the properties to the next revision to the standard, which you will be invited to review before we merge in the changes.

All previous proposals (properties or others) can be accessed in this repository as Github issues (open or closed). Accepted properties can be viewed in the standard document which is available in the Github page of this repository.