Manu Sporny: Any changes to agenda?

Manu Sporny: Maybe we want to move the JSON-LD in HTML discussion to the end since Niklas isn't here yet.

Manu Sporny: Markus, mind taking us through this issue?

Markus Lanthaler: yep... Sandro thinks using @graph to specify the default graph is confusing. He thinks having an array where the first object is the context and all subsequent objects have the context applied.

Gregg Kellogg: that can have strange effects down the line, if you have multiple objects of a property, you'd think that context would apply to subsequent objects in an array. If you had an object that /only/ contained contexts.

Dave Longley: Yeah, we discussed this a long time ago. If you have data in compact form, you can't check lengths of arrays... you have to look through the entire array to see if there is a context there.

Markus Lanthaler: We've had this question several times now... it's not that common that you have an array at the top-level. In some cases, it's a security vulnerability.

Markus Lanthaler: You can easily alias "@graph" to "data". When we expand, we always expand it to an array at the top level.

Gregg Kellogg: There is is interest in using a canonical JSON-LD representation as an array. In JSON-LD in HTML stuff, that's something the supporters see as happening... they think it's not well understood by their community. But an array of objects would.

Markus Lanthaler: If you look at all web apis out there, there's always an object at the top level ... not an array.

Manu Sporny: i agree with markus, there are very few examples of an array being at the top-level in APIs [scribe assist by Dave Longley]

Gregg Kellogg: Yeah, maybe if we show an example with @graph aliased to data'

Markus Lanthaler: Maybe we can do that in that example.

Manu Sporny: I think that sandro's comment may have more to do with unfamiliarity with how JSON is used in the wild, i haven't seen people use JSON in the wild all that much with arrays being at the top-level coming back from API calls, etc [scribe assist by Dave Longley]

Manu Sporny: I don't think people that author JSON on a regular basis typically have objects at the top-level [scribe assist by Dave Longley]

Manu Sporny: typically, i'd expect to see something like this in a search result [scribe assist by Dave Longley]

Markus Lanthaler: but then you'd also see things like "how many results you got back", etc. and those would be top-level properties [scribe assist by Dave Longley]

Markus Lanthaler: and then the array would be underneath another property [scribe assist by Dave Longley]

Manu Sporny: yeah, we should create an alias example using "results" or something [scribe assist by Dave Longley]

Manu Sporny: so people can see how that may work [scribe assist by Dave Longley]

Markus Lanthaler: that would be dangerous because it would affect the default context [scribe assist by Dave Longley]

Manu Sporny: i'm not saying do that, just do an example in the spec [scribe assist by Dave Longley]

Manu Sporny: of using an alias here [scribe assist by Dave Longley]

Gregg Kellogg: maybe also add a note asking for feedback for this use case [scribe assist by Dave Longley]

Markus Lanthaler: Next up - data indexing.

Markus Lanthaler: Sandro feels it's pretty weird but fairly harmless. He thinks we can index data by an arbitrary property?

Markus Lanthaler: We've discussed this before, it adds a bunch of complexity. With Data indexing it's about representation of metadata... I would say we do nothing here.

Markus Lanthaler: having arbitrary properties as indexes is too complex for 1.0.

Dave Longley: I agree as well.

Gregg Kellogg: Yeah, agree.

Dave Longley: One request for this feature didn't want the RDFa data in the index - it meets the use case that was there for it.

Gregg Kellogg: The only thing I worry that we're missing is the other pattern from these indexes where you have a top-level key in which the data contains an array of properties. The Microdata JSON is an example of this, where you have id at the top and then properties, and the value of properties is the value of all of the properties.

Gregg Kellogg: There is a case where you might fold these in, I've seen this in other places as well. I'm a bit concerned that we will wish we had that.

Markus Lanthaler: I think the reason for that is because they don't have a way to namespace properties like JSON-LD...

Gregg Kellogg: Unless the identifier key could be re-used... My concern is that Microdata is something we thought we'd be able to handle at some point through these mechanisms, but we never came back to it.

Markus Lanthaler: There is always the possibility of having a pre-processing step.

Manu Sporny: So, we're doing nothing to change the spec in this case - the feature is good as designed.

