JSON-LD Telecon Minutes for 2012-05-29

Thanks to Markus for scribing! The minutes from today's call are now
available here:

http://json-ld.org/minutes/2012-05-29/

Full text of the discussion follows including a link to the audio
transcript:

--------------------

JSON-LD Community Group Telecon Minutes for 2012-05-29

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012May/0072.html
Topics:
    1. RDF WG Spec Concerns
    2. Concerns about Publishing JSON-LD API
    3. JSON-LD CG to RDF WG document transition
Chair:
    Manu Sporny
Scribe:
    Markus Lanthaler
Present:
    Markus Lanthaler, Manu Sporny, Richard Cyganiak, David Wood, Ivan
    Herman, Gregg Kellogg, François Daoust, David I. Lehn
Audio:
    http://json-ld.org/minutes/2012-05-29/audio.ogg

Markus Lanthaler is scribing.

Topic: RDF WG Spec Concerns

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/127
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/131
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.

Topic: JSON-LD CG to RDF WG document transition

Manu Sporny: http://www.w3.org/community/reports/reqs/
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?
Ivan Herman:  there's no consensus on this

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Tuesday, 29 May 2012 16:05:16 UTC