JSON-LD Telecon Minutes for 2013-01-08

The minutes from today's telecon are now available. Thanks to Markus for
scribing!

http://json-ld.org/minutes/2013-01-08/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2013-01-08

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Jan/0006.html
Topics:
   1. State of JSON-LD Documents
   2. ISSUE-153: Define error handler behavior
   3. ISSUE-178: Consider renaming JSON-LD API to JSON-LD Core
      Processing
   4. ISSUE-204: Compact @id's to relative IRIs
   5. ISSUE-205: Use the term URL instead of IRI in the (API)
      spec
   6. ISSUE-207: Handling of free-floating values in
      flattening/toRDF
Resolutions:
   1. Accept the JSON-LD API spec text on error handling with a
      few modifications - remove the issueCallback mechanism from
      JsonLdOptions, remove severity fromJsonLdProcessorIssue, rename
      JsonLdProcessorIssue to JsonLdError.
   2. Rename JSON-LD syntax spec to "JSON-LD 1.0 - A JSON-based
      Serialization for Linked Data" and the API spec to "JSON-LD 1.0
      Processing Algorithms and API (no subtitle)"
   3. Do not allow terms as values for @id.
   4. The following value types are supported for @id - document
      relative IRIs, absolute IRIs, and CURIEs.
   5. When compacting, attempt to compact absolute IRIs to
      document-relative IRIs.
   6. Include the text "Throughout this specification, the term
      'URL' means IRI as defined in RFC3987. The reason we use URL is
      because it is more familiar to Web developers." and use the term
      URL everywhere in both specifications.
   7. JSON-LD Processors do not modify URLs other than to
      translate between relative and absolute URLs. Specifically, they
      do not implement the URL processing rules as outlined in the
      HTML5 specification.
   8. Disallow free-floating values and IRIs in the JSON-LD Data
      model. If a free-floating value/IRI is detected during expansion,
      drop the value/IRI.
Chair:
   Manu Sporny
Scribe:
   Markus Lanthaler
Present:
   Markus Lanthaler, Manu Sporny, Gregg Kellogg, François Daoust,
   Lin Clark
Audio:
   http://json-ld.org/minutes/2013-01-08/audio.ogg

Markus Lanthaler is scribing.

Topic: State of JSON-LD Documents

Manu Sporny:  Thanks to Markus and Gregg's editorial work, I
   think we're in really good shape for Last Call.
Manu Sporny:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Jan/0000.html
Manu Sporny:  I still hope we can get to LC by the end of January
   ... but there are some things we still need to discuss
   ... for example the ABNF stuff Markus has send to the mailing
   list
   ... I agree with Gregg's concerns.. for example we should not
   make people believe that documents violating the grammar will not
   be parsed.
   ... the JSON-LD API doc is feature-complete - I think
   ... the major discussion is around the algorithms
   ... we should make them as easy as possible to read without
   introducing ambiguity, descriptive instead of proscriptive
   ... seeing the discussion on the mailing list I think we just
   need to make a few more iterations to improve it
   ... my first priority is to complete the syntax spec for last
   call
Gregg Kellogg:
   http://json-ld.org/spec/latest/json-ld-api/alternate.html
   ... Gregg has been working on the algorithms, Dave Longley and
   myself probably will do another pass
Gregg Kellogg:  I finished my work on the algorithms, I published
   it here:
   http://json-ld.org/spec/latest/json-ld-api/alternate.html
   ... I stick closer to the original algorithms
Markus Lanthaler:  I've looked at Gregg's algorithms - some of
   the stuff isn't properly spec'd, I think (don't know if I
   misunderstood some of the algorithms) [scribe assist by Manu
   Sporny]
Markus Lanthaler:  There are some MUST statements in there that I
   don't think are necessary - we shouldn't duplicate normative spec
   text that is in the Syntax spec. [scribe assist by Manu Sporny]
Gregg Kellogg:  I was attempting to replace a similar expression
   that said that it needed to raise an error - it acted as a hook
   for the API. "If the expectation was violated for 2.3, then raise
   this exception" [scribe assist by Manu Sporny]
Gregg Kellogg:  If there is some way to rephrase that, then that
   would be fine if it's not normative text. [scribe assist by Manu
   Sporny]
Markus Lanthaler:  This is the reason I didn't put stuff in to
   raise an error - it's still separated from the API, you just
   specifically enumerate the errors. [scribe assist by Manu Sporny]
Manu Sporny:  it's a strange issue.. we want to make it easy for
   implementers to know where which errors should be raised, at the
   same time we want to separate the algorithms from the API
Gregg Kellogg:  yeah, I didn't want to be explicit about an
   error. We could put something in there that points to the API.
   [scribe assist by Manu Sporny]