Markus Lanthaler: Sandro talking about the data model section, he found it very confusing even though he is familiar with RDF Concepts.

Markus Lanthaler: It's a bit strange since most of these statements have been copied almost directly from RDF Concepts. He asked if we could drop this section, however, the RDF WG requested that we add this section in here.

Markus Lanthaler: Instead of re-defining our own data model, we could just say that it's the RDF data model, but we don't place restrictions on where blank nodes are usable.

Manu Sporny: it may be that sandro knows too much about the RDF data model and he may not be taking the text at face value, but that's just trying to get into his head which i shouldn't be trying to do [scribe assist by Dave Longley]

Manu Sporny: Ok, so we're not changing this section because the RDF WG asked for it, it's clear, concise and nobody in this group thinks we should change it.

Markus Lanthaler: Next up is normative non-normative labels are applied inconsistently.

Markus Lanthaler: we discussed this, but in respec, we'll relabel as appropriate.

Markus Lanthaler: Example 62: http://json-ld.org/spec/latest/json-ld-syntax/index.html#turtle

Markus Lanthaler: The example is correct - it's what we say in the spec and it's quite obvious that we define a prefix in JSON-LD and Turtle. No change.

Markus Lanthaler: In the IANA considerations we have the profile IRI... Sandro didn't apply what the profile IRI applies to. What does the 'SHOULD' Apply to? requests or responses?

Markus Lanthaler: I think it works. He also said he thinks it should work like normal content negotiation. It's an optional parameter, if you can't expand it on the server, you return what you can do.

Manu Sporny: i think it would help if we explained a little bit more in that section about what should happen [scribe assist by Dave Longley]

Manu Sporny: basically put a note in with sandro's concern where we basically say "if you request expanded form and the server can't expand it then it doesn't have to" [scribe assist by Dave Longley]

Markus Lanthaler: Some references are out of date, like TURTLE-TR and reference style isn't correct... we'll have to fix this before we go to LC. Especially since Turtle keeps changing state.

Manu Sporny: let's just call it TURTLE-REC and make the change and assume it will go to REC before JSON-LD does [scribe assist by Dave Longley]

Manu Sporny: these are very small editoral changes and i'm not that concerned about it [scribe assist by Dave Longley]

Markus Lanthaler: they are even informal references [scribe assist by Dave Longley]

Gregg Kellogg: i think RDF-CONCEPTS is a normative link in the JSON-LD API spec [scribe assist by Dave Longley]

Manu Sporny: i guess that's not too much of an issue since it's in the same working group [scribe assist by Dave Longley]

Manu Sporny: in the worst case the JSON-LD API spec is held up while the RDF-CONCEPTS spec goes to REC [scribe assist by Dave Longley]

Markus Lanthaler: next sandro suggests moving RDF conversion to the syntax spec [scribe assist by Dave Longley]

Markus Lanthaler: He also sent a second e-mail about the conversion descriptions - he wants an informative description about the process of turning JSON-LD into RDF and vice versa.

Gregg Kellogg: We'd need to cover the expansion and flattening algorithms.

Gregg Kellogg: i don't think he wants to move the whole algorithm, but maybe a brief description of how they work [scribe assist by Dave Longley]

Gregg Kellogg: I think they want one place where you can go to figure out how JSON-LD can represent RDF and vice versa.

Markus Lanthaler: The whole syntax spec is about that - how the context works, how nodes are expressed.

Gregg Kellogg: We could say something about the general process of transforming JSON-LD to RDF has to do w/ expanding/compacting the document... and then you can translate those statements to RDF.

Markus Lanthaler: As soon as we do that, people are going to ask about the algorithms.

Gregg Kellogg: we refer to the API spec.

Gregg Kellogg: We can explain that expanding is the process of removing the context, flattening is ordering everything in a flat sequence, then you can easily go to RDF.

Gregg Kellogg: We can show how the transformation happens.

Manu Sporny: As long as we can keep it short, that would be fine with me.

Gregg Kellogg: I'll write that section.

