W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > February 2009

Re: Named Graphs in RDFa

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Sun, 1 Feb 2009 23:10:55 +0000
Message-ID: <ed77aa9f0902011510u20c1be2ei5a020cf300443fe@mail.gmail.com>
To: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Cc: RDFa <public-rdf-in-xhtml-tf@w3.org>

Hi Kjetil,

I'm not convinced that named graphs are required to support the
use-case that you describe, and I'd like to show another approach to
templating that doesn't require them.

But also, I think on a more theoretical level that there are problems
with allowing an HTML+RDFa document to contain information that
applies to multiple named graphs.

I'd like to look at both issues, but I'll begin with the second.


NAMED GRAPHS

My RDFa library [1] contains a module that processes what I've called
jSPARQL. It's basically SPARQL expressed in JSON, and the query
results are also JSON.

The library has supported named graphs at the API level for a while
now, meaning that it's possible to insert triples into various graphs,
and then query selectively across those graphs.

But the only way this is manifest at the RDFa document level is that
the URI of the document becomes the named graph.

The reason I chose *not* to reflect the support for named graphs at
the mark-up level, is illustrated by a feature that I'd like to
implement, and which I'm sure would be applicable to others.

I'm working on using local storage to capture triples that are
retrieved from documents, whilst browsing the web, and the approach is
to store the triples in a named graph that uses the document's URI as
the name. This means that the next time I navigate to that URL, all I
have to do is to delete the named graph, then parse the document, and
insert the triples again; I don't have to worry that there may be
other triples floating around that are now 'incorrect'.

This might seem like a mere implementation detail, but it's not. In a
sense, the HTML+RDFa document is itself a graph, in that it's a
collection of triples. However, if you start allowing graphs to
contain triples about other graphs, you have to start tracking where
those triples came from. This is because a named graph (as stored)
could end up containing information that actually came from a variety
of sources.

So I'm keen to see us preserve a one-to-one mapping between an
HTML+RDFa document and a named graph.

Note, by the way, that the act of creating a named graph is the
processor's, so we can still obtain further graphs when we parse other
information -- just not directly in the mark-up.

For example, in my parser, any predicate named 'libxh:include' causes
the document identified by the object to be read and parsed. Since the
parser always creates a graph by the name of the target document, then
this will read the triples into its own named store. This could easily
be fixed to be more standard, such as using 'owl:imports', but the
point here is that the named graph aspect is 'external' to the basic
act of parsing.

And when querying, if you don't specify a graph name you are
effectively querying _all_ graphs, which means that these 'imported'
triples will be available just as if they were in the original
document.

Anyway, although the jury might still be out on named graph support in
the document itself, what I'd like to discuss next is whether
templating support actually requires named graphs.


TEMPLATING

I'm really excited to see the proposals you've made on templating, but
perhaps I can explain the approach I've taken to the questions that
you have raised, to show how I don't think you need named graphs to do
what you want.

In the library I mentioned, I've taken an approach to templating that
is based on Fresnel [2]. To be brutally honest, I think Fresnel is a
bit over-complicated :), but I felt that since it already existed, it
would probably make sense to start with that, and then add things as
it became clear what else was needed.

As you're probably aware, the Fresnel format contains a set of RDF
that describes rules such as 'given an item of this type, add this CSS
class'. This works quite nicely with RDFa because any triples that are
queried from an RDFa document have a definite location. For example,
if you have:

  <div typeof="foaf:Person">
    ...
  </div>

then querying for all items of type 'foaf:Person" leads naturally to
the div that contains the RDFa, making it easy to set a CSS class on
it.

An example in a tutorial on the wiki [2] looks like this:

  <p>
    Welcome to my blog. I have lots of things to say, but before I do, let me
    tell you that I have
    <span about="#bike" xmlns:ebay="http://ebay.com/"
      property="ebay:item" content="120245313159"
    >a bike for sale</span>.
  </p>

