W3C home > Mailing lists > Public > www-webont-wg@w3.org > April 2003

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

From: Michael Mealling <michael@neonym.net>
Date: 04 Apr 2003 16:41:55 -0500
To: pat hayes <phayes@ai.uwf.edu>
Cc: Graham Klyne <gk@ninebynine.org>, w3c-rdfcore-wg@w3.org, www-webont-wg@w3.org, timbl@w3.org, Dan Connolly <connolly@w3.org>, public-uri-cg@w3.org
Message-Id: <1049492515.22745.67.camel@blackdell.neonym.net>

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. 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'.

> 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. The problem here is that we're
having a terminology collision, not an architectural problem.

> 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_. RFC 2396 says nothing about
knowledge systems of any kind, way, shape, form or fashion. The only
thing RFC 2396 defines is the fact that there is an identifier and it
identifies whatever it is it identifies. 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.


> 
> 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.


> 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.


> 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. You cannot redefine intended simplicity of URIs to
accomodate your needs to the detriment of things that explicitly reject
the concepts you are talking about. There are other data models out
there and URIs were designed to work with ALL of them, not just a few of
them....

-MM
Received on Friday, 4 April 2003 16:44:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:57:58 GMT