JSON-LD Telecon Minutes for 2013-02-12

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/

Received on Tuesday, 12 February 2013 17:34:38 UTC