JSON-LD Telecon Minutes for 2012-10-09

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

http://json-ld.org/minutes/2012-10-09/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2012-10-09

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Oct/0005.html
Topics:
   1. ISSUE-140: Consider objectify/link API method
   2. ISSUE-160: Specify property-generator round-tripping
      algorithm
   3. ISSUE-153: Define error handler behavior
   4. ISSUE-159: Add specifying @language to expanded form
Resolutions:
   1. Table issue-140 for the time being, delay discussion until
      all other issues for JSON-LD 1.0 have been addressed.
   2. Adopt Gregg Kellogg's property generator algorithm when
      expanding/compacting with the following modifications; 1) use
      node definitions everywhere when expanding, 2) generate bnode IDs
      for all node definitions without an '@id', 3) use deep
      comparisons when eliminating node definitions during compaction.
   3. Add warning language to the JSON-LD Syntax and API specs
      noting the most problematic issues when working with property
      generators.
   4. Add a non-normative note to tell implementers that their
      implementations may have a feature that allows all but one node
      definition created by a property generator to be collapsed into a
      node reference.
Action Items:
   1. Dave Longley to do an implementation of the conformance
      issue feature.
   2. Gregg to write up language-map spec text for JSON-LD API in
      the issue tracker.
Chair:
   Manu Sporny
Scribe:
   Markus Lanthaler
Present:
   Markus Lanthaler, Manu Sporny, Gregg Kellogg, Lin Clark,
   François Daoust, David I. Lehn
Audio:
   http://json-ld.org/minutes/2012-10-09/audio.ogg

Markus Lanthaler is scribing.

Topic: ISSUE-140: Consider objectify/link API method

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/140
Manu Sporny:  I moved this to the JSON-LD.next milestone.. which
   means we are not going to include it in 1.0
   ... but since I did that Niklas wrote up a proposal
   ... my big concern is that we are pushing 1.0 back for 1-2
   months if we are going to include this
   ... I would suggest to work on this in parallel and see if we
   can get this done before we go to  LC, if we do, then include it.
   If not, then defer it.
Markus Lanthaler:  I have a strong opinion about removing
   .connect() and .frame() - we have .flatten() in there, but it
   requires you to iterate over every object. We need a way to get
   to a node based on ID. [scribe assist by Manu Sporny]
Markus Lanthaler:  We could have something like @id containers -
   we might be able to express that node map as valid JSON-LD. We
   could expose the node map via a call. [scribe assist by Manu
   Sporny]
Gregg Kellogg:  These issues are orthogonal - if you don't have a
   node-map, you need to construct your own. Not all systems work
   that way, though - if you're working w/ backbone, it expects an
   array and builds an index using those models. The .flatten()
   method does create this data, but you can't access it. If we had
   @id-maps, we could expose this data. [scribe assist by Manu
   Sporny]
Gregg Kellogg:  I'm concerned about adding these extra features -
   we don't have to have everything as the W3C spec when we first
   come out... we can add these in supplemental specs published by
   the Community Group. [scribe assist by Manu Sporny]
Markus Lanthaler:  still.. I find it a bit weird to have an API
   that doesn't include a way to access data directly if you don't
   know the exact shape of the data
Markus Lanthaler:  It's a bit weird to have an API without a
   feature like this. [scribe assist by Manu Sporny]
Manu Sporny:  true.. I have been thinking about this myself as
   well.. The question is how easy it is for people to write it
   themselves
   ... I have been writing that several times myself
   ... I'm just really concernced that this requires more time
Gregg Kellogg:  I believe there's a certain amount of energy left
   in the group (at least in my case)..
   ... I'm not sure we should take on more work before 1.0
Markus Lanthaler:  I'm fine with delaying the issue until we get
   all the other stuff done. Let's look at this issue again when
   we're done w/ everything else. [scribe assist by Manu Sporny]
Gregg Kellogg:  If you're interested in this feature, add spec
   text, add tests, implement the feature - that'll move us further
   on this feature. [scribe assist by Manu Sporny]
Manu Sporny:  True.. that would be the right way to do it

PROPOSAL:  Table issue-140 for the time being, delay discussion
   until all other issues for JSON-LD 1.0 have been addressed.

Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Lin Clark: +0

RESOLUTION: Table issue-140 for the time being, delay discussion
   until all other issues for JSON-LD 1.0 have been addressed.

Topic: ISSUE-160: Specify property-generator round-tripping algorithm

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/160
Manu Sporny:  Basically everyone agrees that tagging where the
   data came from is unworkable
   ... this leaves us with Gregg's proposal.
   ... We might need some minor changes though: instead of having
   just node references we would have to copy the data
   ... because otherwise it would be difficult to get to the data
Gregg Kellogg:  Does the data using property generators contain
   node definitions?
Lin Clark:  Yes
Gregg Kellogg:  The other question is what the interoperability
   requirements are
   ... what would happen if an application that just understand
   one of the vocabularies modifies the data?
