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

JSON-LD Telecon Minutes for 2012-01-10

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 10 Jan 2012 14:27:17 -0500
Message-ID: <4F0C9115.1090306@digitalbazaar.com>
To: Linked JSON <public-linked-json@w3.org>
The minutes for today's call are now available here:

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

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-10

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2012Jan/0001.html
Chair:
    Manu Sporny
Scribe:
    Manu Sporny
Present:
    Manu Sporny, Gregg Kellogg, Niklas Lindström, Markus Lanthaler,
    David I. Lehn
Audio:
    http://json-ld.org/minutes/2012-01-10/audio.ogg

Manu Sporny is scribing.

Topic: Specs and Test Suite Update

Gregg Kellogg:  In terms of Editors Drafts - we should push out
    another version of the specs.
Gregg Kellogg:  I think we're close to stability w/ the syntax -
    main thing on the board is changing @literal to @value.
Gregg Kellogg:  Other than that, we may be converging on the
    syntax.
Niklas Lindström:  I finally got around to adding support for
    JSON-LD in RDFExtras... complementary lib to RDFLIB in Python...
    doesn't bring any news issues today, but am getting a feel for
    the details of the spec.
Niklas Lindström:
 
http://code.google.com/p/rdfextras/source/browse/?name=jsonld#hg%2Frdfextras
Niklas Lindström:  I did notice that the tests are a bit strange,
    changed SPARQL to TURTLE examples... I do back-and-forth
    conversion - may want to look into that.
Gregg Kellogg:  Is this in the source repository?
Niklas Lindström:  Not yet.
Manu Sporny:  Test suite looks great... we will probably keep
    using that... you have to implement a test runner for it?
Gregg Kellogg:  Yes, one caveat is that you need SPARQL to do
    some comparisons... we could turn it into normalized JSON and
    just compare that.
Gregg Kellogg:  SPARQL is only used for RDF conversion tests...
Gregg Kellogg:  You could go from JSON-LD - RDF - JSON-LD -
    normalize and compare that, but that's a bit complicated.
Manu Sporny:  Do you know if the JavaScript SPARQL
    implementations are fairly complete?
Gregg Kellogg:  Haven't had the time to look in depth.
Niklas Lindström:  Parsing JSON-LD then serializing to normalized
    JSON structure is complex... you don't really know where in that
    chain those things fail. SPARQL implementations are quite complex
    as well... perhaps we should look into RDF triple set comparison.
    There is a fairly understandable implemention of it in RDF lib.
Gregg Kellogg:  I have one of those in Ruby as well... doing
    Jeremy Carroll's algorithm is not simple. It's important to have
    - triple comparison is simple to do... understandable why you
    can't do that for RDFa... but for JSON-LD, that may be possible.

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

https://github.com/json-ld/json-ld.org/issues/43
Gregg Kellogg:  The issue is that if you are serializing from RDF
    into JSON-LD, where you have namespaces, but you don't have
    terms, you can easily create CURIEs, but you'd also like to have
    the full coercion expressivity.
Gregg Kellogg:  For example, you want to be able to say that a
    property is a certain datatype...
Gregg Kellogg:  In my implementation, anything that can be an IRI
    in the key position in the context can be a CURIE or an IRI...
    that allows you to do useful things, where terms can have
    coercion properties.
Manu Sporny:  Spoke with Dave Longley about it, he's for it. So
    am I, seems like a useful feature.
Markus Lanthaler:  You could have several definitions for the
    same term... you could have 3 different URIs for the same term
    and 3 different datatypes - we'd have to specify how to merge
    those different definitions together.
Gregg Kellogg:  my table is defined w/ IRIs as keys, so this
    can't happen.
Gregg Kellogg:  I think that if you end up setting a term to a
    different IRI, the algorithms won't invoke that mapping.
Gregg Kellogg:  If we split the key on a colon, you look up the
    prefix... you get the IRI... if it is an IRI or CURIE, you just
    get the term part of it.
Markus Lanthaler:  Nevertheless, if you have two URIs defined,
    you have to figure out how to set them.
Gregg Kellogg:  I don't know if we want to specify the
    behavior...
