W3C home > Mailing lists > Public > public-linked-json@w3.org > March 2013

JSON-LD Telecon Minutes for 2013-03-26

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 26 Mar 2013 12:39:10 -0400
Message-ID: <5151CF2E.9030905@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
CC: RDF WG <public-rdf-wg@w3.org>
The minutes from today's telecon are now available.

http://json-ld.org/minutes/2013-03-26/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2013-03-26

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Mar/0055.html
Topics:
   1. Last Call and FCGS for Syntax and Algorithms
   2. ISSUE-217: Disallow BNode identifier as Graph Name
   3. ISSUE-218: Algorithm specification updates by editors
   4. ISSUE-220: Drop empty arrays (sets) and empty lists in
      expansion
   5. Remove re-labeling blank nodes during expansion
   6. ISSUE-232: Replace "optimize" option with "strict" option
   7. Any other issues before Last Call?
Resolutions:
   1. Publish the JSON-LD Syntax and Algorithms specifications as
      Final Community Group Specifications (FCGS) and prep the RDF WG
      Last Call (LC) documents for publication on April 4th 2013.
   2. The term selection algorithm should use the '@null' token
      to specify the null value and the '@none' token to specify the
      none value.
   3. Do not drop empty arrays (sets) and empty lists in
      expansion and compaction.
   4. Remove blank node re-labeling during expansion since it is
      no longer required. The flattening algorithm must still re-label
      blank nodes.
   5. Change 'optimize' flag to be a 'processingMode' option. The
      default value for JSON-LD 1.0 processors is 'json-ld-1.0'.
      Implementers may accept other values, but must ensure that those
      values are not prefixed with the string 'json-ld'. If the
      processingMode is set to 'json-ld-1.0', the outcome must be the
      same as the algorithms.
Action Items:
   1. Respond to David Booth for ISSUE-222.
Chair:
   Manu Sporny
Scribe:
   Gregg Kellogg
Present:
   Gregg Kellogg, Manu Sporny, Dave Longley, Markus Lanthaler,
   Paul Kuykendall, Niklas Lindström, David I. Lehn
Audio:
   http://json-ld.org/minutes/2013-03-26/audio.ogg

Gregg Kellogg is scribing.
Manu Sporny:  final CG specs and LC specs on agenda
   … expansion, compaction algorithms.
   … issue-217 (bnode identifiers)
   … issue-218 (algorithm updates)
   … issue-220 (dropping arrays and lists in expansions)
   … replace optimize option with strict option
Dave Longley:  remove BNode renaming as part of expansion
   algorithm.

Topic: Last Call and FCGS for Syntax and Algorithms

Manu Sporny:  unfortunately, issue queue not empty, so we may
   need to go through another LC.
   … Group feels syntax is ready, but have had no substantial
   feedback on algorithms from the RDF WG. We have substantial
   feedback on algorithms from implementers.
   … That said, we've been feature complete for some time.
   … Any reason not to go to LC?
   … We can tell RDF WG we're not ready, but I think we are
   basically done, and can publish a LC depending on future
   feedback.
   … We need to prep FCGS and LC for the RDF WG. They need to
   give us the pub date.
   … If we do LC spec, pub has to happen Thursday to be out in
   March. That's not realistic.
   … We'll tentatively timestamp for next Thursday, no static
   copies, but the Editor's drafts will be for next thursday, and
   integrate as many comments as we can.
Markus Lanthaler:  do we really need to do another FCGS?
Manu Sporny:  it would be good to do, only 2 non-contributors did
   a IP commitment on the test spec published at end of February.

PROPOSAL: Publish the JSON-LD Syntax and Algorithms
   specifications as Final Community Group Specifications (FCGS) and
   prep the RDF WG Last Call (LC) documents for publication on April
   4th 2013.

Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Dave Longley: +0.5

RESOLUTION: Publish the JSON-LD Syntax and Algorithms
   specifications as Final Community Group Specifications (FCGS) and
   prep the RDF WG Last Call (LC) documents for publication on April
   4th 2013.

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

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/217
Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/222
Markus Lanthaler:  feedback from david, which we never replied
   to, raised it again (222)
   … We discussed and agreed to keep, but just haven't sent out
   email.
