W3C home > Mailing lists > Public > public-linked-json@w3.org > April 2012

JSON-LD Telecon Minutes for 2012-04-03

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 03 Apr 2012 11:32:43 -0400
Message-ID: <4F7B181B.8040100@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
Thanks to Niklas for scribing! The minutes from today's call are now
available here:

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

Full text of the discussion follows, as well as a link to the complete
audio transcript:

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

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

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Apr/0000.html
Topics:
    1. ISSUE-95: Remove @graph from the spec
    2. ISSUE-84: Probing of unlinked objects
    3. ISSUE-74: IRI conflicts when compacting/expanding
Resolutions:
    1. Do not remove @graph from the JSON-LD syntax.
    2. Do not support controlled probing of unlinked objects for
       this version of JSON-LD.
Chair:
    Manu Sporny
Scribe:
    Niklas Lindström
Present:
    Niklas Lindström, Manu Sporny, Markus Lanthaler, Gregg Kellogg,
    David I. Lehn
Audio:
    http://json-ld.org/minutes/2012-04-03/audio.ogg

Niklas Lindström is scribing.
Manu Sporny:  Let's move Marcus' issue 95 to the first item on
    the Agenda
Manu Sporny:  I've heard that Drupal is looking at JSON-LD for
    web service stuff in drupal 8

Topic: ISSUE-95: Remove @graph from the spec

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/95
Markus Lanthaler:  since @graph currently doesn't support named
    graphs, it's just a copy of @set, doesn't provide anything more
Gregg Kellogg:  we *could* do that
    … related issue regarding framing
    … if we coerced a graph to @set, it would not collapse a graph
    (we would keep the array)
Gregg Kellogg:  two arguments to keep graph: 1. forward-looking
    … if we want to add support for named graphs, we need to
    supply the ID
    … by removing graph now, we're gonna have to reintroduce it
Manu Sporny:  I agree. graph has two purposes; 1. the use of @id
    with an array is to implicit 2; we believe that named graphs are
    inevitable
    … if @graph and @id on the same level, @id gives the graphs
    name
    … if you have a signature, you need to know what it applies to
    -- the terminologgy with @set is less obvious
    … we've seen several people being confused by the overloaded
    @type meaning
    … this removal of @graph could be too confusing, since people
    won't know how these things work in context
    … we don't really expect people to use @set explicitly; it's a
    control keyword in the context
Markus Lanthaler:  the way @graph currently is specified, the
    value is just replaced with the content, and you'll lose all the
    other properties
Gregg Kellogg:  we must update the spec to say that if @graph is
    used, it is the only (currently) active keyword
    ... in that object
    … collapsing should only be done if @graph is the only
    property
Markus Lanthaler:  how does things work if @graph is used at
    lower level
Manu Sporny:  the current redundance is temporary
Markus Lanthaler:  even if we are going there in the future, we
    can always introduce it, but dropping things are more difficult
Markus Lanthaler:  you don't have to add new functionality
Gregg Kellogg:  a context can live in any object
Niklas Lindström:  The most tricky part here is the mechanics of
    @set are special in so far as they currently only work in
    conjunction with the term or property for which it is the value.
    [scribe assist by Manu Sporny]
Niklas Lindström:  @set just means repeat the property for each
    value in this array. Making @set something which can be used at
    the top level extends the meaning of set, but only at the top
    level. It would still mean repeat the property if used anywhere
    that is not the top-level. If @graph is used further below, it
    would mean something - it would create a triple to it. We don't
    have names for @graph, because we don't support @id paired with
    @graph. [scribe assist by Manu Sporny]
Niklas Lindström:  There are different semantics to the way these
    things would work in the future. [scribe assist by Manu Sporny]
Manu Sporny:  the problem is that we oversimplify to the
    detriment of the language
    … while in principle we should avoid redundant keywords, in
    this context we expect the difference to be important
Markus Lanthaler:  we could add the @set as a shortcut
    … there is nothing more at the top-level, so the behavior
    isn't different...
