JSON-LD Telecon Minutes for 2012-09-04

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

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

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

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

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Sep/0000.html
Topics:
   1. Talk about JSON-LD at NoSQL conference
   2. Discussion on RDF Concepts terminology
   3. ISSUE-134: Add @container: @id
   4. ISSUE-141: Prefix/CURIE terminology
   5. ISSUE-155: JSON-LD introduction via data model
   6. ISSUE-109: Add flatten() method to JSON-LD API
   7. Determine if .frame() should be in JSON-LD 1.0
Resolutions:
   1. Do not support id-maps via 'container'; '@id' in JSON-LD
      1.0.
   2. Rewrite the introductory portions of the JSON-LD document
      to explain JSON-LD in JSON terms first, then describe the
      advantages of JSON-LD, then rework the Linked Data section as the
      JSON-LD data model section.
   3. Support a 'flatten' option to .expand() and .compact(). The
      value of the option will be the graph to flatten and return. The
      default value will be false, to ensure that that the JSON-LD
      input document is not flattened.
   4. Do not support .frame() in JSON-LD 1.0 API.
Chair:
   Manu Sporny
Scribe:
   Markus Lanthaler
Present:
   Markus Lanthaler, Niklas Lindström, Manu Sporny, Gregg Kellogg,
   François Daoust, David I. Lehn
Audio:
   http://json-ld.org/minutes/2012-09-04/audio.ogg

Markus Lanthaler is scribing.
Niklas Lindström:
   https://github.com/json-ld/json-ld.org/issues/140
Niklas Lindström:  regarding framing we might take into account
   as well ISSUE 140 (objectify) as well
Manu Sporny:  Any updates to the agenda? I have two things -
   would like to hear from Gregg about NoSQL + JSON-LD discussion,
   and I had a long discussion w/ Richard Cyganiak that was good.
   [scribe assist by Manu Sporny]
   ... probably we should start off with framing and look at that
   as an alternative to it

Topic: Talk about JSON-LD at NoSQL conference

Gregg Kellogg:  the audience was a bit unusual as NoSQL is just
   not *a* thing.. it's a lot of things
   ... the tendency in Mongo is to use small docs however this
   can lead into severe performance issues
   ... where JSON-LD really has an advantage there is that it
   supports named graphs
   ... you can include all data collected from a source into one
   document in Mongo
   ... another interesting thing is that there were several talks
   about JSONiq
   ... which is basically XPath for JSON
   ... I didn't had a look at it yet.. but the basic form to use
   it would be flattened graphs
   ... a query should be something we should be able to tackle
   (generically)
Gregg Kellogg: http://jsoniq.org
Manu Sporny:  Yes, framing was intended to do some querying
   ... any question regarding your talk at the conference
   ... how do you feel about the approach you choose this time?
   Was it better than last time?
Gregg Kellogg:  I spent very little time on the API
   ... I probably should have had another slide on the API calls,
   describing them on a high-level
   ... I think this approach worked pretty well.
   ... there was a different group. I think the SemTech people
   understand the issues more to get confused :-)

Topic: Discussion on RDF Concepts terminology

Manu Sporny:  I talked to Richard off-line yesterday
   ... Richard felt that we need to say a bit more how JSON-LD
   relates to RDF
   ... but we don't need to do this at the beginning
   ... he's the one to keep the terminology accross all "RDF" in
   sync
Niklas Lindström: +1 for Richard's contribution
François Daoust: +1 as well
Gregg Kellogg: +1
   ... Richard will try to write that section
Markus Lanthaler: +1
   ... he also proposed to re-write the introduction in terms
   that Web developers understand, i.e., JSON terminology
   ... e.g. JSON folks are more used to talk about objects than
   about nodes
   ... he also felt pretty strongly about the JSON-LD model
   ... he's not concerned about the people reading the model
   ... it's more about people trying to create interoperable
   specs
   ... we should also state clearly what JSON-LD adds to plain
   old JSON
   ... I have an idea how the introduction should look like but
   would like to talk about this first
Gregg Kellogg:  Richard also mentioned to remove the whole Linked
   Data definition from the spec
Manu Sporny:  Yes, that's another point
Niklas Lindström:  the thing the draw me to RDF in general is
   that there is a clear intent on the conceptual level that you
   describe things on themselves
   ... you have not raw data as in a table but you have a clear
   link to the domain model
Manu Sporny:  OK, I'll give it a try
Gregg Kellogg:  I would be -1 for renaming node
   definition/reference to object definition/reference
Manu Sporny:  This brings us to the last point
   ... Richard was concernced about specifying what is linked
   data and what isn't linked data
   ... this might be problematic as the web might change in the
   future
   ... so we should take the normative linked data definition out
   and just define the JSON-LD's data model instead
