JSON-LD Telecon Minutes for 2011-11-29

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

http://json-ld.org/minutes/2011-11-29/

Full text of the discussion follows:

JSON-LD Community Group Telecon Minutes for 2011-11-29
Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0042.html
Chair:
    Manu Sporny
Scribe:
    Manu Sporny
Present:
    Manu Sporny, Gregg Kellogg, Niklas Lindström, Markus Lanthaler

Manu Sporny is scribing.
Manu Sporny:  Any changes or updates to the Agenda?
Gregg Kellogg:  Might be worth talking about Mark Nottingham's
    post.

Topic: Mark Nottingham's post

Markus Lanthaler:
    http://www.mnot.net/blog/2011/11/25/linking_in_json
Manu Sporny:  Mark is looking for a good linked data format - his
    analysis of JSON-LD is a bit off.
Gregg Kellogg:  yeah, he's a bit off - everything he wants to do
    in _meta can be done with JSON-LD context. We definitely don't
    need another way of expressing exactly what JSON-LD already does.
    He did also get wrapped up in the concept that JSON-LD is about
    RDF.
Manu Sporny:  maybe we need to do a blog post to explain why what
    he's proposing is basically JSON-LD?
Gregg Kellogg:  Bring TimBL into the discussion?
Niklas Lindström:  I get the sense that we're going to see
    something akin to Microdata all over again - if people dismiss
    JSON-LD outright without really looking at it.
Niklas Lindström:  I've seen your reply as well - Mark hasn't
    responded to it, right?
Manu Sporny:  Yeah, no response yet.
Gregg Kellogg:  I think that we may want to bring TimBL into the
    discussion - because this seems like another Microdata/RDFa
    thing... and nobody wants that.
Niklas Lindström: +1 re. timbl
Manu Sporny:  Ok, I'll send an e-mail to TimBL about it... to
    make sure that he knows about the overlap.
Gregg Kellogg:  Maybe the best thing would be to work through all
    of the issues and to get this into a WG at W3C.
Manu Sporny:  Yes, I agree.

Topic: Change of telco time

Manu Sporny:  Does one hour earlier work for everyone?
Gregg Kellogg:  What about Tom Steiner? Can he make it?
Manu Sporny:  Let's change the time to 1 hour earlier. It seemed
    to work for the meeting today. Let's ask on the mailing list to
    see if it's okay for everyone?
Markus Lanthaler:  Do we want to do this every week or every
    other week.
Gregg Kellogg:  I think we should go to every week... until we
    eat through all of the issues.
Manu Sporny:  Yes, perhaps that would be best.
Markus Lanthaler:  It's difficult to meet - a call every week
    would be okay. Generally, I'd like to do more on the mailing
    list.
Manu Sporny:  I have a hard time doing more on the mailing list.
Niklas Lindström:  I think the telco's are very complimentary -
    we need these discussions.
Gregg Kellogg:  We need these telcos to decide things - important
    to get stability in the spec.
PROPOSAL:  Teleconferences every week until we get through the
    issue list.

Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0
RESOLUTION:  Teleconferences every week until we get through the
    issue list.


Topic: ISSUE-40: Merge @coerce with @context

Gregg Kellogg: Here are the various proposals:
    https://github.com/json-ld/json-ld.org/issues/40#issuecomment-2930565
Markus Lanthaler:
    http://lists.w3.org/Archives/Public/public-linked-json/2011Nov/0053.html
Manu Sporny:  I'd prefer #3 -
    https://github.com/json-ld/json-ld.org/issues/40#issuecomment-2930565
Niklas Lindström:  I'd be fine with #3 as well... if we use
    @datatype instead of @coerce... we may want to consider something
    like this:
Niklas Lindström: "foo": {"@iri": "http://uri.foo", "@datatype":
    "@iri"} or
Niklas Lindström: "foo": {"@iri": "http://uri.foo", "@iri": true}
    or
Niklas Lindström: "foo": {"@iri": "http://uri.foo", "@coerce":
    "@iri", "@list": true}
Gregg Kellogg:  I'm sympathetic to the point that @datatype looks
    a little odd. The more keywords we have, the more complicated
    it's going to be for people... we're twisting @datatype a little
    bit, but we should focus on keeping things simple.
Markus Lanthaler: "foo": {"@iri": "http://uri.foo", "@iri": true}
    that won't work! You use the same key twice
Gregg Kellogg:  There is a different issue on @datatype and
    @type... I could go with either #2 or #3.
Niklas Lindström: markus, right
Markus Lanthaler: There is an alternate approach -
Markus Lanthaler: 6) "foo": {"@iri": "http://uri.foo",
    "@datatype": [ "@list", "xsd:date" ] }
Markus Lanthaler: 6) "foo": {"@iri": "http://uri.foo",
    "@datatype": [ "@list", "@iri" ] }
Manu Sporny:  I don't like #6 - multiple arrays and nesting is
    starting to make the context look really complicated. Worried
    that authors are going to have a hard time with it. Any strong
    arguments between #2 and #3?
Niklas Lindström:  #6 is just like #1, right? Just with another
    example for @iri?
Gregg Kellogg:  Being able to specify multiple datatypes allows
    you to pattern match across multiple datatypes... I don't think
    multiple types are good for JSON-LD... wary of introducing an
    array in this case.
Niklas Lindström:  I agree, let's not use arrays.
Manu Sporny:  I'm against #6 because of the cognitive load it
    adds to authors.
