JSON-LD Telecon Minutes for 2011-10-18

Many thanks to Gregg for scribing! The minutes for today's call are now
available here:

http://json-ld.org/minutes/2011-10-18/

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

JSON-LD Community Group Telecon Minutes for 2011-10-18
Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2011Oct/0067.html
Chair:
    Manu Sporny
Scribe:
    Gregg Kellogg
Present:
    Gregg Kellogg, Manu Sporny, Niklas Lindström, David I. Lehn

Gregg Kellogg is scribing.

Topic: Approval/Disapproval of the Spec Split

Manu Sporny:  I created a proposal for the spec split over the
    weekend - it's on a separate branch in the code repository...
    published it here:
Manu Sporny: http://manu.sporny.org/tmp/json-ld.org/spec/
    … for quite a while people had been asking to split between
    language description and complicated API and processing rules
    … wanted an easy intro for people to learn JSON-LD syntax with
    details in a different spec
    … had asked to wait for things to settle down, which it seems
    to have now.
    … split into three docs:
    … 1 JSON-LD syntax, describes keywords how IRIs and datatypes
    are expressed.
    … 2: API spec, describes 5 method calls to transform JSON-LD
    between different representations
    … 3: Normalization algorithm, it is generalizable and could be
    used for different RDF languages.
    … API spec depends on normalization
    … syntax doc doesn't depend upon, but refers to the other two.
    … The responses on the list and personal e-mail seem to
    indicate a general feeling that it is a good idea.
Gregg Kellogg:  I think it's something we agreed to do some time
    ago, so it's good that it's done. [scribe assist by Manu Sporny]
Niklas Lindström:  Yes, this is good. [scribe assist by Manu
    Sporny]
David I. Lehn:  there are some spec bugs. List stuff missing?
Manu Sporny:  lists shouldn't have been deleted.
    … experimental concepts weren't moved over, they'll need to go
    back.
    … suggestion is that all experimental concepts turn into
    advanced concepts.
Manu Sporny: Looking at http://json-ld.org/spec/latest/ seems to
    indicate that disjoint graphs and lists were accidentally
    deleted.
Manu Sporny:  need disjoint graphs and lists, those were the only
    two.
    … the latest spec requires an update to merge those two back
    in.
    … gkellogg to update the main processing algorithm for lists
    … general agreement to merge the branch into the main spec?
David I. Lehn:  question on how they will all link together.
Manu Sporny:  RDF normalization doc is stand-alone and doesn't
    refer to the other docs.
    … The API spec refers to the Syntax spec and the normalization
    spec.
    … The Syntax spec refers non-normatively to the API spec and
    the normalization spec.
    … All three must be rec-track documents.
    … general agreement, but can't take a vote with only 4 people
    on the call. I'll merge the spec split into the main line and see
    if anybody complains at that point, but most seem to want this
    change.

Topic: ISSUE-31: Merge @type and @datatype

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/31
Manu Sporny:  Markus had raised this on the list.
    … type is used in two different ways, for literals and for
    objects
    … generally, authors don't know (or care) about the
    difference.
    … RDF people will understand the difference.
    … idea to merge @type and @datatype into a single keyword
    … PROs: simplicity and easing the burden on authors.
    … CONs: may confuse people coming from RDF world.
    … all other keywords need to be paired. Thoughts?
    … niklasl: is an RDF-head, but has a problem with this merger
    … @type is a short-hand for a property
David I. Lehn: did Dave Longley have comments on this based on
    all his implementation work?
    … other people might have problems initially. the conceptal
    difference is huge
Manu Sporny:  Dave Longley hasn't had any strong feelings on it
    on the mailing list or privately.
    … from the syntax, it's clear what to do, it's really a
    stylistic thing.
Gregg Kellogg:  In general, I'm in favor of reducing the number
    of keywords that are needed. The danger is that someone uses a
    class type when they mean a datatype or vice-versa. [scribe
    assist by Manu Sporny]
Gregg Kellogg:  There are many other ways to generate data which
    is wrong... I'm neutral to +1 on this issue. [scribe assist by
    Manu Sporny]