Gregg Kellogg:  I agree that moving it away from defining Linked
   Data is a good idea
   ... it's not really the job of a syntax/API spec to define
   something that broad
Niklas Lindström:  I'm wondering what we are aiming at.. I mean
   we wanna make it compatible to RDF, right?
Manu Sporny:  Yes, and the answer is the RDF appendix Richard
   will be working on
   ... but we can't say JSON-LD is a 1:1 serialization of RDF

Topic: ISSUE-134: Add @container: @id

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/134
Manu Sporny:  Do we want support to @id maps?
   ... the last resolution we made was "Attempt to add other
   @container options, such as "@container": "@language" to support
   Wikidata's language-map use case."
   ... I don't know what the other's position is
   ... my position clearly changed.. I was against it at the
   beginning but after working on integrating some systems into
   JSON-LD I think I would be +1 on supporting this now
Gregg Kellogg:  I'm a bit more worried about using it deeply in a
   document
   ... I would instead see it more reasonable at the document's
   top-level
   ... which means it would need to work differently from other
   @containers
   ... otherwise it's difficult to understand the data by just
   looking at a document
   ... so summarized I would be +1 for having it at the top-level
Niklas Lindström:  I generally agree with Gregg
   ... it would be interesting some examples of the work you
   talked about before Manu
Manu Sporny:  I will try to add some
Niklas Lindström:  I think generally this is very useful for
   expansion (less so for compaction)
   ... just like language maps it distorts the data shape
   ... but the ID is such a fundamental concept that makes it
   problematic
Manu Sporny:  I tend to agree
   ... if people start using all the available ways to express
   data it's very difficult to read documents
Gregg Kellogg:  there are a lot of practical reasons to support
   that at the top-level
   ... e.g. node maps, graphify etc.
   ... otherwise we use a data structure internally and there's
   no way to express that as a document in general
Manu Sporny:  I'm a bit worried about just supporting it at the
   top-level
   ... not even the example in the issue is at the top-level
   ... I'm worrying that adding just that doesn't address the
   issue
   ... my preference right now is to do just nothing
Niklas Lindström:  do we already support this for graphs?
Markus Lanthaler:  no
Niklas Lindström:  we already support similar things so it
   wouldn't be too far off the path
Markus Lanthaler:  What's the difference between this and
   language maps? [scribe assist by Manu Sporny]
Gregg Kellogg:  It's fairly easy to understand what a language
   map is doing just by looking at it... that's not necessarily true
   for @id maps. [scribe assist by Manu Sporny]
Manu Sporny:  Does anyone feels strongly about addressing this in
   JSON-LD 1.0?
Niklas Lindström:  Just as Markus just said it is often a very
   efficient way to access data
   ... if someone has a bunch of resources that are tightly bound
   together you either frame the data using one root node or you
   keep the data in something like a node map
   ... doing graphify would make this probably make unnecessary
   as everything would be linked

PROPOSAL:  Do not support id-maps via 'container'; '@id' in
   JSON-LD 1.0.

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

RESOLUTION: Do not support id-maps via 'container'; '@id' in
   JSON-LD 1.0.

Topic: ISSUE-141: Prefix/CURIE terminology

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/141
Markus Lanthaler:  I already checked the text, it's been changed
   and I think it addresses Gavin's issue. So, I closed the issue.
   [scribe assist by Manu Sporny]
Manu Sporny:  I'll ping Gavin to make sure he's okay with the
   change. [scribe assist by Manu Sporny]

Topic: ISSUE-155: JSON-LD introduction via data model

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/155
Manu Sporny:  This what we discussed at the beginning of the call
   ... I think we handled that already in the beginning of the
   call and I think we have agreement on this
Manu Sporny: In general, the introduction should be re-written to
   do the following things, in this order:
Manu Sporny: 1. Basic Introduction to what JSON-LD is about.
Manu Sporny: 2. Basic introduction to the JSON model and what
   JSON-LD enables over the regular JSON model. Try to use JSON
   model terminology as much as possible at this stage.
Manu Sporny: 3. An introduction to the JSON-LD data model (this
   is currently the Linked Data section, but it may be renamed to
   avoid conflict in the RDF WG)

PROPOSAL:  Rewrite the introductory portions of the JSON-LD
   document to explain JSON-LD in JSON terms first, then describe
   the advantages of JSON-LD, then rework the Linked Data section as
   the JSON-LD data model section.

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

RESOLUTION: Rewrite the introductory portions of the JSON-LD
   document to explain JSON-LD in JSON terms first, then describe
   the advantages of JSON-LD, then rework the Linked Data section as
   the JSON-LD data model section.

