JSON-LD Telecon Minutes for 2012-07-10

The minutes from today's call are now available here:

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

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

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

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Jul/0005.html
Topics:
   1. ISSUE-133: Add @container: @language
   2. Sub-tree support for @container
   3. ISSUE-134: Add @container: @id
Chair:
   Manu Sporny
Scribe:
   Manu Sporny
Present:
   Manu Sporny, Niklas Lindström, Gregg Kellogg, David I. Lehn, Dave
   Longley, Markus Lanthaler
Audio:
   http://json-ld.org/minutes/2012-07-10/audio.ogg

Manu Sporny is scribing.
Manu Sporny:  Anybody had any more thoughts about @container:
   @language?
Niklas Lindström:  I had thought about it a bit - my gluon stuff
   tracks it fairly closely - I think we can do it fairly simply.
Manu Sporny:  Any updates/changes to the Agenda?
Gregg Kellogg:  I'm speaking today at Stanford, about JSON-LD...
   one of the folks will be with the Protoge group. Creating editors
   for vocabularies - can't show it more widely because it's work
   done for a client.
Manu Sporny:  When is the NoSQL talk on JSON-LD?
Gregg Kellogg:  In August at some point.
David I. Lehn: Looking forward to hearing about how that turns
   out.

Topic: ISSUE-133: Add @container: @language

https://github.com/json-ld/json-ld.org/issues/133
Manu Sporny:  Are we making JSON-LD too complicated by adding
   this feature? Is it worth it?
Gregg Kellogg:  The key discussion point was to be able to use
   object patterns where we're using array patterns right now.
   Object-patterns are good for using dot-pattern for accessing
   data.
Niklas Lindström:  Yes, that's the gist of all of this -
   regarding complexity, it's not so much about the complexity of
   JSON-LD, spec-wise... it's more about what to expect as a
   reader/consumer of JSON-LD.
Niklas Lindström:  The generic shape (E-A-V), we fold in a
   property value and use it as a key... it's fairly idiomatic
   JSON... well, JSON is used in a very wide range of data... JSON
   is a slice of data. There are always structures in JSON that
   don't make sense to put it in JSON-LD.
Niklas Lindström:  Sometimes you have keys that come from certain
   view-related contexts that have no reasonable semantic
   representation. If you view JSON like that, and try to express
   those shapes as triples, you will get very strange entities.
Manu Sporny:  When we convert to RDF from language maps (and
   similar) I think it's strange to RDF people. The shape of the
   data is different and we seem to hop around to generate the
   triples, it seems like it may be a little backwards for RDF
   people. [scribe assist by Dave Longley]
Niklas Lindström:  When you see well-shaped JSON, you see what
   the JSON-LD context should be... @container: @language and
   @container: @id - maybe @container: @type and @container:
   ANY_PROPERTY may be possible?
Dave Longley:  Maybe we can let people create maps in any way
   that they want?
Manu Sporny:  does anyone here have a handle on how to genericize
   this? [scribe assist by Dave Longley]
Niklas Lindström:  If we say that "@container" can be used for
   all these cases... maybe @container defines the kind of objects
   ... if it's lists or sets, then you use an array... if not, maybe
   you use a map.
Gregg Kellogg: For value-map; in Expansion:
Gregg Kellogg: Before 2.2:
Gregg Kellogg: If active property is has @container: @language,
   and every key in element is of the form language (from BCP47) and
   does not map to an absolute IRI, the return value is an array
   constructed from the result of performing Value Expansion on each
   value using a copy of context with @language set to each key from
   element in turn.
Niklas Lindström:  The exact property that you use is defined as
   the value of the container in the context.
Gregg Kellogg:  The language above tweaks the processing rules a
   bit - when you expand, that pattern goes away.
Niklas Lindström:  This is a specific part of the general
   suggestion - maybe language, just like @context, could be put
   into any context? Maybe it doesn't need to be put in literals...
   but likexml:lang, it can be put anywhere.
Markus Lanthaler:  You can still do that, right? Put @context
   anywhere and make it contain @language.
Niklas Lindström:  Maybe this would make things more complex...
   maybe it would simplify @container: @language.
Markus Lanthaler:  This is getting complex if you have such
   subtrees... especially from the standpoint of compaction.
Dave Longley:  We're still going to have to treat @language a
   little differently - it doesn't work in the same way as some of
   this other stuff.
Niklas Lindström:  Right, but @container: FOO might act a little
   differently.
Manu Sporny:  we need to try out some implementations for this,
   either we can try out some algorithms for the general case, or we
   could just implement @container: @language/@id since we have use
   cases for those ... and we could generalize later. [scribe assist
   by Dave Longley]
Manu Sporny:  what we really need are some implementations to try
   this out, we don't need to talk about it because it would take a
   long time. [scribe assist by Dave Longley]
Niklas Lindström:  @container: @id might be interesting for
   RDF/JSON people.
Niklas Lindström:  Maybe we could do a @graph alias with the
   @container set to @id.

Topic: Sub-tree support for @container

Markus Lanthaler:  regarding @container: @language - do we want
   to support entire subtrees?
Markus Lanthaler: { "de": subtree, "en": or literal" }
Gregg Kellogg:
   https://github.com/json-ld/json-ld.org/issues/133#issuecomment-6740466
Markus Lanthaler:  I think Manu and I want this to be a bit
   simpler...
Gregg Kellogg:  Processing-wise, it's fairly straight-forward...
   objects, or objects that can contain other objects seems
   needlessly restrictive. It disallows the exact process Denny was
   asking for.
Dave Longley:  I don't think it's that difficult to see what's
   going on here - if you get into sub-levels... looking at Gregg's
   example... it's fairly obvious how it works. It may be confusing
   about how to go from expanded to compact form.
Dave Longley:  I don't think people are going to think about how
   to convert from one to another when the tools exist, people won't
   have to think about it.
Niklas Lindström:  Yes, I agree.
Markus Lanthaler:  I agree w/ expansion - quite understandable to
   developers/authors. Regarding compaction, I don't see how it
   would work. You'd have to either keep it in expanded form, or
   you'd have to inject a context.
Niklas Lindström:  This example, when we discussed it, I don't
   recall the guidelines for using skosxl - perhaps using
   dc:language would be more suitable? That is why I brought up the
   idea of a generic @container feature.
Niklas Lindström:  Maybe we should use the IRI for dc:language
   instead - current bnode for SKOS-XL literal form might be a
   datatype ... [scribe missed]
Gregg Kellogg:  All types and languages are datatype
   properties...
Gregg Kellogg:  In RDF 1.1.
Gregg Kellogg:  If the property is of the form BCP47, in this
   case you might be able to have other properties at that level.
   May be reasonable to restrict it - @container: @language - all
   properties of the object it references must be of that form.
Gregg Kellogg:  This would also work better for the definition
   for @container: @id - all keys of the object it's referenced by
   would be IRIs. It would allow us to use compact IRIs, relative
   IRIs, etc.
Niklas Lindström:  Yes.
Dave Longley:  We could just restrict it, like Gregg is
   suggesting - it doesn't work if you don't comply with the rules.
Niklas Lindström:  Yes, anything else would be hard to
   understand.
Discussion about a vocabulary for
   http://dbpedia.org/resource/International_Phonetic_Alphabet
Gregg Kellogg:  This is kind of a form of reification... metadata
   about metadata.
Dave Longley:  Yeah, you could always create a new property...
Niklas Lindström:  Yes, label by map or by language...
Gregg Kellogg:  Compaction rules would be fairly clear on this...
Gregg Kellogg:  There is definitely some complexity in here -
   we're going to have to work through it.
Dave Longley:  We will need to specify where properties like
   @type go.
Niklas Lindström:  I think @type should be there.
Dave Longley:  If we had a second map, we'd have to figure it out
   in the algorithm.
Discussion about corner cases about how to specify where certain
   properties go...
Gregg Kellogg:  Could you have a quick look at this:
   http://typewith.me/p/20120712jsonld [scribe assist by Markus
   Lanthaler]
Niklas Lindström: … "labelByLang": {"@id": "rdfs:label",
   "@context": "@language"}
Niklas Lindström: … "labelByLang": {"@id": "rdfs:label",
   "@container": "@language"}
Niklas Lindström:  The cases for using these @container
   declarations are very application specific - most would probably
   stay away from it.
Markus Lanthaler:  Take a look at the Etherpad link I put above
Markus Lanthaler:  What should we do about @value's that are not
   language-tagged?
Gregg Kellogg:  I think it should remain in expanded form.
Gregg Kellogg:  The way that I was proposing it was that the
   result is to set the language specified in the key as the default
   language in the context.
Gregg Kellogg:  The other way to do it would be to override the
   language definition of 'ex' to say that the language is null...