Manu Sporny:  I think a took an action to respond, but didn't
Dave Longley:  we decided it would be ideal for the RDF WG to
   resolve this, but we need to go forward with out decisions.

ACTION: Respond to David Booth for ISSUE-222.

Topic: ISSUE-218: Algorithm specification updates by editors

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/218
Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/218#issuecomment-15460023
Markus Lanthaler:  I added a comment to the issue with a list of
   things to be done.
Dave Longley:  I think we need to have more error cases in the
   test suite.
Markus Lanthaler:  in the inverse context, @null is used if it
   has a value of null or not specified.
   … dlongley's uses @none if it's not specified. This is just
   for @language: null.
   … my feeling is that it's difficult to see the difference
   between @none and @null. It does introduce a minor conflation,
   but it doesn't change the outcome (just a little, perhaps).
   … niklasl proposed to change @none to @undefined, or just
   eliminate the difference.
   … In IRI compaction, we create the criteria to query the
   inverse context. Some parts of that are in term selection, but we
   could move to IRI compaction.
   … This just moves 2-3 steps from one altorighm to another.
Manu Sporny:  since this is a documented algorithm (regarding
   @null/@none), it's important that people understand the
   difference between @null and @none, although I like the use of
   @undefined.
Markus Lanthaler:  in JSON-lD @null is the same as @none, except
   if you set @language to null.
   … I find it confusing and I don't think it makes it any
   clearer.
Dave Longley:  I feel that using @none is a more natural way what
   is going on with the model.
   … If we go with @null, it seems more like we're creating two
   separate tables, one where you have entries, and another when
   there is nothing in the reverse context.
Markus Lanthaler: Here's a comment showing the resulting inverse
   context for the two proposals:
   https://github.com/json-ld/json-ld.org/issues/218#issuecomment-14833302
   … I understand the desire to reduce the number of keys, but
   the solution requires more complexity in the algorithm.
Paul Kuykendall: +q
Paul Kuykendall:  I'm not clear on the semantics, but from an
   implementors perspective, as long as their's a significant
   difference in meaning, then we shouldn't overload things. If they
   really have different meanings, then I'm okay with having
   multiple meanings.
Gregg Kellogg:  Don't have a strong preference one way or the
   other. I think having another keyword in there doesn't really
   help. [scribe assist by Manu Sporny]
Gregg Kellogg:  If there is a difference, then we need to
   understand if it's a significant difference. If there isn't a
   significant difference, then we don't need it. [scribe assist by
   Manu Sporny]
Markus Lanthaler:  the difference is if you have a default
   language, and a term which shouldn't use it, you would set it to
   @null.
   … In one case, the entry would be under @null, in the other in
   @none.
   … For @type, if you set it to null, or not at all, it would be
   set to @null. This is why it's specific to @language.
Dave Longley:  I understand that just using @null can work, but
   if there are two terms, it may result in a difference in what
   term is selected.
Markus Lanthaler: So this is one possibility for the two choices:
   @language: @null / @null: @null
Markus Lanthaler: This is the other possibility: @language: @null
   && @language: @none
Dave Longley: I think this makes more sense: term1: {"@language":
   null} and term2: {}
Dave Longley:  pretend they have @iri too.
   … The second case more naturally represents what should be in
   the reverse context. The first is trickier.
Markus Lanthaler:  the downside is you also need to add @type
   @none.
Dave Longley:  If you don't put a container on a term, it's
   saying that there is no container.

PROPOSAL: The term selection algorithm should use the '@null'
   token to specify both the null value and the none value.

Markus Lanthaler: +1
Manu Sporny: -1
Dave Longley: -1
Gregg Kellogg:  +0.5
Paul Kuykendall: 0

PROPOSAL: The term selection algorithm should use the '@null'
   token to specify the null value and the '@none' token to specify
   the none value.

Manu Sporny: +1
Dave Longley: +1
Markus Lanthaler: -1
Gregg Kellogg:  -0.1
Paul Kuykendall: 0
Markus Lanthaler:  my issue is that only @language get's set to
   @none
Dave Longley:  the fact that that case exists is why to separate
   them.

RESOLUTION: The term selection algorithm should use the '@null'
   token to specify the null value and the '@none' token to specify
   the none value.

Manu Sporny:  we should probably also fold list conversion into
   the RDF algorithms.
