JSON-LD Telecon Minutes for 2013-05-07

Thanks to Dave Longley for scribing! The minutes from this week's
telecon are now available.

http://json-ld.org/minutes/2013-05-07/

Full text of the discussion follows including a link to the audio
transcript:

--------------------
JSON-LD Community Group Telecon Minutes for 2013-05-07

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013May/0029.html
Topics:
   1. JsonLdOptions base vs. @base
   2. Implementation Report Submissions
   3. Path forward for JSON-LD CR/PR
Resolutions:
   1. Support relative IRIs in @base.
   2. @base is always resolved against the current documents URL.
      @base when set in a remote context document does not apply to the
      document that imports the remote context.
   3. Accept the new Base Resolution Algorithm, which supports
      setting @base: null (no base value).
   4. The API option for 'base' is not set by default.
Chair:
   Manu Sporny
Scribe:
   Dave Longley
Present:
   Dave Longley, Manu Sporny, Markus Lanthaler, Gregg Kellogg,
   Paul Kuykendall, Niklas Lindström, David I. Lehn
Audio:
   http://json-ld.org/minutes/2013-05-07/audio.ogg

Dave Longley is scribing.
Manu Sporny:  Any updates to the agenda? [scribe assist by Manu
   Sporny]
Markus Lanthaler:  quick question, i think i caught up on the
   @base discussion, but was there any thing controversial there?
Markus Lanthaler:  the question was whether or not we allowed
   relative urls in base?
Gregg Kellogg:  other rdf serializations allow relative urls for
   base, even RDFa does, so long as it resolves to an absolute url
   in the end
Manu Sporny:  i thought we did something different with RDFa,
   let's discuss now.

Topic: JsonLdOptions base vs. @base

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/223
Manu Sporny:  two issues to resolve, whether relative IRIs can be
   used with base and what the empty string does
Markus Lanthaler:  i think that relative IRIs can get very messy
Markus Lanthaler:  the spec is a bit fussy about @base anyway,
   we're not really explicit about how it handles it, we just say
   that you expand against the document base, we never say how that
   base is established
Markus Lanthaler:  if you have a remote context with a base and
   it has a nested remote base context which one do you use?
Manu Sporny:  i thought we decided that you use the one in the
   local document
Gregg Kellogg:  i think if base is resolved to an external remote
   document it causes lots of problems
Manu Sporny:  i think devs could understand if base just resolved
   to the local documnet
Gregg Kellogg:  it complicates processing slightly but we could
   consider using @base in an external context illegal
Manu Sporny:  we wouldn't even need to make it illegal if it just
   applies to the local document
Gregg Kellogg:  if we do @base: ".." how does that behave?
Markus Lanthaler:  if you define a term and then you use that
   base and that base is different from anywhere else it gets weird,
   right now if you take your external context and put it in your
   document it just works
Manu Sporny:  yeah, but if we allow @base in remote contexts then
   your local document doesn't have the right base
Markus Lanthaler:  what's the use case, for a relative @base, why
   not just use relative IRIs in your document?
