JSON-LD Telecon Minutes for 2012-09-25

Thanks to Gregg for scribing! The minutes from today's call are now
available here:

http://json-ld.org/minutes/2012-09-25/

Full text of the discussion follows including a link to the audio
transcript:

--------------------
JSON-LD Community Group Telecon Minutes for 2012-09-25

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Sep/0018.html
Topics:
   1. TPAC JSON-LD breakout session
   2. RDF WG review of latest JSON-LD docs
   3. ISSUE-153: Define error handler behavior
   4. ISSUE-160: Specify property-generator round-tripping
      algorithm
Action Items:
   1. Manu to ping Richard on JSON-LD Syntax and RDF Concepts
      terminology alignment.
   2. Manu to update JSON-LD Syntax spec and integrate changes
      from issue tracker.
Chair:
   Manu Sporny
Scribe:
   Gregg Kellogg
Present:
   Gregg Kellogg, François Daoust, Manu Sporny, Markus Lanthaler,
   Niklas Lindström, Dave Longley, David I. Lehn
Audio:
   http://json-ld.org/minutes/2012-09-25/audio.ogg

Gregg Kellogg is scribing.
Gregg Kellogg:  Probably going to visit Wikimedia Germany - going
   to talk to them more about JSON-LD and Wikidata during that trip.
   [scribe assist by Manu Sporny]
François Daoust:  TPAC coming up and of October, last year there
   were lots of break out sessions, and we're looking for ideas
   … I wonder of someone could run a breakout session on JSON-LD

Topic: TPAC JSON-LD breakout session

Manu Sporny:  it would be good to do, but it doesn't seem like
   anyone has the time to go.
Gregg Kellogg:  Maybe a BOF? [scribe assist by Manu Sporny]
Manu Sporny:  perhaps we can make ourselves available over Skype,
   if there's a BOF.
   … of course, if the connections bad, it might not be worth it.
François Daoust: [I will try but I doubt there will be bridges
   available during the plenary day]

Topic: RDF WG review of latest JSON-LD docs

Gregg Kellogg:  I got an issue put on me in order to get a plan
   together for a review from the RDF WG from folks who hadn't
   reviewed it yet. [scribe assist by Manu Sporny]
Gregg Kellogg:  Richard and Sandro volunteered to review the
   documents. I didn't know the status of the docs at the time, need
   to understand the status. [scribe assist by Manu Sporny]
Gregg Kellogg:  We need the timeframe/plan for the syntax spec to
   be available for review. [scribe assist by Manu Sporny]
Manu Sporny:  we have some resolutions that we can apply to the
   spec, which would put both syntax and API in good shape
   … We could theoretically have a review ready spec by next
   week.
   … There are still some outstanding issues, but we can just put
   issue markers in
Gregg Kellogg:  I think synchronizing the status of the spec w/
   the latest issue resolutions would be good. [scribe assist by
   Manu Sporny]
Gregg Kellogg:  I think we also decided on language maps - don't
   know if we have them documented. [scribe assist by Manu Sporny]
Manu Sporny:  cygri took the action to align the doc with RDF
   Concepts. We can do everything else.
Manu Sporny:  They're in the syntax spec... not in the API spec.
   [scribe assist by Manu Sporny]
   … Since Richard is reviewing the document, maybe he would also
   make sure the two docs are aligned.
Markus Lanthaler:  shouldn't we decide how language maps and
   property generators are going to be implemented before asking for
   review?
Manu Sporny:  they're reviewing the syntax, and not the API, so
   it might not be important.

ACTION: Manu to ping Richard on JSON-LD Syntax and RDF Concepts
terminology alignment.

Markus Lanthaler:  there haven't been many changes since the last
   rounds of reviews, so I don't know how much sense it makes to do
   a review.
Manu Sporny:  that's what diffmarks are for. However, people like
   Sandro, who haven't done a review, end up doing a full review.
   … I think there will be significant changes to the intro.

ACTION: Manu to update JSON-LD Syntax spec and integrate changes from
issue tracker.

Topic: ISSUE-153: Define error handler behavior

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/153
Manu Sporny:  last comment has the basic proposal.
   … we probably need more than what we have there right now.