Manu Sporny:  Gregg, from what I understand you took Markus'
   algorithms and tried to stick closer to the previous algorithms
Gregg Kellogg:  Yeah.. expansion is more or less the same as
   Markus'
   ... context processing is quite different I would say.. for
   example I don't use a vocabRelative flag
   ... in IRI expansion e.g. I just said that there must not be a
   recursive term definition instead of exactly prescribing how to
   do it
   ... most changes are in Compaction
   ... and IRI Compaction continues to use Term Ranking with
   minor modifications
   ... I think having term ranking is simpler than having an
   inverse context
   ... it has been very difficult for me to understand the
   inverse context
Markus Lanthaler:  We could simplify toRDF/fromRDF if we flatten
   the document first, and then we run the toRDF() algorithm on it.
   [scribe assist by Manu Sporny]
Gregg Kellogg:  It's not too many steps, there might be some
   benefits to be gained by flattening. [scribe assist by Manu
   Sporny]
Gregg Kellogg:  The only changes I needed to make was to make
   sure that when we were creating new bnodes that it continues
   using the same bnode generator that we used during the expansion
   phase. [scribe assist by Manu Sporny]
Manu Sporny:  One of the things we almost definitely will put in
   the document is that the outcome of the algorithms is not going
   to change in LC but they might be modified to be simpler to read
Gregg Kellogg:  currently I don't pass any of the flattening
   tests whereas I passed them all before
   ... I think that's mostly because I ignore property-less nodes
Gregg Kellogg:  Markus did you change anything dramatically in
   the algorithm?
Markus Lanthaler:  No, the only fundamental change was that now
   all graphs will be in the flattened output whereas before there
   was always just one

Topic: ISSUE-153: Define error handler behavior

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/153
Manu Sporny:  I went ahead and updated the spec with the error
   handler behavior
   ... Markus had some concerns about the complexity of the
   implementation, he thinks it goes a bit too far
   ... basically saying that non-fatal errors are just useful for
   validators/linters
   ... and that standardizing all possible issue codes is time
   consuming
Markus Lanthaler:  We have two error handling mechanisms now, one
   for fatal errors, another for warnings and non-fatal errors.
   [scribe assist by Manu Sporny]
Markus Lanthaler:  This is debug output - you can't really do
   anything useful with it. It might be nice to have the debug
   output, in the end, it wouldn't help you at all. The provided
   information is by no means enough to do anything useful with it.
   [scribe assist by Manu Sporny]
Markus Lanthaler:  You can't track the message back to a specific
   location in the document. [scribe assist by Manu Sporny]
Markus Lanthaler:  You can't implement a validator that
   highlights the parts that caused an error or a problem. I don't
   think it makes sense to specify it. It is potentially more
   harmful than helpful. [scribe assist by Manu Sporny]
Markus Lanthaler:  I would propose that JsonLdOptions can be
   extended by concrete implementations - any implementation is free
   to add other debugging/monitoring functionality. [scribe assist
   by Manu Sporny]
Markus Lanthaler:  We just specify where JSON-LD processors stop,
   and the error conditions for those. [scribe assist by Manu
   Sporny]
Manu Sporny:  One of the issues I always had with JavaScript is
   that you don't get such information
   ... all you get is "processing failed"
   ... you don't know why it failed
   ... you don't get warnings - a lot of developers might want to
   have just that
   ... I also don't think we need to standardize every issue code
   ... we could let that organically grow. There wouldn't be that
   much of an implementation-burden for us as spec writers
   ... yes, we don't have line numbers etc. because JSON parsers
   don't provide that
   ... if the processor can get the line number somehow it should
   include that in the error
   ... so we should implementers not only say they can extend
   jsonLdOptions but also JsonLdProcessingIssue
   ... when we are developing systems we want to have this
   information
Gregg Kellogg:  I think it's useful to have these things but it
   may get burdening when we need to enumerate all those errors
   ... that would allow use to include even more debugging
   information
Manu Sporny:  would you be more happy with having more generic
   error codes for non-fatal errors
Discussion about whether non-fatal error reporting should be
   specified
Gregg Kellogg:  I agree that having debugging output is useful
   but I also agree that it might not be necessary to put this into
   the spec
   ... for example in my Turtle processor it would have been much
   more difficult to include all the debugging information if the
   specs would have been very specific about it
Manu Sporny:  Are you saying that we don't need to specify that
   callback?
Gregg Kellogg:  In my case in Ruby, the more specific we get in
   the JSON-LD API the less similar my Ruby implementation looks to
   the API
   ... because it's just not done that way in Ruby