PROPOSAL:  Adopt #3 (from
    https;//github.com/json-ld/json-ld.org/issues/40#issuecomment-2930565
    ) as the mechanism to express coercion rules in JSON-LD.

Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: + 0.5
Markus Lanthaler: +1
David I. Lehn: +0
RESOLUTION:  Adopt #3 (from
    https;//github.com/json-ld/json-ld.org/issues/40#issuecomment-2930565
    ) as the mechanism to express coercion rules in JSON-LD.


Topic: Compact Serialization from RDFa to JSON-LD

Gregg Kellogg:  There are some related issue that would be good
    to get out of the way... how do we specify that a particular
    CURIE should have a certain datatype?
Gregg Kellogg: "dc:date": { "@datatype": "xsd:date"}
Gregg Kellogg:  When coming from RDF, this is important in order
    to generate something readable in JSON-LD.
Niklas Lindström:  If you want some of the URIs to be coerced,
    you have to use @iri as a key in the context... if you use URIs,
    you impose much more on the consumer of the data anyhow... using
    coercion to alleviate any of the pain doesn't warrant this,
    really.
Niklas Lindström:  You should be able to handle explicit literals
    in the data as well.
Gregg Kellogg:  This is really an issue when serializing - we
    don't want to sacrifice the compactness in being able to use the
    datatypes in @context... if we don't have a way to do this, we'd
    have to create arbitrary prefixes that are not used in order to
    get the datatype specification.
Manu Sporny:  I'm not following.
Gregg Kellogg:  If we take an RDFa document and express it in
    JSON-LD... we have no way to define terms in RDFa - the only way
    to accomplish that is to manufacture terms... or make a literal
    with the datatypes expressed.
Gregg Kellogg:  If we look at JSON-LD vs. Microdata JSON - one
    advantage when expressing schema-like things, we do a better job
    at expressing datatype ranges.
Gregg Kellogg:  but that requires manufacturing terms for every
    schema property - we don't want to impose that burden on a
    JSON-LD author.
Niklas Lindström:  I can see a certain merit in being able to do
    this - if we have defined a default vocab, I'd expect that we'd
    want to write something akin to this:
Niklas Lindström: "date": {"@datatype": "xsd:date"}
Niklas Lindström: "dc:date": { "@datatype": "xsd:date"}
Niklas Lindström: "dc:date": { "@datatype": "xsd:date", "@iri":
    ...}
Niklas Lindström:  In the case of using a URI, we could add a
    rule stating that if the term in the context is a URI, you're not
    allowed to use an IRI to define what the term is defined to.
Gregg Kellogg:  if it's not an NCName
Niklas Lindström:  This would prevent people from re-defining
    URIs.
Markus Lanthaler:  The disadvantage of supporting that is that -
    it's a term with a colon in it.
Manu Sporny:  I'm concerned that this will hurt more than it
    helps... it's going to look very complicated to authors.
Gregg Kellogg:  JSON-LD "lite" is everything that's in basic
    concepts... so, we can add a few advanced concepts.
Gregg Kellogg:  if the mandate is for JSON-LD to deal with RDF
    serialization, then it becomes an important feature.
Markus Lanthaler: "foaf:homepage": { "@datatype": "@iri" }
Markus Lanthaler: "foaf:homepage": { "@datatype": "@iri" }
Manu Sporny:  The reason to have this is to ensure that
    serializers could compact the data more easily... but at the cost
    of added complexity for authors attempting to understand how a
    context works.
Markus Lanthaler:  I don't like that I'd have to create a
    separate term for homepage just to say it's an IRI.
JSON-LD serialization. This is a case against supporting it for
    the general case for RDF serialization.
Niklas Lindström:  One reason we may want to support URIs in the
    key position in @context is to support namespaces, but that's
    pretty awful in JSON.
Manu Sporny:  I think that this use case may be better served by
    JSON-LD compaction and framing.
Gregg Kellogg:  I think automatically creating a context that
    allows terse expression is difficult without this feature... we
    could do this before with @coerce, but we can't now that we've
    combined everything together.
Niklas Lindström: .. I can go for supporting "dc:date": {
    "@datatype": "xsd:date"} where the @iri key is disallowed, albeit
    it is rather advanced
Manu Sporny:  What about expanding context out... full IRI in the
    key position?
Gregg Kellogg: "http://purl.org/dc/terms/date": {"@datatype":
    "xsd:date"}
Markus Lanthaler:  I don't really like that approach.
Manu Sporny:  We do this for Web Payments - we compact and
    reframe data coming in via RDFa - so, we haven't had the need for
    this feature.
Gregg Kellogg:  When serializing from RDF to JSON-LD - you want
    to be able to coerce without having someone pre-create terms. A
    CURIE makes it unambiguous and still makes it a fairly terse
    representation.
Niklas Lindström:  I can see that supporting it - making it an
    advanced concept.
Manu Sporny:  Gregg, could you create an ISSUE for this and
    re-raise it on the mailing list? We need some more time to think
    about it.

ACTION: Gregg to create issue on use of CURIEs and/or IRIs in context.


Topic: ISSUE-36: Define if data in context documents is ignored

https://github.com/json-ld/json-ld.org/issues/36
Manu Sporny:  I'm pretty sure that we already resolved this,
    right? We decided that we would not import the data?
Niklas Lindström:  I'm for not importing the data.
General agreement that we don't pull data in from context
    documents into the local document that is referencing the
    external context document.
Gregg Kellogg:  We should make it clear that the Compact API call
    can take both a JSON object as the context to use to compact, as
    well as an external IRI.

-- 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, 29 November 2011 18:27:18 UTC