JSON-LD Telecon Minutes for 2012-05-22

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

http://json-ld.org/minutes/2012-05-22/

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

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

JSON-LD Community Group Telecon Minutes for 2012-05-22

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012May/0008.html
Topics:
    1. JSON-LD pushed to RDF WG for review
    2. ISSUE-114: JSON-LD Grammar
    3. ISSUE-118: @graph support in framing
    4. ISSUE-119: Aggressive embedding support
Resolutions:
    1. Defer @graph and, in general, value matching from the
       framing algorithm.
Chair:
    Manu Sporny
Scribe:
    Niklas Lindström
Present:
    Manu Sporny, Niklas Lindström, Gregg Kellogg, Markus Lanthaler,
    David I. Lehn
Audio:
     http://json-ld.org/minutes/2012-05-22/audio.ogg

Manu Sporny:  Any changes to the agenda? [scribe assist by Manu
    Sporny]
Niklas Lindström:  I have one thing I'd like to discuss - the
    multiple embeds issue... alternative to the RDF API... wondering
    if it could apply to what I'm working on. [scribe assist by Manu
    Sporny]
Gregg Kellogg:  It might be worth talking a bit more about the
    JSON-LD grammar. [scribe assist by Manu Sporny]

Topic: JSON-LD pushed to RDF WG for review

Manu Sporny:
    http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0480.html
Manu Sporny: I sent that e-mail out to the RDF WG to request that
    JSON-LD be picked up in that group and be taken to REC. We should
    all keep a close eye on the mailing list and respond to any
    questions as they come in. I've asked Guus and David (RDF WG
    chairs) what the next steps are.
Niklas Lindström is scribing.

Topic: ISSUE-114: JSON-LD Grammar

Manu Sporny: The grammar that Markus put together was reworked
    slightly and put into the spec here:
    http://json-ld.org/spec/ED/json-ld-syntax/20120522/#json-ld-grammar
Gregg Kellogg: issue is here:
    https://github.com/json-ld/json-ld.org/issues/114
Manu Sporny:  took markus' revision, rewrote a bit to the
    language of the spec
    … if we express the grammar in ebnf, people may have hard to
    follow what's going on
    … gregg mentioned that there may be some controversial stuff
    in the grammae
Markus Lanthaler:  some minor errors
    … i'll go through it in the next couple of days
Gregg Kellogg:  21 and 22 might need some more discussions
    (perhaps some more)
Markus Lanthaler:  @type under discussion: if we really allow an
    object
    … and are we going to allow relative iri:s?
    … (e.g. in compact form)
Gregg Kellogg:  my processor handles relative in subjects and
    object, but not in predicates and datatypes
Gregg Kellogg:  and @type handled like datatype: i.e. must be
    absolute
Manu Sporny:  but what if there is a relative iri in there?
Gregg Kellogg:  treated like a term - if not resolved or it's not
    an absolute iri, ignore it
    … just like datatype: integer (not xsd:integer) would be
    ignored
Manu Sporny:  should we have the exact same mechanism everywhere?
    …: but there's a tradeoff, we don't want to generate faulty
    data
    … but the authors need to understand where relative are
    allowed and where not
Gregg Kellogg:  but we already do that with properties
    … so why don't we treat a relative term like a relative iri?
    … we want to be consistent
Niklas Lindström:  I agree with gregg, these are orthogonal value
    spaces (predicates and types have different roles than
    subjects/objects); and it's the way all other rdf serializations
    work
Markus Lanthaler: "@type": "relativeornot"
Gregg Kellogg:  not relative
Gregg Kellogg: "@id": "relativeornot"
Gregg Kellogg:  relative
Manu Sporny:  the latter is relative
Gregg Kellogg:  that's how it works in RDFa
Niklas Lindström:  I agree, I don't think it's a problem in
    practice
Manu Sporny:  but the group that's going to use this don't have
    an RDF background
Gregg Kellogg:  I think it will be clear
Manu Sporny:  we could have a relative ref in @type; it's frowned
    upon but allowed
Gregg Kellogg:  but this would confuse things a lot if we e.g.
    reintroduced @vocab
Markus Lanthaler: "@type": "/types/Person"
Gregg Kellogg:  the current spec would drop that
Manu Sporny:  we should make a distinction between best practice
    and allowed grammar
Gregg Kellogg:  we can't give simple grammar rules for
    determining if somethings abs/relative; that's on another level
    [of semantics]
Manu Sporny:  that's also why I'm concerned about using EBNF
Gregg Kellogg:  then we shouldn't call it a "grammar"
Manu Sporny:  markus want sometning explicit about whats
    syntactically allowed
    … we need to figure out how a processor will report back
    what's allowed and not
Manu Sporny:  normally, if a grammar is violated, the parser
    quits; but this is not the case, the json-ld spec explains how to
    continue (and possibly recover)
Gregg Kellogg:  not entirely true in all cases.
Gregg Kellogg:  we can have a formal grammar plus higher-level
    consistency rules
Niklas Lindström:  I think that the JSON-LD spec can be defined
    using plain language as well - we don't have to formally define a
    grammar, we can just say that something is ignored. [scribe
    assist by Manu Sporny]
Manu Sporny:  markus' list is simple enough and seems to cover
    what we need
Niklas Lindström:  I think that we can approach this in the same
    way as the Atom spec - they have SHOULDs and MUSTs, but
    everything else is ignored. [scribe assist by Manu Sporny]
