Re: RDF Stylesheets

On Nov 13, 2007 12:23 PM, Sean B. Palmer <sean@miscoranda.com> wrote:

> And here's how we do it using a GRDDL Stylesheet:

I just noticed a minor bug in my formalisation, and I've been thinking
about some more nifty properties of the RDF Stylesheet mechanism.
(Warning: this message gets quite involved and pedantic; this is not
an *overview* of RDF Stylesheets anymore.)

The bug is that the domain of grddl:transformation is an XPath root
node. So what you'd actually need in the GRDDL Stylesheet would be as
follows:

<> a Stylesheet;
   input [ fn:doc [
     grddl:transformation <.../example.xsl>
] ] .

But to make it simpler there's nothing to stop us coming up with a new
property whereby:

{ ?P fn:doc [ grddl:transformation ?Q ] }
   <=> { ?P :newProperty ?Q } .

If you read my "P.S." on the original message, you may have noticed
that the :input property that I coined uses imperative naming
conventions rather than declarative ones. The appropriate declarative
name might be :styles, as in "the subject styles the object".

<> a Stylesheet;
   styles [
      g:transform <.../example.xsl>
] .

It's actually good that we're using a new property anyway, because
existential quantification possibly doesn't quite cut it here: we
don't want to say "this is a stylesheet that styles at least one
document which has a GRDDL transformation example.xsl". Rather, we
want to say this:

{ ?P stylesheet ?Q .
  ?Q log:semantics [
     log:includes { ?Q styles [ g:transform ?T ] }
  ] } => { ?P fn:doc [ grddl:tranformation ?T ] } .

Again with all variables quantified over the root scope. The
:stylesheet property there is what I mentioned at the top of the email
as wanting to introduce. It formalises the rel="stylesheet" verb, and
it happens to be inverse of :styles:

styles owl:inverseOf stylesheet .

Why the :stylesheet property is useful is not just in formalisation of
how this works, but also in RDF Stylesheet languages, because it means
you can import other stylesheets, a bit like @import in CSS.

<> a Stylesheet;
   styles [ stylesheet <other.rdf> ] .

Where we have the following:

{ ?P stylesheet ?Q .
  ?Q log:semantics [
     log:includes { ?Q styles [ stylesheet ?R ] }
  ] } => { ?P stylesheet ?R } .

Which gives RDF Stylesheet languages (such as the proposed GRDDL
Stylesheet Language) potentially the power of recursion, like CSS has,
and like GRDDL has.

An alternative way of thinking about this is that styles and
stylesheet act on classes of documents which a stylesheet transforms.
The naming starts to get a bit more complicated in that case, but it
might be a better model:

{ ?P h:stylesheet ?Q .
  ?Q log:semantics [
     log:includes { ?Q styles ?C . ?C stylesheet ?R }
  ] } => { ?P a ?C; h:stylesheet ?R } .

Now we have two stylesheet properties. Confused yet? The problem that
I think this would solve is as follows:

Consider, using the instance rather than the class system, that we
have an HTML document with:

   <link rel="stylesheet" type="application/rdf+xml"
      href="http://example.org/alpha.rdf" />
   <link rel="stylesheet" type="application/rdf+xml"
      href="http://example.org/beta.rdf" />

That gives us the following triples in the formalisation mechanism:

<example.html> stylesheet <http://example.org/alpha.rdf> .
<example.html> stylesheet <http://example.org/beta.rdf> .

Let's say that alpha includes only a GRDDL Dublin Core stylesheet, and
beta includes only a GRDDL FOAF stylesheet.

<alpha.rdf> a Stylesheet;
   styles [ stylesheet <dublin-core.rdf> ] .
 - alpha.rdf

<beta.rdf> a Stylesheet;
   styles [ stylesheet <foaf.rdf> ] .
 - beta.rdf

We end up with:

<example.html> stylesheet <dublin-core.rdf> .
<example.html> stylesheet <foaf.rdf> .

Looks fine so far. But this means that we also end up with the following:

<alpha.rdf> a Stylesheet;
   styles <example.html> .
<beta.rdf> a Stylesheet;
   styles <example.html> .

Now consider we have some new input which also uses just *alpha* alone:

<new.html> stylesheet <alpha.rdf> .

In our current store we have:

<alpha.rdf> a Stylesheet;
   styles [  stylesheet <dublin-core.rdf>; stylesheet <foaf.rdf> ] .
<beta.rdf> a Stylesheet;
   styles [  stylesheet <dublin-core.rdf>; stylesheet <foaf.rdf> ] .

Where that bNode matches against <example.html>. Now, this isn't going
to fall afoul of the following:

{ ?P stylesheet ?Q .
  ?Q log:semantics [
     log:includes { ?Q styles [ stylesheet ?R ] }
  ] } => { ?P stylesheet ?R } .

Unless we import all of the triples from ?Q's log:semantics. But if we
did import ?Q's log:semantics, then we'd end up with alpha.rdf
importing both dublin-core.rdf and foaf.rdf. Okay, so we could simply
not import the statements; but this means we're making a closed world
assumption for it to work. Note that the triples which we implied,
even though they're not from alpha.rdf directly, were based on what
alpha.rdf was saying. Even then, I think it's fine to ignore the
authoritativeness of the conclusions given N3Logic's approach to RDF
documents and their semantics, but I'm not sure that people would be
entirely happy with that in general. Something to discuss.

Exercise for those who want to try it: run through the scenario
sketched above but using the classes model (with h:stylesheet being
distinct from :stylesheet), rather than the instances model, to prove
that it fixes the problem.

At any rate this is all very minor formalisation stuff; the general
way that it works, and the benefits, are hopefully quite clear. I'm
just so enchanted by the beauty of the architecture that I wanted to
think quite a bit about the formalisation.

-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Tuesday, 13 November 2007 15:12:47 UTC