- From: Jonathan A Rees <rees@mumble.net>
- Date: Fri, 23 Mar 2012 18:25:46 -0400
- To: Tim Berners-Lee <timbl@w3.org>
- Cc: Jeni Tennison <jeni@jenitennison.com>, public-lod community <public-lod@w3.org>, Leigh Dodds <leigh@ldodds.com>, Dave Reynolds <dave@epimorphics.com>, Ian Davis <me@iandavis.com>
On Fri, Mar 23, 2012 at 5:51 PM, Tim Berners-Lee <timbl@w3.org> wrote: > > On 2012-03 -22, at 16:21, Jeni Tennison wrote: > > [...] > > Second, a 200 response to a probe URI no longer implies that the probe URI > identifies an information resource; instead, this can only be inferred if > the probe URI is the object of a ‘describedby’ relationship. > > So for any arbitrary web page out there, under this change, I would not > be able to write any RDF about it. Jonathan cannot express what its licence > is, which was his first. No one would know whether he or I meant the > web page, or some other thing. Surely this fails a basic requirement to be > able > to use RDF to give information about existing web pages. > > Tim Tim, Just because something doesn't have a URI, doesn't mean you can't talk about it - there is blank node notation. What you want to express is: The generic resource whose instances are retrieved using URI U, has such and such a property. If w:instanceURI related generic resources to the URIs from which their instances are retrieved, you could write: [w:instanceURI "U"] xhv:license cc:attribution or [w:instanceURI "U"] xhv:license [w:instanceURI "http://foo/bar/attribution"] or whatever. You could have a second predicate for the other interpretation, just to make things clear: [w:descriptionURI "U"] ... and then you could refer to the two things differentially, without any sensitivity as to a default interpretation of <U>. Not convenient or intuitive, but I don't think it's right to say there is no way to express what needs to be expressed in this alternative universe. Don't take my saying this as an agreement with the proposal; as a matter of taste and parsimony I prefer the same architecture you do. I just don't think this is a sound argument. And in any case, as I've said often, httpRange-14(a) as stated does not address this problem either. Jonathan
Received on Friday, 23 March 2012 22:26:15 UTC