Niklas Lindström:  You can throw in forbidden attributes
    anywhere, but they're ignored. They have an informative RelaxNG
    specification, parsers are not supposed to use it - it's just
    there for teaching purposes. [scribe assist by Manu Sporny]
Manu Sporny:  we could e.g. turn true into "true"
Gregg Kellogg:  but we should not allow bad data
Manu Sporny:  true. that also seems to support not supporting
    relative iri:s in properties and @type
Manu Sporny:  the grammar rules should perhaps be called
    authoring rules
Gregg Kellogg:  json-ld processors should be able to process any
    json
[pushing back this to the list]
Manu Sporny:  deferring issue 110 (too long to discuss today)

Topic: ISSUE-118: @graph support in framing

https://github.com/json-ld/json-ld.org/issues/118
Gregg Kellogg:  we're sort of in the area of inventions; we need
    implementations to see the needs
Manu Sporny:  yes, we need to allow implementations to evaluate
    the changes
    … the other concern is that if we treat everything as flat, I
    don't want to paint ourselves into a corner
    … to not prevent ourselves from future use cases
Manu Sporny:  proposal right now is to put this in the back
    burner until we know what should be done (e.g. 3 different
    implementors tackling he situation)
Gregg Kellogg:  what is really required for specific
    applications, and handle that in a separate framing spec...
Manu Sporny:  if we make framing as complex as sparql is, it'll
    be hard to grasp. It should be a very basic query language.
    … for right now, focus on really simple rest services; if
    people want to do complicated framing, they can implement it on
    top of the api
Markus Lanthaler:  so you're arguing against e.g. value matching?
Manu Sporny:  yes, for now..
Niklas Lindström:  I wonder if these advanced scenarios go beyond
    what JSON-LD is for... aren't we just re-implementing the entire
    RDF stack if we support some of these more advanced use cases?
    [scribe assist by Manu Sporny]
Markus Lanthaler:  but why did we introduce named graphs?
Manu Sporny:  the reason for named graphs is more for [packaging
    the data] for e.g. signing
    … we only need one named graph at a time in the document
Markus Lanthaler:  but it's not the @graph, it's the value
    matching in framing that's more complex
Manu Sporny:  yes, but we're adding nice-to-haves we haven't seen
    fully formed needs yet, and it'll add more rules for people to
    comprehend

PROPOSAL:  defer @graph and, in general, value matching from the
    frame algorithm.

Niklas Lindström: +1
Manu Sporny: +1
Gregg Kellogg: +1
David I. Lehn: +1
Markus Lanthaler: +0 (want to work on a solution for this)

RESOLUTION: Defer @graph and, in general, value matching from the
    framing algorithm.

Topic: ISSUE-119: Aggressive embedding support

https://github.com/json-ld/json-ld.org/issues/119
Manu Sporny:  how developers need to use data (looping over
    cycles etc.)
Manu Sporny:  currently, you need to implement a "findSubjects"
    … josh suggests "aggressive embedding"
    … insert the same subject [and data of it] everywhere it's
    referenced, just cycles
Niklas Lindström:  I've had this embed situation in 3 different
    contexts. 1) I've used a tree representation of an OWL ontology
    and tried to generate documentation from that, where labels need
    to be associated with classes - either the tree is going to be
    gigantic, or I have to back away from using a tree representation
    entirely and use a proper graph representation. [scribe assist by
    Manu Sporny]
Niklas Lindström:  This is the general case for using Linked Data
    programmatically - unless I'm trying to render the tree in a flat
    way. Anytime I need a label for a link, or the context for a link
    - publisher, responsible person at publisher, etc. Any real-world
    situation of using this data, I need a graph in memory. Where
    I've found aggressive embedding useful, is when I've used a
    JSON-LD context... [scribe assist by Manu Sporny]
Manu Sporny: ...applied on a big chunk of data and related things
    and put that into Elastic Search.
Niklas Lindström:  I can do very advanced filters, etc. - sort on
    date values for things referencing the current object - things
    like that. Those things invalidate the current document - need to
    filter on those dates. Need to see if they are active at the
    current time. So, I've seen both of these proposed solutions to
    the problem. [scribe assist by Manu Sporny]
Niklas Lindström:  I think that we should actively explore both
    of them. [scribe assist by Manu Sporny]
Niklas Lindström:  One is using JSON is indexing scenarios - very
    narrow usecase - but useful (MongoDB, Solr, Elastic Search).
    [scribe assist by Manu Sporny]
Niklas Lindström:  Programmatically using Linked Data, you use
    in-memory graph of what you've gathered in order to walk it
    properly. Dereferencing the links must be easy in that case.
    [scribe assist by Manu Sporny]
Niklas Lindström:  If I have a compact JSON-LD representation of
    a lot of vocabularies, I need labels for them all, it's
    straight-forward if I have a flat JSON-LD structure. [scribe
    assist by Manu Sporny]
Niklas Lindström:  Properties are compacted, I have simple keys
    and I have @language to reduce to simple graph list - if I walk
    every property and put the object in place where there is a
    reference, that's a very simple loop and makes the data
    infinitely more useable in a template or programmatic usage.
    [scribe assist by Manu Sporny]
Markus Lanthaler: Josh Mandel has built an objectify() API call
    to create an in-memory graph:
    https://github.com/json-ld/json-ld.org/issues/109#issuecomment-5758808
David I. Lehn: https://github.com/digitalbazaar/jsonld.js/pull/15
David I. Lehn: in case you all didn't see JoshM's in memory graph
    experiment

-- 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, 22 May 2012 16:09:38 UTC