Manu Sporny: 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
Richard Cyganiak: 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.
Manu Sporny: 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
David Wood: 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
Manu Sporny: 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
Manu Sporny: The one thing I can see is that the RDF WG might not be interested in publishing the API due to potential charter issues.
Ivan Herman: 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.
Gregg Kellogg: I did most of the work on the RDF conversion algorithms
Gregg Kellogg: 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.
Manu Sporny: I'm somewhat concerned on changing the spec based on what the RDF WG charter says instead of doing what would make most sense
David Wood: as long as go over the patent-policy hurdle it's easier... otherwise we have a major problem.
Richard Cyganiak: 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
Manu Sporny: +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)
Ivan Herman: 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
Manu Sporny: 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
Ivan Herman: 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
Gregg Kellogg: 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.
Manu Sporny: 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
Ivan Herman: that's not quite correct
... if the RDF WG is going to publish a standard it has to be fully specified and complete
David Wood: +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
Manu Sporny: 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.
Ivan Herman: the problem is that we are pushing one doc through the process and not the other
Manu Sporny: 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.
Ivan Herman: I would be fine with that
David Wood: I'm wondering how much "Linked Data" JSON-LD can be if it can't be transformed to RDF
Manu Sporny: 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.
François Daoust: I agree with Manu. JSON-LD is pretty useful without the RDF bits.
Manu Sporny: I'm just saying it stands on it's own
David Wood: 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.
Gregg Kellogg: 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.
Richard Cyganiak: 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
Gregg Kellogg: +1 to cygri
Manu Sporny: 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.
Markus Lanthaler: 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]
Markus Lanthaler: expansion, compaction, to/from RDF are fairly stable.... [scribe assist by Manu Sporny]
Ivan Herman: So, perhaps we could take framing out and just publish JSON-LD API? [scribe assist by Manu Sporny]
Ivan Herman: then we might just extract framing and publish the rest if it's stable
Markus Lanthaler: 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]
Ivan Herman: 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]
Markus Lanthaler: 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]
Manu Sporny: Maybe we publish JSON-LD Syntax and JSON-LD API (modulo framing)? [scribe assist by Manu Sporny]
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)
Ivan Herman: the only concern I have is that APIs are not in the RDF WG charter
David Wood: I don't think it's our biggest issue... we may be making this into a bigger issue than it is.
Manu Sporny: 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.
David Wood: yes, I think that's fine
... but prepare to be flexible and together we will find a way forward...
Richard Cyganiak: 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.
David Wood: +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
Manu Sporny: 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.
David Wood: well you have specs that can be read, that's a positive. Folks are going to have to RTFM before raising real technical issues.
Manu Sporny: 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.
Manu Sporny: 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
David Wood: you should apply via the invited expert form if you have not done so already
Manu Sporny: the only other remaing thing: how do we track issues?
... is it ok to continue on GitHub?
Ivan Herman: 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
Manu Sporny: should we continue to have separate telecons?
David I. Lehn: May be more efficient to do so.
Ivan Herman: 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...
Manu Sporny: 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
David Wood: That would make a nice WG Note, but we aren't chartered to standardize it.
David Wood: Yes, Ivan and I agree
Ivan Herman: 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
David Wood: The RDF WG will consider n-quads, but not yet
Gregg Kellogg: does the WG considers standardizing N-Quads?