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

RDF/A simplification proposal

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Mon, 01 Nov 2004 09:00:22 +0000
Message-ID: <4185FB26.3000309@hplb.hpl.hp.com>
To: public-rdf-in-xhtml-tf@w3.org



I fixed the whitespace bug and my latest implementation of RDF/A is
http://lists.w3.org/Archives/Public/www-archive/2004Nov/0000

I also had a go at trying to make a concrete proposal to how to improve 
RDF/A on the complexity front (i.e. how to simplify some of the rules)
This too is implemented and is at

http://lists.w3.org/Archives/Public/www-archive/2004Nov/0001

The idea is that (except when using rdf:nodeID) simple triples behave 
the same (i.e. if subject predicate and object are all explicit in an 
element). In this message I will call the simplified proposal RDF/ABC.

However the way that parents and children interact is different, and is 
loosely  based on adobe's XMP subset of RDF/XML (RDF minus seven).

One or two examples:


<link about="#subj" rel="eg:prop>
    <meta about="#subj2" property="dc:creator" content="jjc"/>
</link>

RDF/A:
<#subj2> dc:creator "jjc".
<#subj> eg:prop <#subj2> .

RDF/ABC
<#subj2> dc:creator "jjc".
<#subj> eg:prop _:a .


In RDF/A and RDF/ABC we have the meta element producing a triple

<#subj2> dc:creator "jjc".

In RDF/A the link element has no object specified, and so it takes the 
subject of its child(ren) and propduces a triple for each one, so we get:

<#subj> eg:prop <#subj2> .

In RDF/ABC, the link element has no object specified and so we gensym 
one and get:

<#subj> eg:prop _:a .

Since the meta statement is a global statement it does not interact with 
this triple (in RDF/ABC).

If we change the example to be:

<link about="#subj" rel="eg:prop>
    <meta property="dc:creator" content="jjc"/>
</link>
RDF/A:
<#subj> dc:creator "jjc".
<#subj> eg:prop <#subj> .

RDF/ABC
<#subj> eg:prop _:a .
_:a dc:creator "jjc".

In RDF/A the meta element has no explicit subject, and so it inherits 
the subject from its parent and we get

<#subj> dc:creator "jjc" .
The link element has no explicit object, and so it takes the subject of 
its child, since its child has no explicit subject, that is inherited 
from the parent and we get

<#subj> eg:prop <#subj> .

In RDF/ABC the link element is treated as before to give:

<#subj> eg:prop _:a .

The meta element, since it has no explicit subject, is seen as 
qualifying the *object* of its parent (if any object specified or 
implied) and so we get

_:a dc:creator "jjc" .


Final example

<p id="foo">
    <link property="dc:creator" content="jjc"/>
</p>

In both RDF/A and RDF/ABC we get

<#foo> dc:creator "jjc" .

In RDF/A the subject is inherited from parent.
In RDF/ABC since the parent has no object (explicit or specified), we 
see the qualifying statement as qualifying the subject identified by the 
parent.

===

nodeID in RDF/A identifies subjects, nodeID in rdf/ABC identifies objects.

So in RDF/ABC to say

_:a eg:foo _:a .

We have to do e.g.

<link nodeID="a">
    <link rel="eg:foo" nodeID="a"/>
</link>

In RDF/A we can achieve the same by

<link nodeID="a" rel="eg:foo">
    <link rel="ignore-me"/>
</link>

The object of the parent is given as the subject of the child which is 
inherited from the parent. The rel on the child does not generate any 
triples but does ensure that RDF/A processing is done on the child.
I believe that without that attribute the example produces no triples in 
  RDF/A.

====

RDF/ABC summary

global statements with subjects do not interact with their parent.

qualifying statements without subjects should be read as
"which ...."
If parent has object then the "which ...." is modifying object; if 
parent does not have object, then the "which ..." is modifying subject.


On a fairly simplistic measure the complexity is reduced from 432 triple 
patterns to 152 triple patterns, and I have added additional literal 
handling rules as we discussed at Friday's telecon.

A triple pattern is an XPath expression that can be used to extract a 
triple.

Jeremy
Received on Monday, 1 November 2004 09:00:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:59 GMT