JSON-LD Telecon Minutes for 2012-06-26

Thanks to Niklas for scribing! The minutes from today's call are now
available here:

http://json-ld.org/minutes/2012-06-26/

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

--------------------

JSON-LD Community Group Telecon Minutes for 2012-06-26

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Jun/0071.html
Topics:
   1. Transition of documents to the RDF WG
   2. ISSUE-120 recap - Expansion and @type
   3. .objectify() vs. .frame()
Chair:
   Manu Sporny
Scribe:
   Niklas Lindström
Present:
   Manu Sporny, Gregg Kellogg, Niklas Lindström, Markus Lanthaler,
   Dave Longley, Josh Mandel, François Daoust, David I. Lehn

Manu Sporny:  Anything else we should discuss today? [scribe
   assist by Manu Sporny]
Gregg Kellogg:  Let's discuss .objectify() vs. .frame() [scribe
   assist by Manu Sporny]
Gregg Kellogg:  Markus wanted to look at ISSUE-120 again -
   expansion and @type [scribe assist by Manu Sporny]
Manu Sporny:  i also spoke with linclark, some of that info is in
   the jsonld irc channel [scribe assist by Dave Longley]
Manu Sporny:  I spoke w/ Lin Clark - she has an interesting use
   case that we should discuss. [scribe assist by Manu Sporny]
Manu Sporny:  let's discuss some of the issues that have come up
   before the w3c publication in the rdf working group [scribe
   assist by Dave Longley]
Niklas Lindström is scribing.

Topic: Transition of documents to the RDF WG

Manu Sporny:  we're pretty much set to go
   ... bug the publication tool is buggy, so we can't get the
   FPWD out just yet...
Manu Sporny:  then we need everyone to do their IPR coverage
Manu Sporny: https://dvcs.w3.org/hg/json-ld
   ... we don't have a hg repo, but the W3C staff is ok with us
   mirroring the github repo into the w3c hg for the time being
   (specs, tests, website)
Manu Sporny:  the IPR stuff means a blanket statement that one
   has no issues regarding patents when going forward
   ... the editors/auhors in the community group must be ok with
   this from a copyright pov
Manu Sporny:  we must use the tool for this for the legal stuff
   to become valid
Discussion about the w3c membership process...
Manu Sporny:  any other questions re. W3C FPWD publication
No questions.
Manu Sporny:  markus, you had a question re #120?

Topic: ISSUE-120 recap - Expansion and @type

Markus Lanthaler:  why do we support objects as value of @type at
   all?
Markus Lanthaler:  the reasoning says that the value space is
   different, but the decision to throw away data seems
   contradictory
Manu Sporny:  the only thing @type is looking for is a value to
   interpret as an @id
Manu Sporny:  in order to make the algorithm more accepting, we
   allow an object but only keep the value of @id
Markus Lanthaler:  I'm find with both ways, but not a combination
Manu Sporny:  keeping the data adds lots of complexity, throwing
   an error is unnecessary since it's easy to get the value of @id
   from the object..
Manu Sporny:  we need a better reason for throwing an error than
   that otherwise we discard the other data in the @type object
Manu Sporny:  it makes the algorithm more complex than necessary
   if we throw an error in this corner case
Manu Sporny:  we have plenty of other corner cases where we throw
   an error
Markus Lanthaler:  we have callbacks, but we don't define what
   they do
Manu Sporny:  do you rather see that the callback controls
   recovery instead of automatic recovery?
Dave Longley:  that would be fine with me (explicit callback
   recovery)
Dave Longley:  Markus makes a good point that other things have
   to be considered as well. if an object is there, callback
   controls recovery
Gregg Kellogg:  in the absence of a callback, I'd like the
   current recovery
Gregg Kellogg:  the narrow use case, having RDF data transferred
   over, with a type in expanded form, and when doing compaction I
   want to use @type, this would be beneficial default behaviour
Dave Longley:  so the use case is fromRDF not using @type, but
   wants @type in compacted form?
Manu Sporny:  the other (stronger) reason is that we don't want
   to err out where it's easy to recover (it's the html5 behavior)
Dave Longley:  we have a similar problem with @id
Gregg Kellogg:  it's different
Gregg and Dave discuss thoughts on numeric id:s and IRI
   templating....
Manu Sporny:  there could be something like that in the future;
   in the mean time (going to REC) we need to work this out
Markus Lanthaler:  currently there is no JSON-LD out there, so
   it's better to not support it until it appears
Dave Longley:  to we have real data like this?
Gregg Kellogg:  I think it was an observation from working with
   external sources
Niklas Lindström:  It's hard to reason too much about this w/o
   looking at concrete cases - part of this discussion cropped up a
   few months ago when we discussed whether it was possible to
   represent the RDF type like a general relation, just like any
   other property. [scribe assist by Manu Sporny]
Markus Lanthaler: as far as I remember this came up before we
   allowed rdf:type not to be automatically to @type in fromRDF()
Niklas Lindström:  I've seen some need for this - for example -
   Elastic Search - you want an IRI for the type or perhaps a
   keyword and /also/ some kind of label in different languages
   because people want to search for it. [scribe assist by Manu
   Sporny]
Niklas Lindström:  If you declare rdf:type in your context... it
   may not be coerced like @type. I think this works if you create
   an expanded form fromRDF() and define a term forrdf:type in your
   context when you compact. [scribe assist by Manu Sporny]
Gregg Kellogg: rdf:type a rdf:Property .
Niklas Lindström:  From my point of view - I'm fine w/ throwing
   an error - that we don't allow this form. There should be means
   for recovering. [scribe assist by Manu Sporny]
