Re: Requirements update

On Aug 19, 2011, at 6:48 AM, Markus Lanthaler wrote:

> I finally had some time to review the requirements. All in all I'm happy
> with them, but I would like to discuss basically two things on the mailing
> list.
> 
> 
>> Gregg Kellogg wrote:
>> 
>> 3. All JSON constructs MUST have semantic meaning in a JSON-LD
>> document: JSON objects, arrays, numbers, strings and the literal
>> names false, and true.
> 
> I would like to add NULL..

This was brought up either on the mailing list or on the call. The fact is, in a graph-based model, the value needs to be a node. It could be the equivalent of rdf:nil (@null?). It could also be equivalent to an empty list.

>> 13. The literal value of JSON null is undefined.
> 
> Why? I think sometimes it is good to be able to say that something is NULL
> instead of just saying nothing about it. Simple (and probably stupid)
> example:
> 
> I have a customer object which is linked to a user account. If I just leave
> out that triple I don't know if that customer has a user account or not
> (open world assumption). If I put in a triple whose object is NULL I know
> that that customer for sure doesn't have a user account.
> 
> What was the rationale to remove it? I think a lot of JSON developer are not
> familiar with the open world assumption and allowing NULL  would help in a
> lot of situations.
> 
> 
>> 14. A JSON array MAY be used to associate multiple objects
>> with a subject through a common property.
>> 15. Without explicit syntactic support, JSON arrays MUST NOT
>> be interpreted as defining an object ordering.
> 
> Why should we do that? Why don't we do it the other way round? We shouldn't
> change the semantics of a JSON array which is defined to be ordered. Instead
> of having a @list element we could define a @set element.

The reason for this is that the data model is that of an directed graph, which is inherently unordered. Ordered values are not easily represented by this. Doing so requires either linked lists or indirection through a separate layer. The bias towards unordered attributes is in keeping the with underlying data model.

>> 16. A JSON-LD document SHOULD be able to express and ordered
>> list objects.
> 
> Fully agree, but don't like to change existing semantics without adding any
> real advantage. For the parser it's no difference, but a developer familiar
> with JSON may have to debug his code for quite some time since he figures
> out that in JSON-LD an array is, in contrast to plain JSON, not ordered.
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
> 
>

Received on Saturday, 20 August 2011 16:01:18 UTC