Markus Lanthaler: Sandro wanted to add to the conformance section: a JSON-LD Expander, JSON-LD COmpacter, JSON-LD To-RDF-Converter, JSON-LD From-RDF-Converter.

Markus Lanthaler: This is about the syntax specification, not the API specification.

Manu Sporny: So, no change.

Markus Lanthaler: we can talk later about maybe adding that to the API spec instead, it doesn't belong in the syntax spec [scribe assist by Dave Longley]

Markus Lanthaler: His first point is that JSON-LD should be an RDF syntax - same data model, same semantics as other serializations.

Manu Sporny: We've had a very long discussion about the differences in the data model - the only distinction is blank nodes, right?

Markus Lanthaler: Yes, only difference.

Gregg Kellogg: In this regard, we're not too different from notation 3 for properties. For graph labels, it has a different context.

Dave Longley: He effectively asks to change the RDF specs first, however, there is disagreement over where the future should go. We would prefer it to go into the RDF spec, but that's not happening right now.

Markus Lanthaler: We've discussed all of this several times, not even the RDF WG has a clear position about the additions to the data model that JSON-LD has... re-opening the discussion again isn't productive at this point in time. It is a super-set, we discussed with the RDF WG, they accepted it, we clearly documented the differences, we can't do much more than that.

Markus Lanthaler: We would like to keep JSON-LD as-is.

Manu Sporny: I agree.

Markus Lanthaler: His second point is that JSON-LD should not require that IRIs are de-reference-able. I find this a bit odd since JSON-LD is about Linked Data and Linked Data is about dereferenceable IRIs.

Markus Lanthaler: Besides, it's a SHOULD not a MUST, so it's not a hard requirement.

Gregg Kellogg: We had these conversations a while ago, nothing has changed.

Gregg Kellogg: Regarding JSON-RDF - that name was already taken at the time.

Manu Sporny: Besides - this is more about Linked Data than it is about RDF.

Dave Longley: This spec is about JSON in Linked Data... the name is fine.

Gregg Kellogg: JSON-RDF exists, and application/rdf+json exists - we can't re-use it.

Markus Lanthaler: I responded to his issues.

Gregg Kellogg: He seems to be happy with the changes.

Markus Lanthaler: He did respond today about @base and @vocab and how they're used in relation to relative IRIs. He acknowledges that @base is marked as at-risk, he still sees the risk with trying to do too much with expansion.

Markus Lanthaler: The other thing was mainly editorial, we characterize JSON-LD as a serialization of Linked Data in JSON.

Markus Lanthaler: Not sure I understand him completely. He thinks that RDF/XML could have benefited from a distinction.

Markus Lanthaler: So you could have multiple expressions of RDF in JSON (flattened, expanded, re-framed, etc.)

Markus Lanthaler: One aspect of JSON-LD is serialization and the other is authoring.

Markus Lanthaler: Before he realized that we had a flattened form, he thought that JSON-LD has many of the same problems as RDF/XML... but now that he knows about flattened form, you get the data in a deterministic form.

Dave Longley: he was worried that with all the ways of expressing the data, that it would be hard for an application to find out where the data is... but that only solves some of the "find the data" use cases.

Dave Longley: Unfortunately, some of this has to do with framing, because it's not in the spec.

Gregg Kellogg: I think it's useful to have someone that made a statement like this, some older RDF hats have said that we're making same mistakes that RDF/XML did... but we do allow the data to be modified and re-framed, which RDF/XML didn't do. That said, I don't think this comment is really action-able.

Markus Lanthaler: I think the point he's trying to bring across is that this isn't as much about serializing data, just augmenting the data with a context so you can interpret it as RDF.

Markus Lanthaler: You already have your JSON, you want to transform it to Linked Data, you just add your context and almost magically it can be interpreted as RDF.

Manu Sporny: That's a very good, concise statement - we should say that in the spec.

Dave Longley: Yes, if it's not in the spec, it should be in there.

Markus Lanthaler: We don't say that in the abstract/intro, we probably should.

Markus Lanthaler: He's also worried about remote contexts. Remote contexts are important, we have plenty of use cases for them.

Gregg Kellogg: It's a bit different from RDFa - documents aren't meaningless w/o them. In JSON-LD, documents are meaningless w/o being able to dereference the remote context.

