Re: ACTION-363 - XRD correspondence with RDF

On Fri, 2009-12-18 at 10:19 -0500, Tim Berners-Lee wrote:
> Nice.  I don't really like the reification, though.

Reification is only performed to cover one specific XRD construction,
and that's:

<XRD>
  <Subject>http://example.com/subject</Subject>
  <Link rel="http://example.com/predicate"
        href="http://example.com/object">
    <Property type="http://example.com/predicate2">Object2</Property>
  </Link>
</XRD>

That is, a <Property> element inside a <Link> element. This is supposed
to modify the semantic of the triple as a whole, according to the XRD
draft spec. In fact, what it means is closer to this N3:

  ex:subject
    [ rdfs:subPropertyOf ex:predicate ; ex:predicate2 "Object2" ]
      ex:object .

But as RDF doesn't support bnode predicates, and as I didn't want to
mint throwaway URIs to replace the bnode, I implemented it as:

  ex:subject ex:predicate ex:object .
  [] a rdf:Statement;
     rdf:subject ex:subject ;
     rdf:predicate ex:predicate ;
     rdf:object ex:object ;
     ex:predicate2 "Object2" .

So you get a reified triple plus an unreified one. If there is no
<Property> element inside the <Link> then the reified triple isn't
created.

That having been said, I haven't seen <Property> elements inside <Link>
elements outside of examples in the draft XRD spec, so I don't think
it's a situation that's going to arise often. The only reason the
example I posted to this list contained so many reified statements is
because I've been tweaking how these are handled recently, and just
picked one of my recent test cases to post here.

> What about converting it to the POWDER-S ontology for the link URI
> patterns and suchlike? POWER is (a W3C Rec) designed for this case. I
> haven't looked at how well they map but the use cases are more or less
> teh same and they have ways of saying what the.

Yep - I'm aware of POWDER. It's probably feasible. I'm not sure if it
might end up making the conversion a "deeper" ontology that I'd hoped.
For example, it would be easy to convert a link element to something
like:

 [] a xrd:Link ;
    xrd:from <foo> ;
    xrd:to <baz> ;
    xrd:rel xhv:next ;
    xrd:type [ a xrd:MediaType ; xrd:value "text/html" ] .

But I prefer to keep it as shallow as possible:

 <foo> xhv:next <baz> .
 <baz> dcterms:format <http://....../text/html> .

My current solution for URI templates isn't pretty, but it is easy - not
just easy for me to implement, but hopefully also easy for people using
the converter to consume. I'm already using the parser to power my
WWW::Finger implementation of WebFinger. With one line of code I can
parse an XRD host-meta file into something I can SPARQL to pull out URI
templates.

  $model  = XRD::Parser->hostmeta('gmail.com')->consume->graph;
  $query  = RDF::Query->new('SELECT * ...');
  $result = $query->execute($model);

POWDER might be a win for URI templates though. Given that XRD::Parser
is a library for programmers to use rather than an end-user tool,
there's probably nothing wrong with offering both options and letting
the code calling the parser choose. TIMTOWTDI.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Friday, 18 December 2009 22:50:17 UTC