Re: version for review

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.


> 

Jeremy

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