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

JSON-LD Telecon Minutes for 2012-04-10

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 10 Apr 2012 12:23:25 -0400
Message-ID: <4F845E7D.7050104@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
The minutes from today's call are now available here:

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

Full text of the discussion follows, the audio transcript will be
uploaded later today:

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

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

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Apr/0031.html
Topics:
    1. ISSUE-91: Re-definition of keywords
    2. ISSUE-92: Limit JSON-LD properties to one @list per
       property
    3. ISSUE-93: Keyword aliasing operation
    4. ISSUE-99: @graph treatment when expanding
    5. ISSUE-58: Specifying the active context for compaction
    6. ISSUE-57: Should @context be minimized when compacting?
    7. ISSUE-53: Remove normalization completely from JSON-LD API
       spec
Resolutions:
    1. When performing expansion properties that are coerced to a
       @container type of @list MUST be placed in an array in expanded
       form. For example, "prop-iri": [{"@list": [1, 2]}] is correct,
       "prop-iri": {"@list": [1, 2]} is not.
    2. JSON-LD supports multiple aliases for a JSON-LD keyword.
    3. Re-affirm that the aliasing of @context is disallowed due
       to algorithmic complexity/ambiguity and lack of a compelling use
       case.
    4. A @context is processed without regard to keyword aliases.
       Keyword aliases are taken into account when processing the body
       of a JSON-LD document.
    5. If @graph is the only property in the document's top level
       object, it MUST be dropped in expansion and compaction. In all
       other cases (which includes @graph at the document's top level
       object when there are other properties other than @context at the
       same level), @graph MUST NOT be dropped in expansion and
       compaction.
    6. The first input parameter for all JSON-LD API methods MAY
       be an object, an array of objects, or an IRI (DOMString).
    7. The second input parameter to the .compact() method is the
       context that should be used for compaction. The value can be
       either an object or an IRI.
    8. The second input parameter to the .frame() method is the
       frame that should be used for compaction. The value can be either
       an object or an IRI.
    9. If the optimize flag is not set, the context used for
       compaction MUST be included without modifications in the
       resulting document. This applies to both context objects as well
       as contexts specified by passing an IRI. If the optimize flag is
       set, a processor is free to modify the context in order to
       optimize the resulting document body.
    10. Remove the normalization algorithm and API from the
       JSON-LD API specification. The normalization algorithm will be
       placed into a separate RDF Graph Normalization specification
       which contains an API for retrieving a set of normalized
       statements.
Chair:
    Manu Sporny
Scribe:
    Manu Sporny
Present:
    Manu Sporny, Gregg Kellogg, Markus Lanthaler, Niklas Lindström,
    David I. Lehn

Manu Sporny is scribing.
Manu Sporny:  any updates or changes to the agenda?
Gregg Kellogg:  We need to go back over the resolved issues and
    make sure that we can close remaining open issues. Can we close
    them, or what further action should be taken to close them? Or
    are they obsolete?
Markus Lanthaler:  Regarding the test suite - should we do the
    split of the test suite?
Manu Sporny:  I'd rather keep that in the current website for now
    - keep them all in the same place.
Gregg Kellogg:  We could use git submodules, but that gets
    annoying.
Markus Lanthaler:  It takes a while to download the website.
Manu Sporny:  We could update the php to package up the test
    suite and download it.
Niklas Lindström:  I agree with Gregg - working with it online or
    working with it as a web app has been very beneficial. If I have
    to run tests locally, I want to be able to check in copies of the
    tests to the repo - so I agree with Gregg.
David I. Lehn: btw, if git is too slow, github has a zip you can
    download. may be faster?
David I. Lehn:  It's on the main page - you can download it.
Niklas Lindström:  It would be beneficial if it was just the
    manifest and the tests.

Topic: ISSUE-91: Re-definition of keywords

https://github.com/json-ld/json-ld.org/issues/91
Manu Sporny:  This is about changing how JSON-LD keywords work -
    redefining keywords.
Niklas Lindström:  General problem I have is with rdf:type - as
    it is a regular relation. Not being able to re-define @type is
    fine with me, if you can create a regular keyword and map it
    forrdf:type.
Niklas Lindström:  I do it in the third example in the issue. I
    don't really know if the algorithm supports this.
Niklas Lindström:  If i need to control the way rdf:type is used
    in compact form, can I?
Markus Lanthaler:  Currently in compaction/expansion, nothing
    would prevent you from doing the thing in your 3rd example.
Niklas Lindström:  Would my definition of @type take precedence
    over @type.