Manu Sporny:  the use case (we've had two people bring this up)
   is for packaging
Manu Sporny:  if files exist in directories further up in the
   tree that need to be referred to in a package that has no real
   absolute iri
Manu Sporny:  how do you reference things like that easily?
Manu Sporny:  one approach is to use relative IRIs everywhere the
   other is to set @base and use cleaner relative IRIs
Manu Sporny:  i agree that it's not necessarily the best use
   case, but that's what it is
Markus Lanthaler:  the other case is using @base in the test
   suite
Gregg Kellogg:  we talked about doing that, we don't currently,
   but we want to move the test suite to a location that people
   report against
Markus Lanthaler:  but it would be an absolute IRI there
Paul Kuykendall:  we have been using @base to build up widgets,
   etc. and we haven't had a problem with just using absolute IRIs
Paul Kuykendall:  it doesn't seem very compelling to us, we
   haven't had a problem, it seems more compelling to come in line
   with other serializations, but to support widget stuff, i'm
   dubious
Niklas Lindström:  i think, firstly, it would be good to have the
   same resolution as RDFa, we're kind of similar to turtle w/vocab
   space vs. document space, but we're mostly in line with RDFa,
   with vocabulary space we really don't need relative IRIs, when
   you have lots of data in JSON files that are statically generated
   and you don't yet know for sure what the domain name for the
   publication of these it's very useful to be able to ha
ve relative IRIs to be able to relocate your entire dataset

PROPOSAL: Do not support relative IRIs in @base.

Manu Sporny: -1
Gregg Kellogg: 0
Markus Lanthaler: +1
Dave Longley:  0
Paul Kuykendall: 0
Niklas Lindström: -0.5

PROPOSAL: Support relative IRIs in @base.

Manu Sporny: +1
Markus Lanthaler: -1
Gregg Kellogg: 0
Dave Longley:  0
Niklas Lindström: +0.5
Paul Kuykendall: +.2
Markus Lanthaler:  another problem if we support relative IRIs is
   that we don't support it in @vocab and in other term definitions
Niklas Lindström:  i disagree, that's what the case is in RDFa
   already
Gregg Kellogg:  yeah, that behavior is very similar to RDFa
Niklas Lindström:  for the reasons i discussed just now regarding
   the conceptual vocabulary space where it's very rare to need to
   relocate that
Markus Lanthaler:  but just looking at the keywords they do very
   similar things but not quite, so it's strange to support in one
   and not the other
Niklas Lindström:  they serve very different purposes
Manu Sporny:  i don't think it would be that strange
Niklas Lindström:  we don't have what Turtle does to make
   distinctions, but it's the same distinction of vocab vs document
   space
Manu Sporny:  i think there's very slightly more support for
   relative IRIs for base than not, so i'll say we resolved that wya
Manu Sporny:  then we'll have to deal with having a blank @base
   IRI
Manu Sporny:  any objections?
Markus Lanthaler:  yeah, i objected already
Manu Sporny:  are we making a catastrophic error by supporting
   this?
Markus Lanthaler:  are we going to support these in external
   contexts as well?
Markus Lanthaler:  for example, the widget case, discussed on the
   mailing list, he used a relative term which was then resolved at
   runtime, he had a bundle prefix which was a relative IRI that
   wouldn't work
Manu Sporny:  i was referring to a use case from about a year ago
   with people working with web widgets, which had to do with that
   spec
Paul Kuykendall:  my main concern the change here, i'm more in
   favor of consistency amongst JSON-LD, RDFa, turtle, and the like
Manu Sporny:  i agree that that is the most compelling argument
Paul Kuykendall:  my hesitation again is to avoid adding too much
   additional complexity right at the end
Manu Sporny:  i think @base isn't used too often (relatively
   speaking), the majority of documents out there don't use it
Manu Sporny:  i think being in the minority may mean that
   requiring them to really understand it is an acceptable hurdle
Manu Sporny:  we may want to elaborate on the spec to make that
   clear
Markus Lanthaler:  we don't have much time to do that
Manu Sporny:  yeah, we have one more iteration and then that's it
Manu Sporny:  but it's informative (the warning part)
Gregg Kellogg:  just one issue, is in the syntax document, in the
   context definitions, we do say that it must be an absolute IRI or
   null
Gregg Kellogg:  what does this mean about the stability of the
   syntax document
Manu Sporny:  did we have an issue marker on that?
Gregg Kellogg:  i don't think so, i think B is normative, which
   it says there .... oh, there is an issue marker, nevermind, we're
   good

RESOLUTION: Support relative IRIs in @base.

Manu Sporny:  now, is @base included from external contexts?
Manu Sporny:  we might want to just do the simple thing and say
   that it is
Manu Sporny:  if you have a context that includes an external
   context, and you have a whole chain of them, the first @base is
   set in the parent document, and then each new context overrides
   the @base
Manu Sporny:  i think that's the complicated case we were trying
   to avoid by saying that @base only applies to the local document,
   but people are saying that makes it complicated, so maybe we just
   want to make it simple and people who generate external contexts
   should really understand that @base will effect all external
   documents that use that @base
Manu Sporny:  that use that context
Niklas Lindström:  if your context is intended for wider use,
   don't use @base
Niklas Lindström:  (or be careful)

PROPOSAL: When @base is specified in an external context, that
   @base is applied to the document including the external context.

