JSON-LD Telecon Minutes for 2013-02-19

Thanks to François for scribing. The minutes from today's telecon are
now available.

http://json-ld.org/minutes/2013-02-19/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2013-02-19

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Feb/0089.html
Topics:
   1. ISSUE-217: Disallow BNode identifier as Graph Name
   2. Publishing JSON-LD 1.0 as a FCGS
   3. ISSUE-218: Algorithm specification updates by editors
   4. Update to RDF Algorithms
Resolutions:
   1. This group re-affirms that the common practice when naming
      a graph is to use either an IRI or a blank node identifier. The
      JSON-LD specification remains unchanged. When expressing graphs
      in Linked Data, the graph name SHOULD be an IRI.
   2. Publish the JSON-LD 1.0 syntax specification as of February
      19th 2013 as a Final Community Group Specification.
Chair:
   Manu Sporny
Scribe:
   François Daoust
Present:
   François Daoust, Manu Sporny, Niklas Lindström, Gregg Kellogg,
   Markus Lanthaler, Dave Longley, David I. Lehn
Audio:
   http://json-ld.org/minutes/2013-02-19/audio.ogg

François Daoust is scribing.
Discussion about graph BNode identifier as Graph Name
   permathread.
Mostly a summary of the discussion thread:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Feb/0038.html

Topic: ISSUE-217: Disallow BNode identifier as Graph Name

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/217
Manu Sporny:  A bit of a breakthrough in the RDF WG, which is
   great. We need to support BNodes identifier for graph names. I
   think that's all we need. We don't really need Pat Hayes
   suggestion, although it would be nice.
   … I'd like for us to make the statement that the ID of a graph
   denotes the graph in JSON-LD.
Niklas Lindström:  Not comfortable if that deviates from what the
   RDF WG decides
Gregg Kellogg:  I agree. I don't think that's the way to do it.
Manu Sporny:  That's fine, I don't feel strongly about this being
   in the spec, but I do think strongly that it's the right thing to
   do.
Gregg Kellogg:  My update to the RDF algorithms was to note that
   this is an issue. We could say that it is at risk.
   … I think that we need to wait for the RDF WG to come to a
   final decision and see here what that entails.
Manu Sporny:  Markus, Gregg, and myself, let's make sure we show
   up on tomorrow's RDF call then.
[more discussion on blank nodes and base document IRI]
Manu Sporny:  OK, then waiting for the RDF WG to come up with a
   resolution.
   … Do we want to do any kind of proposals? To state the
   solution that we believe would be the right one?
Gregg Kellogg:  Yes, it would be useful
Niklas Lindström:  maybe some informal recommendation that IRIs
   are preferred.
Gregg Kellogg:  Not so sure. Eric came up with a few examples
   where BNodes identifier are the best way forward.
Markus Lanthaler:  isn't it enough to say that we don't change
   our current spec?
Gregg Kellogg:  the point of the proposal is to point to a
   decision of this group that strongly supports that position in
   order to get the concepts updated.

PROPOSAL: This group re-affirms that the common practice when
   naming a graph is to use either an IRI or a blank node
   identifier. The JSON-LD specification remains unchanged. When
   expressing graphs in Linked Data, the graph name SHOULD be an
   IRI.

Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
François Daoust: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Niklas dreams aloud about an utopic world where something named
   RDF 2.0 would solve everyone's problems.

RESOLUTION: This group re-affirms that the common practice when
   naming a graph is to use either an IRI or a blank node
   identifier. The JSON-LD specification remains unchanged. When
   expressing graphs in Linked Data, the graph name SHOULD be an
   IRI.

Topic: Publishing JSON-LD 1.0 as a FCGS

Manu Sporny:  The only thing that was blocking the publication
   was that graph name thing.
Gregg Kellogg:  I think we can publish it as an FCGS right now
   and have the RDF WG understand that one issue moving forward is
   the graph name discussion.
Manu Sporny:  OK, so proposal is to publish the syntax spec as
   FCGS

PROPOSAL: Publish the JSON-LD 1.0 syntax specification as of
   February 19th 2013 as a Final Community Group Specification.

Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Dave Longley: +1
François Daoust: +1
Niklas Lindström: +1

