Re: Named Graphs in RDFa

On 1 Feb 2009, at 09:17, Dan Brickley wrote:

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


The basic idea would be along the lines of:

<link about="_:advograph" rel="foaf:maker" resource="http:// 
advogato.org/#us" />
<link about="_:megraph" rel="foaf:maker" resource="http:// 
advogato.org/someuser#me" />

<p about="#me">
   <a property="foaf:name" rel="foaf:homepage" graph="_:megraph"
   href="http://someuser.example.com/">Some User</span>
   (<span property="a:category" graph="_:advograph">master</div>)
</p>

Because foaf:name and foaf:homepage are on the same element, they  
can't be part of different graphs, but that could be worked around like:

   <span property="foaf:name" datatype="" graph="_:graph1"><a
   rel="foaf:homepage" graph="_:graph2"
   href="http://someuser.example.com/">Some User</span></a>

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

A named graphs parser should not be significantly slower than a  
standard RDFa parser written in the same programming language. If you  
take a look at section 4 of the draft, you'll see that the  
modifications to the standard algorithm are only minor, so don't add  
very much extra processing.

Because of the design decisions employed, if you parse a document  
that does not use named graphs in a named graphs processor, you find  
that all the triples simply end up in the default graph. There is no  
need to go down one parsing route for named graph documents and  
another for standard documents.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Sunday, 1 February 2009 09:42:40 UTC