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

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

Manu Sporny: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

Niklas Lindström: +1

David I. Lehn: +1

David I. Lehn: fwiw, i think dlongley really should be voting on this stuff too since he knows alot about the implementation issues

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

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

Manu Sporny: +1

David I. Lehn: +0

Markus Lanthaler: +1

Gregg Kellogg: +1

Niklas Lindström: +0.5

Manu Sporny: +1

Gregg Kellogg: +1

Niklas Lindström: +0.5

Markus Lanthaler: +1

David I. Lehn: +0

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

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

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

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]

Manu Sporny: +1

Markus Lanthaler: +1

Gregg Kellogg: +1

David I. Lehn: +1

Niklas Lindström: +0.5