Re: Proposal to amend the httpRange-14 resolution

I wasn't trying to argue the merits of the proposal (as Tim did, which
is fine), I was just trying to make sure I understood it. And it
sounds like what I thought was true, which is that it would deprecate
huge amounts of deployed RDF, and incompatibly change previously
provided advice. That's coherent, and it's fine to propose (the same
objection has been raised before, so you're not alone), but in my
opinion any proposal that would do this ought to be transparent and
list such a consequence under "negative effects" or "risks".

Jonathan

2012/3/26 トーレ　エリクソン <tore.eriksson@po.rd.taisho.co.jp>:
> Hi Jonathan,
>
> On Sun, 25 Mar 2012 Jonathan A Rees wrote:
>> On Sat, Mar 24, 2012 at 11:44 PM, Tore Eriksson <tore.eriksson@gmail.com> wrote:
>> > ==Summary==
>> >
>> > This proposal entails a partial reversion of the httpRange-14
>> > resolution. Specifically, it suggests that a representation retrieved
>> > from a HTTP URI will never* be equivalent to what the URI denotes (the
>> > resource), but will always be a description (of the state) of the
>> > resource, eliminating the risk of confusing a resource with its
>> > description.
>>
>> In this case I think you need to add to "negative effects" that
>> referential use of URIs for which there is no available descriptive
>> information is deprecated. There are many such uses of URIs in extant
>> RDF, so I think this would be a problem.
>
> Sorry if my prose is unclear. I have read a lot of what you have written
> on this subject, but I haven't yet wrapped my head around all
> definitions. If you have a URI, you can use it in RDF, regardless of any
> http request, so I assume you are talking about the reverse case. Which,
> in my opinion, using the URI to refer to the document, e.g. an HTML
> document, retrieved through doing a GET on the URI.
>
> In [1], you argue that
>
>>>>
> To say that any representation retrieved from "http://example/hen" has
> (or will have) "Trouvee" as its title, we can write (in Turtle [turtle])
>  [ir:onWebAt "http://example/hen"] dc:title "Trouvee".
>>>>
>
> And later you use <http://example/hen> as the URI for the blank node. Is
> this the referential use you are talking about? Ignoring your usage of
> the URI for now, you are saying that all representation will have the
> same dc:title. This could be acceptable if you own the URI in question.
> However, if you don't own the URI, stating this seems to irresponsible.
> The owner might add a content-negotiated Swedish translation with a
> dc:title of "Hittad" and make your statement invalid.
>
> I'm sure that this usage is quite common now. I probably come out
> sounding very arrogant, but I think this way of using URIs is wrong.
> Since most resources lack RDF currently, all we have are the
> representations. It is tempting to use information in the
> representations in RDF statements about the resources, but since you
> can't tell what the owner had in mind, you might say something that is
> incorrect. The argumentation of httpRange-14 and [1] is an attempt to
> justify this behaviour, saying that your interpretation supersedes that
> of the URI owner. I works when the owner doesn't care about his
> resource, but it fails badly when he does. That is why I think we should
> deprecate this usage to clear the way for real, user-served RDF. Thus,
> the effect sure is disruptive, but in a positive way!
>
> <RANT>To separate resource clearly, and to not confound resources with
> their descriptions is supposed to be very important on the semantic web -
> and I agree completely. Then why is it that most solutions proposed
> repeats this very mistake by conflating resources and
> representations?</RANT>
>
> Returning to the example in [1]; in my opinion, it is much more
> straightforward to model this as
>
>  <http://example/hen> :representation [dc:title "Trouvee"] .
>
> where the blank node refers to a representation. In your case, if you
> really want to say that all representations have the same title, how
> about this (probably incorrect) combination of RDF and OWL:
>
>  <http://example/hen> a _:res .
>  _:res a owl:Restriction;
>        owl:onProperty :representation;
>        owl:allValuesFrom _:rep .
>  _:rep a owl:Resctriction;
>       owl:onProperty dc:title;
>       owl:hasValue "Trouvee".
>
> Where :representation should be replaced with any suitable property
> describing the relationship between resource and representations.
> Through this you can infer that all representations (not just one) have
> the title in question, and when one title "Hittad" shows up you will get
> a nice logical error!
>
>> I'm not sure how one would write (in RDF), say, Dublin Core metadata
>> for the document (wiki page) that is accessed from
>> http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ , since that URI has no
>> discoverable RDF. What would you advise people do, should your change
>> proposal be accepted? One could define a second URI to refer to this
>> document, but what descriptive RDF would one write in order to
>> document the new URI?
>
> First, if you want to write RDF about the resource, you would use
> <http://www.w3.org/TR/2004/REC-rdf-mt-20040210/> as the subject. However,
> since there is no discoverable RDF data, you would have to be very
> careful that you know what this URI denotes. Is it really a wiki page? Not
> when I access it. My guess is that it denotes a specific version of the
> RDF Semantics document, but you never know....
>
> To add meta data to the HTML document served form the URI, you would add
> appropriate <META> and <LINK> elements in the <HEAD> of the HTML:
>  <META name="dc:publisher" content="W3C">
>  <LINK rel="xhv:license" href="http://cc.org/licenses/by/3.0/">
> Prefixes would be set according to RDFa, but RDFa has to be amended not
> to hi-jack document meta data first.
>
> I think this is what was the original Dublin Core had in mind, but
> afterward the usage got side-tracked by the incorrect notion that any
> resource described in RDF had to have a URI. One advantage of this
> method is that the licensing information is embedded in the document and
> would be valid even if the document is use off-line. You wouldn't be
> able to use this pattern for text/raw though.
>
> If you really had to write this in pure RDF there are a couple of
> alternatives that you can select from depending on technical factors.
>
> 1. Turn the document into a (long) data: URI and use this as the subject
> 2. Mint a secondary URI using something like <urn:guid:{GUID}>
> 3. Use a blank node.
>
> Regards,
> Tore Eriksson (not Ericson! ;-)
>
> P.S. Sorry for using multiple emails in one discussion...
>
> [1] http://www.w3.org/2001/tag/awwsw/ir/20110625/
>
>
>
>

Received on Monday, 26 March 2012 13:46:12 UTC