[foaf-dev] beyond foaf:mbox_sha1sum

Steve Harris steve.harris at garlik.com
Tue Dec 22 15:39:44 CET 2009

On 22 Dec 2009, at 14:26, Norman Gray wrote:
> Steve and Mischa, hello.
> On 2009 Dec 22, at 13:13, Steve Harris wrote:
>> On 22 Dec 2009, at 12:55, Norman Gray wrote:
>>> Warning. The use of domain URI without a trailing slash, the  
>>> convention as per http examples states that : http:// 
>>> www.google.com is not sociable and should have a trailing slash
>>> I've never heard of this convention, or of the idea that a URI is  
>>> or is not 'sociable' because of the presence or absence of the  
>>> redundant and not-required trailing slash.  Can you elaborate?   
>>> The link in the warning message is to <http://www.w3.org/Addressing/URL/4_Ex_HTTP.html 
>>> >, which only lists a number of example URIs (that's a _very_ old  
>>> page, by the way).
>> Without some convention in this area we make FOAF processors jobs a  
>> lot harder.
> I don't think there's any need for a convention.  The URI http://foo  
> is necessarily identically equivalent in function to the URI http://foo/ 
> , by virtue of the HTTP spec.  Thus although they don't compare  
> equal as strings, they are explicitly noted as equivalent in section  
> 6.2.3 of RFC 3986 (which includes equivalent in the owl:sameAs  
> sense, though I doubt it would be either necessary or useful to  
> state this explicitly).

That's not my reading of RFC 3986.

It says: “Implementations may use scheme-specific rules, at further  
processing cost, to reduce the probability of false negatives. For  
example...” then goes on to give an example of some HTTP-specific  

Nothing in that implies equivalency in the owl:sameAs sense to me.

It goes on to say that “In general, a URI that uses the generic syntax  
for authority with an empty path should be normalized to a path of "/".”

None of that implies to me that it's a good idea to omit the  
normalising / in your data, just that processors may treat it as the  
same, in some cases.

- Steve

More information about the foaf-dev mailing list