Manu Sporny:
   https://github.com/json-ld/json-ld.org/issues/153#issuecomment-8854985
   … whenever there is a processing error, if an error handler is
   specified, it is called one argument, which is the error object,
   with four values.
   … type, operation, data, and value
   … the return value is an object containing continue (boolean)
   and corrected value.
   … Perhaps we want there to be two arguments: the error and a
   callback. The callback would be used to allow it to be
   asynchronous
Markus Lanthaler:  what do you mean by data? Is it the input
   document, or a document fragment.
Gregg Kellogg:  Perhaps we need to pass in the entire document
   and a JSON Pointer. [scribe assist by Manu Sporny]
Niklas Lindström:  normally, the document object would be
   available to the error handler anyway.
   … I think it's also good to have the key for the current value
   (parent key and value) in addition to the value.
Manu Sporny:  do we think we need more than just the parent?
Niklas Lindström:  we should try to be simple.
   … In a list, you would need to return the position in the
   list.
Manu Sporny:
   http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-04
Manu Sporny:  json pointer is not final yet.
   … it uses '/' notation.
Niklas Lindström:  it would be more useful to have some
   JavaScript to do the access.
Manu Sporny:  I'm pretty wary of using this right now.
   … It would really complicate the implementation. If someone
   needs to find the reference, they can do that anyway.
Niklas Lindström: .. I'd prefer a regular access path like:
   "root['@graph'][0]['title']['@value']"
   … They can search the document for the value. Even if they
   needed to do that, they can search for the reference.
Niklas Lindström:  if you give them the term string, they can
   check the context.
   ... We could give root, parent, key and value. Then you don't
   need JSON pointer.
Niklas Lindström:  minimum should be term and value, if possible
   parent and root.
Manu Sporny:  with just key and value, it is still ambiguous
   … If we don't want JSON pointer, we need to be sure we have
   something that does the same thing.
   … for that to happen, it needs to be more than the key and the
   value.
Gregg Kellogg:  This is exactly what JSON Pointer is designed to
   do. [scribe assist by Manu Sporny]
Niklas Lindström: .. we can give them a path which is an array of
   strings and numbers
Niklas Lindström: .. that is enough to find the exact value from
   the root
Niklas Lindström: .. that would be path: [@graph', 0, 'title',
   '@value']
Manu Sporny:  I don't want to hold up JSON-LD just because JSON
   Pointer hasn't reached Rec.
Niklas Lindström:  I think that using a string to represent the
   path is overkill.
   … The result of that parsing is something we can already
   produce.
François Daoust:  I have manu's concern as well. We could easily
   be blocked because of that status of JSON pointer, and this is
   not core to the API.
   … I was warning if we could make this informative to suggest
   that implementations ought to (in a non normative way, that is)
   use JSON Pointers.
Markus Lanthaler:  I'm worried that we're going too far. You
   would have to know the internals of the processor to make use of
   this.
   … Either you program the error handler to deal with a specific
   situation or ???
   … Perhaps we should keep it simple with an error type, message
   and return value to continue or stop.
Manu Sporny:  so, this would mean that an implementation couldn't
   hope to correct data at runtime.
Manu Sporny:  I get where francios is going, but I don't think we
   can be informative in this case.
   … It's like saying there's an optional feature.
   … this means you need to reference a normative spec.
François Daoust:  I don't have a good example right now, and you
   may just end up with something you don't like.
François Daoust:  I'd rather leave it as is and allow the spec to
   move forward.
Gregg Kellogg:  In RDFa, we provided different ways to specify
   alternative information. Perhaps there is a way to have some
   options that can be added that allow stuff like this to be
   specified. If you're going to do that, and it's not normative,
   it's probably not that useful. [scribe assist by Manu Sporny]
Niklas Lindström:  I appreciate markus' point. Perhaps we can
   allow for the return to be true or false and not allow for any
   correction.
Manu Sporny:  I still think we should use the data structures I
   proposed. I like the simplicity of Markus' approach, but I'm
   concerned that there is no way to do correction.
   … Correction seems to be associated with corner cases. But, as
   Markus said, you could just run a pre-processor over the input to
   make sure it is in the proper order.
