… for quite a while people had been asking to split between language description and complicated API and processing rules
… wanted an easy intro for people to learn JSON-LD syntax with details in a different spec
… had asked to wait for things to settle down, which it seems to have now.
… split into three docs:
… 1 JSON-LD syntax, describes keywords how IRIs and datatypes are expressed.
… 2: API spec, describes 5 method calls to transform JSON-LD between different representations
… 3: Normalization algorithm, it is generalizable and could be used for different RDF languages.
… API spec depends on normalization
… syntax doc doesn't depend upon, but refers to the other two.
… The responses on the list and personal e-mail seem to indicate a general feeling that it is a good idea.
Gregg Kellogg: I think it's something we agreed to do some time ago, so it's good that it's done. [scribe assist by Manu Sporny]
Niklas Lindström: Yes, this is good. [scribe assist by Manu Sporny]
David I. Lehn: there are some spec bugs. List stuff missing?
Manu Sporny: lists shouldn't have been deleted.
… experimental concepts weren't moved over, they'll need to go back.
… suggestion is that all experimental concepts turn into advanced concepts.
Manu Sporny: Looking at http://json-ld.org/spec/latest/ seems to indicate that disjoint graphs and lists were accidentally deleted.
Manu Sporny: need disjoint graphs and lists, those were the only two.
… the latest spec requires an update to merge those two back in.
… gkellogg to update the main processing algorithm for lists
… general agreement to merge the branch into the main spec?
David I. Lehn: question on how they will all link together.
Manu Sporny: RDF normalization doc is stand-alone and doesn't refer to the other docs.
… The API spec refers to the Syntax spec and the normalization spec.
… The Syntax spec refers non-normatively to the API spec and the normalization spec.
… All three must be rec-track documents.
… general agreement, but can't take a vote with only 4 people on the call. I'll merge the spec split into the main line and see if anybody complains at that point, but most seem to want this change.
… type is used in two different ways, for literals and for objects
… generally, authors don't know (or care) about the difference.
… RDF people will understand the difference.
… idea to merge @type and @datatype into a single keyword
… PROs: simplicity and easing the burden on authors.
… CONs: may confuse people coming from RDF world.
… all other keywords need to be paired. Thoughts?
… niklasl: is an RDF-head, but has a problem with this merger
… @type is a short-hand for a property
David I. Lehn: did Dave Longley have comments on this based on all his implementation work?
… other people might have problems initially. the conceptal difference is huge
Manu Sporny: Dave Longley hasn't had any strong feelings on it on the mailing list or privately.
… from the syntax, it's clear what to do, it's really a stylistic thing.
Gregg Kellogg: In general, I'm in favor of reducing the number of keywords that are needed. The danger is that someone uses a class type when they mean a datatype or vice-versa. [scribe assist by Manu Sporny]
Gregg Kellogg: There are many other ways to generate data which is wrong... I'm neutral to +1 on this issue. [scribe assist by Manu Sporny]
Niklas Lindström: might be problematic, you would never coerce something so that it would be typed, but you would coerce a datatype
… also, we have keyword aliases and prefers to use an alias anyway. Would never use @datatype directly. There are a number of places where the differences are important.
Gregg Kellogg: is there a problem w/ potentially coercing multiple types to the same thing... we're a bit heavy with keywords, I see advantage of limiting it... best we can do is put thoughts out there and see if we can get further input from the list. [scribe assist by Manu Sporny]
Niklas Lindström: @type as it is used now might not be necessary, as you can always do this with aliases.
… It allows a symbol to be used, and identifies the value as an IRI
… if understand correctly, couldn't really discard the concept.
Manu Sporny: could always get the behavior by aliasing @datatype to @type.
… introduces an ambiguity that we should be careful of.
Gregg Kellogg: Removing @datatype and aliasing to @type doesn't allow the same thing... [scribe assist by Manu Sporny]
Manu Sporny: would still be able to do this, because of RDF processing rules.
… RDF checks if @literal is used, and then looks for @datatype. If it was aliased, it would just look for @type at the same literal.
Gregg Kellogg: My point was that we can't get rid of @type completely, because the processing rules need /something/ to generate the rdf:type triple. [scribe assist by Manu Sporny]
Gregg Kellogg: We need a way to define both @types and @datatypes... we should keep them as separate concepts. [scribe assist by Manu Sporny]
Manu Sporny: general agreement to not merge the two
David I. Lehn: I think you all covered issues I had
Manu Sporny: people are confused, as they expect that property should map to datatype, not the other way around.
… right now, it's flipped. This is because we wanted to keep the coercion rules relatively short. This had historically been an issue, as we didn't have a way to specify an external concept.
… Now that we have an external context, we should revisit, as it is more natural and size isn't as important now as it had been in the past.
… people will typically use external files for their contexts, so it's fairly DRY and you can depend on caching.
… proposal is to switch the order of type coercion to be property mapping to datatype
Niklas Lindström: change doesn't affect me; may be cleaner.
… if you have a list of strings, both as an RDF list of URIs.
Gregg Kellogg: This came up in the Microdata conversion work... the current algorithm converts to a list... this is a violation of range restrictions. The only real way to know that you're referencing a list is to refer to the rdfs:range. [scribe assist by Manu Sporny]
Gregg Kellogg: So, there is no way to say what the contents of a list should be a particular type. [scribe assist by Manu Sporny]
Niklas Lindström: We're not sure if the example I wrote up there is even legal... how do you specify that a list contains IRIs? [scribe assist by Manu Sporny]
Manu Sporny: can create a list of IRIs with both markup mechanisms, so this is parallel to what we're discussing.
… Might not want to allow, but if we do it's straightforward with either approach.
… I think we should do the swap - property maps to datatype.
… Another reason is that the data structure you end up creating in the JSON-LD processor is exactly this... it will simplify implementations.
… A processor writer has to do this anyway.
… doing this would be a plus for both authors and implementations.
Niklas Lindström: I'm probably 2-steps ahead, but if we do this, we might be on a path to bring to extend something like updated.
Manu Sporny: very sophisticated, and may cause confusion.
Gregg Kellogg: I can see the advantage of that - but I think it may make the @context documents less readable... keeping @coerce separate will allow people to read the document as two separate parts. [scribe assist by Manu Sporny]
Manu Sporny: people would continue to scan, and if they wanted to find xsd:dates, but not a very strong argument.
… nice to be able to look in different sections to find different things, the separation may be good for beginner authors.
… if combined, it is mixed in on the page and more difficult to parse out for authors... requires you to run the processing rules in your head at some level, which is bad.
… for the time being, prefer to keep as key/value sections.
Gregg Kellogg: We want to not fall into the trap of too many ways to do the same thing. [scribe assist by Manu Sporny]
Niklas Lindström: if we were to allow, I would recommend removing the other way
… this example also goes even further.
… this is close to what _gluon_ did. This JSON-LD approach is cleaner, though.
… I think this mechanism is more compact, and can see everything about a property in a single place.
Gregg Kellogg: I can see the benefit here... we probably need to float it out on the list... pretty big change. [scribe assist by Manu Sporny]
David I. Lehn: I think that could look nice. We might want to run some bigger example cases through such a conversion to see how it turns out.
Manu Sporny: I agree that it does make it cleaner and more compact from a design standpoint, but it smells like feature creep.
… this might make it more difficult for people to understand what's going on, and we certainly didn't intend for JSON-LD to be something with complex processing rules.
… If we do make this change, we're moving further away from the "simple" nature of JSON-LD.
… requires you to have the processing rules in your head to understand what's going on.
… this overcomplicates the language under the guise of "good design"
… if we continue to add features, we make it cognitively far more difficult for people to wrap their heads around.
… I see the design benefit, if the goal was to create a very rich complex language, but don't feel that's the goal of JSON-LD.
Niklas Lindström: I understand your arguments, and was always trying to be as complete as Turtle.
… I think the compactness and directness motivates the complexity.
… As it stand, we have @vocab and @coerce, don't know how much more complex this makes it, if we didn't have @coerce in the top-level context.
Manu Sporny: if we don't have @coerce in top level, this really isn't more complex.
Manu Sporny: Niklas, can you type something up and send it to the mailing list?
Manu Sporny: feel we're okay having the property maps to datatype change.
David I. Lehn: also might want to check how the @list proposal fits into these changes
Gregg Kellogg: We do need @list, but maybe we can use @list as a datatype... if we wanted to specify multiple things, we could use an array-type form. [scribe assist by Manu Sporny]
David I. Lehn: for conflicts, just leave behavior undefined
Niklas Lindström: We like the the ability to do property/value, may as well go with new form.
Manu Sporny: We can't leave behavior undefined, as it leads to confusion.
… end up not interoperating because of conflicts. This is why HTML5 goes into excruciating detail on what to do when a tag isn't closed. HTML4 didn't specify it and neither did XHTML, and so the browser vendors ended up implementing incompatible rules to interpret what was going on.
… need to specify conflict behavior in spec. API indicates this is an error condition.
Manu Sporny: general idea is to adopt the proposal.
… property/datatype
David I. Lehn: i think we also want to look a bit closer at Niklas' proposal too
Niklas Lindström: I'll write down my proposal to the list along with some example contexts.