Niklas Lindström:  might be problematic, you would never coerce
    something so that it would be typed, but you would coerce a
    datatype
    … also, we have keyword aliases and prefers to use an alias
    anyway. Would never use @datatype directly. There are a number of
    places where the differences are important.
Gregg Kellogg:  is there a problem w/ potentially coercing
    multiple types to the same thing... we're a bit heavy with
    keywords, I see advantage of limiting it... best we can do is put
    thoughts out there and see if we can get further input from the
    list. [scribe assist by Manu Sporny]
Niklas Lindström:  @type as it is used now might not be
    necessary, as you can always do this with aliases.
    … It allows a symbol to be used, and identifies the value as
    an IRI
    … if understand correctly, couldn't really discard the
    concept.
Manu Sporny:  could always get the behavior by aliasing @datatype
    to @type.
    … introduces an ambiguity that we should be careful of.
Gregg Kellogg:  Removing @datatype and aliasing to @type doesn't
    allow the same thing... [scribe assist by Manu Sporny]
Manu Sporny:  would still be able to do this, because of RDF
    processing rules.
    … RDF checks if @literal is used, and then looks for
    @datatype. If it was aliased, it would just look for @type at the
    same literal.
Gregg Kellogg:  My point was that we can't get rid of @type
    completely, because the processing rules need /something/ to
    generate the rdf:type triple. [scribe assist by Manu Sporny]
Gregg Kellogg:  We need a way to define both @types and
    @datatypes... we should keep them as separate concepts. [scribe
    assist by Manu Sporny]
Manu Sporny:  general agreement to not merge the two
David I. Lehn: I think you all covered issues I had

Topic: ISSUE-34: Type Coercion is confusing

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/34
Manu Sporny:  people are confused, as they expect that property
    should map to datatype, not the other way around.
    … right now, it's flipped. This is because we wanted to keep
    the coercion rules relatively short. This had historically been
    an issue, as we didn't have a way to specify an external concept.
    … Now that we have an external context, we should revisit, as
    it is more natural and size isn't as important now as it had been
    in the past.
    … people will typically use external files for their contexts,
    so it's fairly DRY and you can depend on caching.
    … proposal is to switch the order of type coercion to be
    property mapping to datatype
Niklas Lindström:  change doesn't affect me; may be cleaner.
    … if you have a list of strings, both as an RDF list of URIs.
Niklas Lindström: .. {"@coerce": "@list": ["authorList"], "@iri":
    ["authorList"]}
Gregg Kellogg:  This came up in the Microdata conversion work...
    the current algorithm converts to a list... this is a violation
    of range restrictions. The only real way to know that you're
    referencing a list is to refer to the rdfs:range. [scribe assist
    by Manu Sporny]
Gregg Kellogg:  So, there is no way to say what the contents of a
    list should be a particular type. [scribe assist by Manu Sporny]
Niklas Lindström: .. "@coerce": {"authorList": ["@list", "@iri"]}
Niklas Lindström:  We're not sure if the example I wrote up there
    is even legal... how do you specify that a list contains IRIs?
    [scribe assist by Manu Sporny]
Manu Sporny:  can create a list of IRIs with both markup
    mechanisms, so this is parallel to what we're discussing.
    … Might not want to allow, but if we do it's straightforward
    with either approach.
    … I think we should do the swap - property maps to datatype.
    … Another reason is that the data structure you end up
    creating in the JSON-LD processor is exactly this... it will
    simplify implementations.
    … A processor writer has to do this anyway.
    … doing this would be a plus for both authors and
    implementations.
Niklas Lindström: .. "updated": {"@iri":
    "http://purl.org/dc/terms/updated", "@coerce": "xsd:date"}
Niklas Lindström:  I'm probably 2-steps ahead, but if we do this,
    we might be on a path to bring to extend something like updated.
Manu Sporny:  very sophisticated, and may cause confusion.
Gregg Kellogg:  I can see the advantage of that - but I think it
    may make the @context documents less readable... keeping @coerce
    separate will allow people to read the document as two separate
    parts. [scribe assist by Manu Sporny]
