JSON-LD Telecon Minutes for 2013-07-23

The minutes from this week's telecon are now available.

http://json-ld.org/minutes/2013-07-23/

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

-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-07-23

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Jul/0106.html
Topics:
   1. ISSUE-277: "partial" lists
   2. GSoC Update
   3. Review JSON-LD github issues ready to be closed
   4. Review of JSON-LD API Spec
Resolutions:
   1. Adopt Markus' algorithmic change to convert partial lists
      from RDF to JSON-LD.
   2. Make it clear in the specification that objects can be
      provided to the context parameter can either be JSON-LD Contexts,
      or objects containing JSON-LD Contexts.
   3. The JSON-LD API should process all documents labeled with
      media types using the application/json or any media type with a
      +json suffix. Implementations must not follow an HTTP Link Header
      if you encounter an application/ld+json media type.
   4. A remote context MUST be served as application/ld+json.
Chair:
   Manu Sporny
Scribe:
   Manu Sporny
Present:
   Manu Sporny, Niklas Lindström, Gregg Kellogg, Dave Longley,
   Markus Lanthaler, Vikash Agrawal, David I. Lehn
Audio:
   http://json-ld.org/minutes/2013-07-23/audio.ogg

Manu Sporny is scribing.
Manu Sporny:  Any other changes to the Agenda other than Niklas'
   addition?
No other changes noted, moving on to first agenda item.

Topic: ISSUE-277: "partial" lists

https://github.com/json-ld/json-ld.org/issues/277
Niklas Lindström:  When I implemented this recently, I noticed
   that if you can serialize a path to rdf:nil, we should do that by
   using syntactic sugar form, even if the property is rdf:rest.
Niklas Lindström:  The only case where you wouldn't do that is if
   that list node is not well formed.
Niklas Lindström:  For example, it's an IRI, has something that's
   not rdf:next, etc.
Gregg Kellogg:  ... and everything before that?
Niklas Lindström:  If you encounter such a node, and there is an
   rdf:rest property pointing to it that is not well formed, then we
   don't do anything about the rest.
Niklas Lindström:  I don't think that we should be that eager to
   unravel a list. There could be places, such as in OpenAnnotation,
   we don't know if it would be sufficient, but we could describe
   the first node as an IRI and then the rest as a well-formed list.
Niklas Lindström:  I don't see a reason for the rest of the list
   to be treated as a non-list when it is a list.
Niklas Lindström:  I'm not sure about Turtle serializers in
   general, but the rdflib serializer is doing the same thing as
   ISSUE-277 proposal.
Niklas Lindström:  So, we should align with that (and this is a
   bug fix)
Dave Longley:  What are the conditions under which this sort of
   data appears? Does anyone create the data intentionally where
   they wouldn't want @list?
Dave Longley:  Do they go with the OpenAnnotations use case?
Markus Lanthaler: what niklasl just described is what my
   algorithm update will do
Dave Longley:  Is it best to just wrap up as much of the list, or
   the end of the list as we can?
Dave Longley:  If something isn't well-formed, we don't use @list
   at all. Is that preferable over wrapping everything up in
   @list... I don't know. Could we list out the various cases under
   which we'd encounter data where the list is not well formed, that
   might help us make a quicker decision as to what should be done.
Gregg Kellogg:  owl:unions aren't... they use lists, but they're
   not well-formed.
Gregg Kellogg:  They have a type of owl:Class.
Niklas Lindström:  I think the first member in the list is a
   owl:Class, but I've seen that in Turtle notation.
Gregg Kellogg:  I think every element is owl:Class.
Niklas Lindström: :ClassC owl:unionOf ( :ClassA :ClassB ) .
Dave Longley:  If that's true, this algorithm wouldn't affect
   that in any way. It would see that every element in that list is
   not well-formed, so we can safely ignore that case.
Gregg Kellogg:  I think the main use case is where there are
   properties on the first element in the list, or the list is the
   subject.
