Re: @structure

On 12/04/2011 08:06 AM, Niklas Lindström wrote:
> Hi Dave!
>
> On Thu, Dec 1, 2011 at 11:39 PM, David I. Lehn<dil@lehn.org>  wrote:
>> In issue #40 [1] and on the recent telecon call progress was made
>> towards a syntax such as:
>>
>> """
>>     "foo": {"@iri": "http://uri.foo", "@datatype": "xsd:date", "@list": true}
>> or
>>     "foo": {"@iri": "http://uri.foo", "@datatype": "@iri", "@list": true}
>> """
>>
>> In IRC I commented that the '"@list":true' style seems non-optimal.
>> To go along with @datatype I suggested '"@parsetype":"list"' or
>> '"@parsetype":"@list"'.  Dave Longley suggested the "@structure"
>> keyword instead.  That name seems a better choice.  This syntax allows
>> more flexibility to support types like "@set" or similar without
>> another '"@{type}":true' construct.  Now in issue #44 [2] we can see a
>> use case of this in @contexts for framing.  I'm thinking this is the
>> right direction to head.  This would make the above something like:
>>
>> """
>>     "foo": {"@iri": "http://uri.foo", "@datatype": "@iri",
>> "@structure": "@list"}
>> """
> I'm definitely for a mechanism like this! I have a crucial need for
> defining that values for a term will always be supplied in a JSON
> array. In fact, the implementation for the service we've built I use
> "@set" for those terms (we're currently only "@list" is allowed in
> JSON-LD). I definitely think that this belongs in the definition for a
> term. Among other things, it is beneficial for e.g. documentation,
> since if a term can be declared to always have array values,
> occurrences of it in different places in a tree won't be surprising
> for a consumer.
>
> (Also I do not need frames, since I root my serialization in one
> resource, prevent cyclic references. All I need is to define which
> terms will be JSON arrays. (I also need and thus support @rev as I've
> suggested, to provide incoming links to that resource. But that's
> another issue).)
>
> I also agree that the form "@list": true and "@set": true appear
> suboptimal (for one that doesn't read very well). I have been thinking
> about the exact same thing as you, to support a key for defining the
> kind of container/collection an array of values will be.
>
> How about "@container" instead of "@structure"? E.g.:
>
>      {
>          "@context": {
>          "knows": {
>              "@iri": "knows", "@datatype": "@iri", "@container": "@set"
>          }
>          },
>          "@iri": "/person/someone",
>          "@type": "Person",
>          "knows": ["/person/anybody"]
>      }
>
> I think "container" (or "collection") is more precise than
> "structure". (And I'm not overly worried about those names' specific
> meanings in RDF, since we're in a different context here. That is,
> while "RDF containers" specifically refer to the legacy Bag, Seq and
> Alt constructs, the term "container" is general enough to mean
> something else distinct and specific in JSON-LD.)

+1 For @container or @structure.

> I have also thought along the lines of Markus, of instead having a
> microsyntax like "@datatype": "@list[@iri]" (or perhaps "@list:@iri"
> or even just "@list @iri"). But at the end of the day I think a new
> key (e.g. @structure or @container) really is the simpler mechanism,
> since having to parse microsyntax is putting more burden on consumers
> than using a ready JSON structure with a new key. I agree that
> keywords shouldn't abound, but neither should we strain ourselves from
> avoiding them where the purpose and needs are clear and distinct. Or
> else I'd prefer {"@list":"@iri"} over "@list[@iri]", since it's only 3
> chars more and using JSON instead of a microsyntax.

-1 For microsyntaxes in JSON-LD. We rejected microsyntaxes before and I 
think it was the right decision.

-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Sunday, 4 December 2011 17:16:36 UTC