Niklas Lindström:  if we provide path information for global
   processing, it can lead to strange scenarios. If the path
   information implies that you can do correction, it's better to do
   a different way.
   … we should have more demand before we add such a feature.
Manu Sporny:  we could keep type and operation. Remove data.
   … Return value is true or false, to ignore and continue or
   abort.
   … The alternative is to allow the return to be different
   things, either boolean or object.
Gregg Kellogg:  We might be boiling this down a bit too much if
   we do true/false. Perhaps we need to keep the return type being
   an object to ensure the greatest amount of future proofing.
   [scribe assist by Manu Sporny]
Gregg Kellogg:  You could just throw an exception - ignore or
   abort the entire operation via an exception. [scribe assist by
   Manu Sporny]
Niklas Lindström:  it doesn't matter where it happens, as it's
   synchronous.
   … If you don't have an error handler, you would just throw the
   original exception.
Gregg Kellogg:  The error handler is a function that is called,
   it's not something that intercepts an exception. [scribe assist
   by Manu Sporny]
Manu Sporny:  I don't think we want to use this as an exception
   intercept. We did this to allow the developer that option.
Markus Lanthaler:  we did the error handler because it's
   asynchronous, not synchronous.
Manu Sporny:  I'd expect that when the processor stops it does
   this by throwing an exception.
Gregg Kellogg:  The reason we went down this path is because we
   wanted the developer to have more control over the error handling
   process. [scribe assist by Manu Sporny]
Gregg Kellogg:  The way that we had thought processing would stop
   (with an error) is with the processor returning an exception.
   [scribe assist by Manu Sporny]
Gregg Kellogg:  if the programmer wants to do anything else, the
   developer should throw an exception. [scribe assist by Manu
   Sporny]
Gregg Kellogg:  I think we should return a structure that
   includes some information that may be used by the processor in
   the future to provide finer granularity, but at this point, the
   actual return content is ignored and the current input is ignored
   and you continue processing the input stream. If the user wants
   to stop processing, they throw an exception. [scribe assist by
   Manu Sporny]
Niklas Lindström:  what happens when an exception is thrown we're
   in something asynchronous, you can't catch it.
Manu Sporny:  the original caller won't get the exception, but
   that happens all the time in JavaScript.
Manu Sporny: We could make this the method signature - function
   handleError(err, callback)
Manu Sporny: if you want to pass along the error, you do this -
   callback(err)
Manu Sporny: if you want to ignore the error and continue, you do
   this - callback(null, {})
Manu Sporny:  there's a standard way to do errors in node.js. If
   you look at the async library, this pattern of having error and
   callback as arguments is well established.
   … If we want to do things asynchronously, this is the way to
   do it.
   … if there's an error, 'handle error' is called with the error
   and a callback. This allows the error handler to notify it's
   completion by calling the callback.
Niklas Lindström:  this is not the way error handler callbacks
   are used in other libraries, like XMLHttpRequest.
Manu Sporny:  that's an old design, and people have moved away
   from that.
Niklas Lindström:  unless the handler is going to do something
   asynchronous itself, this looks like serious overkill.
Markus Lanthaler:  before the handler returns, the processor can
   decide whether to continue or not.
Manu Sporny:  all node.js libraries are designed like this.
Dave Longley: i don't think we want to prohibit asynchronous
   behavior in the error handler -- especially when the rest of the
   design for the JSON-LD API is asynchronous
Dave Longley: you might want to make other JSON-LD calls in the
   error handler ... or do anything else in an asynchronous way; if
   we're not consistently supporting async ... then we're not
   supporting async; it's going to be very frustrating for people
   who need it
