JSON-LD Telecon Minutes for 2013-03-19

The minutes from today's telecon are now available.

http://json-ld.org/minutes/2013-03-19/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2013-03-19

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Mar/0029.html
Topics:
   1. ISSUE-224: Sandro Hawke's JSON-LD syntax spec review
   2. ISSUE-222: David Booth's JSON-LD syntax spec review
   3. ISSUE-230: Charles Greer's JSON-LD syntax spec review
   4. ISSUE-223: JsonLdOptions base vs. @base
   5. ISSUE-231: JSON-LD in HTML
   6. Last Call timeline
Resolutions:
   1. Add the JSON-LD in HTML feature to the JSON-LD Syntax
      specification without support for @data-context. We are still
      discussing @data-context and the danger of it forcing a JSON-LD
      initial context.
Chair:
   Manu Sporny
Scribe:
   Manu Sporny
Present:
   Manu Sporny, Markus Lanthaler, Gregg Kellogg, Dave Longley,
   Niklas Lindström
Audio:
   http://json-ld.org/minutes/2013-03-19/audio.ogg

Manu Sporny is scribing.
Manu Sporny:  Any changes to agenda?
Manu Sporny:  Maybe we want to move the JSON-LD in HTML
   discussion to the end since Niklas isn't here yet.

Topic: ISSUE-224: Sandro Hawke's JSON-LD syntax spec review

https://github.com/json-ld/json-ld.org/issues/224
Manu Sporny:  Markus, mind taking us through this issue?
Markus Lanthaler:  yep... Sandro thinks using @graph to specify
   the default graph is confusing. He thinks having an array where
   the first object is the context and all subsequent objects have
   the context applied.
Gregg Kellogg:  that can have strange effects down the line, if
   you have multiple objects of a property, you'd think that context
   would apply to subsequent objects in an array. If you had an
   object that /only/ contained contexts.
Dave Longley:  Yeah, we discussed this a long time ago. If you
   have data in compact form, you can't check lengths of arrays...
   you have to look through the entire array to see if there is a
   context there.
Markus Lanthaler:  We've had this question several times now...
   it's not that common that you have an array at the top-level. In
   some cases, it's a security vulnerability.
Markus Lanthaler:  You can easily alias "@graph" to "data". When
   we expand, we always expand it to an array at the top level.
Gregg Kellogg:  There is is interest in using a canonical JSON-LD
   representation as an array. In JSON-LD in HTML stuff, that's
   something the supporters see as happening... they think it's not
   well understood by their community. But an array of objects
   would.
Markus Lanthaler:  If you look at all web apis out there, there's
   always an object at the top level ... not an array.
Manu Sporny:  i agree with markus, there are very few examples of
   an array being at the top-level in APIs [scribe assist by Dave
   Longley]
Gregg Kellogg:  Yeah, maybe if we show an example with @graph
   aliased to data'
Markus Lanthaler:  Maybe we can do that in that example.
Manu Sporny:  I think that sandro's comment may have more to do
   with unfamiliarity with how JSON is used in the wild, i haven't
   seen people use JSON in the wild all that much with arrays being
   at the top-level coming back from API calls, etc [scribe assist
   by Dave Longley]
Manu Sporny:  I don't think people that author JSON on a regular
   basis typically have objects at the top-level [scribe assist by
   Dave Longley]
Manu Sporny:  typically, i'd expect to see something like this in
   a search result [scribe assist by Dave Longley]
Markus Lanthaler:  but then you'd also see things like "how many
   results you got back", etc. and those would be top-level
   properties [scribe assist by Dave Longley]
Markus Lanthaler:  and then the array would be underneath another
   property [scribe assist by Dave Longley]
Manu Sporny:  yeah, we should create an alias example using
   "results" or something [scribe assist by Dave Longley]
Manu Sporny:  so people can see how that may work [scribe assist
   by Dave Longley]
Markus Lanthaler:  that would be dangerous because it would
   affect the default context [scribe assist by Dave Longley]
Manu Sporny:  i'm not saying do that, just do an example in the
   spec [scribe assist by Dave Longley]
Manu Sporny:  of using an alias here [scribe assist by Dave
   Longley]
