JSON-LD Community Group Telecon

Minutes for 2013-05-07

  1. JsonLdOptions base vs. @base
  2. Implementation Report Submissions
  3. Path forward for JSON-LD CR/PR
  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.
Manu Sporny
Dave Longley
Dave Longley, Manu Sporny, Markus Lanthaler, Gregg Kellogg, Paul Kuykendall, Niklas Lindström, David I. Lehn
Audio Log
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: 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?
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: 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
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: 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!