JSON-LD Telecon Minutes for 2012-01-17

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

http://json-ld.org/minutes/2012-01-17/

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

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

JSON-LD Community Group Telecon Minutes for 2012-01-17
Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Jan/0016.html
Chair:
    Manu Sporny
Scribe:
    Markus Lanthaler
Present:
    Markus Lanthaler, Manu Sporny, Niklas Lindström, David I. Lehn
Audio:
    http://json-ld.org/minutes/2012-01-17/audio.ogg

Markus Lanthaler is scribing.

Topic: Plan to finish documents

Manu Sporny:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Jan/0020.html
Manu Sporny:  what we try to achieve is to finish all docs by May
    and start a WG afterwards
Markus Lanthaler:  Other concern was that most people just read
    syntax spec w/o looking at API spec... there is not enough
    information in syntax spec to understand how this stuff works w/o
    reading the API spec. [scribe assist by Manu Sporny]
Markus Lanthaler:  We should modularize more - make syntax
    independent of API spec. [scribe assist by Manu Sporny]
Manu Sporny:  I agree with you in principle
Manu Sporny:  what do we need to bring over to the syntax spec?
Markus Lanthaler:  There are details that are just described in
    API spec, must move those details over. [scribe assist by Manu
    Sporny]
Manu Sporny:  So, stuff like the expansion and compaction
    algorithms...
Manu Sporny:  I don't know if not having algorithms in syntax
    spec is enough. [scribe assist by Manu Sporny]
Niklas Lindström:  Let's look at some other specs, like the XML
    spec, to see how they do it
Manu Sporny:  We could also look at the JSON spec and separately
    the JSON.parse() API spec
Niklas Lindström:  the compacted and expanded forms could, as
    Markus said, probably be described in an algorithm-free way
Niklas Lindström:  at least the expanded form is possible to
    describe such as canonical XML
Manu Sporny:  so the approach would be to describe that in an
    algorithm-free way if we can, but specifying the algorithm for
    expanding values in a JSON-LD document given a @context wouldn't
    be terrible either.
PROPOSAL:  Decouple the JSON-LD Syntax specification from the
    JSON-LD API specification.

Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION:  Decouple the JSON-LD Syntax specification from the
    JSON-LD API specification.

Markus Lanthaler:  Manu, what are you thoughts on which W3C group
    should take that to REC?
Manu Sporny:  The RDF working group still has the JSON
    serialization work on their charter, but we might end up creating
    a completely new JSON-LD WG... we don't know yet, we need to have
    that discussion with W3C.

