Set the URI for the base GeoJSON-LD context

[sgillies]

The text is currently at https://github.com/geojson/geojson-ld/blob/master/geojson.jsonld.

When published at, e.g., http://example.com/contexts/geojson.jsonld it can be used in GeoJSON docs like this:

{ "@context": "http://example.com/contexts/geojson.jsonld",
  "type": "FeatureCollection", 
  "features": ...}

Once we arrive at a URI, I'll ask the GeoJSON authors to approve.

[sgillies]

I propose that the GeoJSON working group publish context docs under http://geojson.org/contexts/ and that the base context be http://geojson.org/contexts/geojson-base.jsonld.

Comments?

[tschaub]

Hey @sgillies - maybe naive (and perhaps unrelated) question. Does the context/vocab need to include terms like bbox and coordinates (i.e. things that aren't stand-alone GeoJSON objects)?

Having not used JSON-LD, I'm still trying to get a picture of how a client (or person) would use this context.

To your question above, publishing the context docs and setting the base context as you have suggested sound good to me.

[sgillies]

@tschaub JSON-LD parsers won't break on hitting those terms, if that's what you mean, but they might skip them like the JSON-LD playground does:

http://json-ld.org/playground/index.html#startTab=tab-flattened&json-ld=%7B%22%40context%22%3A%7B%22type%22%3A%22http%3A%2F%2Fexample.com%2Fvocab%2Ftype%22%7D%2C%22type%22%3A%22FeatureCollection%22%2C%22bbox%22%3A%5B1%2C2%2C3%2C4%5D%7D&frame=%7B%7D&context=%7B%7D

Identifiers for bbox and coordinates also lets us take GeoJSON-LD, mix it up with other JSON-LD data that might use similar terms, do stuff, and then extract GeoJSON back out by using the unique identifiers.

[thijsbrentjens]

@sgillies publishing base contexts on geojson.org sounds good to me too.

@tschaub not sure if this is what you are referring to, but added value of a context and especially a broadly used/accepted context could also be that a client knows what it's getting. Clients could offer functionality for well known vocabularies upfront and without the need for a developer for example to assign some kind of "behaviour" (sorry for my English).

For example, a very basic one: if a GeoJSON property of a features is defined as a dcterms:title, a client could decide to use that as the title in a popup. No need for configuration / defining the popup or what so ever. Clients could also choose to ignore properties, for example if they know it is a (GeoJOSN) geometry and can't deal with that kind of properties.

If the same definitions are used, this would be easier. And therefore base contexts published on geosjon.org could make a difference.

More advanced things, like reasoning with the data could be done as well.

[sgillies]

@thijsbrentjens good point about popups. One measure of success for GeoJSON-LD will be when projects like Leaflet and OpenLayers look for properties identified as dcterms:title and dcterms:description to fill out popups instead of fuzzy and underspecified "title" and "description" keys.

Reasoning: this is a semantic web activity that I'm not sold on... I'd prefer to keep OWL out of GeoJSON-LD but allow advanced semweb practitioners to layer it on as they want to.

[sgillies]

I've moved the geojson-base.jsonld, geojson-dcterms.jsonld, and geojson-time.jsonld files to a contexts/ directory. Are there any objections to my proposal at https://github.com/geojson/geojson-ld/issues/4#issuecomment-38811129?

@geojson/owners @geojson/contributors

[azaroth42]

Can I ask about the rationale of having multiple context documents? For example, how does one use both dcterms and the time intervals at the same time? Wouldn't it be easier to have a single joint one, as the context just defines mappings rather than acting as a schema to conform with?

[sgillies]

@azaroth42 Yes, I think merging those contexts makes sense, or rather the elimination of the dcterms one since the dc terms exist in the temporal context.

[azaroth42]

+1 :)

On Tue, May 27, 2014 at 8:19 PM, Sean Gillies notifications@github.com wrote:

@azaroth42 https://github.com/azaroth42 Yes, I think merging those contexts makes sense, or rather the elimination of the dcterms one since the dc terms exist in the temporal context.

— Reply to this email directly or view it on GitHub https://github.com/geojson/geojson-ld/issues/4#issuecomment-44361666.

Rob Sanderson Technology Collaboration Facilitator Digital Library Systems and Services Stanford, CA 94305

[elf-pavlik]

something to consider: https://w3id.org/

@sgillies how much control do you have over: http://geojson.org/contexts/ ?

once it goes into live data we need to guarantee that we won't break it, also version number for contexts may make sense! as in https://web-payments.org/specs/source/identity-credentials/#a-typical-identity

[mitar]

+1 for adding version number to context. So something like: http://geojson.org/contexts/v1/geojson-base.jsonld.

[mitar]

The issue is that current file at http://geojson.org/contexts/geojson-base.jsonld still uses example.com URLs. This is then a bit useless, no? To have that context file already published?

Also, could http://geojson.org/contexts/geojson-base.jsonld have id and type be aliased to @id and @type in that context? In the way it is done here?

Moreover, http://geojson.org/contexts/geojson.jsonld seems to be a broken version of http://geojson.org/contexts/geojson-base.jsonld .