Markus Lanthaler:  If you have @type in your document and you
    expand it, it doesn't get expanded to rdf:type in your document -
    they don't collide.
Gregg Kellogg:  @type without a ??? is just another property -
    there is no issue in JSON-LD, the issue comes in when you
    round-trip.
Niklas Lindström:  I can live with that from a matching point of
    view - when I compact, what is going to happen? Can I always
    force rdf:type to always be a set?
Gregg Kellogg:  If you define something like 'a', then it will
    work just like any other definition.
Niklas Lindström:  In my first two examples - they emulate what
    @type does, right?
Gregg Kellogg:  No, @type doesn't expand... whereas 'a' would.
Niklas Lindström:  In the 3rd example, I used 'rdf:type' without
    using '@type'.
Discussion around 3rd example and round-tripping.
Manu Sporny:  It seems like this usage patter is a little
    strange.
Gregg Kellogg:  You can support this with a frame.
Gregg Kellogg:  The other question here is why we treat @type
    differently from other properties?
Niklas Lindström:  That's what I'm asking here.
Gregg Kellogg:  It might be good to specify @type as another
    property - this might create issues for framing, where framing
    requires a particular pattern.
Niklas Lindström:  Someone on-list asked for something to this
    effect.
Niklas Lindström:  We could solve this, but would have to be
    careful about not complicating things.
Niklas Lindström:  If someone defines another term for rdf:type,
    then it should be treated like any other property.
Gregg Kellogg:  That's too much special magic - we either demote
    @type to be just like any property, or you use framing.
Niklas Lindström:  We have special casing for @type already, it's
    just where to put it.
Markus Lanthaler:  If you look at this from a JSON perspective,
    it's the other way around.
Niklas Lindström:  If you look at it from a Linked Data
    perspective, @type represents a link - and you can have that as a
    subject, you can have multiple types, etc.
Niklas Lindström:  Unlike other relations, you can't say that
    you'd always want it as a set container. If we want to change
    @type back to a property, we may want to move things back from
    @type to @datatype
Gregg Kellogg:  @type means two things, based on where it is used
    - if it's @type it might be in a value, it might be in array
    form, in other cases, it might not be in array form. If we went
    back to @datatype, we wouldn't have to complicate the code.
Gregg Kellogg:  If we make @type in objects be like other
    properties, it would reduce complexity.
Manu Sporny:  So the pseudo-proposal is re-introduce @datatype.
Gregg Kellogg:  yes, that would reduce code complexity - but we
    should ask Dave Longley about this first.
Markus Lanthaler:  Why do we have @type at all then?
Manu Sporny:  Syntactic sugar that folks have come to expect...
    easier to write code based off of it.
Markus Lanthaler:  How is re-introducing @datatype different from
    what we have now?
Gregg Kellogg:  You can't override @datatype like you can
    override @type.
Niklas Lindström:  Even in JSON Schema, there is a different
    between datatype given and relation to an object type.
Niklas Lindström:  Even with JSON schema, which has nothing to do
    with RDF, there is a distinction.
Niklas Lindström: .. re. json schema; they have "format":
    http://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.23
Niklas Lindström: .. in json-schema: format is defined as "This
    property defines the type of data, content type, or microformat
    to be expected in the instance property values"
Postponing decision on ISSUE-91 - topics that we need to address:
    1) if we want to reintroduce @datatype, 2) if keywords can be
    redefined, 3) if there is an initial context that specifies
    '@type' as syntactic sugar (@type is just like any other
    property)

Topic: ISSUE-92: Limit JSON-LD properties to one @list per property

https://github.com/json-ld/json-ld.org/issues/92
Manu Sporny:  A property can have at most one @list associated
    with it, that's what we're discussing here - due to complexity
    for supporting more - throw an exception if more than one @list
    is used.
Gregg Kellogg:  I agree with that, there is another issue.
Gregg Kellogg:  If there is a property that has @list coercion in
    it, then something in array form may need to be put into a list -
    we need to be consistent.
Gregg Kellogg:  The main thing is what is the representation of
    @list in expanded form?
Gregg Kellogg:  Can a property have more than one @list in it.
Gregg Kellogg:  What is the expression in expanded form?
Gregg Kellogg:  We have a pattern that is different from
    everything else we expand - if we show it in array form, it
    implies that we can have more than one element - clear that there
    can only be one list. It's an exception for the way values are
    treated in expanded form - additional complexity in processing
    algorithms.
Gregg Kellogg:  You might have multiple properties that might
    expand to the same IRI, when you go to merge the arrays, it
    creates confusion on list order - two different lists or multiple
    values in the same list?
Gregg Kellogg:  This is an issue in expansion.
Markus Lanthaler:  In expansion, it is just 3 separate lists,
    right?
Gregg Kellogg:  There are cases where you may have conflation -
    it may be 3 separate lists, or it may be one list.
Gregg Kellogg:  I don't see a use case that requires more than
    one list in most cases - if you take that as a concern, then the
    representation is a single object - I'd rather see it as an array
    that holds a single object, not just a single object.
Gregg Kellogg:  I don't think we want to go into the discussion
    on supporting multiple lists of lists unless there is a
    compelling use case.
Gregg Kellogg:  Lists containing lists is extremely complicated.
Niklas Lindström: .. http://spinrdf.org/sp.html#sp-Union
Niklas Lindström:  I think I agree from a practical point of view
    - one very strange real-world use case ^^^
Niklas Lindström:  Really don't expect that to be used in
    JSON-LD. We should know that there is at least one case, and we
    should throw an exception in that case.
Markus Lanthaler:  Could we split this into sub-issues - one for
    compaction, one for expansion.
Niklas Lindström: .. {"prop-iri": [{"@list": [1, 2]}]}
Manu Sporny:  I wonder if we should push this decision off.
Gregg Kellogg:  We should be able to discuss how expanded form
    should look.

PROPOSAL:  When performing expansion properties that are coerced
    to a @container type of @list MUST be placed in an array in
    expanded form. For example, "prop-iri"

Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1

RESOLUTION: When performing expansion properties that are coerced
    to a @container type of @list MUST be placed in an array in
    expanded form. For example, "prop-iri": [{"@list": [1, 2]}] is
    correct, "prop-iri": {"@list": [1, 2]} is not.

Gregg Kellogg:  This was creating more corner-cases for us.
Gregg Kellogg:  This will simplify the algorithm.
Markus Lanthaler:  Maybe dlongley could add explicit examples.

Topic: ISSUE-93: Keyword aliasing operation

https://github.com/json-ld/json-ld.org/issues/93
Manu Sporny:  Markus raises four questions - 1) Can multiple
    aliases exist for a keyword? 2) Why is aliasing of @context
    disallowed? 3) Are aliased keywords supported within a context?
    4) How is this processed during contextprocessing/expansion/
    compaction
Manu Sporny:  I think we should allow multiple aliases for a
    keyword, don't know for #2, I think we only support aliases being
    used outside the context, defer to Gregg and Longley on #4
Markus Lanthaler:  I agree with Dave and Gregg after discussion
    with them.

PROPOSAL:  JSON-LD supports multiple aliases for a JSON-LD
    keyword.

Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1

RESOLUTION: JSON-LD supports multiple aliases for a JSON-LD
    keyword.

PROPOSAL:  Re-affirm that the aliasing of @context is disallowed
    due to algorithmic complexity/ambiguity and lack of a compelling
    use case.

Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
Gregg Kellogg: +1

RESOLUTION: Re-affirm that the aliasing of @context is disallowed
    due to algorithmic complexity/ambiguity and lack of a compelling
    use case.

PROPOSAL:  A @context is processed without regard to keyword
    aliases. Keyword aliases are taken into account when processing
    the body of a JSON-LD document.

Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Manu Sporny: +1

RESOLUTION: A @context is processed without regard to keyword
    aliases. Keyword aliases are taken into account when processing
    the body of a JSON-LD document.

The group notes that the processing rules for compaction,
    expansion and framing are not affected by the previous 3
    decisions.

Topic: ISSUE-99: @graph treatment when expanding

https://github.com/json-ld/json-ld.org/issues/99
Gregg Kellogg:  I think that everyone agrees that the only time
    that @graph is dropped is when it is the only property expressed
    in a top-level object other than @context.
The current proposal is: If @graph is the only property in the
    document's top level object, it MUST be dropped in expansion and
    compaction. In all other cases (which includes @graph at the
    document's top level object when there are other properties at
    the same level), @graph MUST NOT be dropped in expansion and
    compaction.
Manu Sporny:  I'm concerned about how the RDF WG will react to
    this - may be controversial.
Manu Sporny:  This will affect normalization.
Gregg Kellogg:  We need to be able to express graphs - Wikidata
    folks need this - we don't want to not solve that application
    because we haven't yet solved the graph issue.
Gregg Kellogg:  this isn't a big complication to any of our
    algorithms
