Re: Why Framing and Normalization

On Sep 4, 2011, at 3:58 AM, Danny Ayers wrote:

> On 4 September 2011 05:04, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> ...
> 
> 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, the gist of your proposal is to display the @context bit at the end of the object? If so, this is a simple editorial change. This is an associative array, after all, so key order is not significant from a JSON perspective, neither is it important in the RDF conversion algorithm.

Also, note that most (many?) examples use @context as an IRI, not an embedded structure. Even if the order didn't really change, would the following be as confusing?

{
  "@context": "http://example.org/json-ld-contexts/person",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/"
}

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

To simplify cases like this, we could consider using a pattern to determine values that are intended to be IRIs (or prefixed names). This would pretty much remove the need to use {"@iri": "…" } in most cases. If the text said that values are matched against against a pattern matching NCNAME followed by ':' followed by anything else are treated as an IRI (or a prefixed-name, if NCNAME matches a defined term), this would solve most uses. However, it would leave us with cases where something that looks like an IRI is intended to be a literal, which would need to be represented as {"@literal": "http://manu.sporny.org/"}, but this might not be as confusing.

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

Perhaps starting 4.1 with a simpler example would help, how about the following:

{
    "@type": "foaf:Person",
    "foaf:name": "Manu Sporny",
    "foaf:homepage": "http://manu.sporny.org/",
    "foaf:avatar": "http://twitter.com/about/profile_image/manusporny",
    "foaf:address": {
        "@type": "schema:Place",
        "schema:addressLocality": "Blacksburg",
        "schema:Region": "VA"
    }
}

> 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 17:14:14 UTC