Re: [json-ld.org] Merge @coerce with @context (#40)

On Nov 27, 2011, at 1:15 AM, Markus Lanthaler wrote:

> I like the {"@iri": .., "@datatype": ..., "@list": true} notation but find the @list a bit confusing. As I interpret it the datatype would be applied to every list item, right? Isn't @list part of the data type of that property?
> 
> What about having {"@iri": .., "@datatype": ..} for non-list properties and {"@iri": .., "@list": { "@datatype": ... } } for lists? That would make it quite explicit that the datatype applies to the list items.

The thing is, this just doesn't seem much like the rest of JSON-LD. The pattern elsewhere is to use an object notation calling out particular semantics:

    {"@iri": "http://example.com/"}
    {"@literal": "foo", "@language": bar}

introducing a new layer seems like a step away from this. I can see your logic, but I think that adding "@list" to the prefix definition is in keeping with other syntactical cues in the language.

    {"@uri": "http://schema.org/playlist", "@datatype": "@iri", "@list": true}

> Supporting prefix:suffix coercions in the context would definitely have advantages, but why would you like to ignore @iri there? If it's present, we just could just use it. This would also allow to have some sort of namespace support which is heavily discussed these days (not in the context of JSON-LD but for plain old JSON).

If we honored using "@iri", this could lead to inconsistencies, that could even be malevolent. Consider the following:

    "@context": {
      "foaf:knows": {"@iri": "http://nothing" }
    }

This implies that "foaf:knows" is now a term, not a prefix:suffix form, and that it's meaning can vary from that used as a prefix.

> Talking about using @vocab definitions in @context I'm strictly against supporting that. It will make contexts extremely difficult to understand and has the potential to break things. Just consider a scenario where a external context changes @vocab. That would probably break all subsequently defined contexts and would be very difficult to debug. The same applies to @base. Thus I still think it would be a good idea to drop @vocab and @base altogether. We can achieve everything without them and by using prefixes the overhead would be minimal.

There's a separate issue on@base and @vocab (#26). We shouldn't conflate these issues. If we do keep them, then we need rules to ensure they're used appropriately. The issue of defining @vocab in an external context is really no different than defining a prefix in an external context.

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
>

Received on Sunday, 27 November 2011 18:17:05 UTC