Manu Sporny:  if in the future, you want to express multiple
    objects at the top level, you could use either or?
Markus Lanthaler:  if we add @graph now but don't add a blank
    node, do we have to change it?
Manu Sporny:  right now, the processor should throw an exception
    or explicitly ignore it (probably better) if it encounters
    something using @graph in combination with @id or other terms
Markus Lanthaler:  why not introduce named graphs?
Manu Sporny:  we could, but the concern is that we might get out
    of line with that the RDF 1.1. WG will come up with regarding
    named graphs
    … it would unnecessarily tie up the spec
Markus Lanthaler:  but don't we introduce one half of a spec
    then?
Manu Sporny:  we create a placeholder for an expected feature
Gregg Kellogg:  we should add a design note to the spec with
    these thoughts on named graphs
Markus Lanthaler:  but if we cannot fit it into the result of the
    RDF WG graph solution, do we have to add @graph2?
Gregg Kellogg:  we should defer if we cannot make a decision
Markus Lanthaler:  but if we use @set at the top level, it does
    behave like @graph?
Gregg Kellogg:  yes. for consistency's sake with @list.

PROPOSAL: Do not remove @graph from the JSON-LD syntax.

Gregg Kellogg: +1
Niklas Lindström:  +0.75
Manu Sporny: +1
David I. Lehn: +0
Markus Lanthaler: 0

RESOLUTION: Do not remove @graph from the JSON-LD syntax.

Topic: ISSUE-84: Probing of unlinked objects

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/84
Manu Sporny:  raised by niklas. the idea is to explore if we can
    make the processor search for data in the values of terms which
    themselves have no meaning (null-terms)
    … a way of doing deep processing on values
Manu Sporny:  main question: are we putting this in to support
    @rev?
    ... or something more general?
Niklas Lindström:  It's true that I propose this as a way of
    using the structure I've been using @rev for and keeping all of
    the data. [scribe assist by Manu Sporny]
Manu Sporny: It's the former for me - not specifically support
    for @rev - just a way to preserve all of the data in the shape
    that I would end up with if I use my own mechanics for @rev.
Niklas Lindström:  There might be other use cases, but those are
    straw-men from my view. You might have a long path down to a set
    of triples. You might want easy access to this from another part
    of the structure. [scribe assist by Manu Sporny]
Gregg Kellogg:  we need to consider things to support reusing
    other kinds of structures, and this is a good way of doing this
    … we need to clarify how to handle unknown terms in general
    … in this case, it is explicitly saying that the term
    represents nothing
Manu Sporny:  if @rev is what's sought after, we should consider
    it directly, and not have a pseudo-feature with this as the
    ulterior motive
    … I agree that gregg's point about other structures is
    important, but we don't know how those shapes would look nor if
    this would actually support it
    … I have mainly come across using JSON-LD in a new fresh
    approach, not to retrofit legacy JSON with JSON-LD contexts
Niklas Lindström:  I do support @rev in my processor, currently
    it is another kind of structure - it tacks on @rev as a keyword -
    it has an object where the keys are direct terms. I have "@rev":
    [REFERENCES] [scribe assist by Manu Sporny]
Niklas Lindström:  When we discussed deep probing of data, there
    seemed to be interest in that - that's why I proposed it. [scribe
    assist by Manu Sporny]
Niklas Lindström:  I would prefer support for @rev if there is
    interest in that. [scribe assist by Manu Sporny]
Niklas Lindström:  Things might have changed. [scribe assist by
    Manu Sporny]
Niklas Lindström:  Maybe we want to discuss @rev, specifically.
    [scribe assist by Manu Sporny]
Manu Sporny:  I don't think that the need for @rev is stronger
    know. I do believe it might be useful, but people haven't stepped
    forward in favor of it yet.
