RE: Requirements update

> >> 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.

Yes, but how is that different from, e.g., true or false? I don't really
like rdf:nil because it implies that it is an instance of rdf:List. Not all
null values have to instances of a list. We could also introduce a
jsonld:null and define it accordingly.


> >> 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.

I understand that, but there is a conflict between JSON's data model and the
directed graph model. My argument was that we should base it as much as
possible on JSON because developers are familiar with it and thus we should
bias JSON-LD towards JSON instead of "the underlying data model".


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 22 August 2011 13:20:22 UTC