Manu Sporny: Anything that should be added to the agenda?

Manu Sporny: Michael Hausenblas and Peter Patel-Schneider have raised concerns that JSON-LD isn't aligned with RDF to a degree that they're comfortable with. They feel that the JSON-LD data model overlaps the RDF data model to a large degree and that keeping that overlap is going to create incompatibilities and confusion in the future. We have always held the position that JSON-LD can be used to round-trip to RDF and back, in fact, most of us use it that way. Several months ago, we had committed to adding a section, authored by Richard, that will outline exactly how the JSON-LD data model maps to RDF and back.

Manu Sporny: The issues seem to be more editorial than technical. The change would limit what JSON-LD could express, and what would be considered valid, without a compelling technical reason for doing so. So, we need to figure out what we're going to propose to the RDF WG tomorrow during the call.

Manu Sporny: Richard, do you have any other insight into this issue?

Richard Cyganiak: There are two parts to this...

Richard Cyganiak: So, there is the technical side and then there is a non-technical side.

Manu Sporny: More comments from Peter. I agree they fall in those two categories. Danger of derailing the entire discussion in "should we define linked data?". Last time, your advice was to back up a bit, define linked data roughly in the spec. That's what we did, and we're relatively happy with that. We also agreed with you about the addition of an RDF appendix. Do you know what changes would be required now? [scribe assist by François Daoust]

Richard Cyganiak: There really isn't anything they can look at right now that I've edited. They're just commenting on the drafts that don't have any changes. Peter reviewed an earlier draft - that didn't help as he came away with the wrong impression.

Richard Cyganiak: I'm not entirely sure why this discussion about Linked Data has flared up. It's beside the point at the end of the day. Since JSON-LD in it's latest version doesn't contain a normative statement about Linked Data, we should be fine... this may be just some of the WG members wrapping their mind around the concept.

Richard Cyganiak: That part of the discussion can probably be ignored. There is no normative definition of Linked Data in JSON-LD anymore.

Richard Cyganiak: I expected a discussion like this to flare up anyway - if we had the normative Linked Data definition in there we'd have another problem... so it's good that we don't.

Richard Cyganiak: I've been thinking about what the appendix should contain. One problem that I have is that it seems that, in Section 3.1, that definition leaves a number of details open that might become clear once you read through the rest of the Syntax spec, or the API docs.

Richard Cyganiak: For example, same ID in a document means the same node?

Manu Sporny: Yes, it does.

Richard Cyganiak: How do the datatypes and language types on literals work?

Manu Sporny: Same way as RDF...

Richard Cyganiak: How does ordering work?

Richard Cyganiak: Order doesn't matter, right?

Manu Sporny: Yes, unordered unless it's a @list (via type coercion or expanded value form).

Richard Cyganiak: there are a couple of these things that might need to be cleared up. Maybe we need to make those more clear in the data model definition.

Manu Sporny: The group would have no problem with doing that... we should be precise in these cases.

Richard Cyganiak: Fully aligning with RDF early in the spec, from a didactic point of view, wouldn't be so good.

Manu Sporny: Deferring to RDF data model wouldn't solve the initial concerns, I think. [scribe assist by François Daoust]

Manu Sporny: One question: Has your position on this changed since last time? Do you feel that we've hit the right balance, from your standpoint? [scribe assist by François Daoust]

Richard Cyganiak: In my opinion, Section 3.1 still needs some clarification - that's not necessarily a huge complication - might be things like having a statement along the lines of "what is a string?" "String can have a language tag", you can't have two nodes that are labeled with the same IRI, etc.

Richard Cyganiak: I don't have a strong opinion on how to do that editorially.