Dave Longley:  In that case, we want people to see the @list
   keyword.
Gregg Kellogg:  I can't imagine a reason where you could use
   @list - you could also support lists of lists...
Gregg Kellogg:  you'd just have a blank node as an argument and
   have the rest spelled out as rdf:first and rdf:next
Dave Longley:  That would be awkward, but it's no different than
   what we have now.
Gregg Kellogg:  Markus, what's your updated algorithm to address
   this?
Markus Lanthaler:  Yes, it does. It keeps blank nodes in list,
   then rdf:next (scribe missed)
Gregg Kellogg:  It's worth doing this even w/ increased
   algorithmic complexity. This is a detail of the spec.
Gregg Kellogg:  We do have normative language for list of lists
   exception, we might remove that.
Markus Lanthaler: s/rdf:next (scribe missed)/the blank node has
   an @list-array as value of rdf:rest which represents the inner
   list
Niklas Lindström:  I don't think anyone would care if we got rid
   of list of lists.
Gregg Kellogg:  The exception is only generated now during
   compaction, if a property has list coercion on it... I don't
   think we need to generate that exception. We could get the
   recursive list behavior you wanted by using the sugar syntax.
Markus Lanthaler:  The reason we need to raise the exception, if
   you have a property that is a list, and you have another list,
   then you raise an exception.
Gregg Kellogg:  if we did this, we wouldn't need to do that.
Gregg explains the technical implementation of why we wouldn't
   need  to throw an list of lists exception.
Markus Lanthaler:  The algorithm I'm going to commit later
   doesn't have any side-effects.
Niklas Lindström:  I think incorporating it will solve ISSUE-277,
   we could see where we're at with list of lists. We may need a
   separate vote on that later on.
Manu Sporny:  We should put a warning on this change, going into
   Candidate Rec.

PROPOSAL: Adopt Markus' algorithmic change to convert partial
   lists from RDF to JSON-LD.

Niklas Lindström: +1
Manu Sporny:  +0.2
Gregg Kellogg: +1
Markus Lanthaler: +1
Vikash Agrawal: +1
Dave Longley: +1

RESOLUTION: Adopt Markus' algorithmic change to convert partial
   lists from RDF to JSON-LD.

Niklas Lindström:  After this change, rdflib implementation will
   be very much aligned.

Topic: GSoC Update

Vikash Agrawal: So, I think I have concluded the website
   (considering the indentation and validation bugs) Now I am
   writing my contexts (I made some progress with problems here) so
   I am reading the spec again
Vikash Agrawal: This being said, if I am able to complete the
   Person any time soon, I dont think Places and events will be a
   big hurdle. I will submit in /contexts/Person-1.jsonld file
   structure
Vikash Agrawal: I wanted to talk about the status of mid-term
   eval, which is starting from Monday! Can you please throw some
   light over that as in Pass or fail or a definitely pass
Markus Lanthaler: vikash, there are still sites which haven't
   been converted to the new layout.. the last one I saw was
   /minutes
Vikash Agrawal: Thanks manu for allowing the discussion and mlnt
   nikalas too
Vikash Agrawal: mlnt, Can you please just let me know those, I
   will complete those, no worries on that..
Vikash Agrawal: there were few parts I dint touch.
Manu Sporny:  so vikash, on his proposal, had stated that he
   would be further along with the JSON-LD creator tool than he
   currently is for his mid-term evaluation, but i'm fairly happy
   with the work he's gotten done, though it seems like he could
   have gotten more done for one reason or another, a fail would
   mean that he's out of the program and i think that the work he's
   done on the website is certainly good enough to keep him in the
   program so i think we should pass him [scribe assist by Dave
   Longley]
Manu Sporny:  are there any other thoughts on his status in the
   group? [scribe assist by Dave Longley]
Markus Lanthaler:  i'm having trouble keeping up with what he's
   doing, could we get more updates on the mailing list? [scribe
   assist by Dave Longley]
