W3C home > Mailing lists > Public > public-linked-json@w3.org > January 2012

Re: json-ld.org playground updated

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Wed, 18 Jan 2012 23:28:57 -0500
Message-ID: <4F179C09.2060807@digitalbazaar.com>
To: public-linked-json@w3.org
On 01/18/2012 10:08 PM, Markus Lanthaler wrote:
> On Thursday, January 19, 2012 5:02 AM, Alexandre Passant:
>> On Wed, Jan 18, 2012 at 8:16 PM, Manu Sporny
>>> After some discussion with Dave Longley, both of us feel that we
>> should
>>> kill this feature. It overly complicates the number of ways that you
>> can
>>> express a plain literal.
>> You mean killing the "bar" : { "@value": "foo" } feature, and allowing
>> it only it it comes together with a @type, @language or other
>> attribute ?
>> If so, the markup schema would change when one decide to add the
>> @language in an existing JSON-LD documents. JSON(non-LD) parser that
>> were using "bar" : "foo" will eventually not work anymore. So I'd
>> rather keep it for making things uniform and more easily extendable.
> I agree with Alexandre on this. As your fix showed it's trivial to
> implement. We should not encourage this construct, but there's no reason to
> not support it. That would just add another corner case IMO.

The fix only worked because the input is being ignored by the current 
processor. The turtle serializer simply works on the output from the 
processor. The processor itself doesn't handle this syntax and would 
have to be changed, which is more complex.

The complexities include, at least, changing the expansion algorithm so 
that an object (instead of a string) is used for all plain literals and 
changing the compaction algorithm so that objects containing only @value 
are converted to strings. I assume that we would need to make these 
changes to ensure consistency in the compaction and expansion algorithms 
and formats. I also assume that it would not be optional (via the 
@context) to specify whether or not plain literal objects are changed to 
strings during compaction (similar to type coercion).

These changes can be made, but understand that if we support this syntax 
it isn't simply that we're handling a corner-case where some people 
might use this instead of the simpler "string for plain literals" 
syntax. Rather, it should be the official "expanded form" syntax for 
plain literals. Otherwise we'll be introducing inconsistency where there 
wasn't any before. Unless I'm mistaken, this will also be the first 
example of a "built-in" difference between compact form and expanded 
form, where the @context doesn't specify how the syntax is different, it 
is just "known" that compact form uses strings for plain literals and 
expanded form uses objects with a @value property.

> Can we add a test case for that? I don't know if we currently test the
> Turtle output!?

We should add test cases for this, yes, and, no, we don't currently test 
turtle output, but obviously we should.

Dave Longley
Digital Bazaar, Inc.
Received on Thursday, 19 January 2012 04:29:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:33 UTC