Niklas Lindström:  I do think that what we have right now is
   enough, explicit recovery is enough in this case. [scribe assist
   by Manu Sporny]
Markus Lanthaler: { "@id": "rdf:type", "@type": "rdf:Property" }
.. or {"@id": "rdf:type", "rdf:type":{"@id: "rdf:Property"}}
Gregg Kellogg:  perhaps if we use the expanded form in all the
   cases where @id isn't applicable, to not lose information

Topic: .objectify() vs. .frame()

Manu Sporny:  gregg, can you write this down in the issue 120?
Gregg Kellogg:  sure
Gregg Kellogg:  Regarding .objectify() - I find framing very
   confusing to use right now
Gregg Kellogg:  it's hard to predict
Gregg Kellogg:  if I can use objectify instead, I have a surface
   type api, where everything is linked and I can access what I want
   in a very simple manner
Josh Mandel: (Re: potential search mechanisms, have folks seen:
   http://jsonselect.org/#tryit ?)
Manu Sporny:  I agree that it is complex and difficult to
   understand how to use the complex stuff
Manu Sporny:  we can't remove framing until we have a good
   replacement. objectify would probably be that
Josh Mandel: I (clearly) also found framing difficult to use,
   which is why I coded up objectify() in the js library...
Niklas Lindström:  I generally agree that framing is difficult -
   I do have some use cases for framing. [scribe assist by Manu
   Sporny]
Niklas Lindström:  .objectify() feels like the way to distinguish
   JSON-LD usage from regular JSON usage... JavaScript has all of
   the requirements in place to make .objectify() work well...
   [scribe assist by Manu Sporny]
Niklas Lindström:  If you are using JSON-LD in a programmatic
   environment, it makes more sense to have an API that creates a
   graph structure of the objects within... because they are linked.
   It feels like a bit of a waste to not do that. This is the way
   I've used RDF previously in object mappers... we should be using
   references. The context definition is a good way to navigate
   Linked Data in general. [scribe assist by Manu Sporny]
Niklas Lindström:  One thing - I'm not sure about the name
   .objectify() - it might not capture the essence... I would use
   .toGraph() or .graphify() - just a detail, but if we're going
   forward with this, I wanted to raise this. [scribe assist by Manu
   Sporny]
Markus Lanthaler: decode()??
Josh Mandel: Yes, I just made up the name `objectify` because it
   sounded cute and I needed to call it something.
Gregg Kellogg:  There is an alternate meaning of Linked Data here
   - you're linking your data internally to create a real graph.
   [scribe assist by Manu Sporny]
Niklas Lindström:  There is something in rdflab - my play area
   for code on github - I've added something that we may want to
   discuss - reverse relations... which makes navigating an RDF
   vocabulary very easy. The thing that I noticed was that this
   structure I got was interesting in that in-memory graphs in RDF
   are more triple centric. This is just linked objects in a graph,
   and that felt much more natural. The triple view of things could
   be created as an iterator. [scribe assist by Manu Sporny]
Niklas Lindström:  This 'shape' felt much more natural... maybe
   this would fit in well with projections in the RDFa API. [scribe
   assist by Manu Sporny]
Niklas Lindström:  To back up quickly - the case where .frame()
   is useful - which is the case where I mostly use JSON-LD - which
   is to index stuff in elastic search. In that case, I didn't use
   the framing algorithm (I used an expand as much as I can
   algorithm... always rooted in current subject resource, which I
   track), I have very advanced search needs. [scribe assist by Manu
   Sporny]
Niklas Lindström:  I need to search for things linking to and
   from that document. [scribe assist by Manu Sporny]
Dave Longley:  I agree with a lot of this - including naming -
   perhaps .connect()?
Dave Longley:  also a query mechanism is good
Dave Longley:  but we have to make sure that code don't end up
   cycling indefinitely (but that can probably be prevented anyway)
Dave Longley:  it's important not to call e.g. expand on an
   "objectified" structure
Dave Longley:  some of the power in framing is available with
   e.g. @container, but some cases might still need to be supported
   to adapt data to current patterns
Markus Lanthaler:  is the question either or, or can they
   complement each other?
Dave Longley:  it should be noted that non-GC languages and
   objectify might not work as well
Josh Mandel: http://jsonselect.org/#tryit
Josh Mandel:  JSON-select could potentially be used for querying
Niklas Lindström:  I used the prototype-based features to be
   clones of the actual objects - this makes the resulting graph
   object serializable by calling .toJSON() on it. [scribe assist by
   Manu Sporny]
Josh Mandel:  Well, except for cycles. [scribe assist by Manu
   Sporny]
Niklas Lindström:  The clones have replaced the .toJSON() message
   with null - it skips cycles - expands into a tree again. [scribe
   assist by Manu Sporny]
Dave Longley:  it might be ambiguous in general though
Gregg Kellogg:  flatten is the key to get it to work
Markus Lanthaler:  how do you enter the graph?
Manu Sporny:  we need to explore whether we can completely
   replace framing with objectify in usages, and if/how they
   complement each other
Gregg Kellogg:  are we continuing in the github tracker?
Manu Sporny:  yes, we can continue to use it
Gregg Kellogg:  how to get github to notify the mailing list (not
   only the people)?
Manu Sporny:  the w3c tracker doesn't either; we can create a
   script
Manu Sporny:  it's important, and I think we can solve it
Manu Sporny:  and I suspect we agree that gh:s tracker is the
   better one?
Gregg Kellogg:  although the w3c tracker works well with irc (but
   there's probably a means with gh as well)
François Daoust: bye
David I. Lehn: bye

-- 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, 26 June 2012 15:37:38 UTC