Re: Why Framing and Normalization

On 4 September 2011 05:04, Manu Sporny <msporny@digitalbazaar.com> wrote:

[feel free to skip the argumentative bits - there's at least one
concrete proposal further down]

You do need to know the exact structure
> of what the Web Service is publishing - but most JSON folks seem to be cool
> with that (in 2011).

But it might have the structure/syntax of the simple examples you
show, or it may have a really complicated structure/syntax, there
isn't any uniformity.

> Each solution that you have proposed breaks this fundamental principle -
> don't muck around with what makes people happy.

I proposed a simple format for RDF-in-JSON that would be suitable e.g.
for the results of SPARQL CONSTRUCT queries. I suggested a way of
generating a minimal graph to serve for a given URI, with an example
of how it might look in JSON. I don't think I've been mucking around
with anything that makes people happy.

> You can't ask JSON developers to start publishing their data with a very
> restrictive structure because /they do not care about RDF or SPARQL or
> Linked Data/ right now. If they believed in it, they would just use TURTLE -
> not JSON.

I agree about not wanting to force RDF on people, but as it stands the
consumer might receive some JSON that's simple or something that's
effectively full RDF.

>> I can't help seeing :
>>
>> (flexible format) = difficult for developers
>
> I reject the statement above - JSON is an incredibly flexible format - it
> isn't difficult for developers. Therefore having a flexible format does not
> automatically mean that it will be difficult for developers.
>
> The statement above doesn't capture the nuance of this issue. If I were
> arguing your point, I'd say:
>
> The flexibility offered by JSON-LD may be difficult for JSON developers
> transitioning from a JSON-only world to a Linked Data world. That is, they
> will need to understand how graphs work.

Right, thanks, "flexible" wasn't the right word. "Unconstrained" might
be closer.

> I would agree with that statement, but luckily, we try very hard to make it
> so that they don't have to make the transition unless they want to do so. If
> they want to care about Linked Data, they're going to have to learn about
> graphs of information.

Well I don't disagree, but I think at the moment it's quite a way from
the sweet spot.

Developers do understand the concept of links, and there's a subset of
the RDF model that's a structure common in most programming languages
- objects with with a set of properties. You can have linked data
without full RDF, in fact the simple JSON-LD examples do a very good
job of expressing this.

But the consumer is currently faced with receiving simple JSON and/or
arbitrary RDF-in-JSON. This isn't a problem in the situations where
there's simple JSON with additional decoration that makes it
RDF-in-JSON, but (as you yourself point out) if it's just full RDF
you're delivering, you might as well just use Turtle.
All we can safely assume about API developers is that they're
reasonably familiar with HTML and Javascript.

>> (framing) = difficult for developers
>
> Again, this does not capture the nuances involved. Which developers?
> JavaScript developers? SPARQL developers? Linked Data developers? Why is
> framing difficult?

All of those developers, because it's a mechanism they don't already use.

Why is query-by-example (which is what framing emulates)
> more difficult than learning a sub-set of SPARQL? Who is your audience?...
> because it doesn't seem like it is JSON developers. The statement above is
> just as spurious as:
>
> SPARQL = difficult for developers, or
> RDF = difficult for developers

I'm using shorthand here, in this context I'd say the above were also
true. If you aren't familiar with a technology then learning it is an
obstacle to using it.

> Most importantly, what are the alternatives to framing that don't break the
> "Don't muck around with what makes people happy." design principle?

Who does framing currently make happy?

> I have yet to see a single proposal that takes both of these concerns into
> account:
>
> 1. Make JSON developers happy.
> 2. Make Linked Data developers happy.
>
> All of what you have proposed thus far arguably achieves #2 - but fails to
> achieve #1.

Ok, fair enough.

At the consumer side (where the JSON aspect is significant) I think
there are two tests of #1 -

* Can the developer understand enough of the structure of the
delivered data to use it by looking at an example?
* Can the developer access the data structure using simple syntax?

So imagine seeing this for the first time, without prior knowledge of
RDF or the JSON-LD spec (from 3.9 Expansion) :

{
   "@context":
   {
      "name": "http://xmlns.com/foaf/0.1/name",
      "homepage": "http://xmlns.com/foaf/0.1/homepage",
      "xsd": "http://www.w3.org/2001/XMLSchema#",
      "@coerce":
      {
         "@iri": ["homepage"]
      }
   },
   "name": "Manu Sporny",
   "homepage": "http://manu.sporny.org/"
}

I think a reasonable response would be : wtf?

Try this as an alternative:

{
   "name": "Manu Sporny",
   "homepage": "http://manu.sporny.org/",
   "@context":
   {
      "name": "http://xmlns.com/foaf/0.1/name",
      "homepage": "http://xmlns.com/foaf/0.1/homepage",
      "xsd": "http://www.w3.org/2001/XMLSchema#",
      "@coerce":
      {
         "@iri": ["homepage"]
      }
   }
}

I see data I can understand and easily access, then wtf? But I can
ignore the wtf? bit.

So there's a concrete proposal for you - put the @context (and
anything else that might look complicated) at the end of the JSON doc.

The only problem with the above example is that it might not be clear
what the the object that has those properties is (/the subject). I'm
not sure how feasible this would be, but what about saying that in
such situations (where there's a bnode in the corresponding RDF), the
type SHOULD be expressed, i.e.

{
   "type": "Person",
   "name": "Manu Sporny",
   "homepage": "http://manu.sporny.org/",
...

Some of the other examples aren't as straightforward to fix against #1, e.g.
(from 3.10 Compaction)

{
   "http://xmlns.com/foaf/0.1/name": "Manu Sporny",
   "http://xmlns.com/foaf/0.1/homepage":
   {
      "@iri": "http://manu.sporny.org/"
   }
}

Even with RDF glasses on I had to look at that a few times to figure
out what it was saying :)
But the compacted version (at least flipped over with the @context at
the end) is straightforward to get data out of - so why have this
version?

The example in 4.1 CURIES is a total wtf? but that isn't so much due
to the CURIES themselves, it's more the proliferation of @keywords. (I
still don't think CURIES are necessary or desirable, but I don't think
it's an issue in the context of #1, "dc:title" can be viewed as a
self-contained property name without looking at the resolution
mechanism).

So I suppose that would be another (less concrete) proposal - try to
keep the @keywords to a minimum/away from the simple property pairs.

For the publisher, the JSON-friendliness isn't an issue, but mapping
from OO-language objects or SQL tables might be.
It wouldn't necessarily need much, e.g. say in 2.3 Linking Data:

[[
We will be using the following JSON markup as the example for the rest
of this section:
...
This might for example correspond to a record in a database table
called "Person".
]]

The other part -

2. Make Linked Data developers happy.

- is pretty similar in what it needs, like saying somewhere the data
describes the person who's URI is http://manu.sporny.org/people#me and
would be appropriate to serve as part of the data at
http://manu.sporny.org/people

Cheers,
Danny.

-- 
http://dannyayers.com

Received on Sunday, 4 September 2011 10:58:52 UTC