Niklas Lindström:  I think there might be a problem here, one
    thing that strikes me is that we probably should that there is a
    precedence rule... there should probably be the possibility to
    define two different terms for the same IRI, but with different
    coercions.
Manu Sporny:  I think we should kick out an error if somebody
    tries to set an IRI w/ the CURIE mechanism.
Niklas Lindström:  I think that's fine.
Niklas Lindström:  I think that we should expand CURIEs in
    context quickly.
Gregg Kellogg:  I agree that the only time an @id should be set
    is when it's used as a term.
Gregg Kellogg:  We should say that coercions map to the expanded
    version of the terms... that is what is used when we do coercion.
Markus Lanthaler:  If you do that on an expanded IRI, it would
    prevent the use of two different terms with two different
    datatypes.
Markus Lanthaler:  This is mainly for when you generate JSON-LD
    from RDF... when you automatically serialize RDF, you don't know
    if every property will use the same datatype.
Discussion about how the @context is built when processing terms
    and CURIEs
Markus Lanthaler:  The only good use case for this is when you
    convert from RDF to JSON-LD... it's arguable if you need this
    type of optimization. Do we need this feature, not that trivial
    to implement this feature?
Niklas Lindström:  I kind of agree with Markus - I think that
    when you're automatically serializing RDF and you use prefixes
    for one... coercing the values for one feels half-baked to me.
Niklas Lindström:  I'm a bit wary of it... in RDF, you can have
    all kinds of values for a certain property - you could have one
    value which is a language-tagged value, something else that is an
    xsd:string, something else that is a dateTime.
Niklas Lindström:  I prefer to defer this, but would like to hear
    Gregg's use cases on this.
Gregg Kellogg:  There are a number of cases where this may be
    useful - it avoids a great deal of work where you're describing
    things in a context. Cases for doing coercion of CURIEs are
    focused on converting RDF to JSON-LD - my processor creates
    conversion rules when they lead to a net reduction in size.
Gregg Kellogg:  For example, if all dc:created are dates, then I
    can compress the document.
Markus Lanthaler:  The context is about defining terms and
    prefixes.
Gregg Kellogg:  I think that it's natural that people will try
    this - author's will do this, no good reason not to support the
    use case.

PROPOSAL:  Allow CURIEs as @context keys.

Manu Sporny: +0.5
Gregg Kellogg: +1
Niklas Lindström: +0.1
Markus Lanthaler: -0.5
David I. Lehn: +0.5

Manu Sporny:  Let's kick this back to the mailing list... Gregg,
    could you do a concrete proposal on this?
Niklas Lindström:  I remember seeing an experiment in JSON with
    using prefixes, not from this community, but they were using
    something like CURIEs.
Niklas Lindström:  So, it might be useful...

Topic: ISSUE-48: Rename @literal to @value

https://github.com/json-ld/json-ld.org/issues/48
Markus Lanthaler:  Fairly trivial change - rename @literal to
    @value... @literal is coming from an RDF background and most
    developers are more familiar with the term 'value' than they are
    with 'literal' - because a 'literal' could also be numbers.
Markus Lanthaler:  @value would be better for developers - it
    would make it easier to understand for developers.
Gregg Kellogg:  I think that literals are a common term in most
    programming environments... they mean something different from
    value - values have both simple and complex data structures...
    literals imply something that is not a structured element itself.
    integers, strings, dates - scalar might be a better term?
Niklas Lindström:  The thing is that you have the value and the
    datatype... literal is the result of that thing.
Markus Lanthaler:  Yes, literal is the combination of the
    datatype and the thing that we need to name... value could work.
Markus Lanthaler:  Lexical representation... lexical, string, may
    work.
Markus Lanthaler:  @value is just a token anyway...
Manu Sporny:  Dave Longley is in favor of @value, so am I. It
    resonates more with Web developers than @literal.
Gregg Kellogg:  I think RDF people might like @value more...
    @value might work on a number of different communities.

PROPOSAL:  Rename the @literal keyword to @value.

Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
David I. Lehn: +1

RESOLUTION:  Rename the @literal keyword to @value.

Topic: ISSUE-42: Distinguishing a JSON-LD frame from a JSON-LD document

