- From: Sean B. Palmer <sean@miscoranda.com>
- Date: Tue, 13 Nov 2007 15:12:27 +0000
- To: semantic-web@w3.org
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