RESOLUTION: Publish the JSON-LD 1.0 syntax specification as of
   February 19th 2013 as a Final Community Group Specification.

Topic: ISSUE-218: Algorithm specification updates by editors

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/218
Manu Sporny:  Markus has done a fantastic job at getting all our
   comments as a checklist in the issue tracker.
   … Markus, could you give us an overview of biggest concerns?
Markus Lanthaler:  basically the same as last week.
   … Some typos have changed but the algorithms in general have
   not really been updated.
   … Dave fixed a couple of bugs.
   … Other things haven't been done or at least I haven't seen
   them yet.
Dave Longley:  I'm looking at the list. There are a couple of
   things where we're still trying to figure out if we want to
   reorganize algorithms.
   … Moving keywords processing around could be one such thing.
   It would be good to have feedback from others (Gregg?).
   … Maybe folding keywords aliasing processing into IRI mapping.
   It would be fine with me as long as we make it clear that they
   are handled. Previous version did not seem to handle them at all.
Gregg Kellogg:  My previous implementation folded the keywords
   aliasing into the normal term processing.
   … I ended up doing it as a reverse table
   … I haven't progressed enough in updating compaction to see
   that it clarified things or not.
Manu Sporny:  What might help is finding what things the editors
   need feedback about. One way is editors go ahead and discuss
   things among themselves. Or we go through the group for each and
   every point but that would be a disaster in terms of time.
   … Could you isolate points that need feedback from the group?
   … To the extent possible, the editors should fix the spec. If
   there's disagreement or if you don't really know which way to go,
   flag that for the group to look at. Does that seem like a
   reasonable way to proceed?
Markus Lanthaler:  difficult to isolate what really needs to be
   talked about.
Manu Sporny:  If both of you disagree, we can escalate to the
   group.
Gregg Kellogg:  It's worth spending time on this call going
   through the list.
   … I think lots of things related to the context should be
   close to the context processing section.
   … I feel there is no movement because we do not have a good
   overview of what we want as a group.
Markus Lanthaler:  I agree. I haven't made some changes not to
   have to revert the changes afterwards.
Manu Sporny:
   https://github.com/json-ld/json-ld.org/issues/218#issuecomment-13449440
Manu Sporny:  OK, let's start from the top, then
Manu Sporny:  About "folksy wording", I agree.
Gregg Kellogg:  agreement about this, it's just the work needs to
   be done.
Manu Sporny:  It doesn't really need to be done for this version
   but the RDF WG will complain about it, for sure.
Gregg Kellogg:  It's important to prioritize things that change
   the algorithms.
Manu Sporny:  So feedback on first one is "make the changes when
   algorithms are updated".
   … Moving on to "we" being used quite a bit
Markus Lanthaler:  note it also contains a note on relative IRIs.
Gregg Kellogg:  I'll edit the note to move the first part to the
   end of the "folksy" comment and keep the later part.
   … The comment about the relative IRI is related to passing the
   base IRI in the options parameter of the expansion algorithm
Dave Longley:  Maybe add "relative IRI" to terminology to explain
   how it gets resolved.
Manu Sporny:  I like the idea to be more general about it and put
   it in the terminology.
Dave Longley:  sort of micro-algorithms, that's one of these
   examples.
   … We can probably link to RFC something for IRI resolution.
Markus Lanthaler:  If the remote context includes another remote
   context, what base IRI to use? It's not that trivial.
Gregg Kellogg:  The main case is when you resolve the remote
   context IRI which is relative.
Markus Lanthaler:  We don't allow relative IRIs for terms in
   context
Gregg Kellogg:  so maybe it's not an issue anymore.
Manu Sporny:  we seem to be heading in the right direction for
   this one.
   … Moving on to the "General solution" sub-section. I agree.
   Any disagreement?
[none heard]
Manu Sporny:  comment on "xxx equals null" to be replaced by "xxx
   is null".
Gregg Kellogg:  It's an English usage. It just sounds
   unnecessary.
Dave Longley:  I agree. I just wanted to be consistent. I prefer
   the shorter version.
Manu Sporny:  ok, skipping down to "Otherwise is awkward". What
   is the alternative?