Gregg Kellogg:  maybe also add a note asking for feedback for
   this use case [scribe assist by Dave Longley]
Markus Lanthaler:  Next up - data indexing.
Markus Lanthaler:  Sandro feels it's pretty weird but fairly
   harmless. He thinks we can index data by an arbitrary property?
Markus Lanthaler:  We've discussed this before, it adds a bunch
   of complexity. With Data indexing it's about representation of
   metadata... I would say we do nothing here.
Markus Lanthaler:  having arbitrary properties as indexes is too
   complex for 1.0.
Dave Longley:  I agree as well.
Gregg Kellogg:  Yeah, agree.
Dave Longley:  One request for this feature didn't want the RDFa
   data in the index - it meets the use case that was there for it.
Gregg Kellogg:  The only thing I worry that we're missing is the
   other pattern from these indexes where you have a top-level key
   in which the data contains an array of properties. The Microdata
   JSON is an example of this, where you have id at the top and then
   properties, and the value of properties is the value of all of
   the properties.
Gregg Kellogg:  There is a case where you might fold these in,
   I've seen this in other places as well. I'm a bit concerned that
   we will wish we had that.
Markus Lanthaler:  I think the reason for that is because they
   don't have a way to namespace properties like JSON-LD...
Gregg Kellogg:  Unless the identifier key could be re-used... My
   concern is that Microdata is something we thought we'd be able to
   handle at some point through these mechanisms, but we never came
   back to it.
Markus Lanthaler:  There is always the possibility of having a
   pre-processing step.
Manu Sporny:  So, we're doing nothing to change the spec in this
   case - the feature is good as designed.
Markus Lanthaler:  Sandro talking about the data model section,
   he found it very confusing even though he is familiar with RDF
   Concepts.
Markus Lanthaler:  It's a bit strange since most of these
   statements have been copied almost directly from RDF Concepts. He
   asked if we could drop this section, however, the RDF WG
   requested that we add this section in here.
Markus Lanthaler:  Instead of re-defining our own data model, we
   could just say that it's the RDF data model, but we don't place
   restrictions on where blank nodes are usable.
Manu Sporny:  it may be that sandro knows too much about the RDF
   data model and he may not be taking the text at face value, but
   that's just trying to get into his head which i shouldn't be
   trying to do [scribe assist by Dave Longley]
Manu Sporny:  Ok, so we're not changing this section because the
   RDF WG asked for it, it's clear, concise and nobody in this group
   thinks we should change it.
Markus Lanthaler:  Next up is normative non-normative labels are
   applied inconsistently.
Markus Lanthaler:  we discussed this, but in respec, we'll
   relabel as appropriate.
Markus Lanthaler:  Example 62:
   http://json-ld.org/spec/latest/json-ld-syntax/index.html#turtle
Markus Lanthaler:  The example is correct - it's what we say in
   the spec and it's quite obvious that we define a prefix in
   JSON-LD and Turtle. No change.
Markus Lanthaler:  In the IANA considerations we have the profile
   IRI... Sandro didn't apply what the profile IRI applies to. What
   does the 'SHOULD' Apply to? requests or responses?
Markus Lanthaler:  I think it works. He also said he thinks it
   should work like normal content negotiation. It's an optional
   parameter, if you can't expand it on the server, you return what
   you can do.
Manu Sporny:  i think it would help if we explained a little bit
   more in that section about what should happen [scribe assist by
   Dave Longley]
Manu Sporny:  basically put a note in with sandro's concern where
   we basically say "if you request expanded form and the server
   can't expand it then it doesn't have to" [scribe assist by Dave
   Longley]
Markus Lanthaler:  Some references are out of date, like
   TURTLE-TR and reference style isn't correct... we'll have to fix
   this before we go to LC. Especially since Turtle keeps changing
   state.
Manu Sporny:  let's just call it TURTLE-REC and make the change
   and assume it will go to REC before JSON-LD does [scribe assist
   by Dave Longley]
Manu Sporny:  these are very small editoral changes and i'm not
   that concerned about it [scribe assist by Dave Longley]
