- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 26 Mar 2013 12:39:10 -0400
- 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