Gregg Kellogg:  This was with respect to a statement that is
   perhaps not there anymore. I don't remember where it was.
Manu Sporny:  ok, moving on to duplicate normative statments.
.
Gregg Kellogg:  that echoed Markus feedback on my alternative
   version where I had duplicated these statements.
   … It's reasonable to use that language, but maybe add a note
   that says MUST, SHOULD and etc. do not mean the same thing there.
Dave Longley:  I would prefer avoiding using these terms.
Manu Sporny:  Are we skipping this for now?
Markus Lanthaler:  I think we all agree that it shouldn't
   duplicate normative statements.
Manu Sporny:  I'm not too worried about that if that makes
   writing the algorithms easier.
Manu Sporny:  ok, moving on to last point in Gregg's list.
   … the note should go in Context Expansion. [no disagreement
   heard]
   … Moving on to Dave's feedback.
   … Point on audience is correct, indeed. Developers might want
   to have a look at the API in the spec.
   … [no disagreement heard]
   … Moving on to the comment on features
Dave Longley:  I think he's talking about the features section,
   let's add a link to the API section there. [scribe assist by Manu
   Sporny]
Dave Longley:  introduction should point to API as well. [scribe
   assist by Gregg Kellogg]
Manu Sporny: http://json-ld.org/test-suite/
Gregg Kellogg:  the test suite is referenced generically. We
   could get an EARL report in place to link tests and the spec.
Gregg Kellogg: http://rdfa.info/earl-reports/
Gregg Kellogg:  [going through the earl reports example]
Manu Sporny:  I would not be opposed to do that.
Gregg Kellogg:  I may volunteer to do a variation of the report
   that does the job for us.
Manu Sporny:  this work needs to be done to get us out of CR.
Gregg Kellogg:  Something actionable right now would be adding a
   note pointing user to the test suite to provide more examples.
Manu Sporny:  Fine with that. [no objection heard]
Manu Sporny:  Going through Markus' feedback now
Dave Longley:  Intro could explain how JSON-LD can be used to
   switch between different contexts.
[agreement]
Manu Sporny:  Moving on on the "the difference is in their
   context information".
Dave Longley:  The example is not clear if you're not looking at
   details. Markus changed it. But that doesn't really highlight the
   primary function of expansion which is to remove the context.
   … We should need to change the examples to show how very
   different contexts can be used with the same data.
Markus Lanthaler:  right. At the moment, it's very confusing.
Dave Longley:  we may just need to pick up two different names
   for the "homepage" for instance.
Manu Sporny:  Moving on to feedback on section 5.2
Markus Lanthaler:  when you're processing the local context, it's
   more reasonable to process the remote context before you do
   anything else.
Dave Longley:  The separation of concepts is more about doing I/O
   vs. doing something that is JSON-LD related.
Gregg Kellogg:  From an algorithmic point of view, it goes well
   to say that you dereference the context and use that inline.
   Pre-fetching is certainly a good idea but that does not make the
   algorithm any simpler in my view.
Manu Sporny:  I feel the algorithm looks simpler if all remote
   resources get retrieved beforehand.
Dave Longley:  When someone tries to implement the algorithms, it
   makes more sense to process remote resources before. Perhaps not
   easier to read for an overview of the algorithms.
Gregg Kellogg:  I don't really see that it benefits my
   implementation in any way.
Dave Longley:  CPU vs. I/O issue.
Gregg Kellogg:  An algorithm is not the place to specify that.
Manu Sporny:  Agreement that we're going to put a note in the
   spec to say that the contexts may be retrieved beforehand but the
   algorithms won't mention that.
Dave Longley:  [scribe missed the proposal]
Manu Sporny:  Sections 5.2 and 5.3. now read well. Moving parts
   will make things very chunky.
Markus Lanthaler:  that would just add a couple of steps to the
   algorithms and general solution.
Manu Sporny:  OK, général agreement on 5.2 then.
   … Moving on to 5.3.
Dave Longley:  I didn't find it confusing.
   … to mark the keys as having been defined.
Markus Lanthaler:  ok, fine for me if it's clear for everyone
   else. It's basically the first step so a bit confusing.
   … It gets clearer when you read on.
Dave Longley:  Problem is about recursing. It may not actually
   happen anymore though. I'll take a look at that.