Richard Cyganiak: From my point of view - and an editor of the RDF Concepts specs, I would be satisfied that the issue of the relationship of JSON-LD and RDF would be sufficiently addressed if those clarifications were made and if the RDF Appendix exists (which I'm planning on writing).

Richard Cyganiak: if others feel that the alignment should be even closer, Section 3.1 should defer to RDF Concepts directly, I'd be prepared to argue that JSON-LD defining it's own data model should be sufficient... we don't need changes that are that extreme.

François Daoust: When I read the spec, I think 3.1 is pretty clear about the JSON-LD data model. I'm all in favor for it to be more precise.

François Daoust: I'm more on the developer side than the RDF side - I still can't find anywhere, something says the different between RDF data model and JSON-LD data model... maybe with properties allowed to be blank nodes and strings? That's all I can figure out that the differences. Could we add a section in here about that?

François Daoust: I think that would resolve most of the concerns on the RDF WG mailing list.

Richard Cyganiak: That's one of the goals of the appendix - how do the data models map to each other, where are the differences?

Richard Cyganiak: I have an action to do this, have been traveling - will do it soon.

Markus Lanthaler: Appendix Relationship to RDF: http://json-ld.org/spec/latest/json-ld-syntax/#relationship-to-rdf

François Daoust: Will we have a bit in there about differences between RDF data model and JSON-LD data model?

Manu Sporny: Yes, we will have that.

Niklas Lindström: Important to recognize right now that we have general agreement on the approach. There has never been any intent to deviate wildly from the abstract RDF data model. Maybe we should clarify that the JSON data model, given that it's using the JSON structure, is a concrete data model. It's explicitly intended to express everything that is defined by the abstract RDF data model.

Niklas Lindström: The reason we don't want to add this into the document is that it's geared toward the developers. We want to define something that is closed in the document, we don't want to lead people astray... but we also don't want people to deviate from RDF.

Niklas Lindström: Both Gregg and I use JSON-LD to work with RDF - we don't want to deviate from that in any way. I'm not really sure that we can express that in the relationship to RDF appendix. To explain our intent.

Manu Sporny: This is not the first time this came to the table. On this call, we always come to the same conclusion, which is good. Second point, I don't think Peter and Michael picked up the spec with the history background that we already had discussed that in the group. The prose may need to be more clear about that, but we have thought this through quite deeply. [scribe assist by François Daoust]

Manu Sporny: The third thing that are a bit worrisome to me is that both of them said that they have no interest or don't believe that JSON-LD is the right thing to do. [scribe assist by François Daoust]

Manu Sporny: Fundamentally, people that use the spec in production environments should have more weight when opinions are gathered, I feel. Not to say that feedback is not good. But we've discussed this before, and came to the conclusion that a data model was needed because we're building on JSON and trying to bridge to RDF. [scribe assist by François Daoust]

François Daoust: … Let's argue that we throw away the JSON-LD data model away for a second. If you take a JSON document with keys that don't have entries in the context, the JSON-LD document becomes invalid.

François Daoust: … That's something we didn't want. We don't want JSON developers to apply a context to half of their JSON-LD document and have an illegal JSON-LD document. Bits that are not recognized are ignored.

François Daoust: … We're re-discussing the issue but coming to the same conclusion. No one wants to remove the data model entirely because it is subtly different than the RDF data model. Is that a fair outline?

Richard Cyganiak: I disagree slightly, but not suggesting that JSON-LD data model should be discarded and replaced with the RDF data model.

Richard Cyganiak: However, if we do that, we'd have to find some way to deal with keys that are not mapped to URIs - one option is to pull them away, another is to stick them to the end of a base URI - we could do that, might be a good idea anyway - non-URI keys could be retained.

Richard Cyganiak: We'd also have to change quite a bit of terminology throughout the specification - there aren't differences that are that large - property vs. predicate is a small one. Quite a few more occurrences of the letters "RDF" in the spec.

Richard Cyganiak: I'm not saying it should be done, but that's mostly for editorial reasons - the spec as it is at the moment is simpler to digest to the alternative version that would use RDF Concepts elsewhere. From a technical point of view, it would be possible to express the spec in terms of RDF Concepts, but we would lose the ability to do a few things.

Manu Sporny: You said that we could take keys and map them to some base IRI or ignore them. We're should ignore them instead so we don't cut ourselves off from a better model than RDF. [scribe assist by François Daoust]

Manu Sporny: There are things that you can do in JSON-LD today that you cannot do in RDF concepts, literals as property names, potentially literals as @ids, etc. [scribe assist by François Daoust]

Manu Sporny: if a better data model than RDF comes along in the future (e.g., something like microdata, for instance), then we don't want to be forced to map literal keys to complicated URIS [scribe assist by Richard Cyganiak]

Niklas Lindström: From my point of view, my uses of JSON-LD, often represent information that, from a data perspective, is noise - either it's reified things or property paths, if you use pure RDF you'd use OWL or CONSTRUCT - JSON carries noisy information to provide easier access to data for Web developers. That's a good thing, and it doesn't always map to RDF.

Niklas Lindström: When I annotate a JSON document with a context, turning it into JSON-LD - I say that certain keys are relevant and certain ones are not. It's handy to do that.

Richard Cyganiak: I find that argument *somewhat* compelling.

Manu Sporny: Richard has an action to align JSON-LD data model and RDF data model. Expected outcome is that you can round-trip between data models. [scribe assist by François Daoust]

François Daoust: … We'll outline differences between the JSON-LD data model and RDF data model. There aren't many but we don't feel comfortable removing the JSON-LD Data model entirely at this point.

Richard Cyganiak: One more thing that we should state, which might be helpful to address some of these concerns, have a paragraph in the introduction that says "by the way, JSON-LD has a data model that is compatible with RDF, see appendix: RDF"

Richard Cyganiak: That might help address the concern that JSON-LD is not a serialization of RDF (even though it is)

Markus Lanthaler: You can't specify a context to the .compact() API call.

Markus Lanthaler: Could we combine .expand() and .compact() to be one method?

Markus Lanthaler: If you pass an empty context to .compact(), it's basically expansion.

Manu Sporny: We could do that. I'm a bit concerned that it's going to be difficult to pitch that to developers. [scribe assist by François Daoust]

François Daoust: … A completely different type of operations would be happening depending on the arguments

Markus Lanthaler: It's already happening now. Parameters are enough to change the output completely. [scribe assist by François Daoust]

Manu Sporny: Kind of. For compact, array removal, for instance. What you're getting back is still a compacted document even without context. [scribe assist by François Daoust]

François Daoust: … Two different forms of document. That's why I'm not in favor of that. That would confuse early adopters.

François Daoust: … They're kind of polar opposite.

Markus Lanthaler: Basically, not an issue as you can already do that with the current spec. [scribe assist by François Daoust]

Niklas Lindström: I haven't read through all the comments, but Gregg's suggestion to detect whether there's an incoming context and skip expansion form seems reasonable. [scribe assist by François Daoust]

Markus Lanthaler: but you have to loop through all the document as it could appear at the end of the document. [scribe assist by François Daoust]

Dave Longley: there is value in explicitly naming functions after their intended use

Markus Lanthaler: We could move some of this stuff into the options.

Markus Lanthaler: We could add 'expansionContext' to the options?

Dave Longley: if you skip expansion just because a context is missing you won't normalize things like @value

Markus Lanthaler: good point dlongley

Dave Longley: doing expansion before applying our other algorithms simplifies them

François Daoust: I was reacting to the issue of having to parse the document twice before deciding what one should do with the document...

François Daoust: If you start the incoming with an empty context, that turns the document into expanded form, and the document can't decide if it has to do the expansion?

François Daoust: { "@context": {}, "hello": "world" }

Dave Longley: the compaction algorithm (and others) assume the data will have been normalized

Dave Longley: values like "world" -- {"@value": "world"}

Niklas Lindström: If we're going to do anything, we should avoid expanding twice by having an option.

Dave Longley: i think we may be prematurely optimizing -- we always do expansion first because it simplifies everything else ... both in the algorithms that must be written and in understanding how they work

Markus Lanthaler: dlongley, we will still be doing that

Manu Sporny: Dave Longley, concerned that you don't quite understand the issue? (having to do two expand-compact-expand-compact calls ... vs just one?)

Markus Lanthaler: we are discussing to add a expandContext option which would be used as "initial context" for all expansion calls (also expand() itself)

Niklas Lindström: .. if the context needed for expansion is provided out-of-band

Dave Longley: that will only do one expansion and compaction

Manu Sporny: not really, no... we're trying to figure out if it's that difficult.

Markus Lanthaler: void expand (object or object[] or IRI input, object or IRI? context, JsonLdCallback callback, optional JsonLdOptions? options);

Markus Lanthaler: What I'm proposing is that expand looks like this ^^^

Markus Lanthaler: to oid expand (object or object[] or IRI input, JsonLdCallback callback, optional JsonLdOptions? options);

Manu Sporny: change the signature of expand to this: expand (object or object[] or IRI input, JsonLdCallback callback, optional JsonLdOptions? options);

Markus Lanthaler: context is moved into options

Markus Lanthaler: same option available for compact()

Markus Lanthaler: void compact (object or object[] or IRI input, object or IRI context, JsonLdCallback callback, optional JsonLdOptions? options);

Dave Longley: it seems to me that this option only saves a single line? (doc["@context"] = "<result of link header>";) ?

Manu Sporny: not really what we're discussing...

Dave Longley: ok

Manu Sporny: What we're discussing is this - specifying the context in .expand() is optional...

Manu Sporny: it's not optional in .compact()

Manu Sporny: So, why not move the expansion context to options'

Dave Longley: fine by me

Manu Sporny: +1

Markus Lanthaler: +1

François Daoust: +1

Niklas Lindström: +1

Markus Lanthaler: So, next question is whether or not we want to use the 'expansionContext' option, if it is specified, in the .compact() call (when expanding before compacting)

Markus Lanthaler: If you add an 'expandContext' option, it would start as if there were a wrapper around the context that has the context... so the first context processed would be 'expandContext', then the input document contexts would be applied on top.

Manu Sporny: Dave Longley, any input on this?

Dave Longley: i guess it's fine, i think it's unnecessary

Manu Sporny: So the proposal would be to use 'expandContext' if it is specified in the options to .compact() as the first context that is processed.

Dave Longley: we'd have to deal with issues where the input document has another context

Manu Sporny: ... when the .expand() method is called internally.

Dave Longley: and specify how to handle that kind of behavior, etc ...

Markus Lanthaler: dlongley, the input document's context is used nevertheless

Markus Lanthaler: the expandContext is used to initialize the active context

Markus Lanthaler: just the way the context parameter in expand() works today

Dave Longley: what if i want to apply the options context last?

Dave Longley: not first?

Markus Lanthaler: doesn't work

Markus Lanthaler: :-)