You can see that the 'location' of the bike that is for sale -- in the
sense of a DOM location -- is the 'span'. This makes it easy to say
something like 'all eBay items should have a yellow background'. Using
Fresnel, that would look like this:

  :ebayGroup rdf:type fresnel:Group ;

  :ebayFormat rdf:type fresnel:Format ;
    fresnel:group :ebayGroup ;
    fresnel:propertyFormatDomain ebay:item ;
    fresnel:valueStyle "ebay-item"^^fresnel:styleClass  .

For those not familiar with Fresnel, this simply says:

  we have a Group of Formats, and one of those formats says, find
  the items that have a property of ebay:item, and then apply the
  CSS class 'ebay-item' to them.

My library doesn't have a full implementation of Fresnel, and at the
moment all selections are made with something I've called jSPARQL --
SPARQL queries expressed in JSON, and returning JSON -- but the
essential structure for doing templates is there.

So, the Fresnel example I just gave would be expressed in RDFa (and
jSPARQL), like this:

  <div
   xmlns:fresnel="http://www.w3.org/2004/09/fresnel#"
   typeof="fresnel:Group"
   style="display: none;"
  >
    <div rev="fresnel:group">
      <div typeof="fresnel:Format">
        <div property="fresnel:instanceFormatDomain">
          select: [ "s", "item" ],
          where:
          [
            { pattern: [ "?s", "http://ebay.com/item", "?item" ],
setUserData: true }
          ]
        </div>

        <span property="fresnel:resourceStyle"
datatype="fresnel:styleClass">ebay-item</span>
      </div>
    </div>
  </div>

Note that this is in the same document as the data itself, and for the
reasons I gave in the first part of this email, I think that it is
correct that the formats and the data end up in the same named graph.
All that happens is that after the RDFa parser finishes parsing the
document, it then starts to 'do stuff' with the data. It runs a query
on the extracted triples to find things like external files to include
and Fresnel rules. For the latter it then runs each of the 'formats'
in turn, first querying for data and then 'applying' the rules to
whatever data it finds.

Of course, because we can query across all graphs, the model I'm using
also allows for 'built-in' Fresnel rules which might come from a local
store, for example, in much the same way that you can have
personalised stylesheets in browsers.

I've added rules that are more action-oriented than the Fresnel rules,
such as obtaining further triples from a web-service like Amazon,
Twitter or eBay. This allows for interesting things like geo-coding a
document or retrieving Twitter tweets.

Continuing the eBay example, to create a tooltip that contains the
eBay-supplied widget that corresponds to your eBay item, all you need
to do is to add this to the Fresnel format :

  <div rel="libxh:tooltip" xmlns:libxh="http://lib-xh.googlecode.com/">
    <div property="libxh:template" datatype="rdf:XMLLiteral">
      <object width="355" height="300">
        <param name="movie"
value="http://togo.ebay.com/togo/togo.swf?2008013100" />
        <param name="flashvars"
value="base=http://togo.ebay.com/togo/&amp;lang=en-us&amp;mode=normal&amp;itemid=${item.content}&amp;query=track%20bike"
/>
        <embed src="http://togo.ebay.com/togo/togo.swf?2008013100"
type="application/x-shockwave-flash" width="355" height="300"
          flashvars="base=http://togo.ebay.com/togo/&amp;lang=en-us&amp;mode=normal&amp;itemid=${item.content}&amp;query=track%20bike"></embed>
      </object>
    </div>
  </div>

Note the use of items like this:

  ${item.content}

which allows us to use the data that came back from the jSPARQL query
in the template.

As you can imagine this is pretty powerful, because all an author now
has to do to get the eBay widget in their blog is this [2]:

  Now I think about it, I've also got
  <span about="#boat" xmlns:ebay="http://ebay.com/"
   property="ebay:item" content="170225336431"
  >a speedboat</span>
  and
  <span about="#castle" xmlns:ebay="http://ebay.com/"
   property="ebay:item" content="28022772250"
  >a castle for sale</span>.

The mere presence of a @property of 'ebay:item' and a value in
@content gets the full widget inserted into the document.