Topic: ISSUE-109: Add flatten() method to JSON-LD API

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/109
Gregg Kellogg:  we might wanna have a flag to the call to just
   return the node map instead
Markus Lanthaler:  I wouldn't like to just have a flag.. I would
   prefer having two methods instead
Gregg Kellogg:  Is the result of flatten() compacted?
Markus Lanthaler:  no
Gregg Kellogg:  I rely on that in my graphify() and it would be
   also useful in other scenarios such as using it with backbone
   ... I think the question is whether we reduce the number of
   entry points or create API calls that depend on each other
Manu Sporny:  I'm worried that adding all that atomic stuff makes
   it more difficult for people to learn the API
Niklas Lindström:  first my graphify/connect doesn't flatten
   first.. it just traverses entire documents
   ... the other thing is whether we need a flatten() method or
   whether we should have a flag to expand() to flatten a document
   ... or compact()
Gregg Kellogg:  I like that idea
Markus Lanthaler:  You could use an empty frame, and that would
   flatten it. [scribe assist by Manu Sporny]
Manu Sporny:  I think we all agree that some form of flatten
   should go into the spec
Manu Sporny:  Ok, so four options 1) Add a 'compact' flag to
   .expand() and .compact(), 2) Add a .flatten() method, 3) Add a
   .flattenToMap() call, and 4) .frame(obj, {}) would flatten.
   [scribe assist by Manu Sporny]
Manu Sporny: 1) +1, 2) +0.5, 3) +0 - separate issue, 4) -1 - i
   don't think we're going to support .frame()
Niklas Lindström: 1) +1(but the flag should be called 'flatten'
   or perhaps perferably 'merged'?), 2) -1, 3) +0, 4) -1
Gregg Kellogg: 1) +1, 2) +0.5, 3) +0.5, 4) -1
François Daoust:  I'm a bit confused by the different options -
   I'm concerned that where a method can return something that isn't
   JSON-LD in the end. [scribe assist by Manu Sporny]
Gregg Kellogg:  One thing flatten() allows you to do is to pass a
   graph name and it just returns you the contents of that graph
   ... this should be supported as well as something which allows
   you to get back as well the graph definitions itself
François Daoust:  I'm concerned that depending on a flag, you get
   something different out of the API. [scribe assist by Manu
   Sporny]
François Daoust:  It seems like we should be able to get JSON-LD
   out of .compact, .expand, etc. I understand that we don't do this
   for toRDF, and that's fine. [scribe assist by Manu Sporny]
Gregg Kellogg:  You are right, developers want indexed documents.
   If I just get back a flattened document I would have to go and
   redo the step of creating an indexed structure
Manu Sporny:  I think we need to seperate these two issues:
   flattening and id-maps
   ... let's just try to decide what to do with flattening
Niklas Lindström:  I agree.. and looking at the votes we probably
   end up adding a flag to compact/expand
   ... one detail: "merged" might be a better term then "flatten"
Gregg Kellogg:  Is kind of doing both

PROPOSAL:  Support a 'flatten' option to .expand() and
   .compact(). The value of the option will be the graph to flatten
   and return. The default value will be false, to ensure that that
   the JSON-LD input document is not flattened.

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

RESOLUTION: Support a 'flatten' option to .expand() and
   .compact(). The value of the option will be the graph to flatten
   and return. The default value will be false, to ensure that that
   the JSON-LD input document is not flattened.

Niklas Lindström:  Just wanted to tell you that in my
   implementation I also support @type maps
Manu Sporny:  I think this shows that we need some sort of
   .index() API method. Then we could have id-maps, type-maps,
   property-maps, etc. It would be the general solution that we've
   been looking for.

Topic: Determine if .frame() should be in JSON-LD 1.0

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/110
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/118
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/119
Gregg Kellogg:  I have very little use of framing
Niklas Lindström:  I do some kind of framing but it is totally
   idiomatic
Manu Sporny:  We have a strong use of framing but I think it's
   too complicated
François Daoust: +1 not to have framing in JSON-LD 1.0
Markus Lanthaler:  I would be fine either way. What would be the
   next steps if we decide to drop it? Would we remove it from
   json-ld.org?
Manu Sporny:  No, I think we should keep the spec on json-ld.org
   - other people might find it helpful.
David I. Lehn: we do use framing so would be nice to look into
   standardizing it sometime unless an alternative presents itself

PROPOSAL:  Do not support .frame() in JSON-LD 1.0 API.

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

RESOLUTION: Do not support .frame() in JSON-LD 1.0 API.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Which is better - RDFa Lite or Microdata?
http://manu.sporny.org/2012/mythical-differences/

Received on Wednesday, 5 September 2012 01:16:10 UTC