Re: URGENT: train wreck coming, action needed. (was: Fwd: URI-CG group chartered)

>On Fri, 2003-04-04 at 16:06, pat hayes wrote:
>>  (Im CCing this to people outside the RDF Core WG as the issue is much
>>  larger than just for RDF.  Please be selective in CCing replies in
>>  order to avoid cross-list postings, thanks. -Pat)
>
>>  >
>>  >FYI, the URI CG is now officially chartered.
>>  >
>>  >   URI Coordination Group
>>  >   http://www.w3.org/2001/12/URI/
>>  >
>>  >"The mission of this group is to coordinate ongoing work in the area of
>>  >Uniform Resource Identifiers (URIs); to serve as a coordinating body of
>>  >all issues involving URIs in the W3C and act as the coordinating body
>>  >for URI issues with other groups.
>>  >
>>  >...
>>  >
>>  >Back in the mists of 2002, I volunteered to act as RDFcore liaison
>>  >for this group.
>>  >
>>  >As yet, there's been little activity.  It might be worth noting that
>>  >Roy Fielding is working on a revision to RFC2396 (version available
>  > >at: http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html).
>>  >
>>  >The IETF URI BOF (a week or so ago) also had some discussion or IRIs.
>>  >
>>  >There were a couple of things raised at the IETF meeting that may be
>>  >of relevance to RDFcore:
>>  >
>>  >(1) a suggestion that "resources" don't exist unless a URI is
>>  >defined for them.  (I raised an objection to this --because we have
>>  >bnodes-- which was somewhat brushed aside with "If RDF has a problem
>>  >with URIs its RDF's problem not URI's problem.  Since the matter is
>>  >more philosophical than of practical import, I don't think it's a
>>  >big deal.)
>
>Hi, I'm the one that made that comment and I'll stick by it. The issue
>is not that I'm denying that resources as __YOU__ are defining them
>exist. I'm not using any other definition of the term other than the one
>found in RFC 2396.

Neither am I.  I never have used any other definition, which is why 
this issue is so important. That text (repeated in Fielding's draft 
referred to above) reads as follows:

"A resource can be anything that has identity.  Familiar 
examples include an electronic document, an image, a service 
(e.g., "today's weather report for Los Angeles"), and a 
collection of other resources.  Not all resources are network 
"retrievable"; e.g., human beings, corporations, and bound 
books in a library can also be considered resources.
"