Manu Sporny: +1
Gregg Kellogg: +1
Paul Kuykendall: +1
Dave Longley: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Markus Lanthaler:  wait, I think there is a problem with this.
   let's say we have two external remote contexts, the first one
   establishes @base, the second one uses a relative @base, is the
   second @base resolved against the previous absolute base or
   against the remote context
Manu Sporny:  if your previous @base is to example.org and in the
   second context it's "../", having "../" apply to the document vs.
   the base that's already been set would be strange
Markus Lanthaler:  i think it's less strange
Markus Lanthaler:  you can include the same remote context in
   multiple documents, but i think the term definitions in there
   should expand to the same URLs
Niklas Lindström: {@context: "/some/path"} /some/path contains
   {@context: {@base: "./other"}}, the base is "/some/other
Markus Lanthaler:  so i think the remote context "../" should
   expand against the previous context @base
Gregg Kellogg:  you could use something that composes remote
   contexts that uses other remote contexts and weird stuff could
   happen, but maybe we should just resolve that by cautioning
   people from doing that because it can lead to unexpected results
Markus Lanthaler:  if you have a document and you set the base in
   that document, it should not change the @base in that remote
   context
Markus Lanthaler:  otherwise you would break that remote context
   without noticing
Gregg Kellogg:  so when you load the remote context...
Markus Lanthaler:  you use the remote context URL to expand every
   base statement in there
Gregg Kellogg:  what if you have a remote context that is using a
   relative IRI, do i resolve it using a base declaration that is in
   scope or do i resolve it using the document's actual location
Gregg Kellogg:  base is entirely a semantic concept used for
   resolving properties, it doesn't affect the way that you retrieve
   documents
Niklas Lindström: .. it should work like base works going from an
   html document to a CSS or an SVG (and from them to other css or
   sag)
Manu Sporny:  if you're looking at @base as it's used in html, if
   you include like a CSS file or some other ... trying to think if
   there's a way to include other html-like files ... in all of
   these cases the @base only applies to the document, actually in
   CSS you can do that right? the @base only applies to the document
   itself
Manu Sporny:  so when you import one CSS file into another, all
   of the path resolutions happen happen based on the @base for that
   file, we don't have this weird chaining thing that happens like
   it does with the JSON-LD context
Manu Sporny:  i'm not arguing one way or the other, just food for
   thought, i think it's a little strange the way we're doing this i
   think
Paul Kuykendall: Do we need to timebox this, or continue on,
   pushing out other agenda items?
Markus Lanthaler: [ { "@base": "http://example.com/" },
   "/dir/remote-context.jsonld" ] - remote-context.jsonld: {
   "@base": "./" } (1) what's the base here | (2) what's the final
   base in the doc?
Manu Sporny:  the problem here is that we need to resolve this if
   we're going to get another LC doc out next week
Manu Sporny:  we can't go to LC2 if we don't resolve this
Gregg Kellogg:  this becomes simpler if base is only allowed
   locally and not within a remote context
Markus Lanthaler:  every document can be used as a remote context
Gregg Kellogg:  in which case it would be ignored
Niklas Lindström: 1: the base in remote-context is
   "http://example.com/dir/"; the base in the document is
   "http://example.com/"
Markus Lanthaler:  so base is always established locally (local
   to the document), never changed by a remote context
Gregg Kellogg:  when we start evaluating a remote context, we
   pass a flag that says "ignore base"
Niklas Lindström:  if there is a base in the local document
Gregg Kellogg:  when we process a remote context, we always
   ignore @base
Gregg Kellogg:  it's as if the @base declaration does not exist
   when processing a remote context
Niklas Lindström:  so @base is intransitive
Gregg Kellogg:  yeah
Niklas Lindström:  meaning not-inherited
Niklas Lindström:  the drawback is that you can never define
   @base in an external context
Markus Lanthaler:  is that something that we want to prevent?
Niklas Lindström:  i'm not sure
Paul Kuykendall:  does RDFa/turtle have anything equivalent
Niklas Lindström:  i cannot think of any web based technology
   that would inherit @base
Niklas Lindström:  if you have xml base in an xml doc, and you
   include another xml doc, base in that document would never apply
Markus Lanthaler:  there is really no tech that changes
   namespaces like we do with remote contexts
Markus Lanthaler:  we expand properties to urls using an external
   doc
Niklas Lindström:  external dtds can do that, to some extent
Niklas Lindström:  i'm not sure what having xml base defined in
   that dtd would add it to the local document, i think it would,
   that's the closes analogy i can think of right now
Markus Lanthaler:  the spec would stay the same, but @base would
   always be resolved against the current document url

PROPOSAL: @base is always resolved against the current documents
   URL. @base when set in a remote context document does not apply
   to the document that imports the remote context.

Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Dave Longley:  0, can't both follow and scribe this crazy
   conversation! :)
Paul Kuykendall: +1
Niklas Lindström: +1, with resolution inconsistency caveat ;]

RESOLUTION: @base is always resolved against the current
   documents URL. @base when set in a remote context document does
   not apply to the document that imports the remote context.

Manu Sporny:  what does the blank string do? does it clear @base?
Manu Sporny:  or is it like saying current document URL?
Niklas Lindström:  it should use the current document url
Manu Sporny is scribing.
Dave Longley:  I believe this had to do with a use case where
   people wanted to preserve relative IRIs in their documents where
   @base: "" meant "keep it relative"
Dave Longley:  null would mean "don't set the base to nothing,
   but revert to previous options base value.
Dave Longley:  I think there was a case that was not supported
   where we were looking at was the "leave the IRIs alone - there is
   no base associated with the document"
Markus Lanthaler:  Shouldn't we change the default value for
   options to make that happen?
Markus Lanthaler:  We could say if you just put in JSON, there is
   no base.
Dave Longley:  yeah, that seems like a good idea.
Markus Lanthaler:  Yes, so change the 'default base' to 'null'
Dave Longley:  Yes.
Dave Longley:  @base: null means "fall back to whatever the
   previous options were" - either base of the document, or the base
   option passed into the API.
Niklas Lindström:  Can we have @base: null , null out the base?
Markus Lanthaler:  If you read the RFC that explains how you
   expand a relative IRI - the last thing that expansion falls back
   to is the application-defined space - which is the JSON-LD
   options. I don't think we need to do anything else to have the
   same behavior in the document itself.
Dave Longley:  Two possible use cases - 1) you want to enforce
   leaving URls alon, 2) You want to set @base to revert back to
   null. Two different cases, but we don't have two different
   values.
Niklas Lindström:  We could do "empty string means revert", and
   "null means none"
Dave Longley:  I said the reversed...
Dave Longley:  We were going to say empty string meant "no base"
Dave Longley:  null meant revert
Discussion surrounding benefits drawbacks for either approach.
Confusion about what is meant by "revert to the previous value,
   null, resetting, etc."... group working out definitions.
Markus Lanthaler: Document at http://example.com: { "@context": [
   { "@base": "http://example.com/dir/" }, { "@base": "./" } ... }
Markus Lanthaler: Document at http://example.com: { "@context": [
   { "@base": "http://example.com/dir/" }, { "@base": "" } ... }
Dave Longley: there is "previous" and "original"
Dave Longley: 1. original document location (may be null for just
   data)
Dave Longley: 2. API base option
Dave Longley: 3. base as set by processed contexts
Dave Longley: what does "@base": null set @base to?
Gregg Kellogg:  Yes, I think that's correct.
Gregg Kellogg:  If you set @base: null, you fallback to 2.
Discussion about various pros/cons to @base: null setting API
   base option.