Gregg Kellogg:  This comes down to a different style - the list
   stuff is different enough that it makes sense to break it out. I
   prefer it the way it is. [scribe assist by Manu Sporny]
Gregg Kellogg:  It's a set of very small algorithms, easier to
   understand. [scribe assist by Manu Sporny]
Manu Sporny:  I agree [scribe assist by Manu Sporny]
Dave Longley:  I feel like it makes it less daunting if it's
   broken up into smaller pieces. [scribe assist by Manu Sporny]
Dave Longley:  I think it's less daunting to keep it as separate
   algorithms.
Manu Sporny:  sounds like we don't want to fold it in.
Dave Longley:  we didn't finish talking about term selection.
   … I'm fine with markus' suggested changes, hopefully it
   doesn't make it too heavy.
Markus Lanthaler:  I don't see a good ready to keep the two steps
   separate, then term selection just loops over the reverse
   context.
Manu Sporny:  sounds like we have agreement.
Manu Sporny:  how does API invoke the algorithms?
   … sounds like a good idea, but if it's non-normative, it
   doesn't matter. Might be too much work.
Markus Lanthaler:  2-3 steps for each algorithm.
Manu Sporny:  perhaps just in the method description for each
   call.
   … that is the sense of the group, but it technically makes it
   normative.
   … Put the explanation in the method description of what
   algorithms are called in what order.
Manu Sporny:  collapse purpose and general method into one
   section?
Markus Lanthaler:  there are some cases where the intro and the
   purpose are exactly the same. Effectively, they're saying the
   same thing. This seems redundant.
Dave Longley:  we might want to just keep purpose and get rid of
   intro, fold intro into purpose.
   … That would be better to just use purpose.
Markus Lanthaler:  it's odd to have two headers.
Gregg Kellogg:  I would prefer to fold everything into the
   introductory paragraph to the section.  [scribe assist by Manu
   Sporny]
Manu Sporny:  I think it would be better to keep purpose as the
   introductory paragraph.
   … Get rid of purpose sections and fold into introductory
   paragraph.
Dave Longley:  we have algorithm terms, which describes what
   things mean. For "active property" the meaning has been
   repurposed to make the algorithm simpler.
   … for example changes that remove validation in compaction.
   active context was repurposed to mean something slightly
   different.
   … This means that "active property" is used for two different
   things.
Manu Sporny:  if it means two different things, we should have
   two different terms.
Markus Lanthaler:  I modified the algorithms a bit. It's true
   that it isn't any more the original lexical form, but in a sense,
   it is still the active property.
   … we use it like a variable in some cases.
Dave Longley:  I think we were a little more strict.
Markus Lanthaler: Current definition of active property: The
   currently active property that the processor should use when
   processing. The active property is represented in the original
   lexical form, which is used for finding type mappings in the
   active context.
   … One reason I rewrote the algorithms was that I kept getting
   confused about the meaning of active property, because the
   meaning was changing.
Markus Lanthaler: maybe we should just drop the second sentence
   … I intentionally made changes to make sure it wasn't
   confusing.
   … I'd at least like us to address the fact that we're
   conflating the meaning of the algorithms.
Markus Lanthaler:  perhaps we can just update the definition and
   remove the second sentence.
   … we mis-use it just for aliases, it's difficult to say
   otherwise.
Dave Longley:  I don't think we should get rid of the 2nd
   sentence, but we should just say that sometimes we re-use the
   active property after it's been resolved.
Manu Sporny:  why not just introduce a new term "resolved active
   property"?
Dave Longley:  because the algorithms are recursive, and
   sometimes it is the active property, and some times it is already
   expanded. I previously add "expanded active property" for this
   case.
Markus Lanthaler:  we could say that if a term is expanded to a
   keyword, then the keyword is added instead of the original
   lexical form.
Dave Longley:  the problem before was that I needed to understand
   the algorithms before I could understand the terms.
   … I don't know what we could say to help explain this.
Markus Lanthaler:  we could say the active property is either
   term or the keyword being processed.
Manu Sporny:  that helps me a bit.
Dave Longley:  that should work. I think that when there was no
   active property, you recursed and added @graph because it worked
   the same way.
Markus Lanthaler:  I think that we use null in that case.

Topic: ISSUE-220: Drop empty arrays (sets) and empty lists in expansion