Now, it is clear from this that 'resource' is intended not to be 
restricted to things that are web-retrievable, but is intended to 
refer to *anything* which can possibly be given an identifier (not 
that already has an identifier: most human beings don't have a URI). 
Other W3C working groups have determined that this includes imaginary 
things (unicorns) and abstractions (properties, classes) as well as 
things that may exist in the future or past. In fact, that phrase 
'anything that has an identity' seems to mean literally anything, 
unless the word 'identity' is being used in some nonstandard way, and 
there is nothing in the rest of RFC 2396 to indicate that it is.


>If it will help we can change the term used in RFC
>2396. URIs identify 'froogles'. 'Froogles' are defined as things that
>are identified by URIs. It is up to your system to scope and extend the
>definition of a 'froogle' to match your systems needs. But that extended
>definition is _scoped_ to your application, not to the entire system of
>URIs and 'froogles'.

Fine; I am treating the word 'resource' in much this way, since it 
has no predefined meaning. But the problem I have is that the scope 
of RFC 2396 (or whatever you guys do) *is* the entire system, so if 
RFC 2396 (or you) restrict the notion of 'froogle', we ALL get 
restricted. The issue at hand is whether or not froogles can exist 
which have no URI.  If you say no, then we don't have the option of 
overriding you on that; and that restriction would be disastrous to 
just about every use of a database or inference engine on the Web, 
and also, if taken seriously, to many web services models and other 
applications.

>  > But this IS a VERY big deal, and we should raise hell about it, and
>>  not stop raising hell until this idea is abandoned. This decision
>>  would be a disaster not just for RDF but for almost any web logic. It
>>  would force all web logics to treat resources as temporal entities
>>  which come into existence at a time (and maybe go out of existence
>>  and reappear later).
>
>Then you are using the term 'resource' to mean something that is
>completely out of scope of RFC 2396.

I profoundly disagree. First, the text of RFC 2396 seems to go to 
some length to not restrict the scope of the term in any way at all. 
Second, nothing in RFC 2396 says or implies that resources come into 
existence when they are assigned a URI. The text of RFC 2396 is clear 
on casting the net of 'resource' extremely wide, and this 
interpretation has been borne out in many subsequent email 
discussions and even in formal decisions made by working groups. I 
think that you are interpreting the language of RFC 2396 far too 
narrowly.

>The problem here is that we're
>having a terminology collision, not an architectural problem.

I am using the term in the way that it is used throughout large 
sections of the W3C technical community. The word is a term of art 
within the W3C and does not have a clear predetermined meaning; but 
it is abundantly clear that it does NOT refer only to things that are 
(a) web-retrievable, or (b) have been assigned a URI at any given 
point in time. Entire W3C standardization efforts depend crucially on 
the fact that the set of 'resources' includes things that may not 
currently have (but can be given) URIs; and virtually all of the 
proposed and existing semantic web reasoners depend on the ability to 
quantify over things that have no URI.  The issue was discussed at 
length by the RDF working group, and would have been discussed again 
by the Webont WG if RDF had not got it sorted out. And this isn't 
just RDF's business: all these WGs are required to conform to RFC 
2396 (or whatever you guys do to replace it) so if you impose 
restrictions on what a 'resource' is then all these other efforts are 
hamstrung by those restrictions.

>  > This plays havoc with ALL quantified logics, not
>>  just RDF.  It effectively makes all current mechanical reasoners
>>  invalid (since they all use, one way or another, the principles
>>  underlying existential quantification.) It also plays havoc with all
>>  semantics for NL dialog and just about everything else.  It would
>>  drive a truck through all assertional datatyping and most attempts to
>>  do syntax layering (such as the OWL/RDF mappings and any future
>>  son-of-OWL/RDF mappings.) It is not just an obscure philosophical
>>  niggle: it is absolutely fundamental.
>
>Again, those things aren't using the term 'resource' the way it is used
>in RFC 2396. Please get that _CLEAR_.

I have it clear, and they ARE using it in that way. There are now 
about a dozen W3C documents in last call which use it in this way, 
referring to RFC 2396. I wrote one of them myself. The RDF M&S 
document uses it in this way and has been publicly available for four 
years.  Please, allow me to ask you in return to not confuse issues 
concerning URIs with those concerning resources, and to take the text 
of RFC 2396 more seriously. That stuff in the intro parts of RFC 2396 
isn't just chit-chat.

>RFC 2396 says nothing about
>knowledge systems of any kind, way, shape, form or fashion.

That is not the point; but in any case, it does, in fact, although 
indirectly and implicitly, because it talks about names and what they 
refer to, and names are fundamental to 'knowledge systems' (I presume 
you mean inference systems).  RDF for example is required to use URIs 
as names. So it has to conform to RFC 2396.

>The only
>thing RFC 2396 defines is the fact that there is an identifier and it
>identifies whatever it is it identifies.

No, it also says something about what KIND of thing can be 
identified. It also, by the way, thereby implies quite a lot about 
what 'identifies' means. It does not (only) mean 'identifier' in the 
narrow sense in which it is used in programming languages; it means 
it in the sense in which logical and assertional languages refer or 
denote. That is a very different sense of 'identify', and it obeys 
different semantic rules. And to repeat, this isn't what _I_ say: it 
is what RFC 2396 says, and it reflects the facts of the matter in the 
way that URIs (particularly URNs) are actually used on the Web.

>If you build a system that
>constrains that further then that is the intended purpose. The thing you
>CANNOT do is impose your definition on others.

I am not imposing anything on others. I am only asking that in your 
role as a member of the coordinating group, you pay some close 
attention to the ways that URIrefs are actually being used on the 
Web, and avoid making de novo rulings which violate both the 
intentions and the practice of the actual web.

>  >
>>  For one (tiny) example of the trouble it would cause, try making
>>  sense of this idea in the context of a URI scheme for identifying
>>  dates and times. If nobody has perviously mentioned 3.48 am on the
>>  24th of February, 1865, does that date suddenly come into existence
>>  at the time someone one first mentions it with a URI?
>
>Within the formal system defined in RFC 2396 that contains only two
>concepts: a URI and its Resource, no. You're talking about a much richer
>formal system and within _that_ scope you are completely correct.

I am not talking about any formal system. I am talking about the 
_resources_, the actual things in the world, that the formal system 
talks _about_.  Using a richer formal system doesn't make the world 
more complicated, it just enables you to say more about it. The 
resources are not formal constructions, they are the actual things in 
the actual world:  real physical books, real living people, galaxies, 
times, places, countries, sodium atoms, bottles of wine, whatever. 
Really, they are: RFC 2396 asserts that that is what they are.  So if 
you start restricting this to some narrow subset of things, that 
imposes a huge constraint on ALL other uses of URIs in ALL other Web 
languages and formalisms. RDF (for example) is not free to invent new 
kinds of things to be its resources: it has to conform to RFC 2396. 
If they are restricted to some small class of things, or required to 
obey some narrow strictures about existence, then RDF (and RDFS and 
OWL and OIL and DAML, to name a few at random) are automatically 
restricted in their meanings. Users of these languages  will have two 
options: to ignore what the coordinating group says about URIs, or to 
become in effect useless. I would suspect that they will in fact do 
the former, which would be rather a pitiable outcome of an effort to 
coordinate the use of URIs.

>  > What if someone
>>  has mentioned the year 1865? Did that particular year have a
>>  minute-length hole in it, which has just gotten filled in? Don't
>>  laugh when your temporal reasoner figures out that you don't need to
>>  get to the airport until a minute after the flight leaves.
>
>AGain, you're including concepts such as 'someone', 'year', 'minute',
>'hole' which are not defined in RFC 2396. It only defines two things: a
>URI and the thing identified by it. Nothing more.

Im not asking RFC 2396 (or you) to *define* anything. Im only asking 
you to be careful not to *exclude* any of these things. Saying that 
resources must have URIs effectively excludes most of these things, 
since most of them they don't as yet have URIs assigned to them, and 
many of them never will. You would run out of namespace if you tried 
to assign a URI to every protein molecule. So if we follow your 
ruling, they don't exist. But they DO exist, and we may NEED to refer 
to them; or, more subtly, we may need to be able to reason about 
their existence even when they do not have a URI, in order to decide 
to assign them a URI so that we can refer to them. One of the moves 
that a query-answering engine might make, for example (explicitly 
part of the recently defined DQL protocol) is to infer that something 
exists which satisfies a query, then *assign it* a new URI, and use 
that URI to answer the query. With your restriction on the meaning of 
'resource', that would be rendered either invalid or impossible.

>  > This group needs to pay some serious attention to what it is talking
>>  about. Fielding's draft cited above repeats verbatim the extremely
>>  grandiose and rather wooly text from RFC 2369 claiming that
>>  'resources' are anything that can possibly exist, on the web or off
>>  it.  It is irrational and incoherent to assert this and also treat
>  > resources as though they were datastructures or computational
>>  constructs of some kind.  If the group's attitude to issues like this
>>  is that these are just philosophical niggles of no real consequence,
>>  then the best thing this group could do would be to disband itself
>>  before it does more harm, or at the very least try co-opting someone
>>  who knows something about what the issues are here. URIs are too
>>  important to be left to syntactical engineers.
>
>URIs are used in large numbers of places where the only valid thing is a
>syntactic engineer.

Not that it is really germane to the discussion, but I would dispute 
that. Usually, somewhere along the line, URIs are used to refer in 
some way. If they were not, they wouldn't be a great deal of use.

>You cannot redefine intended simplicity of URIs to
>accomodate your needs to the detriment

I am not wanting to redefine URIs at all. I have no opinions about 
URI syntax, and have no desire to redefine or complicate it. I am 
making a point about the meaning of "resource". "Resource" is a 
semantic notion, not a syntactic one. OK, if you are not interested 
in semantics, that is fine: I have no quarrel with you. But please 
don't make damaging semantic pronouncements if you are concerned 
primarily with syntax.

>of things that explicitly reject
>the concepts you are talking about.

What "explictly rejects" the idea that URIs refer to resources? That 
seems to be central to the very idea of a URI, according to RFC 2396. 
And how would allowing more things to count as resources be 
detrimental to any application?

>There are other data models out
>there and URIs were designed to work with ALL of them, not just a few of
>them....

I want URIs to work with all of them. But in order to do that, they 
must be capable of referring as broadly as possible. By restricting 
the notion of resource you are not helping URI syntax in any way at 
all, but you are with a casual stroke of the pen effectively 
prohibiting any Web application from referring to most things in the 
universe.

Pat Hayes


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam