Re: What *is* RDF?

On 03/24/2011 10:27 PM, Peter Frederick Patel-Schneider wrote:
>> Here is one way to interpret what you said:
>>
>> "If I don't understand something, I'm going to vote against it."
>>
>> That sounds scary and like a veiled threat. 
> 
> Well, if I can't understand something after a concerted effort to try, I
> probably would vote against it, unless someone convinces me otherwise.
> Take this whatever way you want.

I don't mean this in a way that is harsh, just stating a few opinions:

A few days is not a 'concerted effort'. If you can't understand most of
it after a month of us attempting to explain it to you, that's a problem.

>> Yet another is:
>>
>> "I wish this WG wasn't wasting its time on this."
> 
> This one doesn't seem to me to have any relationship to my words at all.
> In fact, although I may not have stated publically before, I think that a
> closer relationship between RDF and JSON would be great for both sides.

Good to know. You gave me the impression that you didn't think it was
feasible for us to work on RDF in/on/with JSON.

> Well, I think that I certainly have indicated that I am eagerly awaiting
> answers. 

Yes, but I'm unsure which answers you're waiting on because I think
you're asking a very vague question: "What is JSON?" - you are going to
get vague answers to that question. That's like asking "What is RDF?" -
different people are going to give you different answers to that one.

>> "Why is this steaming pile of crap so badly defined and hard to
>> understand!?"
>>
>> Fair enough. It can be at first.
> 
> But should it be hard for someone who has been doing object-oriented
> programming since the 1980s; understands multiple inheritance and the
> difference between class-based and prototype-based object formalisms;
> has designed object-centered representations; and has a good grounding
> in all of programming language semantics, relational and object-oriented
> data base theory, semi-structured data, and model theory?

Perhaps you know too much :)

I'm serious - I've seen advanced programmers and language gurus have a
more difficult time at picking up JSON serialization than beginners
because they ask tons of questions and need to know every last detail
about the serialization up front.

It makes it harder to learn JSON serialization because there is hardly
any other advanced structured data format that works across all
programming languages. Sure you could argue about TSV/CSV - but do those
have an data model? I claim that they don't.

To fully understand the JSON programming model (which is different from
the serialization), you probably need to program in JavaScript, Python,
and C++ before you grasp what is common across all of those languages.

You can boil it down to arrays of values and associative arrays, but
that is probably more of a simplification than you want. I can hear you
asking about how each language represents numbers and booleans - and
that's up to the language's data model.

> Well, I certainly agree that the situation with RDF could (or maybe
> should) be less complex, but if I want to understand RDF all I need is
> the RDF Semantics document (modulo a couple of errata) and a bit of RDF
> concepts.  I find the RDF semantics document easy to understand.  If I
> want to understand RDF/XML I need to understand far too much, but I hope
> that the RDF documents make the point that it isn't the serialization
> that matters, just the semantics.

Yes, that's one answer. If I ask somebody else, they're going to give me
another answer. My point is that "What is X?" can be a vague question
and is highly context sensitive? People answer it how they interpret it,
and it'll be interpreted differently by different people.

My point is that you started off by asking a vague question: "What is
JSON?" -> incredibly vague.

>>   * What is the object model for JSON?
>>     Answer: JSON (the serialization) doesn't have a defined object
>>             model, it is a serialization format, it has a well-defined
>>             grammar specified in RFC4627 - use that.
>
> This one was very surprising to me.

I can understand that coming from anyone with a heavy formalism/data
modeling/RDF/OWL background. I'm not saying that actually is your
background, that's just my perception of your background.

>>   * Exactly what is the valid JSON grammar?
>>     Answer: If it doesn't conform to RFC4627, it's not valid.
> This one I get, modulo one very important SHOULD, except that I've seen
> three different syntax definitions, none of which defer to any of the
> others. 

Yes, it would be more nice if the specs were better at that, but they're
not. I think we can succeed in creating a specification in spite of this
because we will be citing one of those syntax definitions (RFC4627).

>>   * What happens when you use multiple keys that have the same value?
> [I think that you mean use the same name multiple times in one object.]
>>     Answer: Don't do that, nobody does that, it doesn't work in any
>>             implementations, even if it is valid according to the
>>             grammar.
> Well, then these implementations are *not* conforming!
>>From RFC4627:
>    A JSON parser transforms a JSON text into another representation.  A
>    JSON parser MUST accept all texts that conform to the JSON grammar.
>    A JSON parser MAY accept non-JSON forms or extensions.

They're conforming. They accept all texts that conform to the JSON
grammar - they just don't expose it in the language's data model. This
is the exact same issue as this in the DOM:

<div class="foo" class="bar"></div>

an HTML5 parser will parse that, the DOM will only expose one of those
properties. For example, WebKit's DOM only exposes class="foo" and
ignores the other one.

> And maybe you begin to see part of the problem.

The only issue that I see is that you have a few holes in your
understanding of the JSON serialization and how it is used in
programming environments that we need to fill in. It is important that
we fill those holes in, but I want to be clear that I don't think these
are issues that are going to prevent us from being successful with a
serialization.

>>   * Exactly what object model for JSON should we use?
>>     Answer: We don't need to specify a JSON object model in order to
>>             specify a syntax that works for RDF.
> Well, then do I have a solution for you!
>   The JSON for an RDF graph is an array of arrays, each of which has
>   three elements, each of which are strings.  Each of the three-element
>   arrays encodes a triple ... [You should be able to guess the rest.]
> Done!  Let's ratify this at the first F2F, declare victory, and be the
> first W3C WG in a long time to finish early.

Ha! That would certainly allow us to finish early.

Yep, that would be one solution. However, one solution that doesn't take
into account the way that many developers use the JSON serialization in
practice. There is no document that outlines this, but many JSON
developers that have been using JSON for a few years now know what feels
normal and what doesn't. Just like many C developers know what's safe to
do with a pointer and what's not safe. What you want to know, how people
use JSON serialization in the field, there is no documentation for - in
any programming language.

>>   * and so on...
>>
>> There are other ways to answer the questions above, but they lead us
>> down rat holes.
>
> Well, I, for one, want precise answers to precisely these questions so
> that I can understand why certain directions have been taken and,
> probably more importantly, why other directions have not been taken.

I feel like many of your questions have been answered (or will be
shortly) - so, now I'm unclear as to what questions you still have.

> This sounds like you are going to maintain that a deep knowledge of
> JavaScript is needed for a deep understanding of JSON, "a lightweight,
> text-based, language-independent data interchange format" [RFC4627].  I
> sure hope that this is not the case!

I am going to maintain that the following are required for a language
designer that is developing a JSON-based serialization that is going to
be successful in the marketplace:

 * A deep understanding of RFC4627
 * A shallow understanding of how RFC4627 is implemented in at least 3
   languages with different data models (objects, associative arrays,
   pointer-based data structures)
 * Potentially a deep understanding of ECMA-262, but not necessarily
   required.

> Well, patience is only going to help until some time before the first
> F2F, because the WG is supposed to be making decisions there, or at
> least that is what I think the WG's schedule is.

I think the decisions we're making are constrained by that timeline, but
if we can't make the decision in that time, that we're going to have to
figure out another way to tackle this problem. That is, if the people in
this WG feel that this is a problem work tackling. I'm more concerned
about solving the problem that we define as a group than I am about an
arbitrary timeline that was set before all of us convened based on
assumptions that are probably not valid anymore.

I would hazard a guess that deep down, you feel the same way.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Payment Standards and Competition
http://digitalbazaar.com/2011/02/28/payment-standards/

Received on Friday, 25 March 2011 13:46:10 UTC