Gregg Kellogg: His point is that you don't know if the data that's represented hasn't changed...

Dave Longley: You could run it through the normalization algorithm to see if it's changed.

Gregg Kellogg: How would that work? Use E-Tags?

Dave Longley: It's gets pretty complicated. If the remote context going away is a problem, you should cache or embed the context.

Markus Lanthaler: If you include external files, this is an issue on the Web. Like external javascript files.

Dave Longley: You could hash the external context and include that hash.

Markus Lanthaler: Yes, there are lots of ways to avoid the problem. In many cases, you have control over your context and you can change it in lock-step. The advantages of having a remote context outweighs the drawbacks.

Dave Longley: =)

Markus Lanthaler: The question is what happens when the base is a relative IRI?

Gregg Kellogg: Doing something to allow relative IRIs w/in the document is useful, but otherwise, I can't think of why you'd want base to be a relative IRI. Why isn't it just an absolute IRI?

Gregg Kellogg: You can do this in Turtle, where statements become accumulative, we could do that w/in JSON-LD - don't know if that's an important paradigm.

Markus Lanthaler: HTML and Turtle supports relative IRIs, having the empty string to say there is no base is a bit weird. It's something that should be done at the API level, if you don't want a base. The use case is to not change relative IRIs duringcompaction/expansion/ etc.

Niklas Lindström: .. http://www.w3.org/TR/xmlbase/

Niklas Lindström: Trying to think of a use case where relative base IRIs are useful.

Niklas Lindström: In general, what we should do is to make this work exactly in the same way as it's treated in HTML, Turtle, and XML - we should take care to do the same thing.

Dave Longley: So only difference between PROPOSAL 3 and PROPOSAL 4 - if PROPOSAL 3 is close to what we want, then PROPOSAL 4 enables two other features.

Markus Lanthaler: I'm concerned where the empty string is used for base... in HTML you can have a relative base "" and in Turtle as well.

Dave Longley: Proposal 3 does not allow relative IRIs.

Manu Sporny: It sounds like we agree that we should align with HTML, Turtle and XML, but we don't know what they do?

Markus Lanthaler: Just checked HTML5 - it allows relative IRIs for base, previous versions didn't.

Niklas Lindström: … json-ld fetched from "http://example.org/some/other" , with a @context containing @base: "/doc". I'd then expect base to be "http://example.org/doc"

Dave Longley: What's the behavior when you don't set the base in this case?

Dave Longley: If you have relative IRIs in the document and you have no base, and you get a relative IRI, how does "../.." change? Does it become just "/"?

Gregg Kellogg: I think it happens in the same way as any other RDF serialization. When you join IRI segments, it results in the IRIs being normalized, which includes removing dot-segments.

Dave Longley: does "../../foo" become "/foo" ?

Dave Longley: because i think that's unexpected when base is none

Markus Lanthaler: You can't have relative IRIs in a RDF serialization.

Gregg Kellogg: Yes, but you can have it in a syntax.

Markus Lanthaler: Yes.

Markus Lanthaler: if you are not able to establish an absolute base, we shouldn't try to resolve relative IRIs in the document, you just leave them as-is.

Gregg Kellogg: if we do that, we'd be the only serialization format that tries to go this far to explain why this happens.

Markus Lanthaler: We have to resolve this because we allow the base to be set.

Dave Longley: It also affects normalization.

Manu Sporny: Yes, we need to resolve this issue.

Gregg Kellogg: Maybe this means that if you specify a base IRI in the API, it must be an absolute IRI... in the absence of it, you'd be left with a document that has relative IRIs in it.

Dave Longley: I think it's important that we say: If you do not specify a base... what happens? Base doesn't exist - leave relative IRIs alone? What happens if base is specified in the document and it's relative? What happens when it's specified in the API and it's relative? We need clear answers to these.

Gregg Kellogg: Maybe we should say it's unaltered.

Manu Sporny: Let's take this back to the JSON-LD issue tracker and cover all corner cases and see if they apply to how HTML, Turtle, and XML deal with these corner cases.

