- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Sun, 27 Nov 2011 17:15:09 +0800
- To: "'Gregg Kellogg'" <reply+i-2240361-29163d86e50e3454355df3dde3b4f52d01e39be5-456407@reply.github.co>
- Cc: <public-linked-json@w3.org>
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.
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).
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.
--
Markus Lanthaler
@markuslanthaler
Received on Sunday, 27 November 2011 09:15:44 UTC