Lin Clark:  It would be nice to have but I think it is definitely
   not a requirement
   ... we would do that directly in compact form
Gregg Kellogg:  I just feel we are conflating a couple of things
   for convenience
   ... e.g. things that could be done with owl:sameAs
Lin Clark:  there have been proposals using different HTTP
   headers, query parameters etc.
   ... but I think that's not the right way to do it
Manu Sporny:  Prop. generators have some downsides but I think
   esp. for mobile apps they are very valuable
Manu Sporny:  Lin, is there something in the current proposal
   that doesn't address Drupal's requirements
Markus Lanthaler:  The main difference between the proposal I put
   forward and Gregg put forward was separating the "main id" from
   "alternative ids" - a term can also expand to alternative IRIs,
   but in compaction you just ignore the "alternative IRIs" [scribe
   assist by Manu Sporny]
Markus Lanthaler:  This would keep the algorithm quite trivial
   because the "alternate ids" would be removed in compaction.
   [scribe assist by Manu Sporny]
Markus Lanthaler:  Downsides are - no removal of extra data in
   compaction. The reasoning behind it is that you have a main
   vocabulary that you're using - you can use a more generic
   vocabulary such as schema.org or foaf. [scribe assist by Manu
   Sporny]
Markus Lanthaler:  It's more or less a simple addition to
   expansion. [scribe assist by Manu Sporny]
Manu Sporny:  You also had an issue with the implied relationship
   between all IRIs in a property generator. [scribe assist by Manu
   Sporny]
Markus Lanthaler:  Yes, they might think that they're owl:sameAs
   when they're not. [scribe assist by Manu Sporny]
Markus Lanthaler:  The other issue is that developers might
   assume that both IRIs compact to the same term... but that only
   happens when there is data duplication. [scribe assist by Manu
   Sporny]
Manu Sporny:  all that being said, we all have concerns with
   property generators but it addresses a real world problem

PROPOSAL:  Adopt Gregg Kellogg's property generator algorithm
   when expanding/compacting with the following modifications; 1)
   use node definitions everywhere when expanding, 2) generate bnode
   IDs for all node definitions without an '@id', 3) use deep
   comparisons when eliminating node definitions during compaction.

Gregg Kellogg: +1
Manu Sporny: +1
Lin Clark: +1
Markus Lanthaler: -0
François Daoust: 0
Manu Sporny: dlongley: +1
David I. Lehn: +0

RESOLUTION: Adopt Gregg Kellogg's property generator algorithm
   when expanding/compacting with the following modifications; 1)
   use node definitions everywhere when expanding, 2) generate bnode
   IDs for all node definitions without an '@id', 3) use deep
   comparisons when eliminating node definitions during compaction.

Manu Sporny:  we have another proposal based on this resolution
   [scribe assist by Manu Sporny]

PROPOSAL:  Add warning language to the JSON-LD Syntax and API
   specs noting the most problematic issues when working with
   property generators.

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

RESOLUTION: Add warning language to the JSON-LD Syntax and API
   specs noting the most problematic issues when working with
   property generators.

Markus Lanthaler:  Do we want to add a flag to disable property
   generators?
   ... we don't have to put this in the spec though
Gregg Kellogg:  We could add a note
Markus Lanthaler:  Let's add a note to the warning section of
   this feature

PROPOSAL:  Add a non-normative note to tell implementers that
   their implementations may have a feature that allows all but one
   node definition created by a property generator to be collapsed
   into a node reference.

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

RESOLUTION: Add a non-normative note to tell implementers that
   their implementations may have a feature that allows all but one
   node definition created by a property generator to be collapsed
   into a node reference.

Manu Sporny:  Markus raised an issue that we might need define
   some processing/memory limits to mitigate DoS attacks
Gregg Kellogg:  That would have to be done at an operating system
   level, right?
Manu Sporny:  Well, you could e.g. count the number of method
   calls, document size. How to implement it would be up to
   implementers.
   ... but I agree.. it varies wildly from language to language

Topic: ISSUE-153: Define error handler behavior

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/153
Manu Sporny:
   http://json-ld.org/spec/latest/json-ld-api/#jsonldprocessingerror
Manu Sporny:
   http://json-ld.org/spec/latest/json-ld-api/#conformancecallback
Manu Sporny:  The ConformanceCallback is called whenever a
   recoverable conformance issue is detected
Manu Sporny:

https://github.com/json-ld/json-ld.org/blob/master/spec/latest/json-ld-api/index.html#L847
Manu Sporny:

https://github.com/json-ld/json-ld.org/blob/master/spec/latest/json-ld-api/index.html#L936
   ... this is the standard way Node.js does it
Markus Lanthaler:  I feel like we're doing too much here - it's
   difficult to understand where in the document it is. [scribe
   assist by Manu Sporny]
