W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2013

JSON-LD Telecon Minutes for 2013-02-26

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 26 Feb 2013 15:46:00 -0500
Message-ID: <512D1F08.7000104@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
CC: RDF WG <public-rdf-wg@w3.org>
The minutes from today's telecon are now available.


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

JSON-LD Community Group Telecon Minutes for 2013-02-26

   1. JSON-LD Icons
   2. Jeremy Carroll's request for @base
   3. ISSUE-217: Disallow BNode identifier as Graph Name
   4. ISSUE-218: Algorithm specification updates by editors
   5. Publication Timeline
   1. Add @base to the JSON-LD syntax as an at-risk feature.
   2. Support @base and @language declarations in the @context.
      Warn developers that JSON-LD contexts that are to be used as
      remote contexts probably shouldn't include @language or @base.
   3. JSON-LD will continue to support blank node identifiers for
      properties and graph names. When converting data to RDF 1.1, the
      specification will not introduce any special checks to handle
      these specific cases. It is up to the implementations to figure
      out how to convert this data to something conformant to RDF 1.1.
   4. Mark property generators as an at-risk feature in JSON-LD
   Manu Sporny
   Manu Sporny
   Manu Sporny, Gregg Kellogg, Niklas Lindström, Dave Longley,
   François Daoust, Markus Lanthaler, David I. Lehn

Manu Sporny is scribing.
Manu Sporny:  Any updates/changes to the Agenda?
Gregg Kellogg:  Publishing schedule
Manu Sporny:  Ok.

Topic: JSON-LD Icons

Manu Sporny:  Dave Lehn put together a logo for JSON-LD.
General approval from the group on the icons.

Topic: Jeremy Carroll's request for @base

Manu Sporny:  Adding in @base might need to be done before LC and
   then marked as at-risk.
Niklas Lindström:  What's the alternative?
Manu Sporny:  You could create a term for the base IRI, and then
   append that to the beginning of an IRI.
Niklas Lindström:  I've always been pro @base, what you said is
   not the same thing.
Gregg Kellogg:  I agree - not having @base would require the
   document to be re-written.
Dave Longley:  I agree, easy feature to add.
Niklas Lindström:  It was missing from Turtle for a long time,
   and it was requested to add it.

PROPOSAL: Add @base to the JSON-LD syntax as an at-risk feature.

Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
François Daoust: +1
Niklas Lindström: +1
Markus Lanthaler: -0.5

RESOLUTION: Add @base to the JSON-LD syntax as an at-risk

Gregg Kellogg:  Is this limited to @context, or limited to the
   body? Can you use it in an object.
Manu Sporny:  Two ways we go about this - @base is not allowed in
   the context and must be in the body - or @base should be in
   @context only.
Niklas Lindström:  I like @base in the body of the document, not
   in the @context. Maybe @language in context is an argument for
   @base in context.
Gregg Kellogg:  Maybe we should disallow it from being used in a
   remote context.
Gregg Kellogg:  maybe we should add the same restriction for
   @language used in a remote context.
Markus Lanthaler:  The question is - do you trust the remote
   context? If you don't, you shouldn't use it.
Niklas Lindström:  That's true.
Niklas Lindström:  We could say that you SHOULD NOT use @base or
   @language in remote contexts.
Gregg Kellogg:  Maybe an organization only publishes in a certain
   language, so it makes sense to do so.
Manu Sporny:  Couldn't you just override the language in your
Dave Longley:  It could be null for transient messages...
Niklas Lindström:  Yes, you could set your @language and @base to
   null in your local context.
Gregg Kellogg:  if you set @base to null, you could just output
   relative IRIs... it's not legal in and of itself, anyone that is
   parsing the result can apply a base to it.
Manu Sporny:  So, we're saying @language and @base can be used
   both inside and outside the @context. You SHOULD NOT use it in
   remote context,
Markus Lanthaler:  normative statement about SHOULD NOT?
Gregg Kellogg:  I don't see a good reason to have @base or
   @language outside of @context. Putting it inside a local context
   ties everything up in one nice area in the document.
Manu Sporny:  Don't we support @language outside of @context now?
Dave Longley:  Nope.
Manu Sporny:  Ok, sound good.

PROPOSAL: Support @base and @language declarations in the
   @context. Warn developers that JSON-LD contexts that are to be
   used as remote contexts probably shouldn't include @language or

Niklas Lindström: +1
Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
François Daoust: +1
Markus Lanthaler: -0.5
David I. Lehn: +0

RESOLUTION: Support @base and @language declarations in the
   @context. Warn developers that JSON-LD contexts that are to be
   used as remote contexts probably shouldn't include @language or

Gregg Kellogg: Note, this does not represent a change for

Topic: ISSUE-217: Disallow BNode identifier as Graph Name