Anyway, the key point I'm driving at here is that there is no need to
keep the templating rules separate from the main document's graph,
since they are part and parcel of it. They are much like CSS rules, in
that they operate on the DOM, but they use semantic selectors, rather
than DOM selectors. All that is required is to use various predicates
as the trigger for what to do, rather than segmenting things with
named graphs.

As it happens, in most of my demos I place these rules into separate
documents so that they can be used many times over -- they are
imported using the 'libxh:include' technique I described earlier --
and the named graph aspect is implicit.


MORE DEMOS

I gave a Google Tech Talk on RDFa in May last year:

  <http://webbackplane.com/node/50>

and the video shows a lot of demos of this kind of code in action, such as:

  * book covers obtained from Amazon, using ISBN numbers in
    the RDFa;

  * chemical compound diagrams added as tooltips next to the
    mention of a chemical;

  * using FOAF information to retrieve the latest tweets from a
    list of people that is expressed inline [4];

  * formatting of calendar information;

and more.

You can also find some geo-coding examples on the webBackplane site,
which make use of templates stored as Drupal nodes:

  <http://webbackplane.com/node/63>

Regards,

Mark

[1] <http://ubiquity-rdfa.googlecode.com/>
[2] See <http://simile.mit.edu/wiki/Fresnel> and
<http://www.w3.org/2005/04/fresnel-info/manual/>.
[3] For the full tutorial see
<http://code.google.com/p/ubiquity-rdfa/wiki/TutorialIntroduction>.
[4] Linking directly to this one, because I quite like it :):
<http://ubiquity-rdfa.googlecode.com/svn/trunk/_samples/blog-twitter.html>

On Sun, Feb 1, 2009 at 11:06 AM, Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote:
>
> On Sunday 01 February 2009, you wrote:
>> Hi all,
>>
>> This is an idea that Kjetil Kjernsmo and I have been looking at for a
>> couple of weeks:
>>
>> http://buzzword.org.uk/2009/rdfa4/spec
>
> Thanks for posting, Toby!
>
> The reason why I started to think about this is that I lay awake one
> night thinking about the pains we've had with XSLTing RDF. It should be
> possible to create a HTML-near templating language. And RDFa is
> HTML-near, here we go: "RDFa Templates":
>
> http://www.kjetil.kjernsmo.net/software/rat/
>
> Basically, the idea is to use the RDF graph encoded in section of an
> RDFa document in the SPARQL WHERE clause. Additionally, I wanted to do
> this with minimal changes to parsers so that XML, RDF and RDFa tools
> could be used pretty much as they are. If any extension would be added,
> it should use the concepts we allready have.
>
> The idea I came up with was the name this section so that it would
> become a named graph. Thus, when the document is parsed, I could have a
> hash that would have the graph name URI as they key and the
> corresponding RDF graph as the value.
>
> So, my next thought was then "since the graph is now detached from the
> document it was in, how do I identify where it came from?" My answer
> was to use xml:id to name the graph, thus, the full graph name would be
> the URI of the document with the content of the xml:id attribute as a
> fragment identifier.
>
> Then, the template builder would just need to get the fragment
> identifier from the graph name, then $dom->getElementById($fragment)
> and I would have all I need.
>
> Toby has several good arguments why xml:id might not be such a good
> idea, importantly its use in SVG, but I also feel that there should be
> an attribute that one can rely on. I saw that this was Michael's first
> reaction to Toby's draft too, so I'll address that in that thread.
>
> My main use case right now is this: Get as easy access to the XML that
> surrounds the graph as possible, and that seems to be by using
> $dom->getElementByID. However, I understand that one can define an
> attribute to be an ID in a schema, so we could in principle define our
> own for this purpose.
>
> Cheers,
>
> Kjetil
> --
> Kjetil Kjernsmo
> Programmer / Astrophysicist / Ski-orienteer / Orienteer / Mountaineer
> kjetil@kjernsmo.net
> Homepage: http://www.kjetil.kjernsmo.net/     OpenPGP KeyID: 6A6A0BBC
>
>



-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Sunday, 1 February 2009 23:11:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 1 February 2009 23:11:37 GMT