UX & Data Architecture: Location Data Discussion

[adaburrows]

Overview

I built a cheap quick and dirty UI while I was on a train from San Antonio to LA. I don't like it. It's a bit confusing, and I can think of several immediate improvements. Here's how it looks now:

The Very Large Discussion

This is too big to put here, so I moved it into the big document for discussion.

[fosterlynn]

the big document for discussion

I get a 403 no permissions

[adaburrows]

Just updated the comment, but including here too: https://hackmd.io/@adaburrows/HkbE328go

[fosterlynn]

Great discussion @adaburrows !

Some clarifications to put into the mix. I couldn't seem to get comments to work in the big doc, it gave me a comment thing to click, but nothing came up. Maybe because I have popups disabled or something. Anyhow, apologies for switching back here.

From discussions with Lynn, locations are currently mostly associated with agents.

This was in the context of our next playspace milestone around a decent usable UI to get feedback in the near term, so thinking about 3 user groups: Code A, NY Textile Lab, Sensorica. I think NYTL will want them first, there is a map page in the works around offers, which will be an early priority for them, and is based on agent locations.

Currently, location is really truly only a property of other objects. It’s actually really simple to get the GPS coordinates of an address, but then if that’s all we store, we loose readability of the data. It’s no longer an address or a place name, it’s just a (lat, long). This, in my opinion, is another reason to add more information to the location data and make it a first class object in Valueflows.

In VF, location is actually a first class object, called SpatialThing (from geo vocabulary), it is in the lower left of the UML diagram. It might be confusing, because it isn't "properly" represented by relationships to where it is referenced, too many lines. But Agent.primaryLocation, EconomicResource.currentLocation, and those toLocation and atLocation references in various flow classes, all point to a SpatialThing.

I think that hREA not having that yet is more a matter of priorities for the MMR release than any statement of not wanting more. And perhaps the larger question of will there be location more holochain ecosystem wide?

[adaburrows]

I couldn't seem to get comments to work in the big doc

I just dug further into the options. It turns out comments are off by default for people not signed in. I just turned them on, but this is as good a place as any for the actual discussion.

In VF, location is actually a first class object, called SpatialThing (from geo vocabulary)

I was wondering when we'd get to discuss the specifics of this. The wgs84_pos schema, http://www.w3.org/2003/01/geo/wgs84_pos# is really unfortunately inadequate without being extended. It provides one example in the schema, where it derives the Point class from SpatialThing. Then it defines the latitude, longitude, and altitude parameters on the SpatialThing.

This means that we can use any object defined to have a latitude, longitude, and altitude that is derived from SpatialThing. However, it is up to us to define such an object that includes the other parameters we need, like a name or address.

Additionally, other people are well aware of the restrictions that the current ontology has:

• https://www.w3.org/2015/spatial/wiki/An_agreed_spatial_ontology
• https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL

There are modern schemas that could be adopted:

• The Open Street Map data standard. This is defines a system of tagged nodes. The nodes can easily be mapped to a SpatialThing. The tags then provide for various properties like the address, street, city, state, province, zipcode, country, etc. This actually seems like the most flexible format, though there doesn't seem to be a bunch of tooling besides OSM libraries that use it.
  • https://wiki.openstreetmap.org/wiki/OSM_XML
  • https://wiki.openstreetmap.org/wiki/JOSM_file_format
  • https://wiki.openstreetmap.org/wiki/Elements
  • https://wiki.openstreetmap.org/wiki/Tags
  • https://wiki.openstreetmap.org/wiki/Category:Addresses
  • https://wiki.openstreetmap.org/wiki/Develop
• KML is an open data format that could also work.
  • It uses a different shape that doesn't conform to SpatialThing, but can easily be mapped.
  • It can use it's own address for unstructured address data.
  • It can use xal:AddressDetails for structured address data.
• GeoJSON has built in extensibility through the properties field, so we can use it plus xal:addressDetails or something like United States Postal Addressing Terms.
• https://schema.org/GeoShape — this is interesting for some of the other properties it supports like areaServed or serviceArea.
• GeoNames schema.
  • See examples over at GraphDB
  • I can't find how to represent a street address in this. Looking more closely at the schema, it's mostly for just naming and classifying places. The Open Street Map data format is way more flexible.
  • Also see the caveats about using the actual GeoNames service from Open Street Map

We should discuss these and come up with a simple format that works. Creating a zome around it for use by hREA (and other projects) can be delayed until they absolutely need it. Maybe we'll see more activity around these standards by then. Maybe we'll define the standard.

Personally, I'm torn between the various formats. I see the merit in many of them. SO I have questions:

• What is the simplest for indexing and searching?
• What matches up best with our geocoding engine?
• What looks simplest for people to understand?

[fosterlynn]

I'm really happy if we want to pick something better than SpatialThing, and this is a good time to do it in terms of current VF projects, I think.

When we did research on it, it seemed there was not a generally accepted vocab, and this seemed the most accepted for simple needs with the ability to expand into polygons if needed. But that was awhile ago, and we had no geo expertise.

[Edit: Since then, we had an offhand request/recommendation for geosparql from a university food related group we were meeting with, who has a lot of semantic web experience, but that discussion never completed.]

[adaburrows]

Yeah, the mean reason why I omitted GeoSPARQL was because it's relatively complex for people just coming into it, there's overlap with geoJSON and KML, and it doesn't support addresses.

On the other hand, it's not terribly complex, and we could easily mix in xal:AddressDetails so we could have an address field, along with dcterms:title for the name. Then we have all the features the university food group wanted, but we still don't expose RDF data, so SPARQL queries will have to wait until we do (unless we write our own engine on Holochain).

There's a sample of GeoSPARQL 1.1 here: https://github.com/opengeospatial/ogc-geosparql/blob/master/1.1/examples/demo-dataset.ttl Funnily enough, it's using WKT and GeoJSON in the examples, but also supports kml according to the spec: https://github.com/opengeospatial/ogc-geosparql/blob/master/1.1/geo.ttl#L137 it should also support directly using sf: http://schemas.opengis.net/sf/1.0/simple_features_geometries.rdf

Of course, they haven't published the new schema, and the old one only supports WKT and GML.

I guess I should ask since it's ambiguous, which schema are you really wanting to point to with geo:: http://www.w3.org/2003/01/geo/wgs84_pos# or http://www.opengis.net/ont/geosparql#. Both define a SpatialThing, but as very different objects.

[fosterlynn]

Then we have all the features the university food group wanted, but we still don't expose RDF data, so SPARQL queries will have to wait until we do (unless we write our own engine on Holochain).

To clarify, my understanding is they are more gathering and maybe mapping ontologies, not so much implementing software. So I don't mean to imply a requirement for exposing rdf.

[fosterlynn]

I guess I should ask since it's ambiguous, which schema are you really wanting to point to with geo:: http://www.w3.org/2003/01/geo/wgs84_pos# or http://www.opengis.net/ont/geosparql#. Both define a SpatialThing, but as very different objects.

@Prefix geo: http://www.w3.org/2003/01/geo/wgs84_pos# .

[adaburrows]

To clarify, my understanding is they are more gathering and maybe mapping ontologies

Yes, I'm just trying to make sure our code could produce the RDF for SPARQL if needed.

[adaburrows]

I finally got around to writing out my example. I ended up digging into all the schemas a bit more and studying the relationships, but I settled down on something that was really similar to what I was already thinking: Valueflows Location Proposal