Manu Sporny:  it seems to be clear that the RDF WG won't make any
   change. Some people start to get annoyed [scribe assist by Markus
Markus Lanthaler: ... we might wanna propose to drop the feature
Markus Lanthaler: ... or we will keep it and say that such data
   won't round-trip
Markus Lanthaler: ... the alternative proposal in the blog post
   is so bad that we don't want to implement it. We think it will
   damage RDF in the long term
Markus Lanthaler: ... our preference would be to keep support for
   bnodes in predicates and graph labels
Markus Lanthaler: ... we shouldn't throw an error when converting
   to RDF
Niklas Lindström:  I am in agreement with you - as long as the
   language is explicit about this not working for compliant RDF
   systems, we support it syntactically, stay silent on it in
   spirit. People that need it can use it, but we can't guarantee it
   will work w/ legacy RDF systems. If you use the feature you'll be
   violating RDF 1.1 Concepts.
Niklas Lindström:  I think it was good to air these things in the
   discussion. I sympathize with the problems. I think Pat Hayes
   insight was very enlightening. It was also frustrating to read.
   Yes, with appropriate notes, I wouldn't be against this.
Niklas Lindström:  There are systems that already support bnodes
   for graph names in the wild - rdflib already does. They will
   probably add an RDF 1.1 compliance level, but you can work around
   it and parse RDF datasets into rdflib. I understand the
   limitations on storage. The graph names are usually used in that
   aspect. I also understand why RDF 1.1 doesn't support it.
Gregg Kellogg:  The only concern is that the algorithm (node map
   algorithm and convert to RDF algorithm are written wrt to the
   abstract syntax). So, they're aligned w/ concepts... but we say
   we're composing a triple with a blank node as predicate? In
   convert to RDF algorithm we're converting to RDF using an
   algorithm for blank node as graph name.
Gregg Kellogg:  Maybe we can change it into a note for the narrow
   purpose of this algorithm... we can extend for blank node
   identifiers in this case. Hopefully it won't raise any hackles in
   the WG.
Markus Lanthaler:  The cleanest solution would be to just drop it
   in the RDF conversion algorithms. We say clearly in the syntax
   spec stating that those features won't round-trip to RDF.
Markus Lanthaler:  RDF conversion isn't an API call - just a
   description on how to convert to RDF.
Gregg Kellogg:  If we do that, we disallow the Digital Bazaar use
Manu Sporny:  Yes, that's a problem.
Markus Lanthaler:  Does NQuads support blank nodes for graph
Manu Sporny:  No, but it's also not a REC.
Gregg Kellogg:  Yeah, there is no "official" NQuads spec.
Gregg Kellogg:  if you look at N3, it does specifically allow for
   bnodes in graph names and property locations.
Niklas Lindström:  Yes, it does.
Gregg Kellogg:  They manage to do that anyway, even though it
   does extend the data model.
Niklas Lindström:  Yes, I even went so far to leverage blank node
   properties and it became complex very quickly.
Manu Sporny:  Yes, there are issues with blank nodes as
   predicates, makes things algorithmically very complex.
Gregg Kellogg:  If you do this, you no longer depend on
   facilities for RDF... you're not really using RDF.
Markus Lanthaler:  i was thinking of changing the rdf bit just so
   it's clearly different. probably wouldn't want to use n3's
   version directly either in that case. open to suggestions for
   changes or anyone can fiddle with the svg. [scribe assist by
   David I. Lehn]
Markus Lanthaler:  Can we say nothing in the spec?
Dave Longley:  Could we say that it's an optional feature, to
   preserve this sort of thing?
Markus Lanthaler:  Could we say the behavior is not specified in
   the specification. We don't check for it. It's up to the
   implementer to decide.
Dave Longley:  Yes, I agree.
Gregg Kellogg:  Agreed.

PROPOSAL: JSON-LD will continue to support blank node identifiers
   for properties and graph names. When converting data to RDF 1.1,
   the specification will not introduce any special checks to handle
   these specific cases. It is up to the implementations to figure
   out how to convert this data to something conformant to RDF 1.1.

Gregg Kellogg: +1
Manu Sporny: +1
Dave Longley: +1
François Daoust: +1
David I. Lehn: +1
Markus Lanthaler: +1
Niklas Lindström: +1

RESOLUTION: JSON-LD will continue to support blank node
   identifiers for properties and graph names. When converting data
   to RDF 1.1, the specification will not introduce any special
   checks to handle these specific cases. It is up to the
   implementations to figure out how to convert this data to
   something conformant to RDF 1.1.

Topic: ISSUE-218: Algorithm specification updates by editors

Manu Sporny:  Starting at section 5.5
Markus Lanthaler:  Step 3.2 - it's not needed, but I can't
   remember why.
Dave Longley:  Handling keyword aliasing for @graph - maybe for
   dropping free-floating nodes or some other check?
Dave Longley:  yeah, older spec text was checking the active
   property against @graph, but that didn't take into consideration
   aliases for @graph. The new spec text ensures that it's expanded.
Markus Lanthaler:  Expanded active properties wouldn't be needed?
Dave Longley:  You can't check the active property against @graph
   because it could have been aliased.
Markus Lanthaler:  You don't need to handle @graph here, right?
Markus Lanthaler:  under the steps 8.4, validation is done there,
   but the keywords aren't handled there. You're not doing
   processing, you're just doing validation. While expanding the
   value of @graph or @id, instead of doing that in value expansion,
   the values would be simplified.
Dave Longley:  So, value expansion would be simplified?
Markus Lanthaler:  The question is whether we want to split that
   validation part under 8.4 and the actual processing.
Dave Longley:  So you want to combine the validation and
   processing steps?
Markus Lanthaler:  Yes, under 8.4 you check every keyword, but
   you don't do anything with it... then you actually do something
   with it in 8.7, 8.8, and 8.9
Dave Longley:  if you handle the list at the same place that you
   do the validation, you have to duplicate the code that you have
   to recurse through an array.
Dave Longley:  If you do the validation first and then the
   processing, you can have common code to do the recursion. If you
   don't do it that way, you can't share the recursive processing
Manu Sporny:  let's move this to the mailing list discussion.
Markus Lanthaler:  Step 3.4.2: ... or a bnode ID - we never
   validate IRIs, but we don't validate whether it's a valid IRI.
Dave Longley:  we need to do some kind of check to make sure
   something that has a colon or a keyword - we don't have a term
   for that, we should use that term throughout the specification.
Manu Sporny:  RDFa does it by CURIEorAbsoluteIRI - maybe we can
   do something similar.
Markus Lanthaler:  Maybe KeywordOrIRIOrBlankNode ?
Dave Longley:  It's like a JSON-LD Expanded Key?
Markus Lanthaler: If expanded property is either null or is: not
   an array, an absolute IRI or a keyword, then drop key by
   continuing to the next key.
Dave Longley:  So we say it must be a "valid ExpandedKey" and
   then we link to a place in the spec that states what "valid"
Dave Longley:  It's any keyword except for @context - you could
   be expanding an alias.
Gregg Kellogg:  In the context of a node, it can't be @value or
Dave Longley:  it's not just in a node -it might be in a literal.
   We want to use the same word there.
Markus Lanthaler:  "ValidProperty" ?
Manu Sporny:  Why don't we bikeshed the name later, and structure
   the spec correctly now?
Niklas Lindström: +1 for expanded key
Gregg Kellogg:  For right now "ExpandedKey" - we can change it
Niklas Lindström: .. ExpandedKeyRightNow ;)
Markus Lanthaler:  Steps 3.4.3.x: is basically the validation
   stuff we talked about before...
