Manu Sporny: on the agenda today we have going over sandro's syntax feedback, the @vocab precedence issue, sandro's api spec review, zhu's review, roundtripping concerns

Manu Sporny: any changes?

Niklas Lindström: let's do the @vocab issue first, not sure if it's feasible to consider, we cannot change the syntax i believe, but we say that a "term has a type of @vocab" (because @id doesn't support terms as values), i was wondering if we could consider using type: "@context" instead

Manu Sporny: we should discuss it

Manu Sporny: http://blog.meritora.com/launch/

Manu Sporny: our company launched Meritora, which is built on top of JSON-LD

Manu Sporny: the whole protocol is powered by JSON-LD, real money is flowing through Meritora, so hopefully JSON-LD is well-designed where it matters!

Niklas Lindström: btw, i'm now an employee of the national library of sweden so i'm representing them, not just myself

Manu Sporny: you'll want to change your status in the CG, btw.

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/235

Niklas Lindström: basically, the fact that, when compacting, even if a @vocab is defined in the context, if there is a prefix defined with the same value, the prefix will take precedence over @vocab

Niklas Lindström: if you, for instance, inherit a context with that prefix defined, even if you set @vocab, you won't get vocab terms when compacting

Niklas Lindström: i think that other serializations work differently (@vocab having precedence instead)

Niklas Lindström: i think that compaction should make things as small as possible, using @vocab over CURIEs does that

Niklas Lindström: i think it would be sometimes unexpected if the behavior is to give precedence to CURIEs over @vocab, if you have a lot of prefixes defined w/various dependencies you might get undesirable compaction results

Niklas Lindström: if the precedence order went the other way, it wouldn't be so bad

Dave Longley: I tried to break out some of the reasons in the issue tracker, the issue that is going to be the strangest is when you have prefixes in a previous chained context. [scribe assist by Manu Sporny]

Dave Longley: That might be an issue - @vocab trumps everything. [scribe assist by Manu Sporny]

Dave Longley: So, this is a question of what we think the default case is... if you are using @vocab to catch terms that aren't there, then it's going to override too many of the prefixes that are defined. [scribe assist by Manu Sporny]

Dave Longley: If you want CURIEs in the output, you probably don't use @vocab. [scribe assist by Manu Sporny]

Dave Longley: If you want to use @vocab in compaction, and you don't want CURIEs in the output, it's been suggested by niklas, and I think he's right, that you're much more likely to have used prefixes in the context, not the data. [scribe assist by Manu Sporny]

Dave Longley: It's going to be a lot more complicated to get the output you want, you have to undefine all the prefixes, that's not good for developers. [scribe assist by Manu Sporny]

Dave Longley: As far as I can tell, that is going to be the more common case, and we should probably support it (unless there is a reason that someone can see why we should prefer CUREs over @vocab) [scribe assist by Manu Sporny]

Gregg Kellogg: i can easily imagine a number of cases where you get an initial context that does define schema as a prefix but the document does say @vocab is schema

Gregg Kellogg: i can see how you'd end up in precisely this case here so preferring @vocab makes sense

Gregg Kellogg: if a CURIE is more like a term then we have to continue to use that (it's defined explicitly on the LHS w/types and containers on the right)

Gregg Kellogg: that's more like using a term in that case

Dave Longley: i agree, it's a term at that point

Niklas Lindström: yes, i don't think this change would affect that

Manu Sporny: do you disagree with changing this?

Markus Lanthaler: no, i tried implementing it and it was easy

Markus Lanthaler: as long as it's just for compaction

Niklas Lindström: if someone changed expansion that would be bad

Niklas Lindström: +1

Dave Longley: +1

Manu Sporny: +1

Gregg Kellogg: +1

Paul Kuykendall: +1

Markus Lanthaler: +1

Niklas Lindström: .. "category": "Film"

Niklas Lindström: .. "category": {"@type": "@vocab"}

Niklas Lindström: right now, if the content in your document, you want to have a syntax expression like what's in IRC, and the value there is a term which is defined either, you want it to be looked up in the context, either you will find a defined term for it and expand it, or you want to resolve it against @vocab

Niklas Lindström: .. "category": {"@type": "@context"}

Niklas Lindström: a recent addition was to use "@type": "@vocab"

Niklas Lindström: given that it only resolves against @vocab in one of the cases (it can use terms otherwise)

Manu Sporny: i don't think that @vocab is idea, but i also don't think @context is better

Niklas Lindström: .. "category": {"@type": "@symbol"}

Manu Sporny: but adding another keyword fights against our desire to keep the number of keywords limited

Gregg Kellogg: i think they are both unfortunate, but it's one minute to midnight w/the spec, so we need to raise the bar with making changes

Dave Longley: I think part of the confusion is that the meaning of @vocab is being overloaded. I think that looking at @context would be more confusing. [scribe assist by Manu Sporny]

Dave Longley: One way to look at @type: @vocab is to think "Oh, the type of the term is also a vocabulary term" [scribe assist by Manu Sporny]

Dave Longley: The type of data that goes with this term is a 'vocabulary thing' - which means anything in the @context. [scribe assist by Manu Sporny]

Dave Longley: if we had @context there, I'd be more confused - I would expect a context to be there. [scribe assist by Manu Sporny]

Markus Lanthaler: i agree with dave on this

Niklas Lindström: i thought about this, if we see @context there we get confused

Niklas Lindström: when i did the explanation to myself, i reasoned like dave, like dave said, the value is looked up in the @context, and i said, in my head, @context more than @vocab, so i thought maybe it would better explain it

Dave Longley: We're either going to overload what @type means, or we're going to overload the value of @type to get the explanation right. We already overload @type for datatype and regular type. [scribe assist by Manu Sporny]

Niklas Lindström: Yeah, maybe we need to document this clearly... [scribe assist by Manu Sporny]

Dave Longley: Yes, explaining that @vocab has a different meaning is probably easier to explain than putting @context there and explain it. [scribe assist by Manu Sporny]

Paul Kuykendall: i just wanted to chime in, i'm more of an outsider so maybe i can help

Paul Kuykendall: i do think that @vocab is easier to understand, just from listening to the discussions

Paul Kuykendall: using JSON-LD you're already used to a little bit of overloading

Niklas Lindström: ok, that's what i needed to hear, i withdraw any proposal here

Manu Sporny: yes that was helpful, thank you, paul

Manu Sporny: ok, then no change, let's just close the issue

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/224

Manu Sporny: sandro had even more feedback for markus, can we get through this quickly, is there much to be dealt with, it seemed like you mostly had it under control

Markus Lanthaler: not really much to discuss, the most critical thing is whether we normatively reference RDF-CONCEPTS and RDF-SCHEMA

Markus Lanthaler: we'll be discussing that tomorrow in the RDF WG too

Markus Lanthaler: sandro is happy with the other changes i made

Markus Lanthaler: the only thing left is data roundtripping issues

Manu Sporny: ok, that's good, let's focus on just the syntax spec

Manu Sporny: it looks like it was mostly editorial

Markus Lanthaler: i'll double check that... yeah, it was just mostly editorial

Markus Lanthaler: i'll send an email to sandro later to ensure everything has been addressed

Gregg Kellogg: there are some check boxes to check in the issue tracker

Markus Lanthaler: those are some things that i think we shouldn't change, which i explained in emails, i just need sandro's feedback on us not changing it.

Markus Lanthaler: i think there's no change required for those things

Paul Kuykendall: the only ones that i see that might be of interest is where the overloading of @vocab is mentioned as confusing/silly

Markus Lanthaler: yeah, that's one we already discussed in the past

Paul Kuykendall: yeah, just want to make sure we're in agreement there

Manu Sporny: yes, i think we're sure about the keywords and the meaning we overload and we made tradeoffs to do that

Manu Sporny: and it isn't perfect but we aren't going to change it without some really good feedback/lots of people making big mistakes with it for us to change it

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/234

Markus Lanthaler: mostly editorial, sandro didn't review the algorithms himself, but had a number of other comments, which i already addressed, and sandro agrees we can close the issue

Markus Lanthaler: the only thing remaining is data roundtripping which i split out into a separate issue so we can better focus

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/236

Manu Sporny: zhu basically didn't review the algorithms either because he found them too complicated to read through

Manu Sporny: he asked us to reorganize the document fairly heavily

Manu Sporny: but i think it's a bad idea, but we'll see what the group thinks

Manu Sporny: i think it would take a lot of time but not buy us much, we attempted to do what he wanted earlier

Manu Sporny: we are where we are now with the spec because that previous attempt didn't work as well, we made changes that we thought made it easier to read the spec today than that alternative approach

Markus Lanthaler: he didn't say that the algorithms were too complex, that they were instead too long

Manu Sporny: well, we're doing that for a reason, we want to be very explicit about what happens

Paul Kuykendall: the comments i've gotten from my colleague who has been implementing the various algorithms, starting before the algorithm split, he said the new ones are much easier to follow and easier to understand what's going on

Gregg Kellogg: there's a certain stylistic issue with what you see in programming (eg: taking large algorithms and breaking them into smaller sections so that each sub step fits on a screen)

Gregg Kellogg: i took some of zhu's comments in that light, and some of the algorithms would perhaps be more useful if they were broken out into smaller subsections

Gregg Kellogg: i take markus' point that it might be difficult with going back and forth (jumping around) to figure out what's going on then

Gregg Kellogg: i'll use the same razor i did before though, we're getting close to the end, i don't think we need to change this, it's stylistic change, that is left to the purview of the editors, we should leave it alone

Manu Sporny: i agree, the rest seemed like editorial changes, is that true?

Markus Lanthaler: yes, i got back to him, he didn't get back to me yet to let me know if the changes were enough or if he really really wanted the algorithms split up

Paul Kuykendall: i do agree that shorter algorithms are easier to read, but you don't want to lose the context of where you are and how the algorithms work, i think we struck a good balance where we mostly broke the algorithms into sub parts where they could be reused, and implementations might break them up more, but that's an implementation detail, not for the algorithms

Markus Lanthaler: he also raised the point that he would prefer numbers for errors not strings

Dave Longley: I don't think we need to convert the string values to numbers, we're not programming on a Commodore 64 - we have much more modern programming environments available to us [scribe assist by Manu Sporny]

Paul Kuykendall: string processing does suck in some languages, but what we've done internally is use numbers

Gregg Kellogg: i don't think the purpose of the spec is to explain how to implement this in every way

Manu Sporny: ISSUE-237: Sandro's Data Round Tripping Concerns

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/237

Markus Lanthaler: he doesn't understand most of this section

Markus Lanthaler: if we keep this section, why don't we only convert canonical lexical form values to native types, leaving the rest alone

Markus Lanthaler: the other thing we didn't discuss here, is the potential precision loss you experience when converting to JSON-numbers

Markus Lanthaler: so i think the question here is whether we keep the requirement that implementations must use canonical lexical form

Markus Lanthaler: and if we do keep it, if we only convert to native types when the values are in canonical lexical form

Manu Sporny: so the reason that we say this sort of thing in the spec, is because if we don't say anything about it, people will be surprised when their numbers start having rounding errors ... they take their space probe and crash it into mars because they weren't expecting the behavior

Manu Sporny: we also want to be very clear about what they do with those numbers to round trip

Dave Longley: testing becomes far more difficult if we dont' specify this

Markus Lanthaler: well, rounding errors dont' have to do with canonical lexical form

Dave Longley: but testing does

Manu Sporny: it seems like an interoperability issue if we don't specify this

Manu Sporny: if we specify it, it's very clear how to interoperate

Gregg Kellogg: i guess the alternative would be to defer to XSD where possible for the definition of canonical lexical form

Markus Lanthaler: sandro's response to my argumente "we do it to simplify testing" was "I don't think simplifying testing merits a MUST..... Or, if it does, then say that, instead of saying it's because of round-tripping...."

Gregg Kellogg: or at least to say "this is the same as" or "as defined by"

Markus Lanthaler: i think he's saying it might be enough to say something is a certain type (xsd:integer/xsd:double)

Markus Lanthaler: and not care about the lexical value

Dave Longley: There was a specification where something was specified in canonical lexical form, we changed it from it originally was a lowercase 'e', to what it is now, based on some specification. Maybe we should've been referencing that specification. [scribe assist by Manu Sporny]

Markus Lanthaler: there are differences between what languages/JSON serializers and 'e'/'E' for canonical representation

Gregg Kellogg: i do recall that we eliminated some rounding issues w/ruby w/decimal precision length

Markus Lanthaler: i think that string format we used previously also ensured that something was 64-bit for JSON which doesn't define the value space

Markus Lanthaler: That was the issue about precision https://github.com/json-ld/json-ld.org/issues/81

Manu Sporny: we should reference the XSD spec to be very clear about this or reference which spec we based this off of

Paul Kuykendall: i'm looking at the xml-schema second edition under data types and it does define quite a bit there

Markus Lanthaler: Here's our current data round tripping section: http://json-ld.org/spec/latest/json-ld-api/#data-round-tripping

Paul Kuykendall: someone should look there

Manu Sporny: the spec was xml-schema part 2 data types

Manu Sporny: let's make sure it matches what we have in the spec and let's just refer to the spec

Manu Sporny: instead of paraphrasing

Gregg Kellogg: [XMLSCHEMA11-2]

Manu Sporny: but we still make very clear what the canonical lexical form is

Gregg Kellogg: yes, RDF-CONCEPTS references this and we should sync up

Markus Lanthaler: do we require canonical lexical form then?

Gregg Kellogg: we shouldn't restrict the input

Gregg Kellogg: but we should be able to transform into that form to allow for lexical comparison

Gregg Kellogg: in my serializers i have an option for canonicalization, but if that were always supplied i would fail some specs

Gregg Kellogg: JSON of course has its own restrictions when dealing with numbres because it's a native restriction, not a strictly lexical representation

Gregg Kellogg: you can't ensure that the input looks exactly the same as the output

Paul Kuykendall: are we talking about maintaining the mapping between JSON native types and xsd types?

Dave Longley: To be clear, we're not talking about changing the mapping - for a number in JSON, it's either going to be an xsd:integer or an xsd:double. We should tell implementations what these lexical forms should look like if you convert the number to a string. [scribe assist by Manu Sporny]

Markus Lanthaler: all these are valid 1.4 = 14E-1 = 14e-1.. but there's only one canonical lexical form: 1.4E0

Paul Kuykendall: i just wanted to make clear that we weren't changing the mappings here, it sounds good to me that we're just talking about mapping things to an external spec

Manu Sporny: it's really important that we have the flag in the algorithm for converting/not converting to native types

Markus Lanthaler: we aren't defining an API so we don't need to define the flag because there's no operation there

Dave Longley: All we have to do is revert a change we made - if a flag is set, change to native types, if it is not set, don't change to native types. [scribe assist by Manu Sporny]

Manu Sporny: so i think we have one solid proposal then

Manu Sporny: to put the flag for convert to/from native types when doing RDF conversion back into the algorithm

Markus Lanthaler: and deciding if we should require canonical lexical form

Niklas Lindström: i think the rdf type flag is important because it's just a relation like anything else

Niklas Lindström: i'm a bit wary about removing that flag

Gregg Kellogg: as i recall the reason we had it was so that we could do other mapping during compaction/expansion

Gregg Kellogg: there's nothing to prevent you from navigating

Gregg Kellogg: http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/

Gregg Kellogg: https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-Graph-Literal

Markus Lanthaler: http://www.w3.org/TR/rdf11-concepts/#dfn-lexical-to-value-mapping

Manu Sporny: the only way to compare literals in the abstract model is to jump into lexical space to do the comparison, if we don't specify the lexical form for this data, you can't do a comparision, we don't have interoperability

Markus Lanthaler: i don't think we need to be specifying this, it should be in an RDF spec

Gregg Kellogg: we're dealing with native representations so we are losing the lexical form, so we need to be able to convert back

Manu Sporny: if we take a position in this group we can take that position to the group, instead of not taking one and making it an open-ended discussion

Markus Lanthaler: the whole reason we're having this discussion is because sandro, from the RDF WG, has an issue with it

Manu Sporny: +1

Paul Kuykendall: +1

Dave Longley: +1

Gregg Kellogg: +1

Markus Lanthaler: +0

Niklas Lindström: +1

David I. Lehn: +0

Gregg Kellogg: the last issue we can talk about is changing the RDF-CONCEPTS reference to be normative

Gregg Kellogg: David Wood said that if we don't normatively reference our own documents (this is a RDF WG doc) that's a problem

Manu Sporny: why don't we reference other W3C documents

Manu Sporny: normatively

Gregg Kellogg: JSON-LD is an RDF serialization format, so every other RDF serialization format has a normative reference to RDF-CONCEPTS

Gregg Kellogg: it's not clear that we're being an RDF syntax if we don't normatively reference RDF-CONCEPTS