Thoughts on framing, normalization, CURIEs

A conversation that Dave Longley, Gregg Kellogg and I just had on the 
JSON-LD IRC channel. Covers some things we've been discussing on here.

[21:11] <manu> I definitely don't like this "no framing", "no 
normalization" direction...
[21:11] <manu> or splitting the spec into basic and advanced 
functionality conformance levels.
[21:11] <manu> I'm also very concerned about the removal of CURIEs...
[21:11] <manu> framing is something that you hit immediately when 
attempting to work with this data...
[21:12] <gkellogg> I'm not happy about the push towards removing CURIEs, 
but I think we should look for ways to simplify the spec.
[21:12] <dlongley> the same graph can be represented in many different 
ways in JSON-LD
[21:12] <manu> Not dealing with normalization is a mistake that RDF 
serializations have been making for years...
[21:12] <dlongley> the incoming RDF/JSON people might be unaware of this 
issue
[21:12] <dlongley> or unaware of how JSON people want to work with the data
[21:12] <dlongley> (as structures they form and work with naturally in JSON)
[21:12] <dlongley> as opposed to graph APIs/triples/whatever/etc.
[21:13] <manu> I agree that we should try and simplify the spec - but 
that's always true :) - Not many people want to try to make it more 
complicated :P
[21:13] <dlongley> if you don't know what the data looks like, you can't 
work with it naturally in JSON.
[21:13] <manu> yes, exactly.
[21:13] <gkellogg> I do worry about TL;DR with all the stuff that's in 
there.
[21:13] <dlongley> there are two ways to make the data look a particular way
[21:13] <dlongley> 1. normalization
[21:13] <dlongley> 2. framing
[21:13] <manu> I don't think the people that are asking for framing to 
be removed understand why it is there in the first place.
[21:14] <manu> gkellogg: Well, keep in mind that this is a spec for 
/implementers/ - an introduction and lessons should be elsewhere.
[21:15] <gkellogg> It's really pretty similar to the Haml support I 
added to my RDFa writer; it's necessary to get something out that 
jQuery/CSS can work against. Framing's the equivalent for JSON-LD, but 
we never dealt with serialization issues in RDFa.
[21:15] <manu> That is, I don't think it's bad for specs to be very 
thorough in explaining concepts and how stuff is intended to work.
[21:15] <dlongley> we don't want to fall into the same trap we did a 
little while back
[21:15] <dlongley> with people confusing publishing JSON-LD documents 
and understanding how to do that easily
[21:15] <dlongley> with having to read the spec to write processor 
implementations
[21:15] <manu> right.
[21:16] <dlongley> this sounds like a repeat of the failed "JSON-LD 
Basic" spec vs. "JSON-LD Advanced" is what i'm saying.
[21:16] <gkellogg> Is your worry about separating Framing & 
Normalization into separate specs that they just won't be implemented?
[21:16] <manu> JSON-LD is /easy to publish/ - just slap a @context at 
the top of your object and you're good.
[21:17] <manu> JSON-LD is /difficult to implement/ - the normalization 
algorithm, especially... but yes, gkellogg - if it is moved into another 
spec, it will be confusing how the two are related and it will more than 
likely not be implemented, imo.
[21:17] <manu> I think we can have two conformance levels
[21:17] <manu> 1) The API, 2) conversion to RDF.
[21:17] <manu> People can implement #1 or #2 or both.
[21:18] <manu> I don't think we should cut conformance across the API, 
though - compact/expand in basic and frame/normalize/triples in advanced.
[21:18] <gkellogg> 90% of the people are going to read the spec to know 
how to publish. Those details aren't important.
[21:18] <dlongley> then wouldn't they just skip the details they weren't 
interested in?
[21:18] <manu> I disagree - I don't think anybody but really early 
adopters are going to read the spec.
[21:18] <gkellogg> HTML5 also considered (and maybe does) generating 
different specs for publishers and processors
[21:18] <dlongley> just stop reading when you get far enough?
[21:18] <manu> that is - and we made this mistake with RDFa - there need 
to be clear examples and tutorials on the JSON-LD website.
[21:19] <manu> gkellogg: HTML5 does have a "reference manual" and "the spec"
[21:19] <manu> but I think we need something simpler for JSON-LD.
[21:19] <dlongley> it seems to me like we're worried about people 
reading the spec that likely won't ever read it or need to
[21:19] <manu> tutorials just don't fit nicely into the W3C spec 
model... they're unwieldy.
[21:19] <dlongley> i don't know why we're worried about that group of 
people.
[21:20] <manu> I think we should be worried about that group of people - 
and publish tutorials and examples for them on the JSON-LD website.
[21:20] <manu> Kinda like: "Learn JSON-LD in Five easy steps"
[21:20] <dlongley> let me clarify..
[21:20] <dlongley> i don't think we should be worried about those people 
in how we write the spec.
[21:20] <dlongley> they won't be reading it anyway.
[21:20] <manu> right
[21:21] <gkellogg> Well, it seems like we have an opportunity to get the 
RDF WG to adopt JSON-LD as a REC. To what degree do we feel the need to 
cater to pure RDF concerns?
[21:21] <dlongley> it seems like we just need to produce something that 
lets them represent RDF in JSON
[21:21] <gkellogg> Or, are we better staying away from the "smell" of RDF?
[21:21] <gkellogg> cygri would seem to prefer RDF/JSON, which is 
probably better for his use case
[21:22] <dlongley> if they can represent everything they need to ... 
then it seems like we will have done a lot to provide for them
[21:22] <manu> I think there is plenty that we can do to work with the 
RDF WG to ensure that their use cases are supported.
[21:22] <manu> but what we need to make sure we do is not allow 
pre-conceived notions of what RDF/JSON syntaxes should look like affect 
JSON-LD negatively.
[21:22] <dlongley> but just because RDF people won't use framing/ever 
need to understand what it is, i don't think that that should be a 
reason to cut it from the spec ...
[21:23] <gkellogg> spec complexity can be a barrier, and I can see that 
there could be a big kerfluffle over normalization.
[21:23] <manu> The concern that I have w/ Richards push for RDF/JSON is 
that it is a fairly easy transform from normalized to RDF/JSON form.
[21:23] <dlongley> i'm worried about comments that suggest this line of 
thinking: "Hardly anyone would use this in RDF world, so let's cut it."
[21:23] <gkellogg> I tend to agree with you about framing, and I don't 
find it too complex an issue.
[21:24] <manu> Right, the goal here isn't to support every RDF use case
[21:24] <gkellogg> dlongley: absolutely
[21:24] <dlongley> and *maybe*, if it makes sense to do so, we could 
just change normalized form to use a map instead of an array as an output.
[21:24] <manu> (even though I think we do)
[21:24] <dlongley> the issue with that is that it no longer looks like 
the rest of JSON-LD
[21:24] <manu> yes, but by doing that - we totally screw with the RDF 
conversion algorithm.
[21:24] <dlongley> and it's so darn easy to generate.
[21:24] <manu> (in a non-positive way)
[21:25] <dlongley> i guess what i'm saying is this: some RDF folks have 
joined in on the discussion now ... and I think that's a good thing
[21:25] <dlongley> and we should work to try and cover their use cases.
[21:25] <dlongley> however, i don't think it's a good thing to have them 
starting to request cutting features if they aren't coming from the JSON 
world.
[21:26] <manu> especially if they haven't built a system using JSON-LD yet.
[21:26] <gkellogg> The requests to cut CURIEs come from many places, I 
think we should call them something else.
[21:26] <manu> or grok why we have those features in there in the first 
place.
[21:27] <dlongley> gkellogg: like "prefixes"
[21:27] * manu wonders if we could change CURIE syntax to use "+" -> 
foaf+name
[21:27] <gkellogg> We should invite some RDF folks to the telecon where 
we can discuss
[21:27] <manu> gkellogg: good idea
[21:27] * gkellogg interesting
[21:28] <manu> The only reason we'd do that is to placate people that 
have a strong emotional reaction to CURIEs.
[21:28] <dlongley> that sort of thing always bothers me ...
[21:29] <dlongley> (changing things in no real substantive way)
[21:29] <manu> I mean, we've considered dropping CURIEs many times at 
Digital Bazaar... and every time we come to the same conclusion: "The 
number of terms that we're going to be using in these digital contracts 
is going to explode when 3rd parties start extending the digital 
contracts to suit their needs."
[21:29] <gkellogg> Really, in JSON-LD they are prefixes; the term is 
used as a prefix for expansion using a ":" separator. It falls out of 
the term stuff pretty easily.
[21:30] <gkellogg> Maybe need to show an example @context exploded based 
on actual vocabulary use.
[21:30] <manu> "keys in @context can be used as terms or prefixes."
[21:30] <manu> I'd be fine with that...
[21:30] <dlongley> totally fine with that here.
[21:30] <gkellogg> We could do an @context example from the schema.org vocab
[21:30] <gkellogg> +1
[21:31] <manu> alright, well - you guys ok with me copy/pasting this 
conversation to the mailing list for further discussion there?
[21:31] <gkellogg> Well, it is a public forum, so why not?
[21:32] <dlongley> sure

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Building a Better World with Web Payments
http://manu.sporny.org/2011/better-world/

Received on Wednesday, 31 August 2011 01:47:32 UTC