Markus Lanthaler:  Step "and value language value in
   value" is confusing
Dave Longley:  Yeah, that's really confusing, we need to do
   something else.
Markus Lanthaler:  Maybe format variables in typeset courier.
Manu Sporny:  We usually do "<em>"
Dave Longley:  Maybe we should also colorize it?
Markus Lanthaler:  Yeah...
Markus Lanthaler: language value changes to languageValue ?
Manu Sporny:  Maybe we just do class="variable" around the
Markus Lanthaler:  Camel case the variables?
Gregg Kellogg:  let's stay away from the religious debates about
   camel case...
Manu Sporny:  I think if we mark it up in italic purple, we don't
   also need to camel case.
Markus Lanthaler:  ok.
Markus Lanthaler:  Step 3.4.6: might need some clarification. It
   might be easier to put it under 3.4.3 - this is now section 8.7 -
   3 lines of handling @list and @set - maybe we want to separate
   this into a substep?
Dave Longley:  Yeah, maybe we just want to break this into a
   couple of sub-steps.
Markus Lanthaler:  Can we break it up?
Dave Longley:  yes, looks possible - let's do it.
Dave Longley:  it'll just be 3 steps, it'll look a lot better.
Markus Lanthaler:  8.12 we handle keywords separately... if xyz,
   then set the key to something. I think it might be simpler to do
   this elsewhere, but let's discuss on the mailing list.
Dave Longley:  I think we'll just have to move this around and
   see if it looks better, if so, keep it, if not, don't.
Markus Lanthaler:  Last point - insideList flag - do we need that
   flag? Would it be enough for current active property is @list or
   coerced to a list, instead of passing that flag around.
Dave Longley:  When I was working on this, I had a test case for
   this - once we get the API errors in the spec, I'll be able to
   check this one. If we can remove it, we should remove it,
   otherwise we should have a test that says why we need this flag.
Dave Longley:  I got all of the error phrases back in the spec
   last night. We have a phrase for the type of error now, I need
   Gregg and Markus to go in and figure out what needs to change to
   accomodate both of them. I tweaked some of the error lists,
   consolidated some, added some. Needs review.