Markus Lanthaler:  they are even informal references [scribe
   assist by Dave Longley]
Gregg Kellogg:  i think RDF-CONCEPTS is a normative link in the
   JSON-LD API spec [scribe assist by Dave Longley]
Manu Sporny:  i guess that's not too much of an issue since it's
   in the same working group [scribe assist by Dave Longley]
Manu Sporny:  in the worst case the JSON-LD API spec is held up
   while the RDF-CONCEPTS spec goes to REC [scribe assist by Dave
   Longley]
Markus Lanthaler:  next sandro suggests moving RDF conversion to
   the syntax spec [scribe assist by Dave Longley]
Markus Lanthaler:  He also sent a second e-mail about the
   conversion descriptions - he wants an informative description
   about the process of turning JSON-LD into RDF and vice versa.
Gregg Kellogg:  We'd need to cover the expansion and flattening
   algorithms.
Gregg Kellogg:  i don't think he wants to move the whole
   algorithm, but maybe a brief description of how they work [scribe
   assist by Dave Longley]
Gregg Kellogg:  I think they want one place where you can go to
   figure out how JSON-LD can represent RDF and vice versa.
Markus Lanthaler:  The whole syntax spec is about that - how the
   context works, how nodes are expressed.
Gregg Kellogg:  We could say something about the general process
   of transforming JSON-LD to RDF has to do w/ expanding/compacting
   the document... and then you can translate those statements to
   RDF.
Markus Lanthaler:  As soon as we do that, people are going to ask
   about the algorithms.
Gregg Kellogg:  we refer to the API spec.
Gregg Kellogg:  We can explain that expanding is the process of
   removing the context, flattening is ordering everything in a flat
   sequence, then you can easily go to RDF.
Gregg Kellogg:  We can show how the transformation happens.
Manu Sporny:  As long as we can keep it short, that would be fine
   with me.
Gregg Kellogg:  I'll write that section.
Markus Lanthaler:  Sandro wanted to add to the conformance
   section: a JSON-LD Expander, JSON-LD COmpacter, JSON-LD
   To-RDF-Converter, JSON-LD From-RDF-Converter.
Markus Lanthaler:  This is about the syntax specification, not
   the API specification.
Manu Sporny:  So, no change.
General agreement to no change to the conformance section.
Markus Lanthaler:  we can talk later about maybe adding that to
   the API spec instead, it doesn't belong in the syntax spec
   [scribe assist by Dave Longley]
The group feels it has addressed all of Sandro's comments.

Topic: ISSUE-222: David Booth's JSON-LD syntax spec review

https://github.com/json-ld/json-ld.org/issues/222
Markus Lanthaler:  His first point is that JSON-LD should be an
   RDF syntax - same data model, same semantics as other
   serializations.
Manu Sporny:  We've had a very long discussion about the
   differences in the data model - the only distinction is blank
   nodes, right?
Markus Lanthaler:  Yes, only difference.
Gregg Kellogg:  In this regard, we're not too different from
   notation 3 for properties. For graph labels, it has a different
   context.
Dave Longley:  He effectively asks to change the RDF specs first,
   however, there is disagreement over where the future should go.
   We would prefer it to go into the RDF spec, but that's not
   happening right now.
Markus Lanthaler:  We've discussed all of this several times, not
   even the RDF WG has a clear position about the additions to the
   data model that JSON-LD has... re-opening the discussion again
   isn't productive at this point in time. It is a super-set, we
   discussed with the RDF WG, they accepted it, we clearly
   documented the differences, we can't do much more than that.
Markus Lanthaler:  We would like to keep JSON-LD as-is.
Manu Sporny:  I agree.
General agreement from the group that we're doing all we can to
   address this point.
Markus Lanthaler:  His second point is that JSON-LD should not
   require that IRIs are de-reference-able. I find this a bit odd
   since JSON-LD is about Linked Data and Linked Data is about
   dereferenceable IRIs.
Markus Lanthaler:  Besides, it's a SHOULD not a MUST, so it's not
   a hard requirement.
General agreement from the group - no change, IRIs should be
   dereferenceable.
Gregg Kellogg:  We had these conversations a while ago, nothing
   has changed.
