Thanks to Markus for scribing for 2 hours straight! Hopefully we won't
have too many more of these. The minutes from today's telecon are now
available.
http://json-ld.org/minutes/2013-02-12/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2013-02-12
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2013Feb/0030.html
Topics:
1. Choosing the Algorithms Specification
2. ISSUE-213: Vulnerability when loading HTTP-based JSON-LD
Contexts
3. ISSUE-204: Design Issue with Relative IRIs and compaction
Resolutions:
1. Base future JSON-LD Algorithms 1.0 specification work on
Dave Longley's alternate2.html specification, keeping in mind
that the group is not suggesting that all algorithms are
finalized. Algorithms will need to be clarified further after the
base document is picked.
2. Add a JsonLdUrlDereferencer option to the JSON-LD API
calls. It can be a function that takes a URL and a callback, and
calls the callback with an error or the result of dereferencing
that URL. If the option is provided, then the implementation MUST
use it to dereference remote contexts.
3. If "@type": "@vocab" is specified for a term in the active
context, then processing for the value associated with the term
attempts to resolve it as an IRI - first processing it as a term,
then a CURIE, then an absolute IRI, then against the active
@vocab (if present), then a document-relative IRI.
4. The value space for terms tagged with "@type": "@id" is
compact IRI, absolute IRI, relative IRI, the value space for
"@type": "@vocab" is term, compact IRI, absolute IRI, @vocab,
relative IRI.
5. Within a term definition in the JSON-LD context,
document-relative IRIs are not supported.
Chair:
Manu Sporny
Scribe:
Markus Lanthaler
Present:
Nicholas Car, Manu Sporny, Dave Longley, Markus Lanthaler,
Gregg Kellogg, Niklas Lindström, François Daoust, David I. Lehn
Audio:
http://json-ld.org/minutes/2013-02-12/audio.ogg
Nicholas Car: Hi, I am a researcher at Australia's CSIRO (Nat.
Research Dept.)... calling in now.
Manu Sporny: Any changes to agenda? [scribe assist by Manu
Sporny]
Dave Longley: Move ISSUE-217 to the end, so we can get to the
other items. [scribe assist by Manu Sporny]
Markus Lanthaler is scribing.
Topic: Choosing the Algorithms Specification
Manu Sporny:
http://json-ld.org/spec/latest/json-ld-api/index.html
Manu Sporny:
http://json-ld.org/spec/latest/json-ld-api/alternate.html
Manu Sporny:
http://json-ld.org/spec/latest/json-ld-api/alternate2.html
Manu Sporny: markus went through the algorithms and did a very
thorough review
... most of the comments weren't fundamental issue
Manu Sporny:
http://lists.w3.org/Archives/Public/public-linked-json/2013Feb/0027.html
... the are a couple of comments that popped out as potential
issues
Markus Lanthaler: I haven't been able to look at the changes
that Dave Longley has made based on my comments. [scribe assist
by Manu Sporny]
Markus Lanthaler: Dave's algorithms are more or less the same
than I had in index.html, but overall, they're more or less the
same. He uses an inverse context, looks like the one I wrote.
Expansion looks fundamentally the same. [scribe assist by Manu
Sporny]
Markus Lanthaler: Algorithms were moved around a bit, one
algorithm got split (term definition / creation) from context
processing, which I'm not sure if it makes sense. Gregg seemed to
like it, so I'm fine w/ it. Personal preference, don't like
jumping between algorithms. [scribe assist by Manu Sporny]
Markus Lanthaler: I found a few bugs w/ the algorithms, Dave has
already fixed some of them. All of the bugs had to do w/ property
generators and how they are processed. I think Dave tried to
optimize some of the algorithms, but the optimizations didn't
bring any advantage, they complicated the description, some bugs
were introduced. [scribe assist by Manu Sporny]
Markus Lanthaler: So, some issues with property generator
algorithms - if we want to keep the re-organization, then we need
to decide. The algorithms are split out, moved around. It would
make sense to keep things in that the same as before, would be my
preference. [scribe assist by Manu Sporny]
Markus Lanthaler: Expansion is okay. Compaction, we might want
to have a closer look. [scribe assist by Manu Sporny]
Markus Lanthaler: Flattening, node generation not changed so
far... so good. [scribe assist by Manu Sporny]
Manu Sporny: Do you have a preference on which algorithms we
should use? [scribe assist by Manu Sporny]
Markus Lanthaler: For expansion - we should pick Dave's. For
compaction, we should pick mine. We need error code language,
that's missing from Dave's spec, we have to agree on some
language. [scribe assist by Manu Sporny]
Gregg Kellogg: I'm not entirely happy with splitting out the
remote context processing
Gregg Kellogg: I've started to go through and do some
implementation. My comments are mostly focused on the evaluation
context at this point. I found the eval context processing pretty
logical. Not entirely comfortable with splitting out remote
context processing since Ruby is not an asynchronous
implementation. [scribe assist by Manu Sporny]
... I would prefer to process it inline
... I think it was a premature optimization
... I prefer to keep context processing, IRI
expansion/compaction etc. closely together
... there was a small comment that in some cases when you
expand relative IRIs it might be in a remote context
... markus had a comment doing the shorter bits at the top of
the algorithm instead of at the very end where it might get lost
... compaction: I found it easier to following the description
dave was using for processing the inverse context
Manu Sporny: do you have a preference which spec text to take
Gregg Kellogg: my version was a try to do minimal changes.. I
don't think that's going to happen.. the preference goes to using
an inv. context
... I have to note that I have something similar than a
inverse context
... but typically being too specific inhibits implementers
creating differing implementations
... especially the naming of bnodes in the test suite might be
problematic if you do things in different order (parallel)
Dave Longley: markus haven't seem my updates yet but I fixed
most of the problems already
... so prop. generator stuff works now
... another problem was inheriting term definitions. I think
what my new algorithm does is probably wrong
... markus had a test case choosing a term with a
null-language
... question is whether choose the term with null-language or
no language at all
... for numbers
... I think we need a quick discussion what should really
happen
Gregg Kellogg: If it was a string I think you would want the
null-language term
... I would go for the easier algorithm
Niklas Lindström: .. I consider 12.3 to be (syntactically)
equivalent to {"@type": "xsd:double", "@value": "12.3"}
Manu Sporny: we use strings to represent very small numbers
... we don't want to have them to be language-tagged using the
default language
Dave Longley:
https://github.com/json-ld/json-ld.org/blob/master/test-suite/tests/compact-0048-in.jsonld
Dave Longley:
https://github.com/json-ld/json-ld.org/blob/master/test-suite/tests/compact-0048-out.jsonld
... question is, should propertyNoLang or propertyLanguageNull
be choosen?
Markus Lanthaler: quick question, if propertyLanguageNull
wouldn't be there you would keep the complete IRI
Dave Longley: yes
Niklas Lindström: I think I would choose propertyLanguageNull
because it's most specific, then fall back to propertyNoLang
Markus Lanthaler: I would be fine with that
Gregg Kellogg: yeah
Manu Sporny: ok, lets do that
Dave Longley: markus and gregg said we should highlight the
removal of the context in expansion and not switching between
contexts
Manu Sporny: Just to be clear - @language in the @context only
applies to strings. For TC0048 output should pick the /more
specific/ term definition 'propertyLanguageNull'.
... I think switching between contexts is the most common use
case
Gregg Kellogg: expansions use is not just compaction.. you also
need to expand when converting to RDF
Dave Longley: I think we can re-purpose expansion for RDF
because RDF has no context
... I think it's confusing to say expansion just eliminates
the context without saying why
Markus Lanthaler: Is it really simpler to switch between
contexts than to say that the context is removed? [scribe assist
by Manu Sporny]
Markus Lanthaler: When compacting, I apply a context to compact
it again. [scribe assist by Manu Sporny]
Dave Longley: maybe a better way to reorganize it would be to
add a section before expansion/compaction and describe it there
... and then just say expansion eliminates context, compaction
adds one
Manu Sporny: does anyone thinks there are some fundamental
problems in any of the current spec versions?
Dave Longley: I don't think so
... my preference would be to use alternate2 but pull in a bit
more from what markus had
... we should also pull error constant
... we could also reorder some stuff
Gregg Kellogg: I think I support alternate2 as well
... I found the structure more accessible and especially the
inverse context algorithm easier to understand
PROPOSAL: Base future JSON-LD Algorithms 1.0 specification work
on Dave Longley's alternate2.html specification, keeping in mind
that the group is not suggesting that all algorithms are
finalized. Algorithms will need to be clarified further after the
base document is picked.
Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
François Daoust: +1
Markus Lanthaler: +0.5
Niklas Lindström: +1 (given my current partial knowledge, but I
like the direction)
RESOLUTION: Base future JSON-LD Algorithms 1.0 specification work
on Dave Longley's alternate2.html specification, keeping in mind
that the group is not suggesting that all algorithms are
finalized. Algorithms will need to be clarified further after the
base document is picked.
Topic: ISSUE-213: Vulnerability when loading HTTP-based JSON-LD Contexts
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/213
Manu Sporny: we found a security vuln. in payswarm that you
could reverse a transaction if a remote context was manipulated
... dns poisoning is the main problem
... proposal is to require remote context over https
... or to let the API define a hook which is then used to load
remote contexts
Dave Longley: my implementation does that
Gregg Kellogg: I would be reluctant to require HTTPs
PROPOSAL: Add a JsonLdUrlDereferencer option to the JSON-LD API
calls. It can be a function that takes a URL and a callback, and
calls the callback with an error or the result of dereferencing
that URL. If the option is provided, then the implementation MUST
use it to dereference remote contexts.
Manu Sporny: +1
Gregg Kellogg: +1
Dave Longley: +1
Markus Lanthaler: +0.1
Niklas Lindström: +0.75
François Daoust: +0.1 (same arguments as Markus)
RESOLUTION: Add a JsonLdUrlDereferencer option to the JSON-LD API
calls. It can be a function that takes a URL and a callback, and
calls the callback with an error or the result of dereferencing
that URL. If the option is provided, then the implementation MUST
use it to dereference remote contexts.
Topic: ISSUE-204: Design Issue with Relative IRIs and compaction
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/204
Manu Sporny: The issue is that it requires us to use CURIEs at
the RHS instead of terms
Manu Sporny: here are the options we discussed last time: 1)
skips terms when doing the IRI compaction or 2) appends ./ to the
name if it is an HTTP IRI or 3) exposes the risk that you may
accidentally compact down to a term. [scribe assist by Manu
Sporny]
Niklas Lindström: there 2 options
... if you use relative IRIs you should use ./
... when we auto-generate relative IRIs
... the danger is that people might use relative IRIs without
"./" and their relative IRIs clash with a term
... e.g. "license": "licence".. would end up being a property
linking to itself
... altough we don't like adding new keywords (and we had
feature-freeze).. we might should add a keyword @url for
type-coercions
... just uses relative/absolute IRIs
Manu Sporny: I don't understand why we need @url if we use "./"
Niklas Lindström: we don't need it.. but it would make it
simpler for people to express their intent
Markus Lanthaler: If we are going to allow terms as values in
@id, does it imply that @vocab is effective in @id? [scribe
assist by Manu Sporny]
Markus Lanthaler: If we do that, then IRIs would be handled the
same everywhere, which would be good. [scribe assist by Manu
Sporny]
Dave Longley: Let's just use @vocab on the right, in @type and
@id, and make it consistent everywhere. [scribe assist by Manu
Sporny]
Gregg Kellogg: in RDFa we have different rules for subjects,
properties, objects
... perhaps that doesn't make sense for JSON-LD
... but "./" just makes sense for hierarchical IRIs.. what
about all other cases?
Markus Lanthaler: Maybe there is an argument here for just
having relative and absolute IRIs in @id and @type... why is
@type different? [scribe assist by Manu Sporny]
Gregg Kellogg: there are 4 cases in RDF where IRIs are used:
subj, pred, obj, data type
... pred and data type it makes sense to be vocab relative,
subj, obj should be document relative
Manu Sporny: that makes sense
... so @id wouldn't be vocab-relative
Manu Sporny: "foo": "PurchaseRequest"
... is the vocab. every gonna be used to expand something on
the right hand side of a statement
... "@type": "PurchaseRequest"
Dave Longley: we could do something like @type: @vocab
Niklas Lindström: .. I still wonder if @type: @symbol wouldn't be
more useful
Niklas Lindström: .. we need a keyword which says "expand terms
and curies, or resolve against @vocab"
Dave Longley: @enum
Niklas Lindström: .. "license": {"@type": "@id"}
Markus Lanthaler: The minimal change we could make is to keep
everything as it is currently, plus terms, but compact them to
relative IRIs if they don't collide with a term. If it collides
with a term, we just keep the full IRI. [scribe assist by Manu
Sporny]
... what happens with this? "foo": "not-defined"
... discussing @type: @vocab
Markus Lanthaler: we should also probably just allow absolute
iris in context
Dave Longley: @enum is an alternative, but a new keyword.
... proposal is to just allow absolute IRIs in the context, we
introduce @type: @vocab, which would interpret values just as
values of @type are currently processed
Manu Sporny: If "@type": "@vocab" is specified for a term in the
active context, then processing for @id attempts to resolve as a
term first, then a CURIE, then an absolute IRI, then a
document-relative IRI. [scribe assist by Manu Sporny]
Gregg Kellogg: "term: {"@id": "…", "@type": "@vocab"}
Gregg Kellogg: we could require @vocab to be defined in that
case
Manu Sporny: If "@type": "@vocab" is specified for a term in the
active context, then processing for the value associated with the
term attempts to resolve it as an IRI - first processing it as a
term, then a CURIE, then an absolute IRI, then against the active
@vocab (if present), then a document-relative IRI. [scribe assist
by Manu Sporny]
Niklas Lindström: not necessarily, you might just wanna use
terms defined in the context
PROPOSAL: If "@type": "@vocab" is specified for a term in the
active context, then processing for the value associated with the
term attempts to resolve it as an IRI - first processing it as a
term, then a CURIE, then an absolute IRI, then against the active
@vocab (if present), then a document-relative IRI.
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Dave Longley: +1
François Daoust: +1
Niklas Lindström: Also, we can thus keep the resolution for Issue
204 (Do not allow terms as values for @id.)
Markus Lanthaler: yes, that's the point I think
RESOLUTION: If "@type": "@vocab" is specified for a term in the
active context, then processing for the value associated with the
term attempts to resolve it as an IRI - first processing it as a
term, then a CURIE, then an absolute IRI, then against the active
@vocab (if present), then a document-relative IRI.
Markus Lanthaler: value space of @id: compact IRI, absolute IRI,
relative IRI
Dave Longley: {"@context": {foo: {"@id": "http://bar.org/1",
"@type": "@vocab"}}, "http://bar.org/2": "foo"} expands to what?
Dave Longley: ["http://bar.org/2": {"@id": "http://bar.org/1"}] ?
Dave Longley: [{"http://bar.org/2": {"@id": "http://bar.org/1"}}]
?
Manu Sporny: value space of @type: @id: compact IRI, absolute
IRI, relative IRI
Manu Sporny: value space of @type: @vocab: term, compact IRI,
absolute IRI, @vocab, relative IRI
Niklas Lindström: yes
Gregg Kellogg: the difference of @type = @id and @type = @vocab
is that @id isn't vocab-relative
Markus Lanthaler: yes, and terms are not used
PROPOSAL: The value space for terms tagged with "@type": "@id" is
compact IRI, absolute IRI, relative IRI, the value space for
"@type": "@vocab" is term, compact IRI, absolute IRI, @vocab,
relative IRI.
Gregg Kellogg: +1
Dave Longley: +1
Markus Lanthaler: +1
Niklas Lindström: +1
François Daoust: +1
Manu Sporny: +1
RESOLUTION: The value space for terms tagged with "@type": "@id"
is compact IRI, absolute IRI, relative IRI, the value space for
"@type": "@vocab" is term, compact IRI, absolute IRI, @vocab,
relative IRI.
Dave Longley: in compaction, if we have two terms just differing
in @type.. what do we choose? @id or @vocab?
PROPOSAL: Within a term definition in the JSON-LD context,
document-relative IRIs are not supported.
Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0
RESOLUTION: Within a term definition in the JSON-LD context,
document-relative IRIs are not supported.
Markus Lanthaler: For the record, relative IRIs to reference
external contexts are supported
-- 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/