JSON-LD Telecon Minutes for 2011-12-13

The minutes for yesterday's call are now available here, thanks to 
Markus for scribing:

http://json-ld.org/minutes/2011-12-13/

Full text of the discussion follows:

JSON-LD Community Group Telecon Minutes for 2011-12-13

Agenda:
    http://lists.w3.org/Archives/Public/public-linked-json/2011Dec/0034.html
Chair:
    Manu Sporny
Scribe:
    Markus Lanthaler
Present:
    Markus Lanthaler, Manu Sporny, Gregg Kellogg, Niklas Lindström,
    David I. Lehn

Markus Lanthaler is scribing.

Topic: Reducing the number of keywords in JSON-LD

Manu Sporny:
    http://lists.w3.org/Archives/Public/public-linked-json/2011Dec/0037.html
Manu Sporny:  let's take a little time to talk about this email
Markus Lanthaler:  Basically, I went through the entire spec and
    looked at all of the keywords that we currently define. Without
    considering framing, we have 10 keywords, some of them are
    redundant and others don't necessarily provide functionality that
    are required. [scribe assist by Manu Sporny]
Markus Lanthaler:  For example, @subject and @iri are redundant -
    @iri is kind of a special case, we use it as a datatype in the
    @context. [scribe assist by Manu Sporny]
Markus Lanthaler:  We use @iri to specify a datatype for
    coercion. [scribe assist by Manu Sporny]
Markus Lanthaler:  The same applies to @list [scribe assist by
    Manu Sporny]
Markus Lanthaler:  They're a bit different from all of the other
    keywords in JSON-LD... [scribe assist by Manu Sporny]
Markus Lanthaler:  @datatype and @type are subtly different in
    JSON-LD (for an average developer). In RDF, it matters... that
    may be why people with more RDF background don't want to merge
    them together. Others like @language and @literal usage is very
    clear... [scribe assist by Manu Sporny]
Markus Lanthaler:  @base and @vocab don't have very clear use
    cases - that is, they make reading the JSON-LD more difficult
    because they have to keep 3 base URIs in their head. Base URI of
    the document, @base, and @vocab... hard to keep all of those in
    your head, maybe it would be better to be more explicit. [scribe
    assist by Manu Sporny]
Markus Lanthaler:  Gets worse when you include external
    contexts... makes debugging more complex. [scribe assist by Manu
    Sporny]
Markus Lanthaler:  There is a proposal to drop @base and
    @vocab... you could use prefixes if you need those types of
    things. I tried to remove keywords w/o losing any functionality.
    In the end we could go from 10 keywords to just 6. [scribe assist
    by Manu Sporny]
Markus Lanthaler:  Even with 6 keywords, we don't lose any
    functionality. [scribe assist by Manu Sporny]
Markus Lanthaler:  In some cases, it makes it even easier. Some
    people may be confused with having two concepts @datatype vs.
    @type - if they don't have an RDF background, they don't
    understand the difference. People w/o a RDF background will be
    using JSON-LD - they probably don't care about RDF. [scribe
    assist by Manu Sporny]
Gregg Kellogg:  I'm not sure if we can drop @base
Gregg Kellogg:  it might be necessary to describe something
    without needing to care where the document came from
Gregg Kellogg:  @vocab could be eliminated and we could use an
    empty prefix instead
Gregg Kellogg:  looking at the rest.. I could see merging @type
    and @datatype
Gregg Kellogg:  I would eliminate @datatype instead of @type
Niklas Lindström:  I'm simpathetic to the ideal that Markus
    proposed
Niklas Lindström:  but in reality it's difficult to find a simple
    form
Niklas Lindström:  I agree that @base is important for cases
    where you wanna use relative IRIs independent of where the
    document is stored
Niklas Lindström:  if we allow relative IRIs I believe we should
    allow @base as well
Niklas Lindström:  alternative would be to have absolute IRIs
    everywhere
