Re: @structure

Hi Dave!

On Thu, Dec 1, 2011 at 11:39 PM, David I. Lehn <> wrote:
> In issue #40 [1] and on the recent telecon call progress was made
> towards a syntax such as:
> """
>    "foo": {"@iri": "", "@datatype": "xsd:date", "@list": true}
> or
>    "foo": {"@iri": "", "@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": "", "@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.)

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.

(Notice also that we're in a term definition object in the context
here, so there is no real need other than perhaps for uniformity to
use special "@" for keys at all there. (They're still needed in values
there of course, for distinguishing special symbols, e.g. "@iri",
since it is not representing a datatype IRI).)

> Questions:
> What @structure types might be needed other than @list and @set?

Other than possibly supporting the legacy rdf:Bag, rdf:Seq and rdf:Alt
forms, I think we should focus on these two for now.

Granted, I see a possibility for two advanced forms: @irimap and
@langmap -- for supporting objects where in @irimap the @iri:s of the
contained values respectively are used as *keys* in an object, and for
@langmap @lang as keys. But I've previously suggested @langmap and it
wasn't liked by others, so I suppose this suggestion won't be either.
(Note though that with @irimap one could actually define contexts
supporting a shape more like RDF/JSON if that'd be interesting for

> Could there be use cases for needing multiple @structure types at once?

I'm wary about that. I'd much rather use different terms for that, e.g.:

    "items": {"container": "@set"},
    "itemList": {"container": "@list"}

to distinguish between different expression forms.

> How much does this complicate processing?

For me it's not noticeable (and compared to support for @list, adding
@set should be a simple operation). I've used a similar mechanism in
e.g. Gluon. More importantly, for consumers this normalizes data and
makes it much easier to work with! I had complaints about values for
terms turning up sometimes alone and sometimes in an array. We really
needed to support a mechanism like this.

> Would it be better to use arbitrary IRI types instead of "@list"
> style?  Ie, '"@structure":"jsonld:list"' or something? Maybe @list and
> @set would be aliases for IRIs.

This is very syntax-related so I think keywords should be the way to go.

Best regards,

> [1]
> [2]
> -dave

Received on Sunday, 4 December 2011 13:07:48 UTC