Gregg Kellogg:  Regarding JSON-RDF - that name was already taken
   at the time.
Manu Sporny:  Besides - this is more about Linked Data than it is
   about RDF.
Dave Longley:  This spec is about JSON in Linked Data... the name
   is fine.
Gregg Kellogg:  JSON-RDF exists, and application/rdf+json exists
   - we can't re-use it.

Topic: ISSUE-230: Charles Greer's JSON-LD syntax spec review

https://github.com/json-ld/json-ld.org/issues/230
Markus Lanthaler:  I responded to his issues.
Gregg Kellogg:  He seems to be happy with the changes.
Markus Lanthaler:  He did respond today about @base and @vocab
   and how they're used in relation to relative IRIs. He
   acknowledges that @base is marked as at-risk, he still sees the
   risk with trying to do too much with expansion.
Markus Lanthaler:  The other thing was mainly editorial, we
   characterize JSON-LD as a serialization of Linked Data in JSON.
Markus Lanthaler:  Not sure I understand him completely. He
   thinks that RDF/XML could have benefited from a distinction.
Markus Lanthaler:  So you could have multiple expressions of RDF
   in JSON (flattened, expanded, re-framed, etc.)
Markus Lanthaler:  One aspect of JSON-LD is serialization and the
   other is authoring.
Markus Lanthaler:  Before he realized that we had a flattened
   form, he thought that JSON-LD has many of the same problems as
   RDF/XML... but now that he knows about flattened form, you get
   the data in a deterministic form.
Dave Longley:  he was worried that with all the ways of
   expressing the data, that it would be hard for an application to
   find out where the data is... but that only solves some of the
   "find the data" use cases.
Dave Longley:  Unfortunately, some of this has to do with
   framing, because it's not in the spec.
Gregg Kellogg:  I think it's useful to have someone that made a
   statement like this, some older RDF hats have said that we're
   making same mistakes that RDF/XML did... but we do allow the data
   to be modified and re-framed, which RDF/XML didn't do. That said,
   I don't think this comment is really action-able.
Markus Lanthaler:  I think the point he's trying to bring across
   is that this isn't as much about serializing data, just
   augmenting the data with a context so you can interpret it as
   RDF.
Markus Lanthaler:  You already have your JSON, you want to
   transform it to Linked Data, you just add your context and almost
   magically it can be interpreted as RDF.
Manu Sporny:  That's a very good, concise statement - we should
   say that in the spec.
Dave Longley:  Yes, if it's not in the spec, it should be in
   there.
Markus Lanthaler:  We don't say that in the abstract/intro, we
   probably should.
Markus Lanthaler:  He's also worried about remote contexts.
   Remote contexts are important, we have plenty of use cases for
   them.
Gregg Kellogg:  It's a bit different from RDFa - documents aren't
   meaningless w/o them. In JSON-LD, documents are meaningless w/o
   being able to dereference the remote context.
Gregg Kellogg:  His point is that you don't know if the data
   that's represented hasn't changed...
Dave Longley:  You could run it through the normalization
   algorithm to see if it's changed.
Gregg Kellogg:  How would that work? Use E-Tags?
Dave Longley:  It's gets pretty complicated. If the remote
   context going away is a problem, you should cache or embed the
   context.
Markus Lanthaler:  If you include external files, this is an
   issue on the Web. Like external javascript files.
Dave Longley:  You could hash the external context and include
   that hash.
Markus Lanthaler:  Yes, there are lots of ways to avoid the
   problem. In many cases, you have control over your context and
   you can change it in lock-step. The advantages of having a remote
   context outweighs the drawbacks.
Dave Longley: =)
Group agrees that it has responded to all Charles Greers
   comments.

Topic: ISSUE-223: JsonLdOptions base vs. @base

https://github.com/json-ld/json-ld.org/issues/223
Markus Lanthaler:  The question is what happens when the base is
   a relative IRI?
Gregg Kellogg:  Doing something to allow relative IRIs w/in the
   document is useful, but otherwise, I can't think of why you'd
   want base to be a relative IRI. Why isn't it just an absolute
   IRI?