Manu Sporny:  Right, one piece I updated in the spec is that this
   API is meant to be implemented in JavaScript
François Daoust:  I think I share the view that Markus has
   ... but it doesn't really change the API
   ... it's just a property in JsonLdOptions
   ... but I think it that should be left to implementations
   ... I would drop the issueCallback property
Manu Sporny:  gregg, you were one of the people who wanted to
   have multiple levels of issues - any thoughts?
Gregg Kellogg:  I think we can leave it up to the
   implementations.

PROPOSAL: Accept the JSON-LD API spec text on error handling with
   a few modifications - remove the issueCallback mechanism from
   JsonLdOptions, remove severity fromJsonLdProcessorIssue, rename
   JsonLdProcessorIssue to JsonLdError.

Gregg Kellogg: +1
Manu Sporny: -0.3 (but I can live with it)
Markus Lanthaler: markus: +1
François Daoust: +1

RESOLUTION: Accept the JSON-LD API spec text on error handling
   with a few modifications - remove the issueCallback mechanism
   from JsonLdOptions, remove severity fromJsonLdProcessorIssue,
   rename JsonLdProcessorIssue to JsonLdError.

Topic: ISSUE-178: Consider renaming JSON-LD API to JSON-LD Core Processing

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/178
Manu Sporny:  Markus' PROPOSAL 6 seem to have broad agreement:
   Rename JSON-LD syntax spec to "JSON-LD 1.0 - A JSON-based
   Serialization for Linked Data" and the API spec to "JSON-LD 1.0
   Processing Algorithms and API" (without subtitle)
Manu Sporny:  I'm not sure we are allowed to have no subtitle
François Daoust:  I think we don't need to have one
   ... but rules might have changed

PROPOSAL: Rename JSON-LD syntax spec to "JSON-LD 1.0 - A
   JSON-based Serialization for Linked Data" and the API spec to
   "JSON-LD 1.0 Processing Algorithms and API (no subtitle)"

Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
François Daoust: +1

RESOLUTION: Rename JSON-LD syntax spec to "JSON-LD 1.0 - A
   JSON-based Serialization for Linked Data" and the API spec to
   "JSON-LD 1.0 Processing Algorithms and API (no subtitle)"

Markus Lanthaler:  could we have the short name json-ld instead
   of json-ld-syntax
Manu Sporny:  yes, I think.. we would have to request it
Gregg Kellogg:  I think we might also should change json-ld-api
   to something else as the emphasis is on the algorithms
François Daoust: [re. possibility not to have a subtitle, I note
   the "pub rules" and the sample document they provide do not even
   mention subtitles:
   http://www.w3.org/2005/07/pubrules?uimode=filter#sample-template
   ]
Manu Sporny: shortname - 'json-ld'
Manu Sporny: title - "JSON-LD 1.0"
Manu Sporny: subtitle - "A JSON-based Serialization for Linked
   Data"
Manu Sporny: shortname - 'json-ld-processing'
Manu Sporny: title - "JSON-LD 1.0 Processing Algorithms"
Manu Sporny: subtitle - "Processing Algorithms and API"
Markus Lanthaler:  the only problem I see with this is that API
   wouldn't appear in search results as it's not in the title
   anymore
Manu Sporny:  Gregg, would you be fine to keep what we resolved
   to?
Gregg Kellogg:  Yes, I think if we would do it again we put more
   emphasis on the algorithms

Topic: ISSUE-204: Compact @id's to relative IRIs

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/204
Manu Sporny:  I think we have broad agreement to not allow terms
   as value for @id

PROPOSAL: Do not allow terms as values for @id.

Manu Sporny: +1
Gregg Kellogg: +1
François Daoust: +1
Markus Lanthaler: +1

RESOLUTION: Do not allow terms as values for @id.

Gregg Kellogg:  the question is also whether we allow CURIEs
Manu Sporny: Lin, does Drupal need the use of CURIEs in @id? So,
   for example - "@id": "site1:/nodes/1"
Manu Sporny:  I thought that was important for Drupal. [scribe
   assist by Manu Sporny]
Lin Clark:  I think we could switch to relative IRIs
   ... but I honestly can't say it for sure
   ... I would have to think more about it
Manu Sporny:  We are getting rid of terms in @id
   ... we might also get rid of CURIEs
Lin Clark:  that would be fine for us I think
Gregg Kellogg:  there's not an issue with CURIEs though.. there's
   just a problem with terms
   ... we don't have base so CURIEs could be used instead
Markus Lanthaler:  the issue is that sometimes a relative IRI
   becomes a CURIE after expanding->compacting