Gregg Kellogg:  The interpretation when it comes to RDF is the
    tricky part - but I don't see it as that tricky

PROPOSAL:  If @graph is the only property in the document's top
    level object, it MUST be dropped in expansion and compaction. In
    all other cases (which includes @graph at the document's top
    level object when there are other properties other than @context
    at the same level), @graph MUST NOT be dropped in expansion and
    compaction.

Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1
Niklas Lindström: +1 with a bit of faith

RESOLUTION: If @graph is the only property in the document's top
    level object, it MUST be dropped in expansion and compaction. In
    all other cases (which includes @graph at the document's top
    level object when there are other properties other than @context
    at the same level), @graph MUST NOT be dropped in expansion and
    compaction.

Manu Sporny:  Those were all the discussions related to syntax,
    now on to API issues.

Topic: ISSUE-58: Specifying the active context for compaction

https://github.com/json-ld/json-ld.org/issues/58
Manu Sporny:  We are starting to have a great number of options
    for these API methods
Gregg Kellogg:  We should probably put these in options.
Markus Lanthaler:  What about mandatory arguments, like the
    context for compaction, or the base IRI?
Gregg Kellogg:  We should discuss allowing passing IRIs or file
    objects to the compaction, expansion, etc. algorithms.
Manu Sporny:  That's new, we'll have to discuss the signatures
    for these methods.
Manu Sporny:  Should we focus the API on higher-level languages
    only?
Gregg Kellogg:  I think so.
Discussion around arguments to API methods - whether there should
    be an 'option' object, or if mandatory options should be separate
    from 'options', such as the compacting context in the call to
    .compact().
Discussion concerning what the arguments can be for the input
    parameters.
Markus Lanthaler: http://dev.w3.org/2006/webapi/WebIDL/#idl-union
Markus Lanthaler: (float or float[])

PROPOSAL:  The first input parameter for all JSON-LD API methods
    MAY be an object, an array of objects, or an IRI (DOMString).

Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +1

RESOLUTION: The first input parameter for all JSON-LD API methods
    MAY be an object, an array of objects, or an IRI (DOMString).

PROPOSAL:  The second input parameter to the .compact() method is
    the context that should be used for compaction. The value can be
    either an object or an IRI.

Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Gregg Kellogg: +1

RESOLUTION: The second input parameter to the .compact() method
    is the context that should be used for compaction. The value can
    be either an object or an IRI.

PROPOSAL:  The second input parameter to the .frame() method is
    the frame that should be used for compaction. The value can be
    either an object or an IRI.

Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1

RESOLUTION: The second input parameter to the .frame() method is
    the frame that should be used for compaction. The value can be
    either an object or an IRI.

Topic: ISSUE-57: Should @context be minimized when compacting?

https://github.com/json-ld/json-ld.org/issues/57

PROPOSAL:  If the optimize flag is not set, the context used for
    compaction MUST be included without modifications in the
    resulting document. This applies to both context objects as well
    as contexts specified by passing an IRI. If the optimize flag is
    set, a processor is free to modify the context in order to
    optimize the resulting document body.

Markus Lanthaler:  I think we all agree on this...
Gregg Kellogg: +1
Markus Lanthaler: +1
Manu Sporny: +1

RESOLUTION: If the optimize flag is not set, the context used for
    compaction MUST be included without modifications in the
    resulting document. This applies to both context objects as well
    as contexts specified by passing an IRI. If the optimize flag is
    set, a processor is free to modify the context in order to
    optimize the resulting document body.

Topic: ISSUE-53: Remove normalization completely from JSON-LD API spec

https://github.com/json-ld/json-ld.org/issues/53
Discussion about how this would be implemented across
    specification documents.
Gregg Kellogg:  We don't need normalization in the JSON-LD API,
    it belongs in a normalization API.
Manu Sporny:  So the 'normalization spec' should describe how to
    normalize RDF graphs and it should outline an API call to get
    back a list of quads that is normalized and sorted.
Manu Sporny:  other issue is which bits to pull from the RDF API
    spec.

PROPOSAL:  Remove the normalization algorithm and API from the
    JSON-LD API specification. The normalization algorithm will be
    placed into a separate RDF Graph Normalization specification
    which contains an API for retrieving a set of normalized
    statements.

Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1

RESOLUTION: Remove the normalization algorithm and API from the
    JSON-LD API specification. The normalization algorithm will be
    placed into a separate RDF Graph Normalization specification
    which contains an API for retrieving a set of normalized
    statements.

-- 
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, 10 April 2012 16:24:10 GMT

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