W3C home > Mailing lists > Public > public-wai-ert@w3.org > October 2006

usage of uri:uri

From: Shadi Abou-Zahra <shadi@w3.org>
Date: Mon, 30 Oct 2006 17:34:07 +0100
Message-ID: <4546297F.3080900@w3.org>
To: public-wai-ert@w3.org

Hi group,

Originally we had proposed to introduce a uri:uri property for the
earl:WebContent. The idea was to record at least the URI of a Web
resource in case http:Request and http:Response are not recorded (as
well as to simplify queries for a resource).

Later we thought about using rdf:about instead of uri:uri. However, this
only works well for *unique* Web resources. For example, on a local Web
server ( or on a private network (
etc, the URI of resources can quickly become ambiguous.

On a side note, this is the same issue that emerges in the FileContent
class. For example "file://c:/file.html" is ambiguous outside the local
context of the specific system.

For this reason, we discussed keeping the uri:uri property on the last
call. Each instance of a WebContent (or FileContent) class should
receive a unique and unambiguous ID using rdf:ID (or rdf:about where
applicable). The uri:uri stores the location of the resource but is not
an ID for the RDF class. Many "normal" Web resources will have the same
value for the rdf:about and the uri:uri properties.

Note: the current proposal is that earl:filename will be sub property of
uri:uri and is to be used in the earl:FileContent class.

Are there any comments, thoughts, or issues with any of the above?


Shadi Abou-Zahra     Web Accessibility Specialist for Europe |
Chair & Staff Contact for the Evaluation and Repair Tools WG |
World Wide Web Consortium (W3C)           http://www.w3.org/ |
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ |
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ |
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ |
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France |
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |
Received on Monday, 30 October 2006 16:35:49 UTC

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