Re: Requirements update

On 08/19/2011 09: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..

One of the reasons we don't define null for JSON-LD is because we use it 
heavily in the framing code to specify that an attribute was not found. 
Another reason is because if an attribute exists, its RDF value 
shouldn't be considered null. If you want to express a value that is 
null, perhaps we could look to xsi:null or something along those lines?

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

Typically, your code would ask for the customer object, framed, which 
would provide a user account with a value or a user account with 'null' 
- but only in the case where you frame the data.

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

That's not how people typically work with graph data. Everything is a 
set, not a list. I agree with you that this is an issue with the way 
people think about JSON. Each approach has trade-offs. If we do 
JSON-style ordered lists, the RDF becomes very difficult to work with. 
If we do RDF-style sets, it's going to confuse JSON developers.

I think we have the right balance now, as JSON developers that don't 
care about JSON-LD can continue to use the items as if they were 
ordered. RDF developers are unaffected because they make no such 
assumptions about order. The problem comes in when a JSON developer 
cares about preserving order in their RDF... at that point they're going 
to have to learn about RDF Lists and all of the headaches that go along 
with that sort of stuff. We do have a proposal in the spec that makes 
dealing with lists less of a nightmare than it usually is... don't know 
about how folks feel about that proposal, though.

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

A JSON developer can continue to depend on the array as an ordered 
array. The only point it becomes an issue is when the JSON goes into an 
RDF system and then comes back out in some other order. If that happens, 
your system could always normalize and compact to ensure that sorted 
order is ensured for the JSON developers.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Uber Comparison of RDFa, Microformats and Microdata
http://manu.sporny.org/2011/uber-comparison-rdfa-md-uf/

Received on Tuesday, 23 August 2011 04:40:06 UTC