Manu Sporny:  we could ask him to do weekly updates [scribe
   assist by Dave Longley]
Gregg Kellogg:  i would like to see vikash achieve a higher-level
   of proficiency in JSON-LD, given the time he's spent he still
   shows a naive understanding so i'd like to see him do better with
   that [scribe assist by Dave Longley]
Vikash Agrawal: dlongley sure. but I think, I am able to provide
   updates weekly meeting, unfortunately I wasn't able to join in a
   few of those.
Gregg Kellogg:  i'd also like to see better quality of code in
   what's submitted so we don't have to go back and forth as much
   [scribe assist by Dave Longley]
Vikash Agrawal: gkellogg, Those will be done
Manu Sporny:  some of what vikash may be doing could be a
   cultural thing or a student thing to do a first pass and then get
   feedback, there's certainly a steep learning curve as a student
   and we expect more of him but at the same time he's tackling a
   timezone, cultural, and knowledge gap [scribe assist by Dave
   Longley]
Markus Lanthaler: vikash, I would really prefer updates via mail
   to the mailing list..
Manu Sporny:  i think we want to see improvement from vikash in
   all aspects, but i think he should continue work, is that the
   consensus? [scribe assist by Dave Longley]
Vikash Agrawal: weekly updates Noted.
Dave Longley: [general consensus]
Vikash Agrawal: manu, Yup, I feel the very same. on my personal
   fronts I do see, I need to more with json-ld
Vikash Agrawal: but I also think, I am learning various thingsand
   utility too.
Manu Sporny:  dlehn was saying he definitely want him to be
   writing more code since it's GSoC, so the rest of his time should
   be spent writing a good chunk of JS code [scribe assist by Dave
   Longley]
Dave Longley: Vikash, there's general consensus that you will
   pass the mid-term eval
Vikash Agrawal: Feels good and thanks. Woot.
Vikash Agrawal: Thank-You so much everyone, and with out you guys
   this would have been impossible

Topic: Review JSON-LD github issues ready to be closed

https://github.com/json-ld/json-ld.org/issues?milestone=2&page=1&sort=created&state=open
Manu Sporny:  we've responded to robin berjon's comments as much
   as we could, some concerns we couldn't address with the spec at
   this point [scribe assist by Dave Longley]
Vikash Agrawal: makes sure, that he will make a fast pace and do
   weekly updates
Manu Sporny:  some people feel that robin is misreading what the
   spec is trying to do, i think i dealt with all LC issues he has
   there [scribe assist by Dave Longley]
Manu Sporny:  understanding the JSON-LD data model is now
   difficult to understand, with all the changes we've had recently
   things have become very difficult to understand, the spec is
   pretty unreadable so we need some editorial changes to fix that
   [scribe assist by Dave Longley]
Manu Sporny:  i think we're done with the GLD WG feedback [scribe
   assist by Dave Longley]
Manu Sporny:  let us know if anyone thinks differently [scribe
   assist by Dave Longley]
Manu Sporny:  we'll close that in 24 hours if there are no
   complaints [scribe assist by Dave Longley]
Manu Sporny:  we have some ongoing discussion with markus on what
   we should do with the @context array feature [scribe assist by
   Dave Longley]
Manu Sporny:  i think we're ready to close David and Peter's
   review issue [scribe assist by Dave Longley]
Manu Sporny:  any thoughts from the rest of the group on any of
   the two remaining issues? [scribe assist by Dave Longley]
Vikash Agrawal: Thank-You so much everyone, and with out you guys
   this would have been impossible
Niklas Lindström:  Issue #245 is tricky - if we do not allow the
   data to pass in { "@context": '...' } - not supporting that would
   be okay
Niklas Lindström:  I think that's fine... but wouldn't be a hard
   +1 still.