Manu Sporny: I think the answer is - too bad :)

Dave Longley: :)

François Daoust: +1 to the proposal but make sure the option name is the same for "compact" and "expand".

Dave Longley: seems like it would be more likely that you'd want to apply it last than first, but i don't know.

Dave Longley: anyway, i'm not really in favor of that option because it feels like we're trying to do too much for the developer without knowing exactly what they want ... and then we just cover only some portion of the cases with the option, frustrating others....

Dave Longley: that being said, i don't feel that strongly about it if people really want the option in there.

Markus Lanthaler: tidoust, the options are the same for all operations, they are defined in JsonLdOptions (http://json-ld.org/spec/latest/json-ld-api/#jsonldoptions)

Dave Longley: i think the fact that you acquired the data externally means you should probably be combining it however you want to externally before passing it to the API

Manu Sporny: I agree with Dave Longley, probably going to be a +0 on this.

Dave Longley: i don't mind if we really believe that we're designing these options to cover the most common use cases though (i just don't know if that's true)

Manu Sporny: I don't think this is a common use case?

Niklas Lindström: Hard to determine, I've used a bunch of local data w/ an input context... but that's for testing things out. I've come across scenarios like this, can't say if it's common or not. If we have these options, it seems natural to add this to the API.

Niklas Lindström: feels more uniform.

François Daoust: I agree with Niklas.

François Daoust: It makes the API more consistent.

François Daoust: Also, doesn't seem to add a great deal of complexity to implementations.

Dave Longley: consistency isn't always better :)

Dave Longley: it probably doesn't make things too much more complicated, no

Dave Longley: anyway, i'm +0 on it.

Markus Lanthaler: it's already implemented, just needs to be wired together

Manu Sporny: +0

Markus Lanthaler: +1

Niklas Lindström: +1

François Daoust: +1

Niklas Lindström: To be clear - two sub-issues - is @type resolved against @vocab? If there is no @vocab, do you resolve @type against BASE document IRI?

Niklas Lindström: s/niklasl/markus/ ;)

