Linked Data in JSON Telecon: 2011-08-23

Agenda: http://lists.w3.org/Archives/Public/public-linked-json/2011Aug/0063.html
Chair: Manu Sporny
Scribe: Gregg Kellogg
Present: Ted Thibodeau Jr., Manu Sporny, Gregg Kellogg, Markus Lanthaler, Dave Longley, Nicolas Dufour, Dave Lehn, Thomas Steiner
Audio Log: audio.ogg

Ted Thibodeau Jr.: looking things over before the call...

Ted Thibodeau Jr.: in IANA Considerations (and possibly elsewhere), "form" and "format" are used inconsistently and somewhat interchangeably. I think this needs careful cleanup.

Ted Thibodeau Jr.: related to this -- I think there should be full syntax (possibly EBNF, possibly Unix "commandline usage"-style) and sample string(s) shown here, including the (all?) optional parameter(s),

Ted Thibodeau Jr.: differences between "form" and "format" are inconsistent because we haven't decided exactly what they're going to be yet (still editing that section)... but it'll probably be "form" ... with values being "compacted", "expanded", "framed", "normalized" [scribe assist by Manu Sporny]

Manu Sporny: as far as fully syntax - we could do EBNF/etc. Standard practice in IETF is to just list the parameters and possible parameter values.

Ted Thibodeau Jr.: I can't imagine that giving more info here would violate anything IETF ... and it doesn't matter to me what goes to IETF; I'm concerned about what goes into *this* doc(set)

Topic: Support 'null' in JSON-LD

Manu Sporny: responded to markus on the mailing list as to why not to support 'null'

… we use null to specify something that has been 'framed' as non-existing.

… a frame specifying output elements that don't exist is serialized using 'null'. e.g., foaf:homepage: "null"

… helps programmers to not put in checks to ensure that a key exists, only need to check for 'null' value.

Markus Lanthaler: ok, but then you don't know if the value was null or if the triple wasn't there

Manu Sporny: could define jsonld:null, or rdf:nil, ...

Gregg Kellogg: We could use @null [scribe assist by Manu Sporny]

Markus Lanthaler: we shouldn't introduce a new keyword like @null IMHO

Manu Sporny: A bit hesitant to add another keyword. [scribe assist by Manu Sporny]

Thomas Steiner: +1 for not adding yet another stop word

Gregg Kellogg: suggests "[]" as no value - RDF does something like that.

Gregg Kellogg: Casting new keywords is something we should consider strongly before doing... [scribe assist by Manu Sporny]

Markus Lanthaler: no, that's not the same

Markus Lanthaler: NULL != not existent triple

Ted Thibodeau Jr.: what's the use case/

Markus Lanthaler: dlongley - I would say null is just allowed in object position

Manu Sporny: application specific, empty set can be correct, others would say that database NULL is correct, others would use null in yet another different way.

Manu Sporny: hesitant to put in support yet due to potential for confusion and multiple different ways of interpreting null.

… Right now use null in framing, if we add in another use need to think deeply about how it impacts framing.

… if JSON-LD treats null as rdf:nil, we may have a round-tripping issue.

Topic: Arrays as ordered lists or unordered sets

Markus Lanthaler: yeah.. I think we should bias JSON-LD more towards JSON than towards the underlying data model because that's what people see

Thomas Steiner: +1 for doing what JSON does, Markus

Manu Sporny: concern from Richard Cyganiak, he coined a term called "triple tar-pit"

… which is when you have a bunch of triples that model what you are talking about, but are very difficult to work with.

Markus Lanthaler: yes, but that's a RDF issue not a JSON-LD issue

Manu Sporny: It makes the RDF data messy

… second point, if JSON people want an ordered list, they can continue to use array as being ordered.

Markus Lanthaler: but if we do it that way we again have these round-tripping issues.. you can't expect that array will stay the same across multiple calls to a web service.

Manu Sporny: If RDF people want to ensure ordering, all they need to do is normalize and compact.

Dave Longley: manu, it's not that simple -- you don't know that the sort order will be based on the property/values that you want

Manu Sporny: which use case are we concerned about not addressing?

Dave Longley: a possibility is adding a @sort feature to framing

Dave Longley: to allow you to specify the property to sort on (and the sort order ascending/descending)

Dave Longley: since if you want to work with data coming from RDF/triples you'll likely be framing ...

Dave Longley: so, that could/should be done there.

Manu Sporny: RDF people know how to order, JSON people don't need to worry about ordering; can be service-specific.

Manu Sporny: leads to round-tripping issues.

… JSON-LD converted to RDF, when it comes back, order is not guaranteed.

Manu Sporny: why is that important?

Markus Lanthaler: because api expects it to be ordered.