Niklas Lindström:  If you want to access RDFa as JSON-LD, any
   sort of extra syntactic ritual to access schema.org data would be
   problematic for political reasons. People are concerned about
   Linked Data cruft. We shouldn't allow @context key in - must not
   have a @context keyword.
Markus Lanthaler:  The playground has been working list this -
   allowing @context.
Markus Lanthaler:  It would make it symmetric to the context
   parameter, if we disallowed it, it would be a special case.
Markus Lanthaler:  we've been doing that since the beginning,
   grammar has supported that from the beginning, no reason to
   change that now.
Niklas Lindström: .. the symmetry argument does speak to me
Gregg Kellogg:  I can see an argument for increasing flexibility,
   that would imply being able to pass an object in that has a
   @context.
Gregg Kellogg:  I think we should support as many different
   things being passed in that make sense, if we can do it
   deterministically.
Gregg Kellogg:  Part of me doesn't like that it's so variable...
   but not supporting things where it's clear what the intent is, is
   bad.
Dave Longley:  I support both, agree with Gregg.
Niklas Lindström:  Yeah, I do the same.
Niklas Lindström:  If you put an object in there that doesn't
   have a @context at the top-level, it'll be an issue.
Gregg Kellogg:  I don't know if various options are specified, so
   we should detail this in the spec.

PROPOSAL: Make it clear in the specification that objects can be
   provided to the context parameter can either be JSON-LD Contexts,
   or objects containing JSON-LD Contexts.

Gregg Kellogg: +1
Dave Longley: +1
Manu Sporny: +1
Vikash Agrawal: +1
David I. Lehn: +1
Niklas Lindström: +0.9

RESOLUTION: Make it clear in the specification that objects can
   be provided to the context parameter can either be JSON-LD
   Contexts, or objects containing JSON-LD Contexts.

Topic: Review of JSON-LD API Spec

https://github.com/json-ld/json-ld.org/issues?milestone=1&page=1&sort=created&state=open
Markus Lanthaler:  There is one minor thing that Gregg and I have
   been discussing about nodes with just @id when you frame.
Markus Lanthaler:  Should such a node be in the output or not...
   that's one question.
Markus Lanthaler:  The other one is that we should discuss
   whether we support +json media types in the API.
Markus Lanthaler:  Currently, HTTP Link Header allows a publisher
   to link to a context w/o changing the document. That mechanism is
   specified to work just for application/ld+json
Markus Lanthaler:  +json suffix has been standardized,
   application/stream+json should be able to use it as well.
Markus Lanthaler:  The change would just be to re-phrase that
   section with a small explanation on what you invoke the API, to
   support all +json media types.
Markus Lanthaler:
   http://json-ld.org/spec/latest/json-ld-api/#the-jsonldprocessor-interface
Markus Lanthaler:  Look at the .compact() call... see how it says
   it's only applicable to application/ld+json? We could change that
   to "application/ld+json or "+json" suffix... we're overly
   restrictive here... we're just generalizing the solution.
   Different flavors of JSON, we should support them all.
Discussion about loosening restriction that application/ld+json
   documents MUST contain a @context keyword.
Dave Longley:  This might be a recursion issue wrt. remote
   context.
Discussion about terminating when recursive HTTP requests are
   made against documents.
Niklas Lindström:  We want systems to try to interpret things as
   JSON-LD if possible.

PROPOSAL: The JSON-LD API should process all documents labeled
   with media types using the application/json or any media type
   with a +json suffix. Implementations must not follow an HTTP Link
   Header if you encounter an application/ld+json media type.

Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +1

RESOLUTION: The JSON-LD API should process all documents labeled
   with media types using the application/json or any media type
   with a +json suffix. Implementations must not follow an HTTP Link
   Header if you encounter an application/ld+json media type.

Markus Lanthaler:  ISSUE-279 also affects framing.
https://github.com/json-ld/json-ld.org/issues/279
Dave Longley:  We're going to have to make algorithmic changes to
   certain things to support framing in the future, so it'll fall
   into the same bucket. It's not in the node map.
