- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 04 Apr 2013 10:07:58 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
Thanks to Dave Longley for scribing! The minutes from Tuesday's telecon
are now available.
http://json-ld.org/minutes/2013-04-02/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2013-04-02
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2013Apr/0000.html
Topics:
1. Web Payments Launch (PaySwarm / Meritora)
2. ISSUE-235: Let @vocab take precedence over compact IRIs in
compaction
3. Rename '@type': '@vocab' to '@type': '@context'
4. ISSUE-224: Sandro Hawke's Feedback
5. ISSUE-234: Sandro Hawke's JSON-LD API spec review
6. ISSUE-236: Zhe Wu's JSON-LD API spec review
Resolutions:
1. When compacting IRIs @vocab should take precedence over
Compact IRIs. This reverses the previous order of precedence.
2. Specify what canonical lexical form is for xsd:integer and
xsd:double by referencing the XML Schema 1.1 Datatypes
specification. When processors are generating output, they are
required to use this form.
Chair:
Manu Sporny
Scribe:
Dave Longley
Present:
Dave Longley, Manu Sporny, Niklas Lindström, Gregg Kellogg,
Markus Lanthaler, Paul Kuykendall, David I. Lehn
Audio:
http://json-ld.org/minutes/2013-04-02/audio.ogg
Dave Longley is scribing.
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
Topic: Web Payments Launch (PaySwarm / Meritora)
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.
Topic: ISSUE-235: Let @vocab take precedence over compact IRIs in compaction
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
Error: (IRC nickname not recognized)[Tue 10:10] <trj> Hi, does
anyone know of any examples of JSON-LD being used with IoT
sensors? Perhaps with http://purl.oclc.org/NET/ssnx/ssn
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
PROPOSAL: When compacting IRIs @vocab should take precedence over
Compact IRIs. This reverses the previous order of precedence.
Niklas Lindström: +1
Dave Longley: +1
Manu Sporny: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Markus Lanthaler: +1
RESOLUTION: When compacting IRIs @vocab should take precedence
over Compact IRIs. This reverses the previous order of
precedence.
Topic: Rename '@type': '@vocab' to '@type': '@context'
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
Topic: ISSUE-224: Sandro Hawke's Feedback
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
Topic: ISSUE-234: Sandro Hawke's JSON-LD API spec review
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
Topic: ISSUE-236: Zhe Wu's JSON-LD API spec review
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
(missed scribing a bit here)
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]
(more missed scribing)
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/
Discussion about whether the exact lexical form for literals in
RDF (converted from JSON-LD) must be specified at all)
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
Discussion about deferring the current issue to the RDF WG
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
PROPOSAL: Specify what canonical lexical form is for xsd:integer
and xsd:double by referencing the XML Schema 1.1 Datatypes
specification. When processors are generating output, they are
required to use this form.
Manu Sporny: +1
Paul Kuykendall: +1
Dave Longley: +1
Gregg Kellogg: +1
Markus Lanthaler: +0
Niklas Lindström: +1
David I. Lehn: +0
RESOLUTION: Specify what canonical lexical form is for
xsd:integer and xsd:double by referencing the XML Schema 1.1
Datatypes specification. When processors are generating output,
they are required to use this form.
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
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/
Received on Thursday, 4 April 2013 14:08:24 UTC