Manu Sporny: so, one use case could be a recipe example output in list order?

Dave Longley: which is needed for linked data *anyway* ... since the JSON structure doesn't exist in a triples world.

Dave Longley: preserving order *only* via JSON arrays is a round-tripping issue *regardless*... that structure is not transmitted when going to/from triples.

Gregg Kellogg: It comes down to what the sweet spot is that we're trying to optimize for - is the expectation that almost everything is ordered? Then lists are good. Are ordering an exception, then unordered sets are good. [scribe assist by Manu Sporny]

Gregg Kellogg: It would be nice to say if something is ordered based in the @coercion rules. That's the current state. [scribe assist by Manu Sporny]

Gregg Kellogg: this is a common modeling issue - assuming that ordering is going to be consistent. It is a resonable consideration. JSON-LD provides a simple way of specifing that. [scribe assist by Manu Sporny]

Manu Sporny: if we adopt @list keyword and syntax, that would be one-such solution.

… Markus' concern, however, is that we should be doing list ordering by default.

Dave Longley: it isn't as though you *can't* specify multiple values in plain JSON either ... the way you do it is still with arrays, essentially order is just ignored.

Manu Sporny: people will need to add hypothetic @set for most usages, otherwise they're turned into lists.

… true that JSON developers are used to ordering, but if we implement that way, the impact on Linked Data people is much larger.

Dave Longley: keep in mind that JSON developers use arrays in ways where they don't care about the order either -- and that might even be the average case there as well

Markus Lanthaler: could there be an optional way to override default behavior in the @context?

Dave Longley: that's a possibility, to add it in just the context.

Manu Sporny: we could add an option to specify that.

Gregg Kellogg: One common pattern would be where there is a single value that would not be serialized in an array - when there are multiple or no values, we move toward an array-type specification. There is extra work with someone trying to consume that. Either serialize as a list or a single item, depending on size of an array. [scribe assist by Manu Sporny]

Gregg Kellogg: The normal way of serializing normal values would be to use array notation when there is anything other than one value. If it is just one value - it's just an attribute/value pair. [scribe assist by Manu Sporny]

Manu Sporny: I thought that's what we have today? [scribe assist by Manu Sporny]

Gregg Kellogg: If you specify that a property takes an array... if there was a key with a single value that is in a single array, reduce it to a single object. Actually, nevermind. [scribe assist by Manu Sporny]

Markus Lanthaler: I think that would combine the best of both worlds/approaches.

Markus Lanthaler: if we can specify the default behavior in the context, would that suffice? I can live with putting that in the spec.

Markus Lanthaler: +1

Something like this for ordered lists as default: @coerce: { @list: [] }

Something like this for unordered sets as default - if nothing is specified, this is the default: @coerce: { @list: {}}

Markus Lanthaler: ok, let's discuss that in detail on the mailing list

Topic: Algorithm spec language updates

Manu Sporny: dave and I have spec'd out the algorithms.

… kudos to Dave Longley for figuring it out a normalization algorithm that would work, simplifying it, and cleaning up the language I wrote in the spec on normalization.

… still a bit more work required, but one can see the general idea of the normalization process now.

Manu Sporny: not quite ready for more implementations yet, still need to clean it up a bit.

Topic: API return values - null values vs. Exceptions

Manu Sporny: issue with API, what to do when things go wrong?

… if we're not getting our input into the API from the user interface, we should raise an exception.

… if designing an API from scratch, best thing to do is raise exceptions for programmatic errors.

… e.g., an invalid frame is provided, raise exception instead of returning null.

Markus Lanthaler: +1 for exceptions

Manu Sporny: API will be updated. It either returns correct data or raises an exception.

Gregg Kellogg: +1 for exceptions too

Ted Thibodeau Jr.: +1 exception

Dave Longley: well, currently a return value of null from framing...

Dave Longley: is a way of saying your frame didn't match your input

Dave Longley: rather ... there were no matches

Ted Thibodeau Jr.: -1 for frame mismatch

Dave Longley: right now, if you specify a frame with a set of properties

Dave Longley: if there is a subject with those properties, it will be returned

Manu Sporny: two options, return empty JSON object ( {} ), or return null

Ted Thibodeau Jr.: prefer {} notation.

Dave Longley: maybe {} could work.

Manu Sporny: null means you don't need to check for empty object

Gregg Kellogg: +1 for {}

Markus Lanthaler: +1 for {}

Dave Longley: well, the only issue is possibly with recursion

Dave Longley: since null is used to specify that a property doesn't exist

Dave Longley: because {} is not a string.

Dave Longley: and a property might be a string, etc.

Dave Longley: mailing list - let's talk about it there.

Manu Sporny: Dave Longley to investigate further.

