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.

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

Manu Sporny: -1

Gregg Kellogg: 0

Markus Lanthaler: +1

Dave Longley: 0

Paul Kuykendall: 0

Niklas Lindström: -0.5

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

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)

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

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 ;]

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

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

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.

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" ?

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

Manu Sporny: +1

Markus Lanthaler: +1

Paul Kuykendall: +1

Dave Longley: +1

Gregg Kellogg: +1

Manu Sporny: +1

Gregg Kellogg: +1

Dave Longley: +1

Markus Lanthaler: +1

Paul Kuykendall: +1

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);

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.

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!