Alternative support for list-like structures such as schema:ListItem

[gkellogg]

Per a suggestion by @danbri, we may want to add a container type, similar to @list for encoding things like schema:ItemList serializations, when the values are schema:ListItem and order is set through schema:position. ItemList can be used with text values as well, but this is already reasonably supported natively.

{
  "@context": {
    "@vocab": "http://schema.org/",
    "itemListElement": {
      "@container": {
        "@type": "@itemList",
        "@itemType": "http://schema.org/ListItem",
        "@itemProperty": "http://schema.org/itemListElement",
        "@itemPosition": "http://schema.org/position"
      }
    }
  },
  "@type": "ItemList",
  "@url": "http://en.wikipedia.org/wiki/Billboard_200",
  "name": "Top music artists",
  "description": "The artists with the most cumulative weeks at number one according to Billboard 200",
  "itemListElement": [
    {"@type": "MusicGroup", "name": "Beatles"},
    {"@type": "MusicGroup", "name": "Elvis Presley"},
    {"@type": "MusicGroup", "name": "Michael Jackson"},
    {"@type": "MusicGroup", "name": "Garth Brooks" }
  ]
}

Original issue Native support for schema:ListItem #595

[iherman]

I must admit I do not really understand this. Can someone shiw what that thing woukd mean in Turtle?

[ajs6f]

@iherman The original ticket has examples that were useful to me.

[azaroth42]

The issue is whether or not we can make it easier for ordered entries to be represented as arrays in JSON-LD, rather than only rdf:List. For example schema has an ItemList that contains ListItems, the Ordered List Ontology has an OrderedList with Slots, and OAI-ORE has an Aggregation with Proxys.

If the only value that these resources are adding is the ability to express an order, and JSON-LD is not ontology specific (e.g. we don't otherwise give (much) preference to RDF/RDFS terms over any others) then it would be valuable to allow a context to express that the json array should be treated as aschema:ItemList rather than an rdf:List, with all of the equivalent blank nodes hidden in the machinery.

[ajs6f]

I've seen this come up in cultural heritage work in particular, where (e.g.) OAI-ORE is particularly important.

[iherman]

Thanks @ajs6f to push me to do my homework and read the original issue:-)

I do feel a bit uneasy about this...

• I realize that the point on ordering in schema.org is a real issue in practice. We did hit the problem in the Publication Manifest work because, for example, the order of authors of a paper is obviously important.
• I also realize that the native (ie, triple level) representation of RDF lists is, to say the least, awkward.

However... the awkwardness of RDF lists is mostly hidden to all users because it is relatively easy to handle them with the usual RDF serializations (including JSON-LD) maybe with the exception of RDF/XML when literal values are used. Ie, on the user level lists are fine, and the usual underlying machinery (SPARQL and others) can handle them already. The problem I see in JSON-LD+schema.org seems to be inherent to schema.org insofar as they shied away to include, say, an "authorList" property that would behave exactly like "author" except that the JSON-LD @context file would include the @list container statement. Ie, we have to be careful introducing new features...

That being said, I also see the value of the proposal of @dlongley (or the alternative version thereof of @gkellogg). I just wonder whether other, similar "patterns" may come up for other structures that would lead to a similar template because, after all, we are talking about baking in some sort of a template into JSON-LD...

[gkellogg]

Perhaps @danbri can common on the actual utility for schema.org use cases.

[azaroth42]

Following discussion on WG call 2018-08-31, the current thinking is to close wontfix. The complexity of the work is high, the value is circumstantial on the ontology following a particular design pattern, it would be out of synch with other RDF serializations, and the scope is sliding towards manipulation of triples rather than serialization of them.

Combined with a wontfix for #7, I think we can propose a new design guideline of:

Describe serialization of graphs, not transformation of graphs.

or similar.

@danbri If this is still an important use case for schema.org, please can you weigh in before 2018-09-07? Thanks!

[azaroth42]

On the WG call of 2018-09-07, we resolved to close this issue, won't fix.

The rationale, following that of #7, is that this is data transformation not simple mapping and is out of scope. Further, the use case has not been validated and out of band discussions on the topic lead us to believe it's no longer desirable.