@type vs type

[dinizime]

Based on the examples @type and type are different properties. But in http://geojson.org/vocab it is mentioned that :

In the base GeoJSON-LD context, http://geojson.org/contexts/geojson-base.jsonld, type is declared to be an alias for rdf:type.

This to me seems the same as saying is the same as @type. And on the examples raise a lot of questions:

• Why FeatureCollection doesn't have @type?
• Why Geometry doesn't have @type?
• Why duplicate at all @type and type?

Also about @id / id, in http://geojson.org/vocab is said that:

In the base GeoJSON-LD context, http://geojson.org/contexts/geojson-base.jsonld, id is declared to be an alias for the JSON-LD @id keyword.

So it follows in the same idea of @type.

In a side note, in the us-statehood.geojson example "coordinates" and "features" have the same "@id". Also, in the example in README both features have the same @id.

[sgillies]

@dinizime the duplication of type and @type is awkward but unavoidable: the GeoJSON format (https://datatracker.ietf.org/doc/draft-butler-geojson/) predates JSON-LD and already has an established practice of using id and type.

Establishing best practices for turning existing GeoJSON identifiers and types into JSON-LD node identifiers and data types is one of the primary objectives of the GeoJSON-LD project.

I added @type only for the features because I wanted this to be an example of extending GeoJSON's Feature type. There's no point in adding duplicate @type for the feature collection or the geometry objects.

Also note that this GeoJSON-LD example is valid GeoJSON. I've pasted it into a Gist here: https://gist.github.com/sgillies/819fea9424da651a2d8a. Et voilà, a map. This is what the GeoJSON-LD project is all about: data that can be understood both as ordinary GeoJSON and as linked data.

I've fixed the ids, thanks!

[dinizime]

In this way id and type are not alias for @id and rdf:type, needing a fix in http://geojson.org/vocab.

In the case of geometry objects, @type could be used to associate semantics of geometry (center of the road vs the margins). Also would not break the GeoJSON.

[sgillies]

@dinizime I'm sure I tested aliasing of id to @id and type to @type on the JSON-LD playground in the past, but I went and tried it just now and it breaks the parser! Apparently id can not be an alias for @id and type can not be an alias for @type.

http://www.w3.org/TR/json-ld/#aliasing-keywords says

Since keywords cannot be redefined, they can also not be aliased to other keywords.

I thought @id ("@" included) was the keyword but apparently id is the keyword?

The GeoJSON-LD project has a huge hole below the water line, yes?

[letmaik]

You certainly can alias id and type, it works for me also in the playground:

{
  "@context": {
    "ical": "http://www.w3.org/2002/12/cal/ical#",
    "id": "@id",
    "type": "@type"
  },
  "id": "foo",
  "type": "ical:foo"
}

[dinizime]

@sgillies You can alias @id and @type, the problem is colliding the variables, since we both have id and @id. (and type/@type)

[sgillies]

@dinizime got it. And we can't use type and @type as in my example from its very start.

(pointless aside: I was against GeoJSON object using type from the very start)

[dinizime]

In this way, to keep the id and type from GeoJSON, they need to be mapped to the GeoJSON vocab (http://ld.geojson.org/vocab#id and http://ld.geojson.org/vocab#type), not to @id,@type,rdf:type, etc.

Side note: And even if we could do that would be pretty weird since the json-ld playground just consider the last declaration of @id and @type. Try this on json-ld playground.

{
  "@context": {},
  "@id": "id1",
  "@id": "id2",
  "@type": "type1",
  "@type": "type2"
}

[akuckartz]

@dinizime That example violates one of the contraints of JSON-LD:

In contrast to JSON, in JSON-LD the keys in objects MUST be unique. http://www.w3.org/TR/json-ld/#json-ld-grammar

[dinizime]

@akuckartz I see, meaning that for sure we cannot have id (as alias to @id) and @id in the object, since after expansion will have duplicate keys.

[sgillies]

Conclusion: aliasing @id to id and @type to type still works for non-LD GeoJSON as they won't be using @id or @type. I will leave the aliasing in this project's contexts. They are designed to be applied to non-LD GeoJSON. These contexts can not be used with GeoJSON-LD that has both id and @id or type and @type.

[letmaik]

I faced a similar issue and opened an issue here: https://github.com/json-ld/json-ld.org/issues/402

[mitar]

I do not understand really a problem here. If you have normal GeoJSON content then you alias @id to id and this is it. You do not have duplicate @id and id fields. And that GeoJSON content becomes a valid (Geo)JSON-LD content. Or, you have only @id and @type, and then it is just JSON-LD and for processors which know how to parse GeoJSON-LD also a GeoJSON.

I would suggest that we alias @id to id and @type to type and in all examples simply continue using id and type. (I am looking at the example in README.)

[letmaik]

I guess the idea was to keep backwards-compatibility to GeoJSON.

[mitar]

Yes, but aliasing one could continue to use id and type, but it would one to keep both id and type to be strings.