Markus Lanthaler:  where the error is - I don't know if it's
   possible to have a generic error handler like this. We could just
   have STOP_ON_ERROR and IGNORE_ERROR. I'd like to see an
   implementation of this. I can't make a decision based on this
   proposal. [scribe assist by Manu Sporny]
Markus Lanthaler:  Yeah, having an implementation would be
   helpful to understand whether this is nice in theory, but
   impractical in practice. [scribe assist by Manu Sporny]

ACTION: Dave Longley to do an implementation of the conformance issue
feature.

Lin Clark: No opinion on how it is implemented.
Manu Sporny:  Dave Longley might have an opinion on this
   proposal. [scribe assist by Manu Sporny]

Topic: ISSUE-159: Add specifying @language to expanded form

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/159
Manu Sporny:  The basic question here is how we are going to
   round-trip
Manu Sporny: Ask Drupal to change the data model (non-starter),
Manu Sporny: Adopt a 1-to-1 mapping between compact/expanded form
   for language maps, (adds complexity to syntax)
Manu Sporny: Adopt a complex algorithm to reconstruct language
   maps from expanded form, (adds complexity to API, and may be
   non-deterministic)
Manu Sporny: Model the data using BCP47 language code IRIs.
   (problematic from an RDF data model standpoint)
Manu Sporny: We could do something like this: { '@language':
   {'en': {}, 'de': {} } }
Gregg Kellogg: how would it work for this? {"en": "foo", "de":
   "bar"}
Manu Sporny: or this alternative - {'@languagemap': 'en', a: ”,
   b: ”}
Gregg Kellogg:  This would be another case where we include
   metadata in the data, which we didn't like before
Gregg Kellogg: {"@id": "foo", "@language": "en", …}
Markus Lanthaler:  for strings: {"@value": "foo", "@language":
   "en", …}
Gregg Kellogg: We could just do this in compact form: {"en":
   ["foo", {"@id": "bar"}]}
Gregg Kellogg: which would expand to this: {"http://prop",
   [{"@value": "foo", "@language": "en"}, {"@id":"bar", "@language":
   "en"}]}
Lin Clark: isn't this the proposal in #4?
Manu Sporny: Lin, yes I think it is.
Markus Lanthaler:  what would you do if this was in compact form?
   {"@id": "foo", "@language": "en", …}
Markus Lanthaler:  We could use IRIs for languages - {"@id":
   "foo", "http://json-ld.org/vocab/language": "en", …}
Lin Clark: yeah, that's not a req for us
Markus Lanthaler:  What's the meaning of this: { "@context": {
   "@language": "de" }, "@id": "foo", "@language": "en", …}
Manu Sporny:  the @language outside of the @context takes
   precedence. [scribe assist by Manu Sporny]

ACTION: Gregg to write up language-map spec text for JSON-LD API in the
issue tracker.

Gregg Kellogg: This could be a problem - {"@value": 4}
Gregg Kellogg: if somebody does this - {"en": 4}
Gregg Kellogg: what does this mean? {"http://prop": {"@value": 4,
   "@language": "en"}}
Gregg Kellogg: {"http://prop": {"@value": "4", "@language": "en",
   "@type": "xsd:integer}}
{"http://prop": {"@value": "somestring", "@language": "en",
   "@type": "someType}}
Manu Sporny:  Gregg, what about allowing @language in compact
   form but using @langmap in expanded form instead
   ... the problem with precedence rules is that a developer
   needs to know them to work with the data, and it's hard to keep
   all of that in your head.
Gregg Kellogg:  Yes, but then this feature would become useless
Markus Lanthaler:  wasn't that the same argument we just had for
   prop. generators? We don't want to have metadata in the data?
Markus Lanthaler:  what about this? {"en": 4} - expands to - {
   "@value": 4 }
Markus Lanthaler:  That wouldn't be put in language map when
   compacting
Gregg Kellogg: I think think is possible in compact form:
   {"foaf:age": [{"en": 42}, {"de": 59}]}
Gregg Kellogg: which would expand to this, if we use @langmap:
   {"foaf:age": [{"@value": 42, "@langmap": "en"}, {"@value": 59,
   "@langmap": "de"}]}
Gregg Kellogg: or this: {"foaf:age": [{"en": "42"}, {"de": "59"
   }]}
Gregg Kellogg: would expand to this: {"foaf:age": [{"@value":
   "42", "@language": "en"}, {"@value": "59", "@language": "de"}]}
Markus Lanthaler:  I'm not convinced that we should include
   @langmap - it's metadata, it looks like it's a hack. [scribe
   assist by Manu Sporny]
Gregg Kellogg:  The only reason to have a hack is so we don't get
   to the case where we have both @type and @language. We're adding
   a keyword to support an anti-pattern. Maybe we should just throw
   a conformance error if somebody tries to use a langmap and
   expresses a number against it. [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 Monday, 15 October 2012 00:45:48 UTC