W3C home > Mailing lists > Public > www-archive@w3.org > March 2004

Re: version for review

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Tue, 30 Mar 2004 13:12:52 +0100
Message-ID: <40696444.7070209@hplb.hpl.hp.com>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: www-archive@w3.org, ext Chris Bizer <chris@bizer.de>, Pat Hayes <phayes@ihmc.us>

Patrick Stickler wrote:
>>> Section 8.1: "We require [the value of the swp:signatureMethod property]
>>> to be a literal URI, which can be dereferenced on the Web..."
>>> Question, what is the difference between a URI and a literal URI? Do
>>> you mean rdfs:range xsd:AnyURI?
>> xsd:anyURI I think - a literal URI denotes itself in the RDF Model 
>> Theory and hence can then be used for dereference operation, whereas a 
>> URIref node denotes a resource, presumbably the same resource as that 
>> for which you get a representation when you dereference it, but that 
>> takes us well into the social meaning issue, that we are trying to 
>> skirt around.
> But wouldn't you be *wanting* to denote the resource, the method itself?
> Otherwise, anything said about that method would not be stated in terms
> of that URI.
> I don't think the range/value should be a literal. I think it should
> be the method itself, denoted by a particular URI, which might be
> dereferencable (or might not).

In theory I agree, in practice I don't - let's hear what Pat has to say on 
this one. In theory, whenever you use a web dereferencable URI the resource 
denoted has a representation that is got by the URI-GET, however that is 
not a part of RDF Semantics and I don't think it is for this paper to add it.

>>> Also, while requiring the signature method to be denoted by a URI,
>>> I don't think we need to go so far as to require that the URI be
>>> web-dereferencable. It's *convenient* if it is dereferencable, and
>>> it's probably a "best practice" for it to be dereferencable, but
>>> I don't see it as an actual requirement. As long as the publisher
>>> and consumer understand the URI in the same way, that's all that
>>> counts.
>> That's technically correct, however in practice there will only be a 
>> handful. For the paper I am inclined to leave it as required, it 
>> simplifies the explanation without any real great loss of generality. 
>> Without the document it is much harder to write the semantics of 
>> signature which does actually depend on the method indicated (and if 
>> that method is by private agreement then it is slightly awkward!)
> OK. I won't press the issue. Though I think there's as much potential
> for questions/feedback by stating the requirement than by not stating it.
> But I'll accept it as is.
Let's hear from Pat.


Received on Tuesday, 30 March 2004 07:13:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:25 UTC