Manu Sporny:  most JSON structures has this reverse structure
Niklas Lindström:  In support for @rev - given a subject-oriented
    service that has one document for each resource, this is a very
    nice shape for the data. The alternatives are ugly, as Markus
    outlined. [scribe assist by Manu Sporny]
Niklas Lindström:  These ORM systems often have reverse mechanics
    in place - if you expose something, relevant references to that
    become important. Things linking to that object (publisher,
    creator, etc.) are important. [scribe assist by Manu Sporny]
Markus Lanthaler:  You can always mint a new property for that,
    can't you? [scribe assist by Manu Sporny]
Niklas Lindström:  No, you can't always do that - you don't want
    to litter your core data - there are not always reverse relations
    defined in the vocabulary. If you use the graph API, you have no
    problem traversing the properties in any direction. [scribe
    assist by Manu Sporny]
Niklas Lindström:  This is exactly the scenario I have in the
    legal information system. [scribe assist by Manu Sporny]
Gregg Kellogg:  Have you thought about introducing a rule regime
    on top of this, take a property and associate it with a rule that
    creates an inverse of? [scribe assist by Manu Sporny]
Niklas Lindström:  There are many complex things that could be
    added, but I want to keep this simple. There is no need for
    inverse reification if my developers understood RDF. [scribe
    assist by Manu Sporny]
Gregg Kellogg:  You could solve this problem by re-framing,
    right? [scribe assist by Manu Sporny]
Niklas Lindström:  Not really, no. [scribe assist by Manu Sporny]
Niklas Lindström:  I create extremely denormalized records which
    are put into Elastic Search - filtering is easier when you have
    these reverse relationship. [scribe assist by Manu Sporny]
Manu Sporny:  we need a solid @rev proposal; niklas can you do
    that?
    … we could reserve the keyword @rev
Niklas Lindström:  yes, I can write that proposal
Gregg Kellogg:  the EARL reports might have some use for it, but
    I don't know if I can use this directly

PROPOSAL:  Do not support controlled probing of unlinked objects
    for this version of JSON-LD.

Manu Sporny: +1
Niklas Lindström: +0
Gregg Kellogg: +1
Markus Lanthaler: +0.5
David I. Lehn: +0

RESOLUTION: Do not support controlled probing of unlinked objects
    for this version of JSON-LD.

Topic: ISSUE-74: IRI conflicts when compacting/expanding

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/74
Manu Sporny:  if two terms apply, they are combined
Gregg Kellogg:  you can merge when you're expanding, when you're
    compacting, you might split, partitioning on datatype
    … i.e. on terms which most specifically apply (given coercion)
    the given value
Gregg Kellogg:  i have, in expanded form:
    {"http://example.com/foo": [1, "a", {@id: "/bar"}] }
    … and terms defined for foo: {@context": {"foo_int": {@id
    "foo", @type: xsd:integer"}, … }
    ... the values would be split among them: {foo_int: 1, foo:
    "a", foo_ref: "/bar"}
Manu Sporny:  I'm concerned if there is another issue here: where
    we have to figure out which term applies, and we have to resort
    to lexicographical comparison
Markus Lanthaler:  for all the values or once per value
Gregg Kellogg:  you can calculate how close you're at (if there
    is one integer, one float and value is date time)
Gregg Kellogg:  when I am combining values on expansion, the
    orders of arrays doesn't matter, but tests care for that...
Niklas Lindström:  When you're compacting and you have a term for
    integer and float and dateTime - could we pick either one of
    them? Wouldn't we just not pick any of them - use the
    non-compacted form? [scribe assist by Manu Sporny]
Gregg Kellogg:  You can compact it - but the compacted form would
    have to use a @value. In general, I think we should want to use
    terms for properties rather than IRIs. If you had the information
    to mint a CURIE, you could do that. [scribe assist by Manu
    Sporny]
Gregg Kellogg:  we probably need some informative order for
    combining/splitting values in compaction
Manu Sporny:  Dave Longley has an algorithm for this, we should
    look at that

-- 
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, 3 April 2012 15:33:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:36 GMT