Re: Named Graphs in RDFa

On Monday 02 February 2009, you wrote:
> Hi Kjetil,

Hi Mark! Thanks for the insightful comments, and sorry for taking so 
long to respond. 

> 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.

I'm all ears!

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

Right! 

I think this is valuable too, and so I finally got around to actually 
read the excellent spec and found that it mandates a single default 
graph, and I would not suggest that this is changed, as it would break 
both this useful feature and backwards compatibility. Thus, we are 
suggesting that the triples are in the named graphs in *addition* to 
the to the default graph.

The main argument against this approach is duplication of data, but that 
is a minor thing compared to the potential usefulness of the approach.


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

Sure, but that we say they need to be in both graphs takes care of that, 
right? 

> 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.

Yeah, we also looked at Fresnel, and we came to the opposite 
conclusion. :-) 

To explain where I come from: We do mostly ontology engineering, big-O 
and little-o, reasoning, SKOS thesauri, search and that kind of stuff. 
The web work we do is currently trivial, thus it is not where we'd like 
to spend time, and moreover, we'd like to give the styling to someone 
else in the company, who might be good at CSS and know a little XSLT, 
but we're not there yet. 

I suspect that we might have this in common with some web developers who 
only wants to use a bit of data of the Semantic Web with their 
relatively simple web pages.

So, if visualization was important to me, I'd certainly go with Fresnel, 
and I think I might find use for the full complexity of it. I've been 
advocating that we pick up Fresnel for a long time, but it was hard to 
sell. Not the least because it meant that a designer, who we'd might 
use for styling the site, would need to learn it in addition to CSS. 
So, I was thinking in terms of "as simple as possible, but not simpler" 
(I'm no fan of KISS, because it tends to result in things that doesn't 
do the job).  

A solution that could let me write the HTML and the designer CSS, would 
be the right tool for the job right now. Again, if I was writing 
something more advanced, where the designer should control the HTML too 
would require a Separation of Concerns regime that would make my RDFa 
Template proposal the wrong tool for the job. 

> 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.

Right, but we have some examples that different foaf:Person's should be 
treated very differently in our apps. 

> 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>

I see! But I feel that this is a lot further from RDFa than my proposal. 
You'd have to understand SPARQL and jSPARQL much deeper to actually use 
it, than just use a bit of XML and there you go. Also, it has a lot 
more implementation infrastructure behind it. I was also thinking along 
those lines for an XSLT-like RDF transformation language, but I 
rejected it. If I required that much knowledge about the data, I'd use 
some kind of ontology class-OO class mapper and do the work in the 
application View. 

But again, that's the thing I would do in an application that had 
complex requirements for the Web interface. My current use is for the 
applications that only requires a very simple Web interface.




> 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.

Sure! As stated, there is no conflict with the proposal. 

> 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.

Hmmmm, I don't feel you quite demonstrated this...

Importantly, the same predicates in different parts of the document 
could be used in very different ways. So, I'd have to at least use 
a "triple fingerprinting" to resolve such problems, I without having 
tried, I think that too would fail. For example, in some uses, we have 
a foaf:Person that in one case is an author and in one case is the 
audience. They are known as different to the page author, thus 
identifying them with different named graphs would be trivial, but 
their data structure is identical. And the implementation complexity 
would be much larger, I fear, and I'm out for something that's really 
simple to implement. 

Well, to sum up, my key point is that at this point, it is important to 
have several different approaches flourish. I can certainly see that 
yours have a very important use (though I would do more in the View and 
not inline (j)SPARQL in the page), but I still feel that it is not the 
right solution for us, and also too complex for many web developers 
just out to get a little data from the Semantic Web into his 
application. 

Certainly, one day, all lenses that will ever be needed are written, 
which will change the picture, but up to then, I think several 
directions should be left open.

Cheers,

Kjetil
-- 
Kjetil Kjernsmo
Programmer / Astrophysicist / Ski-orienteer / Orienteer / Mountaineer
kjetil@kjernsmo.net
Homepage: http://www.kjetil.kjernsmo.net/     OpenPGP KeyID: 6A6A0BBC

Received on Sunday, 8 February 2009 23:17:17 UTC