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
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.
… 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.
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
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.