Reference to lists

[lanthaler]

_This is more or less a note to myself at this point in time as I'm not sure yet what to think about it. I put it up here since I think it's an imporant use case. Feedback is appreciated_

The issue is how to reference large lists in another document. This is a use case which affects almost every web service I know.

First idea that was discussed at the 2012-01-31 telecon:

{
  "@context": "somecontext.json",
  "@id": "/album1",
  "artist": "A. Artist",
  "playlist": "/album1/playlist"
}

Currently, /album1/playlist/ would have to be declared by using "@type": "rdf:list" to create a linked list (with two properties rdf:first and rdf:next). This would resolve in a deeply nested object.

An alternative could be to allow a syntax similar to the following in /album1/playlist:

{
  "@context": "someothercontext.json",
  "@id": "/album1/playlist",
  "@list": [
     "Song 1",
     "Song 2", 
     "..."
   ]
}

[gkellogg]

It seems like a fairly narrow use-case, without some more concrete examples. I don't know of any other RDF/LOD systems that attempt to do this. Certainly, it can be done with follow-your-nose and the use of @type: rdf:List, rdf:first "Song 1", rdf:rest {@list: ["Song 2", ...]}, but this now becomes more RDF-specific.

I'd suggest we put this on hold as a design note until some pressing use case presents itself.

[lanthaler]

Well, if you look at web APIs this is used basically in every single one.. So I don't think that this is really such a narrow use-case. I will update the issue with some more examples when I'm back in 2 weeks..

[niklasl]

I would say that such list resources are documents in their own right, which have some kind of member items. The nature of these is dependent on application domain. In regular JSON, that would be the only way in which a resource can be described with other properties, such as creator, created and modified. If it was only a list, faithfully represented as a JSON list at the top level, it could only have indexed members (in the low-level sense), and no other properties.

So a good API design should reasonably represent the member property explicitly, even in plain JSON. When precisely encoded in RDF, that member property could be dc:hasPart or a domain-specific property (with rdfs:range rdf:List). These "list resources" are furthermore often paginated, and described using e.g. iana:prev and iana:next or similar (like in RSS feeds).

Even so, if you want to express a crude service resource which is directly represented as a JSON list, I'd at least use something along the lines of this (in Turtle):

</album1/playlist> a :PlayList;
  rdf:value ("Song 1" "Song 2" "...") .

And while you may use the rdf:first + rdf:next form directly, some RDF syntaxes wouldn't be able to use a syntactic shorthand for that if you annotated the list structure with other properties. (Turtle does allow it though.)

So, although I can see that "@value": [...] could have an abstract appeal, I would recommend the other routes, since they support a more uniform and meaningful form of data. Bear in mind that @value is very low level. Even rdf:value is a bit more expressive.

[lanthaler]

RESOLVED: Do not support the direct naming of lists using IRIs in this revision of JSON-LD.