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

Re: Named Graphs in RDFa

From: Dan Brickley <danbri@danbri.org>
Date: Sun, 01 Feb 2009 10:17:48 +0100
Message-ID: <498568BC.5060503@danbri.org>
To: Michael Hausenblas <michael.hausenblas@deri.org>
Cc: Toby A Inkster <tai@g5n.co.uk>, RDFa <public-rdf-in-xhtml-tf@w3.org>, Kjetil Kjernsmo <kjetil@kjernsmo.net>

Hi all

Interesting thread!

I think I have a use case for this around FOAF+OpenID...

On 1/2/09 08:43, Michael Hausenblas wrote:

> I think [1] this is a valuable contribution. However, I'm having
> difficulties the design decision 5.2 understanding:
> 'No new attributes added to XHTML+RDFa 1.0. To markup graphs a new attribute
> is required, but this document does not define what that attribute is
> called. Instead the producer and consumer of an XHTML document must come to
> a private agreement as to which attribute is used. Markup language
> specifications that decide to adopt the techniques described in this
> document may define such an attribute for usage in that particular
> language.'
> You rightly conclude that we very likely need a new attribute but then state
> that 'this document does not define what that attribute is called'. Hm. I
> think this is too much relying on a convergent market. I can't see how this
> should scale.

It would be nice to have agreement on the attribute, for sure. Just as 
it is nice to know where namespace prefixes come from, etc. However it 
is probably smart to separate the core architectural discussion from any 
threads whose substance amounts to "why should we add any xyz attribute 
to (X)HTML? What a crazy name!" ...

The attribute naming can be sorted out separately.

> [1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Dec/0104.html
> [2] http://esw.w3.org/topic/RDFa_vs_RDFXML

 From Toby:

 > http://buzzword.org.uk/2009/rdfa4/spec
 > Essentially it allows you to divide the usual RDFa output into
 > multiple named graphs.
 > What do people think? Is this useful? Are there better ways of
 > accomplishing it?

Here's a use case, perhaps. I have been thinking about the common case 
of Web site accounts where the content on a profile page is a mix of 
markup whose (un-mediated) content is supplied more or less by the end 
user, and content that comes in some way from the service provide. For 
example, Advogato make available FOAF profiles. The RDF claims about 
name, homepage etc come from you, the bit about the category you are in 
(journeyer, master, beginner or whatever) come from advogato.

Toby, Kjetil, anyone, ... care to try reworking this example to use RDFa 
Quads? (RDFaQ?).

I'll definitely bear this work in mind as a look into signed RDFa...

BTW one argument for getting an agreed attribute name, is that Web-scale 
search engines will need a very cheap test that they can apply before 
deciding to run a full RDFa+Q parser over a document. Maybe eventually 
any RDFa parser will do this, but it should be kept in mind when 
thinking about adoption paths...




Now when we have a flat set of triples without these different streams 
separated out, there is a need I think to figure out who-said-what. I 
believe this can be done with per-site templates.

For examples, see http://svn.foaf-project.org/foaftown/2009/headstream/

Here, the idea is that we *don't* have named graphs in the original 
mixed-source profile, so we need something (i've code named it 
headstream) that indicates which claims have been checked/supplied by 
the service. I use SPARQL CONSTRUCT as a way of stripping those out.

eg. if you apply this SPARQL, 
... to my Advogato FOAF file, 
http://www.advogato.org/person/danbri/foaf.rdf you get just the 4 
triples that come from the service provider: 

Perhaps this distinction could be marked up directly in RDFa+Named Graphs?



ps. re attribute naming, to most HTML authors, I think 'graph' will 
suggest something like diagram, picture, chart. And the word source is 
very much taken already ('src').
Received on Sunday, 1 February 2009 09:18:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:30 UTC