JSON-LD Community Group Telecon
Minutes for 2012-05-29
RDF WG Spec Concerns
Concerns about Publishing JSON-LD API
JSON-LD CG to RDF WG document transition
Markus Lanthaler, Manu Sporny, Richard Cyganiak, David Wood, Ivan Herman, Gregg Kellogg, François Daoust, David I. Lehn
Warning: Your browser does not support the HTML5 audio element, please upgrade.
Markus Lanthaler is scribing.
Topic: RDF WG Spec Concerns
: Richard, would you mind giving a quick overview of the issues you raised?
... also Pat Hayes raised some issues, which are also tracked in ISSUE-131
: the issues that I raised are mostly about the API spec, WebIDL stuff
... the terminology should be changed to match the RDF Concepts
... the normative definition of the data model is in the RDF Concepts spec.
... issue 131 is basically about aligning the terminology with what we have in RDF Concepts
... some problems come from the fact that JSON-LD is slightly different than what RDF COncepts talks about and defines some things as a programmatic interface via WebIDL, so it might not always work out nicely
... nevertheless it's still worth trying to align it.
... I agree with Pat that some things are not that clear in text - graphs etc. - Pat gave some good input there.
: I think both of you made some good points
... we are going to be trying to address them in the next few weeks
... the confusion is probably for a number of reasons: 1) The JSON-LD API spec wasn't ready for review, 2) We have slightly different terminology because of the Linked Data vs. RDF stuff and 3) Hold-overs from the RDF API that is language that is over 18 months old.
... there are some things like predicate vs. property where we might need some more discussion.. but there shouldn't be any show-stoppers here
... some terms were pulled over from the RDF API spec which is clearly outdated
: the RDF WG is very happy with JSON-LD so far.
... even Turtle - which is everyone's darling - has these problems... we have been tweaking it now for a year and are still not done yet
... I think we are all very happy working with JSON-LD
: I don't see any show stoppers at this point either, good.
... I hope no one in the RDF WG sees any show stoppers.
Topic: Concerns about Publishing JSON-LD API
: The one thing I can see is that the RDF WG might not be interested in publishing the API due to potential charter issues.
: outsiders that need to approve what the WG does might disagree because the API is not on the charter.
... depends also what will be done with the RDF conversion stuff
... those algorithms have to end up in the RDF WG at some point, the other JSON-LD API methods like compact/expand/etc. don't necessarily have to end up in RDF WG.
... I'm still a bit uncertain about the other algorithms
... there is an alternative - extract RDF algorithms in a separate document or put them into the syntax doc.
: I did most of the work on the RDF conversion algorithms
: the RDF algorithms depend on the expansion algorithm, so we'd have to move that over as well.
... framing is more experimental...
... compaction is used to make JSON-LD more human-readable
... so we will at least need expansion for the RDF algorithms.
... I don't think the RDF algorithms are tightly bound to the API (WebIDL), we could separate them.
... it would be fairly straightforward to separate the algorithms from the WebIDL stuff.
: I'm somewhat concerned on changing the spec based on what the RDF WG charter says instead of doing what would make most sense
: as long as go over the patent-policy hurdle it's easier... otherwise we have a major problem.
: it would be a bit premature to talk about graphs since the RDF WG is still discussing that... most likely not quads but more what SPARQL does.
... JSON-LD isn't one monolithic thing.. there is syntax, algorithms, etc. and different parts have different levels of maturity
: +1 to what cygri just said.
... so it might reasonable to go with through the W3C process with the mature ones and split out the rest (for the time being)
: some of the algorithms in the API spec need the term experimental
... that worries me a bit
... if we take them through the whole process it will keep back JSON-LD from being standardized in time (the RDF charter is fixed)
... which would mean that we can't finalize JSON-LD Syntax either
... I'm in favour of extracting the RDF algorithms, put it into syntax spec and go on
: that's one path forward
... and we don't want the API to become the blocker
... maybe two docs (syntax + RDF algorithms) and take them to REC...
... and publish the rest of the API at a later point in time
: for me the algorithmic description of how to transform JSON-LD to RDF and vice versa would be enough.. doesn't have to be specified in terms of an API
: most of the body of the API spec is algorithmic and the WebIDL part is quite small
... so we could describe the algorithms not using API terms pretty easily since it's already done like that.
: if we reorganize the specs there will be quite some discussion on how to do it, I'm afraid of burning time doing this
... we would be adding a bit of overhead here...
... part of me is concerned that we are doing all of this work just because we're standardizing in RDF WG vs. a JSON-LD WG
: that's not quite correct
... if the RDF WG is going to publish a standard it has to be fully specified and complete
: +1 to Ivan; The spec needs to be complete, including the RDF conversion.
... the RDF conversion is integral and has to be on the same level of maturity of the JSON-LD spec itself
... and that's why we are going down this discussion
: RDF conversion is a requirement of the RDF WG but it wouldn't be a requirement for a JSON-LD WG
... if we would go through another WG we wouldn't be having this discussion... just outlining this point - we'd still publish a to/from RDF conversion algorithm.
: the problem is that we are pushing one doc through the process and not the other
: no, both would be there.. to/from RDF in a separate doc and the JSON-LD Syntax - that's the best approach we have right now.
: I would be fine with that
: I'm wondering how much "Linked Data" JSON-LD can be if it can't be transformed to RDF
: just as an example.. internally at Digital Bazaar we use JSON-LD completely without RDF (no triples, no triple store, no SPARQL, etc.)
... I'm not saying the conversion to RDF isn't useful... it's just not necessary in our case.
: I agree with Manu. JSON-LD is pretty useful without the RDF bits.
: I'm just saying it stands on it's own
: it's not the use of a triple store that defines RDF. RDF is a data model.
... and that data model has its use as well without triple stores, etc.
: a lot of those issues go back to last summer when we discussed what Linked Data is
... a lot of people jumped in and said Linked Data != RDF
... that's were that "bnode is not linked data" statement comes from
... we just have to make sure to not get into the way of developers that had bad experiences with RDF before... it's a hard line to walk.
: your linked data model is quite in line with what RDF's data model is
... another option: could we put the data model that you define in the API spec into the RDF Concepts
: +1 to cygri
: JSON-LD is basically RDF but we try to paper over RDF with language that is more accessible to non-computer-science-types... to make it compelling for web developers.
... so I don't know if using the RDF Concepts terminology scares average developers away.
: Simple question - if you're looking at the API spec, there are a number of algorithms in there - the only experimental one in there right now is framing... why not just pull that out? [scribe assist by Manu Sporny]
: expansion, compaction, to/from RDF are fairly stable.... [scribe assist by Manu Sporny]
: So, perhaps we could take framing out and just publish JSON-LD API? [scribe assist by Manu Sporny]
: then we might just extract framing and publish the rest if it's stable
: The other question is how long is the process going to take? If we start the process now, we don't have to publish the standard tomorrow or in two weeks? [scribe assist by Manu Sporny]
: Until Last Call - we can have features in there that won't be in the standard... that's fine in a First Public Working Draft and Working Drafts. [scribe assist by Manu Sporny]
: I think we're discussing a lot of things that are not critical - we can extract this stuff into another document at a later time. [scribe assist by Manu Sporny]
: Maybe we publish JSON-LD Syntax and JSON-LD API (modulo framing)? [scribe assist by Manu Sporny]
: would it be OK for the RDF WG to proceed with the syntax and API spec and maybe take out framing (now or later)
: the only concern I have is that APIs are not in the RDF WG charter
: I don't think it's our biggest issue... we may be making this into a bigger issue than it is.
: so would you see that as a way forward? We publish JSON-LD Syntax and JSON-LD API (without framing)? I can send an e-mail to this effect if we're all okay with this approach.
: yes, I think that's fine
... but prepare to be flexible and together we will find a way forward...
: the few of us that are here today can't speak for the majority of the RDF WG
... you never know what may come up during the discussion
... people often feel reluctant to agree on something that they don't understand
... so you will probably need to do a lot of explaining.
: +1 to Richard - expect to explain (and be flexible)
... what this group is proposing is bigger than just a simple JSON serialization (not that that is a bad thing)
... you have to be prepared for push-back on that
... it takes time but is not a fundamental obstacle
: I hope we get enough time to explain the stuff, I'd hate to be given only one telecon to summarize, explain and defend 18+ months of work.
: well you have specs that can be read, that's a positive. Folks are going to have to RTFM before raising real technical issues.
Topic: JSON-LD CG to RDF WG document transition
: there are very specific steps to transition from a CG to the WG
... the two major things we need to do
... 1) All JSON-LD CG members that contributed text to the spec will have to fill out the patent coverage form so that copyright and patent coverage is clear.
... 2) We need to change the copyright from Creative Commons Attribution 1.0 to the permissive W3C license (which still allows us to fork the spec if things go terribly wrong)
... once we transfer the document to the RDF WG, it can not be worked on by non-RDF WG members anymore.
: so we need to make sure that everyone in the CG that is contributing work is an invited expert or similar to be able to continue to work on this
: you should apply via the invited expert form if you have not done so already
: the only other remaing thing: how do we track issues?
... is it ok to continue on GitHub?
: there's no process issue with this
... only thing is that you can proof that all issues have been taken into account
... as soon as we have a FPWD we move over the issue tracker to make collaboration easier
: should we continue to have separate telecons?
David I. Lehn
: May be more efficient to do so.
: yes, I thought about that.. we might need to do this for the time being
... but the RDF WG would need to make the final resolutions.
... on a different note: the canonilization should really be separate from JSON-LD...
: yes, we separated it - and we think we have a generalized RDF graph normalization algorithm. The serialization format is in quads, which is why we have Quads in the JSON-LD API.
... so, yes I think we have a generic normalization algorithm now
: That would make a nice WG Note, but we aren't chartered to standardize it.
: Yes, Ivan and I agree
: this is not something that the RDF WG would publish as a spec but at least as a working group note and specify it in two years or so
: The RDF WG will consider n-quads, but not yet
: does the WG considers standardizing N-Quads?
: there's no consensus on this