Manu Sporny:  that would certainly be surprising for developers.
   I think we should compact to the simplest thing, which probably
   is a relative IRI
Gregg Kellogg:  we could compact to the shortest
   ... the developer has control of the context.. so just don't
   define a term
Manu Sporny: order of operations when expanding for @id - CURIE,
   relative IRI, absolute IRI
it's CURIE, absolute IRI (colon), relative IRI
Manu Sporny: order of operations when compacting an @id - CURIE,
   relative IRI, absolute IRI
so... noprefix:something will end up being interpreted as
   absolute IRI
Manu Sporny: what about URLs like this - urn:foo:bar
Manu Sporny: where the developer uses a relative 'bar'
Manu Sporny: @id : "bar" where base = "foo:bar:" - will that
   roundtrip?
Manu Sporny: The group believes that it will round-trip based on
   the current algorithms.

PROPOSAL: The following value types are supported for @id -
   document relative IRIs, absolute IRIs, and CURIEs.

Markus Lanthaler: +1
Gregg Kellogg: +1
Manu Sporny: +1
François Daoust: +1

RESOLUTION: The following value types are supported for @id -
   document relative IRIs, absolute IRIs, and CURIEs.

PROPOSAL: When compacting, attempt to compact absolute IRIs to
   document-relative IRIs.

Gregg Kellogg: +1
Manu Sporny: +1
François Daoust: +1
Markus Lanthaler: +1

RESOLUTION: When compacting, attempt to compact absolute IRIs to
   document-relative IRIs.

Topic: ISSUE-205: Use the term URL instead of IRI in the (API) spec

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/205
Manu Sporny:  This nomenclature discussion comes up every single
   time we try to put "IRI" into a specification. The problem is
   that the HTML5 spec uses URL, and Web developers are more
   familiar with URL instead of IRI. We are trying to build
   something useful for Web developers, so I think we should
   probably use 'URL'.

PROPOSAL: Include the text "Throughout this specification, the
   term 'URL' means IRI as defined in RFC3987. The reason we use URL
   is because it is more familiar to Web developers." and use the
   term URL everywhere in both specifications.

Manu Sporny: +1
François Daoust: +1
Gregg Kellogg: +1
Markus Lanthaler: +1

RESOLUTION: Include the text "Throughout this specification, the
   term 'URL' means IRI as defined in RFC3987. The reason we use URL
   is because it is more familiar to Web developers." and use the
   term URL everywhere in both specifications.

Markus Lanthaler:  This is what we currently have in the spec:
This specification does not define how JSON-LD Implementations or
   Processors handle non-conforming input documents. This implies
   that JSON-LD Implementations or Processors must not attempt to
   correct malformed IRIs or language tags; however, they may issue
   validation warnings.

PROPOSAL: JSON-LD Processors do not modify URLs other than to
   translate between relative and absolute URLs. Specifically, they
   do not implement the URL processing rules as outlined in the
   HTML5 specification.

Gregg Kellogg: +1
Manu Sporny: +1
François Daoust: +1
Markus Lanthaler: +0

RESOLUTION: JSON-LD Processors do not modify URLs other than to
   translate between relative and absolute URLs. Specifically, they
   do not implement the URL processing rules as outlined in the
   HTML5 specification.

Topic: ISSUE-207: Handling of free-floating values in flattening/toRDF

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/207
Manu Sporny:  the question is, how do we handle free-floating
   values?
Markus Lanthaler:  so, what should happen for @graph: { "@id":
   "/test" }
Markus Lanthaler:  @graph: { "@id": "/test", "doesntexpand": true
   } -- drop @id object?
Manu Sporny:  yep, drop it [scribe assist by Manu Sporny]

PROPOSAL: Disallow free-floating values and IRIs in the JSON-LD
   Data model. If a free-floating value/IRI is detected during
   expansion, drop the value/IRI.

Markus Lanthaler: +1
Manu Sporny: +1
François Daoust: +1
Gregg Kellogg: +1

RESOLUTION: Disallow free-floating values and IRIs in the JSON-LD
   Data model. If a free-floating value/IRI is detected during
   expansion, drop the value/IRI.

Manu Sporny:  I can't say this enough - you guys rock! Thank you
   for all of your great work - Markus, Gregg, Francois, Dave
   Longley, Dave Lehn, and all of the other folks that have
   contributed to the JSON-LD specs. We're in very good shape for
   Last Call, and the specs are in very good shape overall thanks to
   each of your hard work! Can't emphasize that enough. [scribe
   assist by Manu Sporny]

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: HTML5 and RDFa 1.1
http://manu.sporny.org/2012/html5-and-rdfa/

Received on Tuesday, 8 January 2013 18:14:30 UTC