W3C home > Mailing lists > Public > public-linked-json@w3.org > November 2011

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

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Mon, 28 Nov 2011 21:48:34 +0800
To: "'Gregg Kellogg'" <reply+i-2240361-29163d86e50e3454355df3dde3b4f52d01e39be5-456407@reply.github.co>
Cc: <public-linked-json@w3.org>
Message-ID: <003101ccadd4$6fe23730$4fa6a590$@lanthaler@gmx.net>
OK, I see what you mean regarding @list and after having spent some more thoughts on it I agree with you. Using @list as you proposed aligns better with how the rest of JSON-LD is designed.

The only problem with it could be that some people will argue that it's used differently in different contexts, i.e., it expects a boolean within the context but an array of list items in the body of a JSON-LD document. Unfortunately I don't have an clean solution for that.. So perhaps we should reconsider putting @list into @datatype!?

Regarding allowing @iri within prefix:suffix definitions: I don't see this as a big issue. We won't be able to prevent malevolent definitions anyway. On the other hand it would allow us to map "terms" that contain a colon to an IRI. Just imaging a JSON document that was created by combining two other documents. The normal approach would be to prepend a namespace to every key in order to avoid collisions. The usage of a colon is widely used for such scenarios. A note in the spec about the potential misuse would do it IMHO.

Talking about @vocab and @base (#26) I don't think that should be seen as equal. You could see @vocab and @base as kind of global variables while a prefix was specifically (and intentionally) created. But that's another discussion, I agree.

Markus Lanthaler

> -----Original Message-----
> From: Gregg Kellogg [mailto:reply+i-2240361-
> 29163d86e50e3454355df3dde3b4f52d01e39be5-456407@reply.github.com]
> Sent: Monday, November 28, 2011 2:16 AM
> To: Markus Lanthaler
> Subject: Re: [json-ld.org] Merge @coerce with @context (#40)
> 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}
> 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.
> 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.
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/json-ld/json-ld.org/issues/40#issuecomment-2889071
Received on Monday, 28 November 2011 13:49:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:32 UTC