Re: Proposal to amend the httpRange-14 resolution

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 05:32:02 UTC