Topic: ISSUE-43: Use of IRIs and CURIEs as @context keys

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/43
Markus Lanthaler:  We have a technical issue that is of concern
    where an @id specified in a CURIE contained in the context, like
    "foaf:name": {"@id": "http://myotherfoaf.com/name" would override
    the IRI for FOAF. [scribe assist by Manu Sporny]
Manu Sporny:  We could make it so that overriding is okay...
    [scribe assist by Manu Sporny]
Markus Lanthaler:  We could make it such that a direct comparison
    is done first... so check for "foaf:name" in @context first...
    and if that exists, use the @id from that value. If no such value
    exists, look for "foaf" and perform normal CURIE expansion.
    [scribe assist by Manu Sporny]
PROPOSAL:  When expanding JSON-LD keys outside of the @context,
    perform a direct comparison on the @context keys first, then run
    the CURIE expansion algorithm using the @context keys.

Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION:  When expanding JSON-LD keys outside of the @context,
    perform a direct comparison on the @context keys first, then run
    the CURIE expansion algorithm using the @context keys.

Manu Sporny:  What happens when an @id does not exist in the
    CURIE in the @context? We could just fall back to regular CURIE
    expansion.
Niklas Lindström: Why should we allow this? "foaf:name": {"@id":
    "not-foaf-name"}
Markus Lanthaler:  I see it more as *not disallow* it than *allow
    it*
Niklas Lindström:  ok.. we should add a note to not encourage
    this
Manu Sporny:  Yes, this is a corner case and you should only use
    this type of feature if it's absolutely necessary.
Niklas Lindström:  It would make the JSON-LD document very
    difficult to read.
PROPOSAL:  If a CURIE as a key in the @context is not bound to an
    @id, the @id is determined by expanding the key as a CURIE.

Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0
David I. Lehn:  Don't we need a set of test cases before
    resolving something like this?
David I. Lehn:  No, typically we design first and then create a
    test suite once we're sure that the design is sound. A good test
    suite will catch any technical issues, but I don't think we have
    any with this approach. Typically, people catch issues like this
    before a test suite would.
RESOLUTION:  If a CURIE as a key in the @context is not bound to
    an @id, the @id is determined by expanding the key as a CURIE.

Markus Lanthaler:  How does @type coercion work? [scribe assist
    by Manu Sporny]
Markus Lanthaler:  In the context you have "foaf" and "foaf:name"
    (both specify a @type), and in the document you use the full IRI
    "http://xmlns.com/foaf/0.1/name" - which @type do you use?
    [scribe assist by Manu Sporny]
Manu Sporny:  If you want type coercion to work w/ a full IRI in
    the data, you must use the full IRI in the @context to specify
    the @type [scribe assist by Manu Sporny]
Niklas Lindström:  Gregg and Ivan needed that for RDF->JSON-LD
    conversion
PROPOSAL:  The type coercion algorithm only checks for equality
    in the @context keys when attempting to find a type coercion
    rule.

Markus Lanthaler: +1
Manu Sporny: +1
Niklas Lindström: +1
David I. Lehn: +0
RESOLUTION:  The type coercion algorithm only checks for equality
    in the context when attempting to find a type coercion rule.


Topic: ISSUE-44: Allow frames to say: "predicate p always points to a set"

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/44
Manu Sporny:  the problem with this proposal is that there is a
    conflict with what framing does
Niklas Lindström: More discussion on this:
    http://lists.w3.org/Archives/Public/public-linked-json/2011Dec/0005.html
Manu Sporny:  what we might want to do is to introduce a new
    keyword such as @structure or @container (as Niklas proposed)
Niklas Lindström:  My use case is regardless of framing
Niklas Lindström:  In my particular application I don't need
    framing
Niklas Lindström:  I always know the root
Niklas Lindström:  That's why I also proposed @rev, but that's
    another discussion
Niklas Lindström:  I need something specifying that something is
    always an array even if there's just one value
Manu Sporny:  why do you need a keyword for that? You could just
    generate it and tell the people that use your data that the value
    will always be an array?
Niklas Lindström:  I use the context to "specify" this, the
    @context is a contract of what the data should look like
Manu Sporny:  you propose to add a @container that could have to
    values: @set and @list
Manu Sporny:  What we're proposing here are basically document
    conformance rules. If you use @set or @list, the data MUST always
    be enclosed in a JSON array structure.
Manu Sporny:  the issue I have is that it is a very strange
    document conformance rule, one that if people don't follow, there
    isn't really any issue... we could throw an exception if
    something is marked as a @set or @list, but isn't in a JSON
    array.
Manu Sporny:  If we don't, people could just ignore the rule -
    the only way to catch that would be to have a JSON-LD document
    validator or have the processor blow up when it hits something
    that is supposed to be in a JSON array that isn't.
Niklas Lindström:  I see what you mean
Niklas Lindström:  if we are going to create a validator we might
    also wanna have container: object for single values
PROPOSAL:  Add the @container keyword to JSON-LD and allow it's
    value to be '@list' to specify that values MUST be interpreted as
    a RDF List.

Niklas Lindström: +1
Manu Sporny: +1
Markus Lanthaler:  Would that imply that every property has to be
    an array even if there's just a simple value
Niklas Lindström:  Yes, but that's what @list does as well at the
    moment, right?
Markus Lanthaler:  no.. @list just says that if it is an array,
    the order has to be preserved
Niklas Lindström: only every property with @container defined in
    the context (or currently @list)
Markus Lanthaler:  That's what I meant :-)
Niklas Lindström: Good. :) I figured it was, just wanted to make
    sure.
Manu Sporny:  Ok, well - let's kick this discussion back to the
    mailing list. I prefer that we use '@container': '@list' instead
    of '@list': 'true' because that allows us to add '@set' in the
    future in a clean way. Good call, we'll chat next week.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/

Received on Tuesday, 17 January 2012 16:58:35 UTC