Markus Lanthaler: active property: The currently active term or
   keyword that the processor should use when processing.
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/220
Markus Lanthaler:  we modified the algorithms to drop
   free-floating values so that you would drop them silently when
   expanding.
   … However, we keep empty arrays and empty sets. I could
   consider dropping them, as they'd be lost in RDF round-tripping.
   … Empty lists are different, as they can be used in RDF.
   … If the property has a value of null, it is dropped, if it as
   an array, it's kept.
   … In our own data model there is no way to represent an empty
   array.
   … it would be consistent to say that empty arrays are dropped,
   but keep lists.
Dave Longley:  in practice, it's either annoying or confusing, or
   both.
   … From a JSON perspective, it means that they need to add
   something to guard against this case. I found it annoying to have
   arrays I was using to go away.
   … null values are different. When you set them up to be
   arrays, we're expecting that they will always be arrays.
Manu Sporny:  I think that that's the strongest argument for not
   removing this kind of data.
   … I think our primary audience is JSON developers, such as
   removing empty arrays, that's a real problem.
   … The RDF developers are capable of writing code to modify
   data, and we should optimize for JSON developers.
Dave Longley:  it's important to note that RDF developers don't
   need to do anything at all.
   … It would only impact JSON developers.
Manu Sporny:  It would be a problem if we needed to update code
   to see if it exists and then if it's empty.
Markus Lanthaler:  it depends on where the data comes from. If
   it's your own data, why would you re-compact? It could also be
   set to null and then it would disapear.
Niklas Lindström:  I'd like to know an example use case. I have a
   hard time deciding on bits and pieces of the scenario.
   … Someone receives expanded JSON-LD and then want's to compact
   it.
Dave Longley:  you build your own data and need to expand it to
   digitally sign it and re-compact it.
   … If someone wants to work against the data after it's been
   re-compact, it's going to be annoying.
Markus Lanthaler:  if you sign it, there is no data.
Markus Lanthaler:  we just recently started to drop free-floating
   values, so this is consistent with that.
Manu Sporny:  this change would negatively affect us. By trying
   to be consistent, we're going to cause headaches for JSON
   developers.
Niklas Lindström:  it does make it more consistent.
Dave Longley:  note that normalization works on a hash of
   N-Quads.
Niklas Lindström:  we preserve index keys in expand/compact.
   These are also just syntactic elements; it's also an argument for
   preserving null values.
Manu Sporny:  if we need to preserve null values, we can put that
   in JSON-LD 1.1
Dave Longley:  we did originally preserve them, but it made sense
   to remove them.

PROPOSAL: Do not drop empty arrays (sets) and empty lists in
   expansion and compaction.

Manu Sporny: (maintain current behavior in JSON-LD 1.0
   Algorithms)
Manu Sporny: +1
Gregg Kellogg: +1
Dave Longley: +1
Niklas Lindström: +0.5
Paul Kuykendall: +1
Dave Longley:  I think they're preserved in flattening.
Markus Lanthaler: +0

RESOLUTION: Do not drop empty arrays (sets) and empty lists in
   expansion and compaction.

Topic: Remove re-labeling blank nodes during expansion

Dave Longley:  after removing property generator support, we
   don't have any reason to relable BNodes during expansion.
   … I support removing it, because it's an unnecessary
   complexity, I don't see a reason to do it.
   … We already do generation during flattening.
Manu Sporny:  I agree. I think the counter argument is to show
   developers that they can't depend on the identifiers. If we
   always relabel, they'll know they can't depend on them.
Gregg Kellogg:  it makes testing difficult [scribe assist by Dave
   Longley]
Gregg Kellogg:  some people do ascribe meaning to their bnode
   labels and as long as their used internally there's nothing wrong
   with that [scribe assist by Dave Longley]
Gregg Kellogg:  i don't think we're being consistent by changing
   them, and in the spirit of not messing with data i think we
   should leave them alone [scribe assist by Dave Longley]
Gregg Kellogg:  with someone who just wants to work within the
   JSON domain there's not a good reason to relabel them here
   [scribe assist by Dave Longley]
Dave Longley:  I think it only happens in expansion. Also be
   explicit that it doesn't change flattening.
   … I'm pretty sure that they way the flattening algorithm is
   written it works. The previous algorithm did.

