W3C home > Mailing lists > Public > public-wai-ert@w3.org > May 2005

Re: correct RDF Re: Locating In EARL Example

From: Charles McCathieNevile <charles@sidar.org>
Date: Sun, 01 May 2005 16:10:26 +0200
To: "Chris Ridpath" <chris.ridpath@utoronto.ca>, public-wai-ert@w3.org
Message-ID: <op.sp3obosmw5l938@pc048.qadoc.oslo.opera.com>

On Wed, 27 Apr 2005 12:50:41 +0200, Chris Ridpath  
<chris.ridpath@utoronto.ca> wrote:

>> This seems feasible to me,except that on the call I think we went in  
>> the directionof definig a class earl:Location (instead of earl:thing in  
>> yur code).
> I've modified the "location" from my previous example so it looks like  
> this:

You have used the class Location, not the property (this is why I think  
they should have distinct names) so this isn't rdfs-valid RDF. But  
otherwise it would be fine.

> <earl:Location>
> <rdf:Bag>
> <rdf:li rdf:parseType="Resource">
> <dc:title>anchor</dc:title>
> I've added a title to describe what the things are instead of using the  
> rdf:about attribute as you suggested. It's valid RDF and I think it  
> means the same as what you suggested.

It means something very different. the rdf:about means you have a URI for  
the statement, so you can make further descriptions somewhere else. The  
title provides some human-readable text describing a resource.  (By the  
way, whenever you have a plain text value you should language tag it with  

> In this example I need to store info about the anchor and the link text  
> because the accessibility test requires that the link text describe the  
> link destination.
> I've created 2 new earl elements called earl:md5 and earl:text but I  
> don't think this is quite right. We're going to need more of these  
> things but I'm not sure how to put them in the location properly.

You need to decide if they are properties or classes (I think you have  
correctly used them as properties here). This comes back to the question  
of whether we want to create a huge list of context things, or if we want  
to create a simple mechanism for defining them, like the one I described  
earlier (label, value). The benefit of doing the latter is that tools at  
least know they are getting some kind of element type. (The alternative is  
to define things as subProperties).



Charles McCathieNevile                      Fundacion Sidar
charles@sidar.org   +61 409 134 136    http://www.sidar.org
Received on Sunday, 1 May 2005 14:10:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:52 UTC