Gregg Kellogg: There are cases where expressing metadata in HTML using either Microdata or RDFa is not feasible or has been shown to be error-prone.

Gregg Kellogg: As an alternative way of doing this, the idea is to put JSON-LD in HTML.

Gregg Kellogg: A process that conforms to this could extract the content of this script tag and run it through the JSON-LD algorithms. It could be used to easily extract anything - for Turtle, it's for extracting RDF.

Gregg Kellogg: In addition, there is a strong desire to not require boilerplate w/in the JSON - take JSON that came out of some JSON-LD database, without adding a context to the content of the script tag.

Gregg Kellogg: So, that's why @data-context is being proposed to be used for this purpose.

Gregg Kellogg: This is a way of specifying an external context, kind of like we do with link headers.

Gregg Kellogg: One of the advantages of @data-context is that you don't have to be very explicit - as long as you can de-reference it, if you can get to the context, you're going.

Manu Sporny: Any opposition to putting this into the spec?

Gregg Kellogg: This is an informative addition.

Niklas Lindström: I've seen some possible uses for this, I'm still a bit uneasy about the feature, but it seems useful. Maybe instead of an RDFa API, we can just read JSON out of the page.

Niklas Lindström: It's a good thing to have. Since Turtle has it, it'll be nice to have this as well.

Gregg Kellogg: When I added support for this for Turtle in my processor, I did it generically.

Gregg Kellogg: My own system, if it saw this, it would extract the RDF and add it to the default graph.

Gregg Kellogg: I'd need to refine it, but it has some history.

Dave Longley: This would be useful for Web Applications, to get them some initial data to start up.

Markus Lanthaler: Wouldn't you just assign it to a variable in that case? That's another way to do it. I don't like that the context is placed somewhere else.

Markus Lanthaler: I don't like that you can't cut/paste that. Also, data-* isn't intended for that use. We also say in the spec that the context has to be in the document if you're usingapplication/ld+json.

Gregg Kellogg: I tried @vocab instead of @data-context - but got push-back on that.

Gregg Kellogg: @vocab has similar behavior to @context.

Niklas Lindström: I don't quite agree with that. We took out @profile in RDFa. They're not really isomorphic.

Gregg Kellogg: You're right, I'm not suggesting we use that.

Markus Lanthaler: Why can't we use @context in JSON-LD?

Gregg Kellogg: The companies that want this don't want boilerplate - they feel very strongly about this. It's a small concession, it's in the spirit of how we specify it in a Link Header. I think it's reasonable for us to do. I have asked the people that have been promoting this to be more vocal, but they haven't done so yet.

Gregg Kellogg: if some of these issues are raised, maybe that'll provoke a response.

Markus Lanthaler: My fear is that we now say that they should use the @data-context attribute - you end up having JSON that isn't JSON-LD, people may forget to create it. Then we get to the point where we might have to pre-define prefixes.

Manu Sporny: Like Markus, I'm very concerned with people not using @data-context and us having to make that an initial context.

Dave Longley: I'm not too sure that boilerplate argument works here - I don't know if we're solving anything either way. They may not include the @context, they may not include @data-context.

Markus Lanthaler: At least we wouldn't be implementing something new.

Manu Sporny: +1

Gregg Kellogg: +1

Dave Longley: +1

Markus Lanthaler: +1

Niklas Lindström: +1

Niklas Lindström: What about: <script type="application/ld+json;context='http://example.org/context.jsonld'">

Niklas Lindström: We talked about allowing @context as an optional parameter to the MIME TYpe a long time ago?

Niklas Lindström: Maybe we can do the above.

Manu Sporny: I think a lot of authors would mess that up.

Gregg Kellogg: It's worth discussing it in more depth.

Gregg Kellogg: Let me send that back to them and see what sort of response I get.

Gregg Kellogg: That would also serve the same effect. It's boilerplate, but maybe that would work.

Manu Sporny: We've finished all review comments, we'll fix up the spec with the decisions we've made on those comments.

Manu Sporny: We'll get the JSON-LD Syntax spec into Last Call after we get those changes in, hopefully there won't be a flurry of new comments in the mean time.