Discussion about what the publisher meant by "@base": null
Niklas Lindström: Q: Document at "http://example.com/doc": {
   "@context": [ { "@base": "http://example.com/dir/" }, { "@base":
   "" } ... } - base is "http://example.com/dir/" or
   "http://example.org/doc" ?
Discussion about the use case for relative-only IRIs
Discussion of merits of digital signatures on graphs that contain
   purely relative IRIs.
Discussion about variations that we could use to resolve the
   issue.
Niklas Lindström: .. we should write down numbered concrete
   examples (seems to be 4-6), and vote on the desired effect in
   each
Niklas Lindström: Q 2: Document at "http://example.com/doc": {
   "@context": [ { "@base": "http://example.com/dir/" }, { "@base":
   null } ]… } - base is either "http://example.com/doc" or null (if
   that is even legal)..
Paul Kuykendall:  There seem to be several different alternatives
   - could you write up a simple example and dissect each example?
Markus Lanthaler: http://piratepad.net/GjJt14kUlA
Gregg Kellogg:  To summarize @base is ignored if it's in a remote
   context.
Gregg Kellogg:  Only issue that's open is what happens when
   @base: null ?
Gregg Kellogg:  It falls back to API base and then document base.
Dave Longley: Document at "http://example.com/asset", it is a
   bundle with relative IRIs
Hour-long discussion about definitions, approaches, etc.
Result of the discussion is a new Base Resolution Algorithm,
   described here:
1. initialize base to null
2. if document URL exists, initialize base to document URL
3. If API option is set, override base with base API option.
4. @base overwrites base
Rule #1: remote context, @base doesn't overwrite base
Rule #2: @base: null, when used in the local document, sets base
   to null (no base)
Rule #3: If you try to set a relative base, and your existing
   base is null, throw an error.

PROPOSAL: Accept the new Base Resolution Algorithm, which
   supports setting @base: null (no base value).

Manu Sporny: +1
Markus Lanthaler: +1
Paul Kuykendall: +1
Dave Longley: +1
Gregg Kellogg: +1

RESOLUTION: Accept the new Base Resolution Algorithm, which
   supports setting @base: null (no base value).

PROPOSAL: The API option for 'base' is not set by default.

Manu Sporny: +1
Gregg Kellogg: +1
Dave Longley: +1
Markus Lanthaler: +1
Paul Kuykendall: +1

RESOLUTION: The API option for 'base' is not set by default.

Dave Longley: (this means that if the document location is not
   set (it is null), base will be null)
Markus Lanthaler:  What happens when you compact?
Manu Sporny:  you use the same algorithm as above.
David I. Lehn: should i mention spec bugs now or wait until you
   all get off the telecon? :)
David I. Lehn: https://github.com/json-ld/json-ld.org/issues/245
David I. Lehn:  That's a spec bug, it's a non-substantive change.
   We should make it, but can be made at any point.
Markus Lanthaler: JsonLdOptions.base: http://example.com/
   compact(http://example.com/subdir/doc.jsond, somecontext);
Markus Lanthaler: { "@id": "me" 0
Markus Lanthaler: - expands to: { "@id": "http://example.com/me"
   }
Markus Lanthaler: JsonLdOptions.base: n/a
   compact(http://example.com/subdir/doc.jsond, somecontext);

Topic: Implementation Report Submissions

Dave Longley is scribing.
Manu Sporny:  so the plan for the RDF WG meeting tomorrow, so we
   have implementation reports
Manu Sporny:  Gregg you said your implementation will be done
   within a week
Manu Sporny: http://json-ld.org/test-suite/reports/
Gregg Kellogg:  my implementation is pretty virgin since i
   haven't been too involved in the changes to the algorithms
Manu Sporny:  once gregg's implementation is in, we'll give the
   test suite a permanent url. So, we're good to go as far as
   CR-criteria and implementation reports are concerned.

Topic: Path forward for JSON-LD CR/PR

Manu Sporny:  the question is: how are we going to take this
   stuff forward in the RDF WG?
Manu Sporny:  what's the proposal we're putting forward?
Manu Sporny:  i put together a proposal yesterday that says we
   could go to candidate rec with the syntax spec, we have to take
   the API spec into LC2
Manu Sporny:
   http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0052.html
Manu Sporny: Ivan had issues with it. So, I think the plan is to
   take JSON-LD API through a 2nd Last Call. We'll leave JSON-LD
   Syntax 1.0 alone until we get through the 2nd LC for JSON-LD API.
   We more-or-less meet all of the CR exit criteria already, so once
   JSON-LD API is out of LC, we will proceed directly to PR. We'll
   get RDF WG's input on the plan tomorrow.
Manu Sporny: Thanks for the super-long 3 hour call today
   everyone!

-- 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 Tuesday, 7 May 2013 17:48:27 UTC