JSON for Linking Data Telecon Minutes for 2011-08-23

JSON for Linking Data Telecon Minutes for 2011-08-23

Permalink
  http://json-ld.org/minutes/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

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)
 
Note: Gregg Kellogg is scribing.
 
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.
 
. kind of strange in RDF too - a property that doesn't exist as null.
 
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.
 
. let's push the discussion onto the mailing list.
 
. 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.
 
. very little use of lists in RDF.
 
. Ordering would take any JSON-LD and turn into ordered list.
 
Markus Lanthaler: yes, but that's a RDF issue not a JSON-LD issue
 
Manu Sporny: It makes the RDF data messy
 
. requires iterating over lists that aren't expected to be ordered.
 
. 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.
 
. this requires much more markup impact.
 
. 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
 
. thinks an ordered list is an exception in LD, but not in JSON.
 
. doesn't think bias should necessarily carry forward to JSON-LD.
 
. vast majority of code using arrays doesn't really care about order.
 
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.
 
. would rather see current behavior as default.
 
Markus Lanthaler: +1
 
Dave Longley: +1
 
Gregg Kellogg: +1
 
Manu Sporny: +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.
 
. easy ones expand, compact & framing.
 
. normalization is incredibly involved. very difficult.
 
. 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.
 
. only time to return null or "" is when input is given via the UI.
 
. 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
 
. easier from a programmer's perspective.
 
. "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 discussed optional parameters
 
. added form= in header.
 
. can also put in response header
 
. also talked about form=context, to indicate that it is a context document.
 
. still up in the air.
 
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?
 
. how do we specify document is context or not.
 
. input to framing document requires a frame document.
 
. could be a fairly large JSON object
 
. if a web service needs to frame, what to send in request header?
 
. send Accept: application/ld+json;form=framed with post data
 
. otherwise, URI encode large JSON data in header
 
. or, provide frame out-of-band, with URI of frame document.
 
...
 
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
 
http://lists.w3.org/Archives/Public/public-rdf-wg/2011Aug/0131.html
 
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 ;)

Received on Wednesday, 24 August 2011 19:52:39 UTC