Gregg Kellogg:  You can do this in Turtle, where statements
   become accumulative, we could do that w/in JSON-LD - don't know
   if that's an important paradigm.
Markus Lanthaler:  HTML and Turtle supports relative IRIs, having
   the empty string to say there is no base is a bit weird. It's
   something that should be done at the API level, if you don't want
   a base. The use case is to not change relative IRIs
   duringcompaction/expansion/ etc.
Niklas Lindström: .. http://www.w3.org/TR/xmlbase/
Niklas Lindström:  Trying to think of a use case where relative
   base IRIs are useful.
Niklas Lindström:  In general, what we should do is to make this
   work exactly in the same way as it's treated in HTML, Turtle, and
   XML - we should take care to do the same thing.
Dave Longley:  So only difference between PROPOSAL 3 and PROPOSAL
   4 - if PROPOSAL 3 is close to what we want, then PROPOSAL 4
   enables two other features.
Markus Lanthaler:  I'm concerned where the empty string is used
   for base... in HTML you can have a relative base "" and in Turtle
   as well.
Dave Longley:  Proposal 3 does not allow relative IRIs.
Manu Sporny:  It sounds like we agree that we should align with
   HTML, Turtle and XML, but we don't know what they do?
Markus Lanthaler:  Just checked HTML5 - it allows relative IRIs
   for base, previous versions didn't.
Niklas Lindström: … json-ld fetched from
   "http://example.org/some/other" , with a @context containing
   @base: "/doc". I'd then expect base to be
   "http://example.org/doc"
Dave Longley:  What's the behavior when you don't set the base in
   this case?
Dave Longley:  If you have relative IRIs in the document and you
   have no base, and you get a relative IRI, how does "../.."
   change? Does it become just "/"?
Gregg Kellogg:  I think it happens in the same way as any other
   RDF serialization. When you join IRI segments, it results in the
   IRIs being normalized, which includes removing dot-segments.
Dave Longley: does "../../foo" become "/foo" ?
Dave Longley: because i think that's unexpected when base is none
Markus Lanthaler:  You can't have relative IRIs in a RDF
   serialization.
Gregg Kellogg:  Yes, but you can have it in a syntax.
Markus Lanthaler:  Yes.
Markus Lanthaler:  if you are not able to establish an absolute
   base, we shouldn't try to resolve relative IRIs in the document,
   you just leave them as-is.
Gregg Kellogg:  if we do that, we'd be the only serialization
   format that tries to go this far to explain why this happens.
Markus Lanthaler:  We have to resolve this because we allow the
   base to be set.
Dave Longley:  It also affects normalization.
Manu Sporny:  Yes, we need to resolve this issue.
Gregg Kellogg:  Maybe this means that if you specify a base IRI
   in the API, it must be an absolute IRI... in the absence of it,
   you'd be left with a document that has relative IRIs in it.
Dave Longley:  I think it's important that we say: If you do not
   specify a base... what happens? Base doesn't exist - leave
   relative IRIs alone? What happens if base is specified in the
   document and it's relative? What happens when it's specified in
   the API and it's relative? We need clear answers to these.
Gregg Kellogg:  Maybe we should say it's unaltered.
Manu Sporny:  Let's take this back to the JSON-LD issue tracker
   and cover all corner cases and see if they apply to how HTML,
   Turtle, and XML deal with these corner cases.

Topic: ISSUE-231: JSON-LD in HTML

https://github.com/json-ld/json-ld.org/issues/231
Gregg Kellogg:  There are cases where expressing metadata in HTML
   using either Microdata or RDFa is not feasible or has been shown
   to be error-prone.
Gregg Kellogg:  As an alternative way of doing this, the idea is
   to put JSON-LD in HTML.
Gregg Kellogg:  A process that conforms to this could extract the
   content of this script tag and run it through the JSON-LD
   algorithms. It could be used to easily extract anything - for
   Turtle, it's for extracting RDF.
Gregg Kellogg:  In addition, there is a strong desire to not
   require boilerplate w/in the JSON - take JSON that came out of
   some JSON-LD database, without adding a context to the content of
   the script tag.
