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:m...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