Niklas Lindström:  to @datype and @type.. I'm trying to support
    it but the biggest problem I have with it is that in practice
    they don't have the same value space
Niklas Lindström:  so they are distinct concepts
Niklas Lindström:  if we where to merge them we couldn't extract
    statistics e.g. which types/datatypes are used
Niklas Lindström:  it's not impossible to work around it but it's
    a potential problem
Manu Sporny:  I was actually against of changing alot
Manu Sporny:  but I think the part of Markus' argumentation that
    convinced me was trying to simplify JSON-LD especially for people
    without RDF background
Manu Sporny:  I don't see using absolute IRIs or prefixes
    everywhere as being a bad thing
Manu Sporny:  Alexandre posted an example with @base but it took
    me about 15 seconds to figure out what was meant
Manu Sporny:  that makes it much more difficult for people with
    less involvement in JSON-LD
Manu Sporny:  in XML it was a necessary evil
Manu Sporny:  because a lot of editing was done manually
Manu Sporny:  JSON-LD is different since large parts are
    machine-generated
Manu Sporny:  what convinced me most was Markus' argument that we
    should make it as simple as possible without losing functionality
Manu Sporny:  this doesn't have to be a final decision though
Manu Sporny:  we can always add in @vocab, e.g., at a later point
    in time
Niklas Lindström:  I think that's a good point.. let's try to
    reduce it

Topic: ISSUE-15: Are @subject and @iri redundant?

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/15
Manu Sporny:  is there anyone who thinks it's a bad idea to merge
    them?
Manu Sporny:  my only concern is that people might get confused
    whether something is just a IRI or the subject
Gregg Kellogg:  the only thing is that IRI is very specific
Gregg Kellogg:  so it might be better to choose a better term
Gregg Kellogg:  e.g. @id
Niklas Lindström: … @itemid? (ducks and covers) ;D
Markus Lanthaler:  so you would coerce a foaf:homepage to @id?
Gregg Kellogg:  yes
David I. Lehn: we could get rid of naming issues and just move
    back to "@" which we started with :)
Manu Sporny:  the other reason for this is that a lot of people
    don't know what an IRI is
Niklas Lindström:  I'm almost in favour of @id
Niklas Lindström:  maybe also something longer such as
    @resourceid
PROPOSAL:  Use the same keyword for the concepts of @subject and
    @iri.

Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION:  Use the same keyword for the concepts of @subject
    and @iri.

David I. Lehn: fwiw, i think dlongley really should be voting on
    this stuff too since he knows alot about the implementation
    issues
PROPOSAL:  Use the keyword '@id' for the combined concept of
    @subject and @iri.

Gregg Kellogg: +1
Manu Sporny: +1
David I. Lehn: +1
Markus Lanthaler: +1
Niklas Lindström: +0.5
Markus Lanthaler:  the only thing I don't really like is that we
    are using @id in coercion then...
RESOLUTION:  Use the keyword '@id' for the combined concept of
    @subject and @iri.


Topic: ISSUE-26: Drop @base and @vocab

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/26
Manu Sporny:  I would be in favour of doing but dropping @vocab
    makes me nervous because of schema.org
Niklas Lindström:  I believe I'm in the same position as you
Niklas Lindström:  we can use absolute IRIs everywhere or a
    "base" prefix as Markus suggested
Manu Sporny:  that is exactly the problem since it is very
    difficult to understand how an IRI is expanded.. what's the
    precencende if there's @vocab and a defined term
Manu Sporny:  my concern about @vocab was always "what if someone
    would like to use schema.org"
Gregg Kellogg:  would propose to drop both and specify that IRIs
    are absolute
Gregg Kellogg:  regarding the use of empty prefixes: it's not a
    promoted use case but if relax how terms are specified we could
    allow empty terms e.g.
Niklas Lindström:  I could try to discard @vocab as well
Niklas Lindström:  my favourite use was to reduce the size of the
    context
Niklas Lindström:  my context would grow quite a bit if we drop
    it