PROPOSAL: Remove blank node re-labeling during expansion since it
   is no longer required. The flattening algorithm must still
   re-label blank nodes.

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

RESOLUTION: Remove blank node re-labeling during expansion since
   it is no longer required. The flattening algorithm must still
   re-label blank nodes.

Dave Longley:  it happens in node-map generation algorithm.
Dave Longley: "If id is a blank node identifier, replace it with
   a newly generated blank node identifier passing id for
   identifier."

Topic: ISSUE-232: Replace "optimize" option with "strict" option

Dave Longley: from node map generation^
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/232
Markus Lanthaler:  we currently have an optimize option to allow
   JSON-LD processors to do even more work. I think it would make
   sense to generalize the flag further, so that if it is true, it
   must be like the algorithms describe, or have a processing more
   defaulting to "JSON-LD 1.0", so that you could do things that are
   different.
Manu Sporny:  I think the processing mode change is better, and
   we should provide some specific values.
   … Implementors can create their own flags, as long as they're
   not prefixed with "JSON-LD"
Markus Lanthaler:  hat's what I wrote.
Paul Kuykendall:  I'm general in favor, but I"m concerned about
   fragmentation.
   … if it's too wide open, then it doesn't do anything that can
   be counted on.
Markus Lanthaler:  nothing we can really do with that anyway.
Dave Longley:  better to give some direction on how to extend
   then nothing at all.
Manu Sporny:  historically, this hasn't lead to horrible
   divergence.
Markus Lanthaler:  we could add something to conformance section.
Markus Lanthaler: json-ld-1.0

PROPOSAL: Change 'optimize' flag to be a 'processingMode' option.
   The default value for JSON-LD 1.0 processors is 'json-ld-1.0'.
   Implementers may accept other values, but must ensure that those
   values are not prefixed with the string 'json-ld'.

Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Paul Kuykendall: +1
David I. Lehn: +0
Markus Lanthaler:  if mode is set to json-ld-1.0, the output MUST
   be the same.
Manu Sporny: Minor addition: If the processingMode is set to
   'json-ld-1.0', the outcome MUST be the same as the algorithms.
Manu Sporny: No objections by the group to the addition.

RESOLUTION: Change 'optimize' flag to be a 'processingMode'
   option. The default value for JSON-LD 1.0 processors is
   'json-ld-1.0'. Implementers may accept other values, but must
   ensure that those values are not prefixed with the string
   'json-ld'. If the processingMode is set to 'json-ld-1.0', the
   outcome must be the same as the algorithms.

Topic: Any other issues before Last Call?

Manu Sporny: Scanning through -

https://github.com/json-ld/json-ld.org/issues?milestone=2&page=1&state=open
   - looks good, we've covered all of them
Manu Sporny: Scanning through

https://github.com/json-ld/json-ld.org/issues?milestone=1&page=1&state=open
   ...
Manu Sporny:  on use of base vs @base, we should specify both
   modes and describe as at risk.
Markus Lanthaler:  the section is already marked at risk.
Manu Sporny:  even though we marked @base as at risk, doesn't
   mean that passing an option through the API is the same thing.
   … If we don't mention anything about it in the spec, that
   could easily force us to a second LC.
   … We should mark this as at risk in the spec.
Markus Lanthaler:  the whole @base is marked as at risk, but we
   never say how "" is treated, as we didn't agree.
Manu Sporny:  that is what needs to go in the spec as at risk.
Dave Longley:  do we need to mention in the API spec what happens
   when @base is null?
   … We should mention there as well that it's being debated.
Markus Lanthaler:  we discussed clarifying @graph as being the
   default graph, but that's editorial.
Manu Sporny:  four docs to prep: two JSON-LD 1.0 and API FCGS
   static version.
   … The other two are the latest specs for the RDF WG LC
   version.
   … We need to do this before the call tomorrow, so that they
   can reference the document.
   … We can always update the static spec in place.
   … Timestamp should be for 2013-04-04
   … They'll need to copy the docs into place.
   … We'll need another pass next week to be sure they pass
   pub-rules.
   … We'll make a new set of specs and a new call for
   commitments.
   … The previous messages were really just W3C tests.

-- 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, 26 March 2013 16:39:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:21 UTC