Nicolas Dufour: remember to not make decisions on just javascript implementations ;)

Dave Longley: yeah, not just a javascript issue

Dave Longley: just a consistency issue

Ted Thibodeau Jr.: depending on issues that surface, hope that that issue can be resolved and we can keep {} at expense of more implementation.

Dave Longley: it might work fine to do {}, we'll see.

Topic: IANA MIME type registration

Manu Sporny: consensus of WHATWG folks and other IETF folks to use application/ld+json

… other vendor supplied examples of +json as well. application/svg+xml is prior art.

… also talked about form=context, to indicate that it is a context document.

Markus Lanthaler: the other question on the mailing list was "frame"

Manu Sporny: specifies that getting JSON-LD doc in compacted form. Invokes spec language for "compacted"

Manu Sporny: request header would use Accept: not Content-Type:

Manu Sporny: issues - how do we do framed form?

Markus Lanthaler: don't like the idea of passing frame IRI out-of-band.. that could lead to denial of service attacks to a server because it's cheap to force a server to download huge amounts of data

Manu Sporny: problem is not everyone can provide frame as URL

… link header problematic, URL encoding problematic because it seems hack-y, but may want to support as an option.

… OAuth allows parameters to be specified in IRI or HTTP headers. Nice, but it complicates implementations.

… maybe want to specify what a WS will take as input when wanting to specify framing.

Manu Sporny: and then the HTTP mode must be POST

Dave Lehn: we want that to work for GET too

Markus Lanthaler: currently POSTing both docs to the web service seems to be the best option in my opinion - but you can't cache it then

Manu Sporny: with a JSON document that is an array with two objects, the JSON-LD input and the JSON-LD frame, so [{}, {}]

Gregg Kellogg: You're not always going to be specifying the document to be framed. Most likely you're going to request a resource and you're going to apply a frame locally. [scribe assist by Manu Sporny]

Markus Lanthaler: The question really is need we support this? I see this more as a local API issue than a web services issue?

Gregg Kellogg: We haven't discussed what the MIME type of the framed document - why not do a multi-part post? [scribe assist by Manu Sporny]

Dave Lehn: I partly agree with MarkusLanthaler that you could just do the reframing locally.

Manu Sporny: we need to discuss this use case a bit further. It's really only a consideration for the test-suite.

Ted Thibodeau Jr.: +1 to further consideration and more clearly defining use cases... "easing test suite implementation" is not the best argument for spec design.

Manu Sporny: if you want to comply with test-sute, need to implement multi-part post, but leave it at that - don't have to spec that for it to work. Alright, end of telecon.

Markus Lanthaler: +1 to remove it from the main spec for the moment

Manu Sporny: Thanks for scribing, Gregg!!!

Topic: Post-call discussion - RDF/JSON, issue tracking

Thomas Steiner: for those who haven't seen it - I've sent out something about RDF/JSON

Dave Lehn: reframing locally wouldn't be as efficient i guess. you might just want the framed data. no reason to xfer everything in that case.

Markus Lanthaler: Is there a place where we document open issues? The list on GitHub doesn't seem to be very up to date.

Manu Sporny: We should be documenting open issues on github

Manu Sporny: it's not very up to date

Markus Lanthaler: Sure Manu, will do that tomorrow morning, it's already 6pm in Italy

Manu Sporny: np, thanks Markus

Markus Lanthaler: ok.. have a nice evening

Gregg Kellogg: tomayac, finally pointing out the elephant in the room; thanks!

Thomas Steiner: gkellogg, controversial elephant..., but thanks for the support!

"JSON-LD is(**) about objects, simple default assumptions, elegancy, and developers in mind, whereas RDF/JSON seems to be created with the premise to carry all the expressiveness of RDF over to JSON, whatever the cost might be." ... good point

Thomas Steiner: thanks, Henri

"We serve them RDF/JSON (yes, yes, yo, homie), but we will probably fail."

Dave Lehn: i haven't been following the rdf/json work but it doesn't seem so terrible to have that as a spec'ed option for rdf data transport. it just looks hard to use from a javascript viewpoint.

Dave Lehn: problem is same with RDFa/Microdata, having two different ways to do essentially the same thing is wrong-headed.

Thomas Steiner: i was a bit worried wrt the sloppy language in that paragraph...

Thomas Steiner: gkellogg, +1!

Gregg Kellogg: i'm not sure that's the same situation. rdfa and microdata are trying to solve the exact same problem (i think?) but rdf/json and json-ld are taking different approaches and seem to have different goals. [scribe assist by Dave Lehn]

Dave Lehn: but hey, if json-ld wins everyones hearts, that's fine with me ;)

JSON for Linking Data Telecon