Markus Lanthaler:  Why should the context grow if we use @vocab?
    You could just use a prefix, right? [scribe assist by Manu
    Sporny]
Markus Lanthaler:  You have to add the prefix to your whole
    JSON-LD document, so that might grow a bit. [scribe assist by
    Manu Sporny]
Niklas Lindström:  Yes, you could do that... [scribe assist by
    Manu Sporny]
Gregg Kellogg:  we might need to have a better definition of what
    a term is
Manu Sporny:  do we need this for this issue
Gregg Kellogg:  we might need it to get a similarly terse
    representation if we drop @base and @vocab

ACTION: gkellogg to create issue to expand on the lexical range of term 
identifiers

PROPOSAL:  Drop support for @base.

Manu Sporny: +1
David I. Lehn: +0
Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +0.5
RESOLUTION:  Drop support for @base.

PROPOSAL:  Drop support for @vocab.

Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +0.5
Markus Lanthaler: +1
David I. Lehn: +0
RESOLUTION:  Drop support for @vocab.

Niklas Lindström:  should we add a note on the spec that they
    existed and they might come back
Niklas Lindström:  or that prefixes are they way to replace them
Manu Sporny:  I agree

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

Manu Sporny:  are there any arguments against doing this?
Niklas Lindström:  the value spaces are different
Niklas Lindström:  this is my real problem
Niklas Lindström:  or just drop @type because you could also do
    it yourself with RDF
Manu Sporny:  I agree there are different value spaces
Manu Sporny:  but there are not many developers knowing or caring
    about thi
Manu Sporny:  I think we think that @type is more important than
    it is actually in practice
Niklas Lindström: .. example of facets from json-ld in our
    system: http://service.demo.lagrummet.se/-/publ;stats
Manu Sporny:  I think we don't need to make a distinction at the
    language level
Gregg Kellogg:  there's the danger that people conflate these two
Gregg Kellogg:  even though @type is not necessary (in RDF) it
    makes it much easier to understand
Markus Lanthaler:  Even if we keep them different, people need to
    know that they're different. The names are so similar that JSON
    developers probably will not understand the difference. You
    define the type of a variable the same way. [scribe assist by
    Manu Sporny]
Markus Lanthaler:  I don't think we can argue that we reduce the
    amount of invalid data that is created by having two different
    keywords. I'd argue that we increase the problem because people
    might put @datatype in the wrong place vs. @type. [scribe assist
    by Manu Sporny]
Gregg Kellogg:  That is a persuasive argument. [scribe assist by
    Manu Sporny]
Manu Sporny:  I see that difference is because of the way RDF is
    modeled
Manu Sporny:  if you think of a graph and a literal being a node
    in that graph there's not really a difference there
Manu Sporny:  Niklas, I buy the argument in an RDF model but I
    don't buy the argument in an general graph model
Manu Sporny:  I don't think JSON developers will have much issues
    regarding the value space
Error: (IRC nickname not recognized)[11:06] <gkellogg> 
    "2011-12-13"^^xsd;date => [ rdf;value "2011-12-13"; a xsd:date ]
Niklas Lindström:  the thing that makes me nervous is that we
    have an extraction of types (link posted before) and I can't work
    around it
{ "@literal": ...", "@datatype": "..." }
Markus Lanthaler:  Looking at your example Niklas, is there a
    solution if we merge @type and @datatype? [scribe assist by Manu
    Sporny]
Gregg Kellogg:  I think that's more a problem in RDF because you
    can't add a type to a literal
Niklas Lindström:  Yes, I think so... although, it's not as clean
    as it would be if we had @type and @datatype [scribe assist by
    Manu Sporny]
PROPOSAL:  Merge @datatype keyword with @type - @type will be
    used to specify both rdf

Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
David I. Lehn: +1
Niklas Lindström: +0.5
RESOLUTION:  Merge @datatype keyword with @type - @type will be
    used to specify both rdf

-- 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, 13 December 2011 19:24:42 UTC