Benchmarking RDF in JSON

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 = '';
  my $FOAF_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

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

Received on Saturday, 12 November 2011 15:18:18 UTC