Jonathan, On 30 Mar 2012, at 18:10, Jonathan A Rees wrote: > My opinion is that any proposal needs to specify a way to say how you > get from a resource to its content. I do a SPARQL query and find a URI > for a resource based on metadata (stored in the triple store) that > make it seem interesting; title, license, rating, whatever. Then I > want to *look at it*. What do I do? httpRange-14(a) (or its intended > stronger form) says you do a GET on its URI, and if you get a 200, > that's the content, that's what I want to look at. So that's > successful communication. If you delete HR14a, which is fine, you > need, IMO, to replace it with some other way - normative and > actionable - to express the same information, and that method has to > be provided normatively, not as a best practice. Tim's proposal does > this, my "SHOULD not MUST" proposal does, yours doesn't.
OK, I think I see. The intention of the 'no longer implies' proposal is that you GET its URI. If you get a 200 then you have to look at the content that comes back to work out the relationship between the URI and the representation because you can't generally tell whether the representation is content or description. Your assertion, I think, is that we haven't specified a mechanism for providing an explicit statement within the content that says "this stuff you got is the content of the resource this URI identifies", only one for saying "the stuff over there is the description of the resource this URI identifies". The intention was for the :describedby property to double-up for this. The proposal states that if the content includes a statement using :describedby property in which the resource is the object of the statement, then you know that resource is an information resource (ie that you get the content of the resource from the URI). So if you GET U and you have a 200 and it contains something that looks like: _:something :describedby <U> . then you know that what you have gotten from U is the content of U. You say the gap can be fixed with: > This is an easy fix to your proposal. You just add a normative section > that defines a property that people *may* use to provide this > information: > > <http://example/foo> baz:hasContentUri "http://example/foo-content";. > > or whatever you want to call it (Larry suggested 'location', I > suggested 'hasInstanceUri'). This means that to get the content do a > GET on that URI, and if the result is a 200 then you got content, > otherwise all bets are off. (Well, dealing with 301/302/307 would be > gravy.) Then the proposal will not be a net loss as far as expressive > power goes. I *think* that the :describedby triple, as defined in the proposal, provides equivalent information. If you have: <U> :describedby <V> . then you can turn it into: <V> :hasContentUri "U" . and it has the same meaning. What have I missed? Is it important that "U" is a string rather than a resource for example? Cheers, Jeni -- Jeni Tennison http://www.jenitennison.com
