- From: Niklas Lindström <lindstream@gmail.com>
- Date: Tue, 29 Nov 2011 14:26:06 +0100
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: Manu Sporny <reply+i-1477642-03cf6838214958976e2f68a8ac53ef0de003a547-456407@reply.github.co>, Gregg Kellogg <gregg@kellogg-assoc.com>, public-linked-json@w3.org
I have the opposite position on both accounts.. ;) On issue #15: @iri and @subject are synonymous, and I see little value in keeping both. I have only used @iri (actually I use "iri": "@iri" in my context and thus use "iri"). You can always use aliases if you want sugar for certain cases. On issue #31: @type is fundamentally different from @datatype. It is an alias for "http://www.w3.org/1999/02/22-rdf-syntax-ns#type", whereas @datatype is part of the expanded syntax for literals. Where I to alias "@type" to e.g. "a" (which I do), I do *not* want "a" to be possible to use to give the datatype of an expanded literal (nor in coercion, if we are to replace "@coerce" with "@datatype" in the context). Granted, I could define "a" to be "just" the IRI for rdf:type, but in any case having the key for datatype mean rdf:type outside of literals seems confusing and non-pedagogical. I think this weighs heavier than that since they aren't intended for use in the same place their meaning *could* be inferred. .. For completeness, I'm also wary of using "@datatype" instead of "@coerce" in the context. This is because "@coerce": "@iri" means something different from what datatypes are about. Of course, we can do something similar to Gregg's proposal of "@list": true (which I like), and use "@iri": true instead of coercion. But that would also mean forbidding/overriding any "@datatype" coercion directive. I'm may still be open to going down that path though, as I'm also interested in investigating the relative value of e.g. using "@language" to define language-specific terms (e.g. "titleSv: {"@iri": "dc:title", "@language": "sv"}). .. Also, as mentioned before, I need a mechanism for saying that the values for a certain term will *always* be a JSON array (i.e. a "set"). I have evaluated if I can leave that aspect to the (much more advanced) use of framing, and I've concluded that that is much less viable. Best regards, Niklas On Tue, Nov 29, 2011 at 1:10 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote: > This issue was originally raised by Gregg: > > http://lists.w3.org/Archives/Public/public-linked-json/2011Jul/0060.html > > I think in this case it makes sense to keep both @subject and @iri even though @subject is just syntactic sugar. So for me it would be fine to close this issue.. let's see what Gregg thinks about it - I've CCed him. > > P.S.: For me this issue is quite different from the @type/@datatype issue (#31). I wouldn't like to treat them the same way. > > > >> -----Original Message----- >> From: Manu Sporny [mailto:reply+i-1477642- >> 03cf6838214958976e2f68a8ac53ef0de003a547-456407@reply.github.com] >> Sent: Tuesday, November 29, 2011 12:42 PM >> To: Markus Lanthaler >> Subject: Re: [json-ld.org] Are @subject and @iri redundant? (#15) >> >> Technically, they are redundant. However, I think that just like @type >> and @datatype, we should keep the two concepts separate to help people >> understand what is going on in the markup a bit better. >> >> --- >> Reply to this email directly or view it on GitHub: >> https://github.com/json-ld/json-ld.org/issues/15#issuecomment-2912823 > > >
Received on Tuesday, 29 November 2011 13:27:00 UTC