Dave Longley: (as in, they'll have to rewrite the processor)
Dave Longley: i think it's a bad idea to mix and match async
   w/sync... because it just means that it won't always work
Manu Sporny:  I don't think there's anything to prevent the
   processor from continuing to process.
Markus Lanthaler:  either you stop processing, or you have a
   callback state to start and restart.
François Daoust:  you mentioned that it is common practice, but
   I'd like to see an example.
Manu Sporny: http://expressjs.com/api.html
   … I can't find an example having a continuation.
François Daoust:  I'm still a bit confused.
Dave Longley:

http://stackoverflow.com/questions/7310521/node-js-best-practice-exception-handling
Manu Sporny: https://github.com/caolan/async
David I. Lehn: hmm
François Daoust:  in the async world, the error handler signature
   doesn't take a callback.
   … handle error is already a callback.
   … This is only necessary if the error handler needs to be
   asynchronous itself.
   … I don't think that a error handler callback itself using a
   callback is that common.
Manu Sporny:  but sending a callback for something that should
   execute asynchronously is common.
Dave Longley: as soon as you force synchronicity into an
   asynchronous system you've broken it -- which means that you've
   prohibited yourself from using the same async APIs that do things
   for you in your error handlers that you use everywhere else
Markus Lanthaler:  I wanted to ask if we should postpone until we
   have more information.

Topic: ISSUE-160: Specify property-generator round-tripping algorithm

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/160
Manu Sporny:  we never got around to discussing this in depth.
   … I think we said that there were issues with compaction, as
   it could be combinatorially complex to run, and we may want an
   option to tell the API to do this, or not.
Niklas Lindström:  I think we should probably resolve issue 113
   first.
   … Based on that, we can decide on issue 160.
   … that will tell us if it is feasible to do something that
   isn't "high fidelity"
Markus Lanthaler:  as there might be more information under a
   language, I don't know if it's even feasible.
Niklas Lindström:  when we introduced property generators we said
   that it was likely that we wouldn't use it for compaction at all.
Manu Sporny:  the crux of the issue is that data gets created.
   … drupal community wants to be sure that if the compact, they
   get the same thing. We said we'd given them a flag to allow this.
Gregg Kellogg:  I think we could accomplish this by just picking
   the property-generator term before all other terms. [scribe
   assist by Manu Sporny]
Gregg Kellogg:  We may also want to implement duplicate removal
   as well. [scribe assist by Manu Sporny]
Niklas Lindström:  I realized that what gregg said makes sense:
   given a flag, property generators should only be used on data
   which you know about in advance. You shouldn't use them
   otherwise.
   … Given that, we could simplify the algorithm by just using
   the first value in the property generator, because you expect
   (require) that the data be consistent with doing that.
   … If a flag is used, you won't accidentally use that.
   … The flag should enable the use of property generators in
   compaction.
   … by using try, you're prepared that every term that has a
   property generator will only create round-trippable data if your
   input has duplicate data for all values.
Manu Sporny:  if you use gregg's algorithm, it is linear and not
   combinatorial.
   ... The key thing is that in the term selector you have to use
   property generator terms first.
   ... If we follow a standard selection process, it is linear.
Manu Sporny:  modify compaction algorithm to consider property
   generator terms before any other term.
   … any time you find something that matches, you check to see
   if it already exists and if it has that value. If it does, you
   ignore it, otherwise, you add to the end of the array.
Markus Lanthaler:  What about @lists - do we check all entries in
   there? [scribe assist by Manu Sporny]
Manu Sporny:  Yes, I think we have to. [scribe assist by Manu
   Sporny]
Gregg Kellogg:  Yes, and keep in mind that list order is
   important. [scribe assist by Manu Sporny]
Niklas Lindström:  if there's a value, you need to check all keys
   in the value.
   … If there's an ID, the expressed information is enough.
Markus Lanthaler:  this doesn't guarantee that the node
   definitions are equivalent.
Niklas Lindström:  I have a problem with expanded forms not
   always being flattened anyway.
   … For this case, it would really help.
   … we could say that to not loose data, it needs to be used
   with 'flatten' set to true.
Niklas Lindström:  drupal wants this because the use RDFa, and
   this is consistent with the use in RDFa.
   … what they don't care about is the potential of using
   vocabulary expansion, which could be done on the RDF side.
Manu Sporny:  it seems we have a solution, but it still has
   complexities due to complex values.
   … We can implement a basic version of this, but if we find
   deeply nested objects we can throw an exception.


-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: HTML5 and RDFa 1.1
http://manu.sporny.org/2012/html5-and-rdfa/

Received on Tuesday, 25 September 2012 17:22:22 UTC