Gregg Kellogg:  So, that's why @data-context is being proposed to
   be used for this purpose.
Gregg Kellogg:  This is a way of specifying an external context,
   kind of like we do with link headers.
Gregg Kellogg:  One of the advantages of @data-context is that
   you don't have to be very explicit - as long as you can
   de-reference it, if you can get to the context, you're going.
Manu Sporny:  Any opposition to putting this into the spec?
Gregg Kellogg:  This is an informative addition.
Niklas Lindström:  I've seen some possible uses for this, I'm
   still a bit uneasy about the feature, but it seems useful. Maybe
   instead of an RDFa API, we can just read JSON out of the page.
Niklas Lindström:  It's a good thing to have. Since Turtle has
   it, it'll be nice to have this as well.
Gregg Kellogg:  When I added support for this for Turtle in my
   processor, I did it generically.
Gregg Kellogg:  My own system, if it saw this, it would extract
   the RDF and add it to the default graph.
Gregg Kellogg:  I'd need to refine it, but it has some history.
Dave Longley:  This would be useful for Web Applications, to get
   them some initial data to start up.
Markus Lanthaler:  Wouldn't you just assign it to a variable in
   that case? That's another way to do it. I don't like that the
   context is placed somewhere else.
Markus Lanthaler:  I don't like that you can't cut/paste that.
   Also, data-* isn't intended for that use. We also say in the spec
   that the context has to be in the document if you're
   usingapplication/ld+json.
Gregg Kellogg:  I tried @vocab instead of @data-context - but got
   push-back on that.
Gregg Kellogg:  @vocab has similar behavior to @context.
Niklas Lindström:  I don't quite agree with that. We took out
   @profile in RDFa. They're not really isomorphic.
Gregg Kellogg:  You're right, I'm not suggesting we use that.
Markus Lanthaler:  Why can't we use @context in JSON-LD?
Gregg Kellogg:  The companies that want this don't want
   boilerplate - they feel very strongly about this. It's a small
   concession, it's in the spirit of how we specify it in a Link
   Header. I think it's reasonable for us to do. I have asked the
   people that have been promoting this to be more vocal, but they
   haven't done so yet.
Gregg Kellogg:  if some of these issues are raised, maybe that'll
   provoke a response.
Markus Lanthaler:  My fear is that we now say that they should
   use the @data-context attribute - you end up having JSON that
   isn't JSON-LD, people may forget to create it. Then we get to the
   point where we might have to pre-define prefixes.
Manu Sporny:  Like Markus, I'm very concerned with people not
   using @data-context and us having to make that an initial
   context.
Dave Longley:  I'm not too sure that boilerplate argument works
   here - I don't know if we're solving anything either way. They
   may not include the @context, they may not include @data-context.
Markus Lanthaler:  At least we wouldn't be implementing something
   new.

PROPOSAL: Add the JSON-LD in HTML feature to the JSON-LD Syntax
   specification without support for @data-context. We are still
   discussing @data-context and the danger of it forcing a JSON-LD
   initial context.

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

RESOLUTION: Add the JSON-LD in HTML feature to the JSON-LD Syntax
   specification without support for @data-context. We are still
   discussing @data-context and the danger of it forcing a JSON-LD
   initial context.

Niklas Lindström: What about: <script
   type="application/ld+json;context='http://example.org/context.jsonld'">
Niklas Lindström:  We talked about allowing @context as an
   optional parameter to the MIME TYpe a long time ago?
Niklas Lindström:  Maybe we can do the above.
Manu Sporny:  I think a lot of authors would mess that up.
Gregg Kellogg:  It's worth discussing it in more depth.
Gregg Kellogg:  Let me send that back to them and see what sort
   of response I get.
Gregg Kellogg:  That would also serve the same effect. It's
   boilerplate, but maybe that would work.

Topic: Last Call timeline

Manu Sporny:  We've finished all review comments, we'll fix up
   the spec with the decisions we've made on those comments.
Manu Sporny:  We'll get the JSON-LD Syntax spec into Last Call
   after we get those changes in, hopefully there won't be a flurry
   of new comments in the mean time.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
President/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Tuesday, 19 March 2013 16:07:15 UTC