Gregg Kellogg:  I think the changes are good, mostly what I was
   going for.
Gregg Kellogg:  maybe we should link to the error code section?
Dave Longley:  Should they become trefs?
Gregg Kellogg:  I like that they're styled differently, maybe
   done not as a tref, but a dtref?
Markus Lanthaler:  Currently code w/ a special error class - we
   could pre-process in ReSpec.
Discussion about how to make this work in ReSpec.
Markus Lanthaler:  Gregg, you want the error in the algorithm to
   link down to the entry in the error table, right?
Gregg Kellogg:  Yes.
Manu Sporny:  Looks like 5.10 is the next thing that needs to be
Dave Longley:  Talking about compactArrays as an option is tying
   it to the API instead of the algorithm - I don't know if we want
   to handle this w/ another flag.
Gregg Kellogg:  I think what I was trying to say before - "if
   compacting arrays" vs. specifically talking about flags... flags
   are in there, I don't think they're going away. Options are less
   API-ish than flag.
Dave Longley:  What would your preference be for the language?
Dave Longley:  "If a choice has been made to compact arrays"?
Gregg Kellogg:  It was basically a feeling about being tied so
   closely to the API. Important take-away is to consider that when
   looking at algorithmic text, and you're doing that now.
Dave Longley:  I'll try to come up with something that is more
Gregg Kellogg:  great.
Markus Lanthaler:
Markus Lanthaler:  The link above is a proposal about how to
   re-order the algorithms.
Dave Longley:  Maybe we want to put context processing under it's
   own group entirely. Maybe they need their own grouping.
Markus Lanthaler:  Like "IRI Processing", for example?
Gregg Kellogg:  It depends - these seem like they're tightly
   bound - when expanding IRI, I'm doing it relative to the context.
Dave Longley:  My only issue with that is that you could say this
   about every one of these algorithms. It seems somewhat arbitrary
   where you draw the line. It seems like some of these are
   subalgorithms, you don't call them on their own - maybe something
   like "IRI Processing" as Markus suggested, might be best.
Markus Lanthaler:  Should we introduce a new group like "IRI
Dave Longley:  We can call it that for now.
Gregg Kellogg:  They could also be bound together with various
   "Compaction/Expansion" algorithms?
Dave Longley:  That's fine with me. I think Markus wanted to move
   it up because it's a concept that is used generally...
Markus Lanthaler:  IRI Expansion is so title bound to context
   processing, it doesn't make much sense to put it elsewhere.
Dave Longley:  Maybe "Utility sub-algorithms"

Topic: Publication Timeline

Manu Sporny:  We handed the JSON-LD 1.0 Final Community Group
   Specification over to RDF WG - we need some changes before it
   goes to LC - add at-risk for property generators, @base, clarify
   blank nodes as predicates/graph names.
Gregg Kellogg:  We may want to drop property generators entirely?
Manu Sporny:  I don't know about taking out entirely - we need
   feedback from Lin and Stephane.
Niklas Lindström:  Compared to @rev, property generators are
   really complex and we only put it in for Drupal.
Dave Longley:  It also polluted the expansion algorithm. The
   feature on it's own is complicated and it made all the other
   algorithms more complicated.

PROPOSAL: Mark property generators as an at-risk feature in
   JSON-LD 1.0

Manu Sporny: +1
Dave Longley: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Gregg Kellogg: +1

RESOLUTION: Mark property generators as an at-risk feature in
   JSON-LD 1.0.

Manu Sporny:  Do we want a super-session to go through the rest
   of the API spec?
Markus Lanthaler:  I'd be fine either way.
Manu Sporny:  I don't think meeting before next Tuesday is
Markus Lanthaler:  I think the JSON-LD Algorithm spec is very
   close, algorithms seem pretty solid.
Manu Sporny:  End of the call, anything else?
Niklas Lindström:  Yeah, JSON-LD is being used very heavily at
   National Library of Sweden - we're ahead of Library of Congress
   in that respect!
Niklas Lindström:  What we do now is we have our JSON shapes in
   place, and we have two contexts we use for book-keeping - we can
   mutate the RDF at will depending on which vocabulary is willing.
Gregg Kellogg:  The BBC is giving a talk at SemTech on their use
   of JSON-LD in their Linked Data program.
Manu Sporny:  Go Sweden!
David I. Lehn: we should have a page on the website linking to
   these sites and projects using json-ld
Gregg Kellogg:  We do this at Wikia now - JSON-LD is working
   nicely for us.
Happy Birthday (tomorrow) to Gregg ! Well wishes all around for him.
Gregg Kellogg: Thank's very much!

-- manu

Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
Received on Tuesday, 26 February 2013 20:46:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:36 UTC