Dave Longley:  Framing may need to make modifications to node-map
   and expansion to preserve things for framing.
Gregg Kellogg:  We will need to provide a framing option to the
   algorithms.
Dave Longley:  We already have to do that w/ other algorithms
   too.
Manu Sporny:  Ok, so we're putting that discussion off.
Manu Sporny:  ISSUE-264 - need to discuss
Dave Longley:  we need to discuss recursion, when you use an HTTP
   Link Header, must you specify that the document is
   application/ld+json? The result is to avoid endless recursion.
Markus Lanthaler:  That would simplify the problem quite.
Dave Longley:  You might have a document that is application/json
   and it can't serve ld+json, so you need to have redirection for
   that.
Dave Longley:  If we say you only follow one HTTP Link Header,
   you only have one result, plus you could support this use case.
   If you only follow one link header, it doesn't matter what the
   media type is.
Markus Lanthaler:  That might be dangerous, it changes the
   interpretation of that document, in one case, you use the link
   header, in the other case you do not.
Markus Lanthaler:  If you have a document that has an inline
   context, and that context depends on the remote context, you
   could have different contexts if you pay attention to the ld+json
   link header and one where you don't.
Markus Lanthaler:  Talking about your proposal where you just
   follow one Link Header.
Dave Longley:  Trying to figure out what you're saying... if you
   just follow one link header... (scribe missed)
Dave Longley:  I'm fine w/ restricting to ld+json, if that's a
   problem, implementations will become looser.
Markus Lanthaler:  It's always much easier to loosen something
   later, than restrict it later. I'd rather keep it stricter to
   start off.

PROPOSAL: A remote context MUST be served as application/ld+json.

Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
Dave Longley: +1
Niklas Lindström: +0.75

RESOLUTION: A remote context MUST be served as
   application/ld+json.

Dave Longley:  Another issue here, when you get a remote context
   and you encounter re-directs, what becomes the base URL to
   resolve relative URLs against.
Dave Longley:  In the case with w3id.org, do you use w3id.org/ as
   the base URL or the final destination.
Markus Lanthaler:  Usually, with a redirect, you use the last
   URL.
Dave Longley:  Is that true, or does it append onto the HTTP
   response code?
Markus Lanthaler:  If you have a bookmark, the HTTP status states
   whether or not you should update your bookmark.
https://w3id.org/payswarm#vendor
Dave Longley:  One way to do this - if you're using a Link
   redirector, don't use relative IRIs.
Markus Lanthaler:  or set the base.
Dave Longley:  it would be strange to get back a document via
   redirects that has relative URLs and use a different URLs based
   on where you started from.
Markus Lanthaler:
   http://json-ld.org/spec/latest/json-ld-api/#data-round-tripping
Manu Sporny:  ISSUE-258 - what changes do we need to make re:
   unresolved resolution?
Markus Lanthaler:  I think we already state that.
Manu Sporny:  ISSUE-238 - WebIDL reference...
Dave Longley: http://json-ld.org/test-suite/idltest/
Markus Lanthaler:  We've already referenced WebIDL in the proper
   way.
Dave Longley:  We pass the WebIDL test harness, so we're clear.
Markus Lanthaler:  Refering to Futures/Promises?
Manu Sporny:  We specify Promises very lightly and point to the
   spec, that's how we should keep it.
Markus Lanthaler:  We'll also want an expert to review the WebIDL
   during CR phase.
Manu Sporny:  ISSUE-229 - Make test suite more obvous
Gregg Kellogg:  We need to link to the test suite... it also
   needs to be styled... need a purpose for each test... otherwise
   it's done.
Gregg Kellogg:  It just pulls in the manifest, could have better
   structure, css, could use some style love.
Gregg Kellogg:  there was probably a comment from RDF WG about
   making tests more obvious.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Tuesday, 23 July 2013 16:52:03 UTC