Add examples related to GeoSparql and GeoData that are not PostalAddress

[OR13]

We want to develop a set of user stories which can help shape the argument for compatibility with GeoSparql...

On the call today, we heard that VCs might get added to RDF data sets where GEO Sparql might be useful for answering questions like:

• As a purchaser of coffee, I want to see all coffee SGTINs i bought from the same region of columbia.
• As a farmer, I want to see crop yields with overlapping regions, that both recived the same chemical treatment....

Its possible that such information might not be stored in the VC, and instead, we might aggregate multiple VCs to make such information queryable.

We might also decide to pull that location data into other systems, that are not GEO Sparql related.

[TallTed]

There's insufficient context to base construction of such JSON-LD snippets on. "examples related to GeoSPARQL" could mean almost anything! Before examples related to GeoSPARQL (a query language; a relatively small extension of SPARQL), there should be something related to GeoData, which would give GeoSPARQL something to operate against...

A plausible scenario might be a wish to SELECT all locations at which a given shipping container had been observed as present, including the datetime of such observation, which would not necessarily represent a complete trace of the container's path (as there almost certainly must be gaps between observations), etc. The specifics of the query would largely depend on the specifics of the data.

[OR13]

yep! I tried to weave all this stuff together a while ago with:

https://jsld.org/case-study-agriculture-futures

Mixing a couple different ontologies, along with some of the features that are available if you build on top of JSON-LD.

I guess a better way of framing my initial question would be:

How can we use GeoData to make SPARQL queries over traceability VCs more familiar.

[OR13]

@mprorock to add comments regarding this, has strong opinions.

[OR13]

Lets try and compare with existing terms like lat / long and PostalAddress.

[oldskeptic]

The primary value of geosparql is in its concept of a Feature vs a Geometry. That allows for the creation of places without committing to a physical location (eg: The #brewHouse in #152) or having multiple physical locations over time.

I have a service that makes use of this for container tracking. As they get (un)loaded from trailers, carriers and ships, you can reuse the geometry waypoints for both container and carrier. This gives you both ontology consistency and ease of querying.

[OR13]

@mprorock I believe you made a verbal proposal on the last call, can you recommend a path forward?

Perhaps we can add an example to the issue?

[OR13]

@OR13 update the description with a hypothetical user story, and additional context.

[OR13]

I updated the description.

[TallTed]

GeoSPARQL and GeoRDF or other GeoData are no different from any other sort of data or query. It's typically best to retain as much information as possible, rendering querying possible at any complexity — or simplicity! — that may arise.

(Historically, I would expect paper documents to have more information than has been stored in DBMS, because of historical difficulties in altering schema structures, as well as historical costs of electronic storage, among other things. Shifting to RDF data allows for much more flexibility, even as storage and query-compute cycles continue to get cheaper.)

I would expect to receive important provenance information (regardless of the ontologies used therein) in VCs.

I would expect to store the data that arrived in those VCs in a quad store, using named graphs to also enable storage of the provenance information — making both the provenance data from within the VCs and the data about the VCs themselves queryable.

I might also retain the VCs themselves in an object store, whether that be a filesystem or a DBMS or otherwise, for later reference and/or proofs of assertions or inferences I may make based on the data in or about those VCs.

[OR13]

The advantage of retaining the VC and having it use a representation that is compatible with GeoRDF is that you can answer some questions about why you believe a particular conclusion from a reasoner... even if you don't use a semantic reasoner, but instead pull that geo location geometry into geo JSON, etc...

[OR13]

What benefit does VCs bring to life that did not exist previously... how are other ways of expressing geo data better for more compute friendly.

expressing in 1 form, doesn't mean it can't be expressed in other forms.

sometimes we want geo datat, sometimes we want street address.

[OR13]

proposal is to add an example that is not a postal address.

[OR13]

Find all sources of resource X within radius Y of spot.

[OR13]

telecom use cases, tower locations, agriculture examples, would be nice to see location expressed in different ways.

[mprorock]

discussion on call - will keep open, and will revisit as use cases drive need for new objects

[VladimirAlexiev]

• "purchaser of coffee, I want to see all coffee SGTINs i bought from the same region of columbia."
  • GADM and Wikidata have geometries of administrative regions.
  • Eg http://gadm.geovocab.org/id/1/331/geometry_100m is for Pazardzhik, Bulgaria with 100m resolution
  • SGTIN should be described as gs1:Product pointing (manufacturer) to Organization pointing (location) to Place pointing (containedInLocation) to parent place.
  • Or, there could be some regionOfOrigin info in the Product
  • Or, you could define a random region (eg your favorite valley)
• "want to see crop yields with overlapping regions, that both recived the same chemical treatment"
  • In the BigDataGrapes project, we represented agricultural plots using GeoSPARQL, and field observations at particular coordinates (using GPS positioned instruments or sat observation). We used GeoSPARQL to slot the observations in the appropriate plot/grid (we used W3C Cube, and the plot as a qb:dimension). @nikolatulechki can you add a link?
• https://github.com/w3c-ccg/traceability-vocab/issues/152#issuecomment-823584623 "adding geometries and making relationship statements (eg: Boston, MA sfWithin USA)"
  • IMHO such GeoSPARQL relations are not needed since you have explicit place hierarchy in gazetteers like Geonames, Wikidata
• "sources of resource X within radius Y of spot"
  • this is one of the simplest GeoSPARQL queries

[OR13]

I suggest we switch from PostalAddress to Place, and add some tests for sparql perhapse.

[brownoxford]

No activity, and we have a good representation of handling this with schema.org place RDF+. Closing.