Niklas Lindström: .. answer for above: not resolve, use @type as string with concatenation

Manu Sporny: Is @type special? Does @vocab apply to it?

Markus Lanthaler: @vocab is special, not @type.

Niklas Lindström: Wouldn't you be able to achieve what you want via "@vocab": "" ?

Niklas Lindström: If you do that, you use the document base IRI? I guess you'd need a hash mark if you wanted something safe...

Markus Lanthaler: That would affect all the properties as well...

Niklas Lindström: If I wanted to use locally defined types, I'd use type coercion ...

Niklas Lindström: { "foo": {"@id": "http://foo.com/vocab"} }

Niklas Lindström: Then use relative paths?

Markus Lanthaler: I want a fallback to a relative IRI... I want to test locally and remotely - use relative IRIs everywhere - dependent on document base IRI... why shouldn't type allow relative IRIs?

Niklas Lindström: It might confuse people - it's not thought of that way in most cases - RDF use cases, general practice, is not to have local types. You probably go out of the way to express that. Think of TURTLE - you'd use an explicit IRI values.

Markus Lanthaler: I can't pass a relative IRI to type.

Niklas Lindström: There is a difference in syntax there.

Markus Lanthaler: I can pass in an absolute IRI, why can't I pass in a relative IRI?

Niklas Lindström: Same value space as terms...

Markus Lanthaler: Terms expand in @id...

Niklas Lindström: You could use './' or use a full base IRI there.

Markus Lanthaler: +1

Niklas Lindström: +0

David I. Lehn: +0

Manu Sporny: +1

François Daoust: +1 for consistency

Markus Lanthaler: https://github.com/json-ld/json-ld.org/issues/173

François Daoust: Just wanted to raise ISSUE-166 - provide feedback in written form.

Niklas Lindström: +1

Markus Lanthaler: +1

Manu Sporny: If you want to provide spec text for a conformance section, that would be great.

Manu Sporny: +1

Niklas Lindström: .. to join @vocab with the suffix using textual concatenation..

Markus Lanthaler: @vocab: http://example.org/vocab#

François Daoust: +1

Markus Lanthaler: the term 'test' would resolve to http://example.org/test if we treat @vocab as an IRI instead of a prefix, which is not what we want.

Niklas Lindström: note for the minutes: mlnt's last example was what we don't want :)

Lin Clark: bye