https://github.com/json-ld/json-ld.org/issues/42
Manu Sporny:  JSON-LD frames are not JSON-LD documents... we may
    want to just make them regular JSON objects.
Niklas Lindström:  Has anybody thought about using the @frame
    keyword in a JSON-LD document?
Niklas Lindström:  I may want to publish frames... they would
    constitute documentation for me... in those scenarios, I think
    that @frame would be helpful in those scenarios.
Niklas Lindström:  If we're worried that people look at frames
    and confuse them with instance documents, we may want to add
    @frame.
Gregg Kellogg:  I think we went through the same discussion with
    @context... so we decided that @context documents start with a
    @context key.
Gregg Kellogg:  if we are going to have a data structure that has
    a frame, we're inevitably going to need to get that data from an
    IRI.
Gregg Kellogg:  I don't have a way to express a frame inline,
    very effectively. The fact that the document is part of JSON-LD
    does argue that they should have something that has a JSON-LD
    MIMEType...
Gregg Kellogg:  This is very symmetric with the way we deal with
    @context.
Markus Lanthaler:  I don't think that frames are the same as
    @context... they are quite different in my opinion. You include
    the @context directly in a JSON-LD document, you'd never do that
    with a frame. The Frame is a distinct concept, separate from the
    document.
Markus Lanthaler:  The cleanest solution would be to create a new
    MIMEType for JSON-LD frames.
Markus Lanthaler: Frames are kind of a query language for JSON-LD
Niklas Lindström:  I'm a bit wary about MIMEType proliferation...
    people screw it up in usage... people are more prone to look at a
    document and think it looks like JSON-LD, than look at the
    MIMEType.
Niklas Lindström:  We may want to specify @frame to make it
    explicit.. @frame should not be in the JSON-LD spec... it should
    be in the API spec.
Manu Sporny:  There are two issues here - follow-your-nose and
    helping newbies recognize the difference between a JSON-LD
    document and a JSON-LD frame. The first problem is addressed by
    creating a MIMEType for frames. We don't know if adding @frame
    will address the second problem. In the worse case, we add frame
    and newbies still think it's a JSON-LD document and not a JSON-LD
    frame. We may not even want a new MIMEType because nobody looks
    at those, like Niklas said. JSON-LD frames don't look like
    JSON-LD documents, really.
Markus Lanthaler:  Yes, but not having a MIMEType prevents people
    from doing things like having different icons, using different
    editor's for frames, etc.
Niklas Lindström:  I still think that JSON-LD frames look very
    much like JSON-LD documents.
Gregg Kellogg:  I think that just using a plain JSON document
    fails the follow-your-nose test... it needs to be a JSON-LD frame
    MIMETYPE or a subtype of JSON-LD document
Gregg Kellogg:  There is some danger of making it too much like a
    JSON-LD document, but the contents are explained in the spec. You
    can clearly find out the meaning of that by looking at the
    specification.
Long discussion about whether or not @frame would solve the
    problem of confused developers - fair arguments that it would and
    wouldn't.
Niklas Lindström: Look at the library example - the frame looks
    exactly like a JSON-LD document:
    http://json-ld.org/playground/playground-examples.js
Markus Lanthaler: We could put the @frame beside the @context?
    (a) { "@frame": { "@context": "....", "query": "..." } vs. (b) {
    "@context": "....", "@frame": "query..." }
Manu Sporny:  Let's straw-poll to see if we want to support a
    MIMEType for JSON-LD frames...

PROPOSAL:  JSON-LD frames should have a MIMEType, which is
    distinct from JSON-LD documents.

Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0

Niklas Lindström: .. like "application/jsonldframe+json"
David I. Lehn: I can see people just wanting to use regular json
    mimetype for all these docs
Niklas Lindström: David Lehn, I believe so too

RESOLUTION:  JSON-LD frames should have a MIMEType, which is
    distinct from JSON-LD documents.

Gregg Kellogg: application/frame[+-]ld+json
Gregg Kellogg: The syntax document is almost done, we should
    figure out what our plan is for the next couple of months... send
    something to the mailing list, Manu.

-- 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, 10 January 2012 19:30:23 GMT

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