Robert Sanderson: we'd very much like to give rdf:Lists identity, so that they can be referenced from multiple graphs. Also to describe them with other properties
... in openannotation, we need lists to define a selector which determines which part is annotated
... for instance, which piece of a text is annotated, with "before" and "after" also recorded (most clients work like that)
... Futhermore, IDPF has agreed to use openannotation for all EPub books
... EPubs, being zip files with a bunch of files
... To define a selector here (take the EPub, select a file, then a part in there)
... So we don't want to reproduce every single selector mechanism. Thus, an ordered list of two selectors would be neeeded.
... We thus need to identify lists, so that we can reuse these selectors in multiple statements.
... I.e. a person wants to disagree with a specific annotation, or place being annotated.
... Furthermore, we have the order of multiple targets, e..g. "the first passage on page three, is derived from the second passage on page five"
... Not as essential, since it's not really machine actionable
... Another project using lists is Shared Canvas
... We'd very much like to use JSON-LD there too, for selecting pages, using a list of pages and so forth
... For this, we took the "list items" approach; the list doesn't need to be referenced directly.
Markus Lanthaler: robert, do you have the link of an example at hand?
... But it might be nice to have this standardized, so people don't reinvent list items all the time.
... at the mailing list and also the OA community meeting in Europe, we agreed that we don't want to change the model to accomodate different syntaxes
... We want to recommend JSON-LD
Manu Sporny: what's the timeline for these needs / when would the WG close
Robert Sanderson: at the moment, the CG is in an implementation phase. We need to dicuss with Ivan, but we hope to move from CG to WG next year
Manu Sporny: we're very close to CR in JSON-LD. If we'd add his feature in, it would put us back for many months. Could we add this for JSON-LD 1.1?
... If we think we can put the feature in, I think we can easily convince implementers to add it. If we add it to the test suite, other implementers would add it.
... So for practical purposes, we aim for it to be added within a year or so.
Robert Sanderson: Yes, that approach could work for us. Given that your'e much further ahead. It's not our prefered option, since for implementations, it might be unpredictable.
... Also, changing this for OA now is much easier than when in a WG
... I don't believe anyone has implemented it yet, but IDPF needs this to be implementable
Manu Sporny: so we may put it in jSON-LD 1.1
Niklas Lindström: First thing, as far as I know, Turtle doesn't support this syntax either. Given that you have a shorthand in Turtle.... actually, none of the formats in RDF/XML and Turtle support this sort of list syntax. [scribe assist by Manu Sporny]
Markus Lanthaler: niklasl, AFAICT they currently set rdf:rest to a Turtle list
Niklas Lindström: Have you discussed that as well? Am I missing something? [scribe assist by Manu Sporny]
Robert Sanderson: No, I don't think you missed anything. [scribe assist by Manu Sporny]
Robert Sanderson: The identity is easier in RDF/XML - you have the property for the URI. [scribe assist by Manu Sporny]
Robert Sanderson: We did consider the other serializations, it's not a ubiquitous feature, but it would be nice to have in JSON-LD. [scribe assist by Manu Sporny]
Niklas Lindström: Right, the main argument when we had the issue, even though it's in the Primer that says there is nothing preventing lists from being described, multiple start properties, etc. None of the core syntaxes allow it, it's not intended to be used like that. [scribe assist by Manu Sporny]
Niklas Lindström: They're supposed to be used as syntactic constructs.... model-wise, they're not really a part of RDF. [scribe assist by Manu Sporny]
Niklas Lindström: If this is supported in JSON-LD, it would be a lot easier to deviate from the recommended usage pattern.... also making it harder for a future RDF spec, who wants to add lists as a native part of the model [scribe assist by Manu Sporny]
Niklas Lindström: You can still use rdf:first / rdf:next explicitly today. [scribe assist by Manu Sporny]
Robert Sanderson: I agree. The notion of order in a graph is always problematic. Not the common method to have a resource that is a list and has identity. [scribe assist by Manu Sporny]
Robert Sanderson: Maybe RDF COncepts 1.1 should discuss it. [scribe assist by Manu Sporny]
David Booth: Yeah, RDF WG should consider this. I agree with Niklas. It doesn't fit w/ the usual list pattern. Important to consider implications. [scribe assist by Manu Sporny]
Robert Sanderson: That's it exactly, thanks Niklas1
Manu Sporny: any other thoughs on this?
Markus Lanthaler: it would make it hard to expect compaction to behave as predicted
... also, compaction might be more complex
Manu Sporny: Yes. We wanted to stay away from it since it might be a mine field in general.
... that said, there might be a case for this.
Niklas Lindström: Agree with Manu's point - there might be something new that's interesting here. I don't think we should do it w/o discussing implications. Algorithmic complexity for JSON-LD API and implementations. It might be almost as problematic as bnodes as predicates. It's possible to do this in raw RDF. It seems highly obvious that you can add ID in other properties. On the other hands you... [scribe assist by Manu Sporny]
Manu Sporny: ...can do it w/ literals.
Niklas Lindström: This borders on the syntactical collapse. [scribe assist by Manu Sporny]
Markus Lanthaler: syntactically having a property carrying the actual list is nearly indistinguishable as the requested form (using "@list" as key)
Robert Sanderson: I agree. The easisest solution for everyone would be to have a "listItem" as a property.
... and for the RDF WG, it might be good to define a dedicated predicate for it. rdf:value is explicitly fuzzy, so you can't always expect a list.
David Booth: Robert, would it be feasible to just wrap the list in another object, and attach the additional info to the wrapper object? (I apologize that I have not fully grokked the problem, so this suggestion may not be helpful.)
... It would be easier to sell changing the model if there was another predicate for this.
Manu Sporny: so a specific vocabulary for lists would be beneficial in general, working in all syntaxes
... would that adress this issue? If we quickly create a list vocabulary?
Robert Sanderson: I think so. Not preferable duing the discussions we had, but the syntactic arguments may sway this position.
... A single, interoperable solution is preferable.
Manu Sporny: anyone objects to open issue 75, to continue this dicussion?
Niklas Lindström: I think we should try to have this as an RDF issue - it really would not come up if lists were core to the RDF model. It's a sore spot in RDF Concepts. I think we should push it over to the RDF WG immediately. It's arbitrary if we or OA try to push something forward, it won't solve the real problem.... not in rdf schema vocab. [scribe assist by Manu Sporny]
Robert Sanderson: +1 to Niklas
PROPOSAL: Create an issue in the RDF WG to formalize a way to express lists that need to be identified with a URL and annotated using properties.
Manu Sporny: +1
David Booth: +1
Robert Sanderson: +1
Niklas Lindström: +1 could be someything like rdf:listValue
David I. Lehn: +1
Markus Lanthaler: +1
RESOLUTION: Create an issue in the RDF WG to formalize a way to express lists that need to be identified with a URL and annotated using properties.
Topic: GSoC update
Vikash Agrawal: what's broken in the playground?
Manu Sporny: a bit weird ui paradigm when clicking on expanded form; headings for JSON-LD Context stay, but the input box disappears.
Markus Lanthaler: the headers stay but the inputs disappear. Previously headers were toggled off if input areas weren't applicable
Manu Sporny: play around a bit. I think the old way is better. There may be something even better, but right now, the problem is that something not used is still shown.
Vikash Agrawal: this is bug 50
... by this week, this should be done. Next week is a creator app.
Markus Lanthaler: could we discuss these things on the mailing list or the issue tracker?
Manu Sporny: email danbri and gregg regarding a schema.org JSON-LD context
David Booth: I'd expect it to be, to the extent that I can channel Peter.
David Booth: Every node is an IRI , a blank node , a JSON-LD value , or a list .
David Booth: restricting the literal space to JSON-LD values is a restriction rather than an extension to the RDF model.
Robert Sanderson: Sorry, have to attend another call now, though would like to have stayed for the rest of the conversation. Thanks everyone for the discussion re lists.
... and I don't think that lists need to be mentioned there; they are just sugar.
Markus Lanthaler: "A JSON-LD value is a string, a number, true or false, a typed value, or a language-tagged string."
Markus Lanthaler: thanks for joining robert
Manu Sporny: on top, we extension the value space to json true and false, numbers and strings.
David Booth: A JSON-LD value is a string , a number , true or false , a typed value , or a language-tagged string .
David Booth: it wasn't clear that those lined up with the corresponding RDF value space.
Manu and David agree that the JSON number value space is more general.
Manu Sporny: different lexical spaces for booleans in xsd and json
Topic: Lists in the JSON and RDF data models
David Booth: What about lists, aren't they the same as expressed in RDF?
Manu Sporny: not convinced that they are..
... we need to translate it to something in the data model. In RDF, it translates to the list properties. There is nothing in RDF concepts to point to.
... many just assumes that it's basically part of the data model, but it's formally not
David Booth: why not point to rdf schema?
Manu Sporny: not part of the rdf data model.
Niklas Lindström: Yeah, just a comment. Could we correlate this RDF Concepts problem w/ the suggestion wrt. list values. [scribe assist by Manu Sporny]
Niklas Lindström: Clearly, lists are under-specified. [scribe assist by Manu Sporny]
Niklas Lindström: Maybe we should expand RDF Concepts that is present in the 2004 Primer and the Syntax that I scanned previously. [scribe assist by Manu Sporny]
Manu Sporny: but does rdf schema extend the rdf data model?
David Booth: no, just a convention which is using the rdf data model
Markus Lanthaler: but's still just a vocabulary. In JSON-LD, we use [a keyword and] an array
... it's like a node type [just as literals]
Manu Sporny: the JSON-LD data model does not talk about rdf:first and rdf:rest
David Booth: I don't think any test cases needs to be changed by the way this is described. So it's just a question of how this concept is being described. At present, it's described as a difference.
Manu Sporny: True. We only change how you think about the data model.
Manu Sporny: if we make an argument about the difference between native JSON literals and RDF literals, we need to explain the difference of expressing lists as well.
David Booth: I don't see the benefit as a difference, from an RDF perspective.
Niklas Lindström: I think I can answer re: benefit of having different model wrt. JSON lists and RDF lists. In JSON, there are arrays, those arrays represent repeated statements in RDF> [scribe assist by Manu Sporny]
Niklas Lindström: RDF people understands that intuitively. We mention @set because people that don't understand RDF, but do understand mathematical sets.... ordered list is more popular than sets in programming. [scribe assist by Manu Sporny]
Niklas Lindström: We need a way to explain lists in JSON-LD, in the same way that we explain sets, and other things. Not in a way that introduces rdf:first and rdf:next. [scribe assist by Manu Sporny]
David Booth: Bottom line: I do not see a need to call out lists as being a difference from the RDF model, but I'm okay with it being mentioned, in part because I'd like to push RDF to have native lists.
David Booth: it seems strange to have @set (unordered) as the default
... in regular json, the default is ordered
Markus Lanthaler: We discussed this quite a bit in the beginning, the rationale was that the RDF that was generated would be unmanageable - lots of blank nodes, lots of rdf:first/rdf:rest, you couldn't work w/ the RDF anymore. [scribe assist by Manu Sporny]
Markus Lanthaler: we discussed it quite a bit in the beginning. The rationale we came up with is that the generated RDF would be very gruesome, using rdf lists for everything.
... hundreds of blank nodes for everything.
Niklas Lindström: Yeah, I agree. That's the rationale. While it's true that arrays in JSON are ordered in their nature, in all the JSON-LD examples, they are commonly only sets. There is no real order. JSON-LD is intended to be used w/ RDF properties, there are only a handful of common RDF properties - author, contributorList, propertyChainAction, where the order is semantic, it means something. [scribe assist by Manu Sporny]
Niklas Lindström: In every other case, it's just a bundle of things. I think that's the better case - explicitly say order doesn't mean anything. The same thinking has obscured lots of things wrt. XML. You can rely on the order of the elements, not sure if you should. It's better to say that "you can't rely on the order", unless someone says so explicitly. [scribe assist by Manu Sporny]
David Booth: As a programmer, I'd use the exact opposite rationale. [scribe assist by Manu Sporny]
David Booth: So if the default were changed to being ordered, then the examples would have to be changed to add @set?
Niklas Lindström: We discussed whether we should do it in the @context, we could define @set to be the default. [scribe assist by Manu Sporny]
Niklas Lindström: I agree w/ David that as a programmer, you think like that. Unless you think otherwise. [scribe assist by Manu Sporny]
David Booth: There is also minimal changes going from JSON to JSON-LD. [scribe assist by Manu Sporny]
Niklas Lindström: Datasets on the Web, you never know if the order is intentional or not. It's better to assume that it's not ordered. [scribe assist by Manu Sporny]
Markus Lanthaler: JSON-LD can already serialize the same data in so many ways already - remote contexts, you can't really interpret the data anymore by just looking at it. Maybe doing it in a processor flag, but not in the context. [scribe assist by Manu Sporny]
Niklas Lindström: I'd like to be able to do this in the context. "@container": "@set" would be useful to me. [scribe assist by Manu Sporny]
David Booth: Can we have a global way to indicate @set ?
Niklas Lindström: Yeah, but I could wait for this feature. [scribe assist by Manu Sporny]
David Booth: I'm worried about the element of surprise. It reverses the common expectation.
Manu Sporny: It has not come up as a real issue from anywere though.
Markus Lanthaler: Is there a use case for this? [scribe assist by Manu Sporny]
Markus Lanthaler: In the majority of instances, the order is irrelevant
David Booth: yes, quite possible
Manu Sporny: a change could also backfire at this stage
... we could potentially have a JSON-LD 1.1, for e.g. this.
David Booth: I think the best solution would be a simple global way to specify @set, and user get used to always doing that.
Niklas Lindström: I think that it can't fly from my point of view - given that for every case where I've seen order having meaning, it's always been a very specific technical reason. Implicitly ordered things as properties on the object. In every specific scenario where order is used.... [scribe missed] [scribe assist by Manu Sporny]