… We had a fairly good discussion about JSON-LD last week. There have been several offline discussions prompted from this.
François Daoust: Markus, I haven't but will do.
… I've added all issues that were raised in the RDF WG into the issue tracker.
Markus Lanthaler: thanks, just upload it somewhere.. no need to put it into the repo
… The biggest concern comes down to the differences in the data models and potential miss-alignment between them.
… The biggest concern that that there _was_ a difference. Once we discussed that it is a consequence of the spec approach, there is still a desire to align them.
Gregg Kellogg: I think basically, the question of "Is JSON-LD, RDF?" is the general push. [scribe assist by Manu Sporny]
Gregg Kellogg: I think we have expressed a desire that everything in JSON-LD can be converted to RDF. [scribe assist by Manu Sporny]
Richard Cyganiak: There's a question of if JSON-LD is a graph syntax, a dataset syntax or both.
François Daoust: Markus, here is a diff: http://goo.gl/bUZPM (loses most styles, but text remains readable), will add the reference to the issue tracker
… In the RDF WG there's been a consensus that graph and dataset syntaxes should be disjoint.
Markus Lanthaler: tidoust, thanks a lot!
… If you think of JSON-LD as a graph syntax that can also serialize datasets, it goes against this assumption, but it hasn't been discussed yet.
Gregg Kellogg: This comes about from TRiG - are curly braces required for a 'default graph'? [scribe assist by Manu Sporny]
Gregg Kellogg: If you treat a document as if it is a graph, you could import the data from the default graph into a particular location. This was one of the reasons why it's not entirely resolved. Curly braces might still be required for the 'default set' in TRiG. In JSON-LD, there is no way to specify when you have something different than JSON-LD... maybe we need a new MIMEType for JSON-LD. [scribe assist by Manu Sporny]
Markus Lanthaler: it's just about what parsers are going to expect, and in JSON-LD it's clear that it may include named graphs in additional to the default graph.
… I don't see it as a problem in JSON-LD.
Markus Lanthaler: also an issue if we should have a WebIDL API, or just processing rules.
Richard Cyganiak: There is a statement in the RDF WG that JSON-LD makes the same mistakes as RDF/XML.
… Manu pointed out that this statement isn't useful, to be constructive it would need to be backed up with details on how it can be addressed.
… I wanted to acknowledge that it is not a useful statement and needs to be backed up, but there probably is something that needs to be considered.
Manu Sporny: The problem with that statement is that we can't really respond to it as there are many mistakes made by RDF/XML, what is it that we need to address.
Markus Lanthaler: In an offline discussion with Sandra, he mentioned that JSON-LD is trying to be the master of multiple domains, and when you do this, you come up with something mediocre.
Gregg Kellogg: Once criticism I hear of RDF/XML is that there is many different ways to say the same thing - indeed that's true in JSON-LD... as it is in TURTLE. [scribe assist by Manu Sporny]
… We need to understand specific weaknesses, not broad statements.
Niklas Lindström: If you look at JSON-LD and through it into a templating system, you have a similar problem that you don't know the shape of the data. THe key difference is that JSON-LD has a context that allows you to remove these.
… The key pieces missing are framing and graphiphy that are the key to being to finally address shape differences.
… With connect, I've been able to do much more templating than before.
Markus Lanthaler: +1 to all what niklas just said
Gregg Kellogg: The 'flatten' option does allow you to get a consistent shape. [scribe assist by Manu Sporny]
Niklas Lindström: after flatten, you can do connect in a few lines of code.
Manu Sporny: these are things that people in the RDF WG may not be aware of, because they didn't know about them, or are not programmers and can't appreciate the benefits.
Topic: JSON-LD Breakout Session
François Daoust: I had a breakout session at the "BAR Camp" event at TPAC.
… It's fair to say that most people were RDF/Linked Data guys.
… I don't think there's much take away, it was more informal.
… It was really interesting to have the Linked Data Platform WG folks.
Manu Sporny: Were the LDP WG folks interested, is it useful?
François Daoust: JSON-LD isn't their priority for the time being. Different people have different views.
… I only attended the first day of the LDP WG F2F.
… There was a question of relating JSON Schema with JSON-LD context?
… There is overlap in the syntax, and this was probably the most interesting question.
Manu Sporny: in the Web Payments group, we use JSON Schema to validate input into the system, buy using our context and frame the data such that the structure is regular and then we apply JSON schema against that. It works extremely well.
François Daoust: the main point from "RDF guys" is that they want to work with the data model (triples) and don't necessarily like the way it approaches it.
Manu Sporny: you don't need JSON-LD if you have a triple store.
Richard Cyganiak: I was surprised at how large the turnout was, it was by far the largest I attended.
… It seems to hit the right memes that bring people in from different places.
… At LDP WG, the question of format is relevant.
… They used to say you need to use Turtle to be compliant, but they removed RDF/XML. You may support other formats.
… JSON-LD wasn't specifically mentioned, but it probably should have been.
Manu Sporny: We should discuss this with the LDP WG, but it could be a multi-month discussion and reduce our ability to complete work.
Richard Cyganiak: it might be helpful to bring it up sooner rather than later. It's a fresh issue; it's been resolved, but immediate push-back might make a difference.
… According to LDP charter is due in May 2013. I wouldn't be totally surprised if it's delayed.
Gregg Kellogg: I've noticed similar things come up on some outcomes from TPAC from WebID - normative use of TURTLE... many members of the group seem to object to that. [scribe assist by Manu Sporny]
Gregg Kellogg: I think that LDP is using TURTLE normatively might align with the WebID work, although I think it's clear to the folks in this group that any Web-based format could benefit highly from JSON-LD. [scribe assist by Manu Sporny]
Manu Sporny: I don't expect the WebID folks to turn away from turtle.
… However, it doesn't mean we shouldn't try.
ACTION: Manu to send a note to the LDP and WebID groups noting their selection of Turtle, and suggest they consider JSON-LD.
Niklas Lindström: mention that with JSON-LD you can use RDF structures only using JSON.
Topic: Strategy for addressing pre-LC RDF WG issues
Manu Sporny: we've had a garage of issues over the last 2 weeks.
… We signed up to have LC docs by the end of January, which means we need to resolve issues faster.
… I propose that we deal with the issues purely in the issue tracker, with +/-1 in the issue and commit from there.
… Reserve telecon time for contentious issues.
… we have a long cycle where it takes a while to commit text from resolutions.
Markus Lanthaler: perhaps we should note that we're freezing features.
Manu Sporny: A freeze is good, but we should note that we can do small things.
PROPOSAL: A feature freeze is in effect for JSON-LD 1.0 Syntax and JSON-LD 1.0 API effective November 06th 2012.
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +0.9
Richard Cyganiak: +1 (in case I get to vote :-)
François Daoust: +1
David I. Lehn: +0
RESOLUTION: A feature freeze is in effect for JSON-LD 1.0 Syntax and JSON-LD 1.0 API effective November 06th 2012.
Manu Sporny: is anyone opposed to using the issue tracker to close issues.
Richard Cyganiak: I think that some issues may be best dealt with by pushing back rather than implementing.
… There's a slight risk that if you do edits directly, they might not be necessary.
Manu Sporny: agreed. What would have to happen is that we would need consensus within the issues.
… We could only make an edit if there is a consensus view (no -1's).
Richard Cyganiak: I think it would be a good idea to do a quick call for consensus, or in the issue, giving a 24 hour period before it will take effect.
Manu Sporny: editors will check for consensus and resolve when there is.
Manu Sporny: when the editors note the resolution, they will send an email to the JSON-LD mailing list saying that the resolution has been made and will take effect within 24 hours.
Richard Cyganiak: how about: send an email: "call for consensus on issues x, y, and z. if you have additional concerns not yet raised there, please do so before xxx"
Richard Cyganiak: the assumption is that if no one raises a concern that discussion has completed.
François Daoust: do we need to raise issues for small editorial changes? no.
Manu Sporny: a long thread with cygri on the data model. It has been productive.
Richard Cyganiak: I plan to finish the mapping this week.
Gregg Kellogg: I think that there is the Graph/Dataset thing we're not very clear on - I think we describe JSON-LD as creating a graph, but it glosses over the Dataset aspect of it. There is something to be set about calling it a "Dataset model" [scribe assist by Manu Sporny]
Gregg Kellogg: We should mention the Dataset aspect of it. [scribe assist by Manu Sporny]
Markus Lanthaler: Isn't that what a JSON-LD document is? [scribe assist by Manu Sporny]
Gregg Kellogg: Dataset is abstract, JSON-LD document is concrete syntax. [scribe assist by Manu Sporny]
Manu Sporny: We need an issue to discuss this.
ACTION: Gregg to create an issue to track the differences between graphs and datasets in JSON-LD.
Niklas Lindström: We need to be sure we don't end up with something that only represents datasets.
… It's important that a JSON-LD document be useable as a named graph, even if it describes a default graph.
Manu Sporny: sandro things that "adding meaning" doesn't actually add meaning.
Niklas Lindström: .. sandro suggested: "it means adding information which enables disambiguating the relational structure and the identities of the elements of that structure"
Richard Cyganiak: there might be some useful phrases that could come in if we push back.
Manu Sporny: Ivan brought this up. The concerns are that the RDF WG doesn't have the constituency to create WebID.
… The other concern is that having WebIDL being normative is confusing.
Richard Cyganiak: "JSON-LD Processing and Data Model"? And keep the API part in?
Manu Sporny: we could either split the WebIDL out or keep it in as an appendix.
Gregg Kellogg: Richard had a great e-mail earlier today regarding orthogonality in specs - particularly relating to strongly relating Syntax with Behavior. That orthogonality argument also relates to having a concrete WebIDL API as a part of the specification. [scribe assist by Manu Sporny]
Gregg Kellogg: Doing so tends to limit the appliciability of the specifications, it's crossing over in domains - it's not key in what they're trying to accomplish. [scribe assist by Manu Sporny]
Richard Cyganiak: I didn't have JSON-LD in mind when sending this email; it really is about RDF Concepts. Anything you do there has consequences depending on how other specs depend on it.
… If you have something new, that doesn't have such complicated interdependencies, it is not necessarily a bad thing, and there is a cost in separating things into multiple documents.
François Daoust: I would prefer that we leave the WebIDL in; if we move it, it could just disappear.
… The syntax and the algorithm are tightly tied together, and right now, it's an informative reference.
… I would have only a single document.
… It shouldn't be a problem to have each normatively reference the other.
Markus Lanthaler: we should keep in mind the different audiences for each document.
… The RDF WG is more interested in the algorithms.
… We should be clear on the audience.
… I don't think we need a normative reference from the Syntax to the API, but it is just a minor edit.
Manu Sporny: one reason is that there are two specs is that we decided early on that we shouldn't tightly link them as it might make a problem going to REC.
… We also tried to make sure there are no normative references from Syntax to API.
… I think the positive effect of splitting the two is that it makes the Syntax spec stand alone, and could allow us to go to rec at a different pace.
Richard Cyganiak: I think specs should be written with implementers in mind foremost.
… In this case, it makes sense to focus on implementers of the algorithms; developers just need the API documentation.
… It might be better communicated using documentation of a particular library.
… If you believe that the documentation can be provided differently, it makes less sense to keep them separate.
Markus Lanthaler: it's more about the message if you call it "Core Processing" rather than "API".
… I would say that developers are more likely to look at an API spec, rather than one which is focused around algorithms.
François Daoust: moving to an appendix doesn't really change anything in practice.
Manu Sporny: we wanted to give the reader a gentle intro to the material. The WebIDLE seemed to be the easy way into the document.
Gregg Kellogg: If we do rename it as Core Processing, it makes sense to move the WebIDL down to an appendix. This is an issue that was of big concern in the RDF WG. [scribe assist by Manu Sporny]
… Ivan's reading it differently, in that if you don't correspond exactly to the WebIDL.
Niklas Lindström: I agree with the change to "Core Processing".
… It feels better.
Manu Sporny: two big issues: JSON-LD to RDF data model mapping.
Topic: ISSUE-159: Add specifying @language to expanded form
… The other is the language container discussion.
… We're still trying to figure out what we're going to do, BNodes or @language syntax, and just do in RDF.
Gregg Kellogg: I think I'm in the minority when I want to create bnodes for language maps in expanded form. [scribe assist by Manu Sporny]
Gregg Kellogg: I did discuss this at length w/ Lin - she is concerned about this not being in the best interest of Drupal. [scribe assist by Manu Sporny]
Markus Lanthaler: Richard, would be very interested hearing your opinion on this, e.g., introduction of jsonld vocab vs. dc:language
Gregg Kellogg: I think differently, I think we're creating a divergence in the JSON-LD data model and the RDF data model - I'm not as sympathetic to the concerns in expanded form that there are some nodes represented there. [scribe assist by Manu Sporny]
Gregg Kellogg: However, unless there is support for bnodes in expansion, I think we'll have to go the other way. [scribe assist by Manu Sporny]
Niklas Lindström: I also feel that BNodes in expanded form are a better way to go.
… Perhaps we don't need an intermediate BNode if we fold @language into the resource, and relate it to dc:language, say.
Richard Cyganiak: Markus, I haven't fully followed the discussion so far I'm afraid
Gregg Kellogg: I need to look at it in more depth. [scribe assist by Manu Sporny]
Markus Lanthaler: Richard, basic question is how to "language-tag" resources
Niklas Lindström: I am concerned about moving too far away from RDF.
Manu Sporny: I'm not so concerned about divergence between JSON-LD and RDF data models, but more concerned with the Drupal community.
… If we do the translation to a BNode we're working against what the spec enables.
… It seems like it will be more difficult for developers to work with expanded form.
Markus Lanthaler: Are we going to allow nodes to be language tagged or not. If we are, then we need to either introduce vocabulary or @language.
… This allows us to split JSON-LD from RDF mapping.
Niklas Lindström: I think the intermediate BNode might not be necessary, if we interpret @language to map to dc:language.
Manu Sporny: If we take Markus' points and separate @language being in expanded form, and taking the mapping to dc:language as being difference.
Gregg Kellogg: I think this approach is good - clear mapping to RDF (we use dc:language) [scribe assist by Manu Sporny]
Gregg Kellogg: we also avoid bnodes in expanded form... we may want to mint a JSON-LD namespace property that has a link with dc:language? [scribe assist by Manu Sporny]
Gregg Kellogg: Is there a similar property in RDF to dc:language? [scribe assist by Manu Sporny]
Gregg Kellogg: I think binding to dc:language to it doesn't make it weaker. [scribe assist by Manu Sporny]
Manu Sporny: let's just bind @language to dc:language in the spec.
ACTION: Gregg to write up proposal in language maps.