W3C home > Mailing lists > Public > public-swbp-wg@w3.org > February 2006

RE: [HTML] comments on RDF/A primer

From: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Fri, 3 Feb 2006 23:57:53 -0500
Message-ID: <A5EEF5A4F0F0FD4DBA33093A0B075590097B6821@tayexc18.americas.cpqcorp.net>
To: "Miles, AJ (Alistair)" <A.J.Miles@rl.ac.uk>, <public-swbp-wg@w3.org>

Re: http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0113.html

Alistair,

I just reread the specific examples of URI usage that you called out as
problematic, and on more careful reading against the ontologies that
they use (foaf, dc), I do not see a conflict with dc.  I only see the
issue with foaf.  More below.

> Minor stylistic comment: I suggest the code examples 
> containing HTML and the code examples containing triples be 
> given in different colours, or some other way of telling them 
> easily apart at a glance.

Yes, please!  

> 
>  -- Comment 1. Use of dc:creator --
> 
> One of the triples embedded in the example in section [3.1 
> Literal Properties] is:
> 
> <> dc:creator "Mark Birbeck"^^XMLLiteral .
> 
> One of the triples embedded in the example in section [3.2 
> URI Properties] is:
> 
> <> dc:creator </user/markb> .
> 
> ... where the resource </user/markb> is 'user-profile page 
> for [Mark Birkbeck], a page that summarizes all of his albums 
> and user profile information for others to see.'
> 
> Although these usages of the dc:creator property are not 
> inconsistent with much current practice, I do not believe 
> either usage is consistent with the current definition of 
> dc:creator [2], which is: 'An entity primarily responsible 
> for making the content of the resource.' It does not make 
> sense for either an XML Literal, or another web page, to be 
> the 'entity primarily responsible for making' the web page.

The dc:creator documentation[2] also says: "Typically, the name of a
Creator should be used to indicate the entity."  This suggests to me
that the use of an XML Literal "Mark Birbeck" is entirely acceptable in
that ontology.  In other words, dc:creator is not rigidly constraining
how the creator should be identified.  Even an ambiguous identifier,
such as a person's name, seems acceptable.  Given this latitude,
/user/markb also seems to me to be within the intent of the ontology.

> . . .
> Furthermore, the example from section [3.2 URI Properties] 
> does not help to avoid practices that lead to URI collision, 
> because it implicitly suggests the use of the URI of a web 
> page as an identifier for the person described by the web page. 

I think the foaf examples may be using the same URI for both a web page
(or location on that page) and the foaf:Person it describes.  However, I
now think a much milder warning (if any) about this is in order.

> The example in the section [4.3 Qualifying Chunks of 
> Documents] generates the following triple:
> 
> </user/markb/photo/23456> shutr:takenWith 
> </user/markb/cameras#nikon_d200>
> 
> Firstly, this is missing a full stop.
> 
> Secondly, the URI </user/markb/cameras#nikon_d200> denotes an 
> element in an XHTML document.

Whether that is a potential problem depends on the shutr ontology.  If
that ontology is using the Shadow-Ontology approach[5] to indirect
identification, then there is no problem with
</user/markb/cameras#nikon_d200> denoting an XHTML document (or location
therein).  The interpretation of the triple would be something like:
"The photo at </user/markb/photo/23456> was taken with the camera
described at </user/markb/cameras#nikon_d200>".

David Booth
 
> [1] 
> http://www.w3.org/2001/sw/BestPractices/HTML/2006-01-15-rdfa-primer
> [2] http://dublincore.org/documents/2005/06/13/dcmi-terms/#creator
> [3] http://www.w3.org/TR/2004/REC-webarch-20041215/#media-type-fragid
> [4] http://www.ietf.org/rfc/rfc3236.txt

[5] Shadow-Ontology approach to indirect identification:
http://lists.w3.org/Archives/Public/public-swbp-wg/2006Jan/0171
Received on Saturday, 4 February 2006 04:58:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:46 UTC