Manu Sporny:  people would continue to scan, and if they wanted
    to find xsd:dates, but not a very strong argument.
    … nice to be able to look in different sections to find
    different things, the separation may be good for beginner
    authors.
    … if combined, it is mixed in on the page and more difficult
    to parse out for authors... requires you to run the processing
    rules in your head at some level, which is bad.
    … for the time being, prefer to keep as key/value sections.
Gregg Kellogg:  We want to not fall into the trap of too many
    ways to do the same thing. [scribe assist by Manu Sporny]
Niklas Lindström: .. "dc": "http://purl.org/dc/terms/",
    "updated": {"@vocab": "dc", "@coerce": "xsd:date"}
Niklas Lindström:  if we were to allow, I would recommend
    removing the other way
    … this example also goes even further.
    … this is close to what _gluon_ did. This JSON-LD approach is
    cleaner, though.
    … I think this mechanism is more compact, and can see
    everything about a property in a single place.
Gregg Kellogg:  I can see the benefit here... we probably need to
    float it out on the list... pretty big change. [scribe assist by
    Manu Sporny]
David I. Lehn: I think that could look nice. We might want to run
    some bigger example cases through such a conversion to see how it
    turns out.
Manu Sporny:  I agree that it does make it cleaner and more
    compact from a design standpoint, but it smells like feature
    creep.
    … this might make it more difficult for people to understand
    what's going on, and we certainly didn't intend for JSON-LD to be
    something with complex processing rules.
    … If we do make this change, we're moving further away from
    the "simple" nature of JSON-LD.
    … requires you to have the processing rules in your head to
    understand what's going on.
    … this overcomplicates the language under the guise of "good
    design"
    … if we continue to add features, we make it cognitively far
    more difficult for people to wrap their heads around.
    … I see the design benefit, if the goal was to create a very
    rich complex language, but don't feel that's the goal of JSON-LD.
Niklas Lindström:  I understand your arguments, and was always
    trying to be as complete as Turtle.
    … I think the compactness and directness motivates the
    complexity.
    … As it stand, we have @vocab and @coerce, don't know how much
    more complex this makes it, if we didn't have @coerce in the
    top-level context.
Manu Sporny:  if we don't have @coerce in top level, this really
    isn't more complex.
Manu Sporny:  Niklas, can you type something up and send it to
    the mailing list?
Manu Sporny:  feel we're okay having the property maps to
    datatype change.
David I. Lehn: also might want to check how the @list proposal
    fits into these changes
Gregg Kellogg:  We do need @list, but maybe we can use @list as a
    datatype... if we wanted to specify multiple things, we could use
    an array-type form. [scribe assist by Manu Sporny]
Niklas Lindström: .. "@coerce": {"authorList": ["@list", "@iri"]}
Niklas Lindström: .. "@coerce": "@list": ["authorList"], "@iri":
    ["authorList"] (right now)
Manu Sporny:  assumes people want to coerce the items in a list
    … this is pretty advanced, and don't know of a use-case.
memberList: ["http://foo.com/", "http://bar.com/"]
Manu Sporny: "memberList": ["@list", "@iri"]
memberList: [@list, xsd:anyURI]
David I. Lehn: for conflicts, just leave behavior undefined
Niklas Lindström:  We like the the ability to do property/value,
    may as well go with new form.
Manu Sporny:  We can't leave behavior undefined, as it leads to
    confusion.
    … end up not interoperating because of conflicts. This is why
    HTML5 goes into excruciating detail on what to do when a tag
    isn't closed. HTML4 didn't specify it and neither did XHTML, and
    so the browser vendors ended up implementing incompatible rules
    to interpret what was going on.
    … need to specify conflict behavior in spec. API indicates
    this is an error condition.
Manu Sporny:  general idea is to adopt the proposal.
    … property/datatype
David I. Lehn: i think we also want to look a bit closer at
    Niklas' proposal too
Niklas Lindström: I'll write down my proposal to the list along
    with some example contexts.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
Standardizing Payment Links
http://manu.sporny.org/2011/payment-links/

Received on Tuesday, 18 October 2011 22:13:11 UTC