Niklas Lindström:  It's hard to know what X means here.
Gregg Kellogg:  We need to be careful here about how to set
   xsd:string - it's an RDF 1.1 model issue, so a back-end should
   implement it this way, though. A plain literal gets the datatype
   of xsd:string.
Gregg Kellogg: From RDF Concepts: "A language-tagged string is
   any literal whose datatype IRI is equal to
   http://www.w3.org/1999/02/22-rdf-syntax-ns#langString."
Manu Sporny:  it sounds like we're homing in on some kind of
   solution here, but only an implementation would handle most of
   the issues with this [scribe assist by Dave Longley]
Manu Sporny:  any other concerns about @container: @language
   before we talk about @container: @id? [scribe assist by Dave
   Longley]
Niklas Lindström:  Maybe applying compaction w/ SKOS-XL labels,
   you have to do a deep traversal, put things into different
   buckets - that's an argument against doing deeper subtrees.
Gregg Kellogg:  The problem with compaction is that you need to
   know when you're in a subtree... it makes it more complicated.
   That's why the rule I specified above is simpler.
Niklas Lindström:  In expansion, it's simpler... in compaction
   it's a bit more difficult.
Gregg Kellogg:  It may be that this is not applied in
   compaction...
Niklas Lindström:  Maybe only on language literals is where you
   can use this in compaction?
Gregg Kellogg:  What if there are multiples?
Niklas Lindström:  The code would end up being half-way to a
   reasoner.
Gregg Kellogg:  Maybe we need to have something like dc:language
   as niklas suggested...
Niklas Lindström:  That would make it a bit simpler, yes.
Gregg Kellogg:  If we allowed "@language" in a subject definition
   - we could just use that instead.
Manu Sporny:  i'm a bit concerned that we're now thinking about
   adding features just to make other features work more cleanly
   [scribe assist by Dave Longley]
Gregg Kellogg:  i think the answer is that we're not done yet, we
   need to keep working on the issue [scribe assist by Dave Longley]

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

https://github.com/json-ld/json-ld.org/issues/134
Manu Sporny:  do we want to support @container: @id? is the
   RDF/JSON use case compelling? would people actually rather use
   that than just N-triples, etc.? [scribe assist by Dave Longley]
Manu Sporny:  one argument for it would be that they could just
   JSON-LD for everything if we had this feature [scribe assist by
   Dave Longley]
Manu Sporny:  the concern is that if we don't generalize this
   @container behavior it's one more special feature we have to add
   and consider how to interpret JSON-LD [scribe assist by Dave
   Longley]
Manu Sporny:  it's becoming more difficult to look at the JSON
   data without looking at the @context to understand it [scribe
   assist by Dave Longley]
Gregg Kellogg:  You can't really do RDF/JSON - the keys at the
   top-level are subjects. With @container: @id, it has to be an
   object that is the value of some other property.
Gregg Kellogg:  We can't completely the duplicate RDF/JSON
   pattern.
Niklas Lindström:  Unless we can [scribe missed]
Niklas Lindström: … "byURL": {"@id": "@graph", "@container":
   "@id"}
Gregg Kellogg:  We could just change it so that the object of
   graph is a subject-map. Maybe we don't have to do @container: @id
Gregg Kellogg:  You can syntactically have @graph with an
   object-value rather than an array-value... we could change it for
   @graph so that if it is an object value, then it is a
   subject-map.
Gregg Kellogg:  We could do that w/o any context definition at
   all.
Manu Sporny:  could you clarify what you're saying about how we'd
   change @graph? [scribe assist by Dave Longley]
Manu Sporny:  Could you clarify a bit?
Dave Longley: change the meaning of @graph: {} from a single
   subject to a subject map.
Gregg Kellogg:  @graph is something that was more recently
   introduced. The fact that we have @graphs that can have values
   that are objects... it's a convenience... we could change the
   processing rules so that if the value of @graph is an object,
   then the keys of that object are treated as subject.
Manu Sporny:  Do we support @graph deep down in the subtree?
Dave Longley:  yes
Gregg Kellogg:  yes.
Niklas Lindström: … "@graph": {"@id": "@graph", "@container":
   "@id"}
Niklas Lindström:  We may need to have a flag to specify when to
   do this.
Niklas Lindström:  Specifically, for compaction.
Manu Sporny:  ok, it seems like that may be a fairly reasonable
   approach for supporting @container: @id [scribe assist by Dave
   Longley]
