Re: Benchmarking RDF in JSON

On Nov 12, 2011, at 7:18 AM, Toby Inkster wrote:

> I'm not talking about benchmarking in terms of "how fast?" but in terms
> of "how easy?". There are a number of different ways of encoding RDF in
> JSON, with specifications at various different levels of maturity. This
> is a simple benchmark to compare how easy they are to work with:
> 
> In your favourite programming language, given an object representing
> the deserialised form of a JSON file, encoded to the specification
> being tested, write a function "name_for_homepage" which takes a URL,
> finds which person (or organisation, etc - I don't care about the
> rdf:type triple) has that URL as their foaf:homepage, and return that
> person's name. Sometimes there will be more than one person with the
> same homepage, or they'll have multiple names. If so, just return a
> single arbitrary result. If there are no results, return null.
> 
> For example, using Talis' RDF/JSON, and Perl, and assuming $data holds
> the deserialized data, we can write the function as follows:
> 
> sub name_for_homepage
> {
>  # Perl's idiom for function arguments
>  my ($homepage) = @_;
> 
>  # Pseudo-constants
>  my $FOAF_HOMEPAGE = 'http://xmlns.com/foaf/0.1/homepage';
>  my $FOAF_NAME     = 'http://xmlns.com/foaf/0.1/name';
> 
>  # Examine each predicate-object list
>  RESOURCE: foreach my $po_list (values %{$data})
>  {
>    # Skip over resources with no foaf:name
>    next RESOURCE unless exists $po_list->{$FOAF_NAME};
> 
>    # Skip over resources which don't have the right homepage URI
>    next RESOURCE unless grep
>      { $_->{value} eq $homepage and $_->{type} eq 'uri' }
>      @{ $po_list->{$FOAF_HOMEPAGE} || [] };
> 
>    # Return the zeroth foaf:name
>    return $data->{$subject}{$FOAF_NAME}[0]{'value'};
>  }
> 
>  # No success.
>  return undef;
> }
> 
> Pretty simple. The problem with many proposed RDF in JSON
> serialisations is that they try to make the JSON look pretty at the
> expense of processing simplicity. For example, add CURIES, and then
> consumers have to add code that expands them. Use nested objects for
> bnodes, and suddenly the code to crawl the structure becomes a lot more
> complex.

I'm not sure I buy this line of reasoning. One of the use cases for JSON-LD is to use contexts and framing to put the data in an easy form to access it through normal JSON object pathing. For instance, if I had data such as the following:

<> foaf:maker [ a foaf:Person; foaf:homepage <http://greggkellogg.net/>; foaf:name "Gregg Kellogg" ],
                          [ a foaf:Person; foaf:homepage <http://tobyinsker.co.uk/>; foaf:name "Toby Insker" ] .

I could serialize this to JSON-LD using consistent identifiers and ordering the data in a way that makes sense for my application:

{
  "@context": "http://example.com/context",
  "@subject": "",
  "maker": [
    {
      "@type": "Person",
      "homepage": "http://greggkellogg.net/",
      "name": "Gregg Kellogg"
    },
    {
      "@type": "Person",
      "homepage": "http://tobyinsker.co.uk/",
      "name": "Toby Insker"
    }
  ]
}

Because I know the hierarchy due to the framing document, and I know the object keys used, because of embedding that information in the context, I can use JavaScript object access (using a bit of jQuery):

function nameForHomePage(homepage, data) {
  return $.grep(data["maker"], function(person, ndx) {
    return ( person["name"] && person["homepage"] ) ;
  }).shift;
};

Another nice benefit, it's purely functional with no variable usage. It looks for the presence of foaf:person and foaf:homepage, but doesn't look for well-formedness of the foaf:homepage IRI; this is left as an exercise for the reader, if necessary.

Also, this could be done with an array representation, without using a foaf:maker, but this still requires some form of key in order to make use of a global context, an alternative representation might be:

{
  "@context": "http://example.com/context",
  "@subject":  [
    {
      "@type": "Person",
      "homepage": "http://greggkellogg.net/",
      "name": "Gregg Kellogg"
    },
    {
      "@type": "Person",
      "homepage": "http://tobyinsker.co.uk/",
      "name": "Toby Insker"
    }
  ]
}

JSON-LD framing actually allows you to massage the data into the easiest format for you to access it naturally; which is one of the use cases driving it's development.

Gregg


> So my challenge to other JSON serialisations is to make
> name_for_homepage simpler (or at least not require it to become any
> more complex). Are there any contenders?
> 
> -- 
> Toby A Inkster
> <mailto:mail@tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
> 
>

Received on Saturday, 12 November 2011 18:41:59 UTC