Gregg Kellogg:  I can't have context that uses "language" as an
   alias for "@language". That's not a legitimate aliasing.
Dave Longley:  OK, if it's removable, let's remove it.
Manu Sporny:  If it's not, we could clarify why we need to mark
   it as "defined"
   … Moving on to section 5.4
Dave Longley:  The introduction was changed, so I thought this
   was checked.
Markus Lanthaler:  I think the problem was about term definition
   inheritance.
Dave Longley:  That should be removed now.
Markus Lanthaler:  I'll have a look after the call.
Manu Sporny:  OK, moving on towards the bottom of section 5.4.
Dave Longley:  Gregg recommended re-ordering. I'm fine with that
   change.
Gregg Kellogg:  In my implementation, it's logical to have them
   under context evaluation.
Dave Longley:  OK, I would not introduce a new EvaluationContext
   term.
Gregg Kellogg:  No. I would reorganize under 5.3.
Markus Lanthaler:  Then we will end up 5-6 level deep which would
   be annoying.
Manu Sporny:  Top level content processing algorithms would be
   good as Markus suggested.
[agreement]
Manu Sporny:  I propose to stop here for this week, to let the
   editors catch up. My assumption is that when the whole list is
   checked off, we'll be in good shape for an FCGS.
Markus Lanthaler:  one big issue is error handling. Completely
   missing for the time being.
Dave Longley:  Markus, if you can take the error text that you
   had and add that to wherever we say "otherwise, it's an error",
   I'd be fine with that.
Markus Lanthaler:  Just add that error constant?
Dave Longley:  In the previous version, you called out precise
   errors.
Markus Lanthaler:  At least Gregg was not too happy about that.
Manu Sporny:  Your issue, Gregg, was saying that the algorithms
   should raise an error.
Gregg Kellogg:  twofolds. Raise an error within an algorithm is
   not a pure algorithm. Other part is binding a specific token for
   the specific errors that were raised is also not a good idea.
   … Since then, I think the errors are defined as phrases. I
   think it's fine to include these phrases in the algorithms.
Markus Lanthaler:
   http://json-ld.org/spec/latest/json-ld-api/#idl-def-JsonLdErrorCode
Dave Longley:  Phrases instead of contents in the algorithms then
   … Can we say that an "invalid syntax" has been detected?
Gregg Kellogg:  yes
Markus Lanthaler:  I don't really see any difference to what we
   did last time.
Manu Sporny:  It's one more level of indirection that I don't
   think we really need.
Dave Longley:  I don't think it adds any more level of
   indirection. It should be almost the same as what Markus did
   before except we're dropping the constants.
Markus Lanthaler:  What do we do after detecting an error, then?
Gregg Kellogg:  That's a good question. There are cases where I
   raise errors and they are ignored, and vice versa.
Markus Lanthaler:  I think all errors enumerated here are fatal
   errors.
Gregg Kellogg:  "invalid container mapping", I could go on.
Markus Lanthaler:  then we can ignore everything.
Manu Sporny:  I think we'll have to go down any single one of
   these errors and decide which ones are fatal.
Dave Longley:  In the meantime, I suggest pulling what Markus had
   and insert the appropriate term definition and link to this
   table.
Markus Lanthaler:  ok.

Topic: Update to RDF Algorithms

Gregg Kellogg:  Before we close, a little update on "tref".
   … [scribe missed points]
Markus Lanthaler:  just an update that reSpec does not run
   anymore for the time being.
Manu Sporny: Syntax spec is broken due to: Uncaught Reference to
   undefined term 'compact_iri'
Gregg Kellogg:  One other thing to the updated 2 RDF algorithms.
   One test fails for me.
   … It's either a bug in my implementation or a bug in the
   flattening algorithm.
Dave Longley:  I'll probably re-implement what you've been doing.
Gregg Kellogg:  the convertFrom algorithm is not really
   different. The convertTo algorithm is substantially different.
Manu Sporny:  Alright. Dave will have feedback when he implements
   it.
   … Thanks for the call everyone. We'll chat again next week.
David I. Lehn: bye
[call adjourned]

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Tuesday, 19 February 2013 18:20:02 UTC