next steps re httpRange-14 opt-in

I think the first thing technical target is to come up with a way to
opt in to httpRange-14(a), or more particularly agree on what RDF to
write to say that a URI refers to the document at that URI. I don't
expect AWWSW to accomplish this, but the conversation needs to
continue, so here's the challenge for this group, or its successor, or
the TAG to take up.

There are obstacles to this, that we have so far been unable to overcome.

1. How to support this with an adequate theory. I made a proposal
http://www.w3.org/2001/tag/awwsw/ir/latest/. A few people have read it
and think it sounds OK. IIRC David thought it was OK. Henry has been
the only one to read it critically, and I think he said it seems on
the right track.

Alan R balks at it since it doesn't give even a shred of ontological
satisfaction - a problem that bothers him deeply and me not at all.
Pat seems to balk at it. I have no idea whether TimBL has even read
it. Not sure how Nathan or Michael feel about it.

(Harry, Manu, and others seem to think that it is sufficient to just
write some metadata using the URI, and that will flag that the URI is
being used to refer to the document at that URI. We know this
approach, like httpRange-14(a), is inadequate since there is no
articulation of *which* information resource is meant to be the
metadata subject. And we have seen empirically that it fails (Flickr,
Jamendo, and in my opinion RDF graphs).)

2a. If my theory is rejected, what to replace it with. Alan R proposes
the approach of a bunch of specific types, each with its own
relationship to the retrieved representations. Nobody has pursued this
yet - I presume because Alan has not made time to work on this, and no
one else on the list is motivated.

2b. If it is accepted, we have the problem of settling on what to call
the types and relationships involved. Even if we agree on the theory,
none of the terminology in that document seems to resonate. Naming is
often the most painful part of design.

Types:

   what do we call what these URIs refer to - information resources?
(JAR balks due to conflict with AWWW) generic resources? (David balks)
generic information entities (ugh)? metadata subject? otherwise
uncategorized things that just happen to have certain properties like
in some cases dc:title? documents (TimBL)?

   what is retrieved - representations? (HTTPbis likes, JAR tolerates,
Pat Balks) TimBL-representations (awk)? wa:Representations? entities
(a la 2616)? content entities? (no one liked that one) points?
retrievands? ...

Relationships:

   what is the relation between the two? is a TimBL-representation of?
has specialization? generalizes? "has information" (Dan C)?
(definitely not just "has representation" since that could be read as
Fielding-representation which would be dangerously wrong)

   what is the relation between a TimBL-representation and the
hashless URI using which it might be retrieved?

   what is the relation between what the URI refers to, and the URI?
log:uri? (JAR rejects since it's not documented to do what we need)
ir:onWebAt? (it's really unrelated to the web - consider data: URIs,
URNs)  retrieval-enabled using?  "bound to"? ...

3. Given 2b there is the weakness - both logically and expositorily -
to be repaired of which properties are "metadata properties" (or I've
sometimes said "nonparadoxical properties").  There is a list here
http://www.w3.org/2001/tag/awwsw/ir-axioms/ . Is there any principled
way to define this set so that we can avoid the two extremes of
enumeration (as in ir-axioms) and metaphysical vagueness (as in
TimBL's generic resources memo and other writings)?

Should we get this far, the way to opt in, according to the theory,
would be: <http://example/doc> ir:onWebAt
"http://example/doc"^^xsd:anyURI.   (replacing ir:onWebAt with
whatever name we settle on)  If this approach gets uptake, it could
end up being used any time someone wanted to make clear they were
referring to a document on the web, as opposed to what it talks about.
This would be the "I really mean it" defense against the Talis and
Flickr interpretations.

Jonathan

Received on Saturday, 15 October 2011 14:40:09 UTC