Manu Sporny:  this would allow people to use index based off of
   subjects, etc. [scribe assist by Dave Longley]
Manu Sporny:  so back to the original question, how many people
   would want/need this feature? [scribe assist by Dave Longley]
Gregg Kellogg:  Yes, I had to use object patterns with the RDFa
   Test Suite... you want to use objects in many cases. Avoid the
   use of arrays.
Dave Longley:  This is about wanting to get at subjects quickly
   w/o having to do queries. This would enable that to happen.
Niklas Lindström:  Since RDF/JSON has been shelved, maybe we
   could re-enable that use case with this feature.
Dave Longley:  Don't want to add complexity - but we could re-use
   this for the query mechanism that we had in the API. If we could
   just put @container: @id or @container: @type, you could just use
   it like a JavaScript object and get at the data that way.
Niklas Lindström:  Yes, I hit this when looking at .graphify() -
   this general mechanism of using @container to create maps of
   important bits is very valuable.
Niklas Lindström:  using objects as maps instead of filtering
   arrays is quite palatable - we should be clear that this is for
   specific use cases only.
Manu Sporny:  the concern i keep coming back to is that we're
   adding complexity to the language [scribe assist by Dave Longley]
Manu Sporny:  and we're saying that we only need people to use
   these features for specific corner-cases [scribe assist by Dave
   Longley]
Niklas Lindström:  This should be an experiment and marked as
   such in the spec.
Gregg Kellogg:  This is an issue of some usage of JSON directly.
   I've been putting these data in a collection - each item is a
   model. I get something from the collection by ID. Most convenient
   form for me is to have a flat representation.
Gregg Kellogg:  I like a shallow traversal of the objects that
   come back - if that's how people are going to use JSON-LD, to
   drive REST-ful applications... keeping things in an array form,
   and using .objectify(), .graphify() is a useful pattern.
Dave Longley:  It does seem like we're mixing features - that's
   what the API was intended to do - .frame() and .objectify()...
   maybe we're overstepping our bounds.. maybe this should be
   something the API does.
Dave Longley:  We're definitely talking about how to shape the
   data... that's API territory.
Gregg Kellogg:  Yes, so should that be a step in framing? Maybe
   we're talking about what is syntactically valid JSON-LD... maybe
   language and ID maps are output from the API, but the output
   needs to be syntactically valid JSON-LD.
Niklas Lindström:  If you want to use compacted form, you want to
   send your data in very simple forms - in a common usage pattern.
   These maps instead of arrays are very useful in those scenarios.
Niklas Lindström:  It may be good to see these scenarios in the
   wild - these scenarios are probably not going to look at the API
   ... .graphify() is mainly for people that understand the data
   model.
Gregg Kellogg:  one of the reasons I don't care for graphify,
   what we're talking aobut is the way that people expect to use
   JSON data... they want to use dot-notation to get to data.
Manu Sporny:  there are use cases for each approach that we've
   been talking about, but i do agree with gregg because i don't
   think people are going to depend on an API ... they are just
   going to publish their data and if we don't support that pattern
   they just won't use JSON-LD [scribe assist by Dave Longley]
Manu Sporny:  i don't think they are going to be willing to ask
   the consumers of their data to use the JSON-LD API in order to
   use their data [scribe assist by Dave Longley]
Markus Lanthaler: +1 to what manu just said
Dave Longley: +1
Niklas Lindström:  With this mechanism, in a JSON-LD context - we
   can say "This object map X, means this expression Y."
Niklas Lindström:  We can glean that meaning, but with this
   extended @container we can specify it.
Manu Sporny:  we're at the top of the hour [scribe assist by Dave
   Longley]
Manu Sporny:  these are all good discussions, next step is that
   we need to do some implementations on this and see how feasible
   this is [scribe assist by Dave Longley]
Manu Sporny:  implement @container: @language, maybe modify
   @graph to be a subject map for object values [scribe assist by
   Dave Longley]
Manu Sporny:  and figure out how to generalize @container: foo
   [scribe assist by Dave Longley]
Dave Longley: Discussion about IP/patent agreement stuff - we
   have all IPR necessary to do a FPWD. Josh Mandel is the only
   person that we wanted to get a commitment from that we didn't. He
   didn't contribute anything to the specs that we're publishing. He
   was involved in the .objectify() discussion.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Tuesday, 10 July 2012 19:38:51 UTC