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
Audio Log
audio.ogg
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