[
Lists Home |
Date Index |
Thread Index
]
PMFJI,
Many thanks to all for this thread - particularly PP, as a complete REST
newbie it has been most illuminating.
Whilst reading all this endlessly fascinating stuff regarding URIs and REST
etc, I am constantly reminded of aspects of Chris Date's "Third Manifesto"
dissertation about (amongst other things) types and inheritance thereof,
ObjectIDs, a "single-level data model", and the notion of multiple possible
representations for datatypes.
Whilst the issues raised in both arenas are generally quite deep and
somewhat beyond my feeble ken, it does seem that Date has thoroughly
explored and expounded upon very similar issues in the context of DBMS
systems that are being explored here viz-a-viz URIs and HTTP resources.
In particular the notion of the actual physical representation being used to
store the actual resource/data being a totally inaccessible implementation
detail - with only "possible representations" of the data being accessible
seems exactly the same in both fields. Note also that Date places some
fairly heavy-duty restrictions on what "representations" actually are, and
how they must work in order for them to integrated properly into the DBMS. -
roughly that each representation consist of a named set of mutally
orthogonal scalar-valued properties (I think <g>). Have similar concepts
also evolved in best-practice REST implementations?. Should they? Could
they?
There would also seem to be parallels between URIs and Date's notion of
"representation selectors" (presumably when combined with key-values?), but
again I'm unsure exactly how far this analogy can be taken - or how useful
it might be.
How "truthful" is the analogy of considering the entire world of
URI-addressable HTTP resources as one gigantic database, the HTTP protocol
itself as the DBMS, and URIs as the key-values. Is the analogy close enough
to warrant further scrutiny of the best practices in the DBMS world? Does
the success of CGI systems indicate, at least in part, the usefulness of the
analogy?
I also suspect that a fuller understanding than my own of exactly why Date
is so adamantly against ObjectIDs (aka references/pointers) appearing as
part of the logical data model would provide useful insights on some of the
issues surrounding URIs vs URLs/URNs, entities vs. resources, and the
further development of REST-ful best practices.
respectfully,
gary
----- Original Message -----
From: "Joe English" <jenglish@flightlab.com>
To: <xml-dev@lists.xml.org>
Sent: Sunday, February 17, 2002 3:37 PM
Subject: Re: [xml-dev] Re: Why REST was Re: [xml-dev] URIs are simply names
>
> Simon St.Laurent wrote:
> > Jonathan Borden wrote:
> > > The core issue is whether we are able to describe anything but
"documents"
> > > on the Web. One might take the position that nothing but documents
exists o
> > > the Web. But it is the literal incantation of a document which is
defined a
> > > the _entity_ (the series of bits)
> >
> > I don't think the incantation of bits is sufficient cause to believe
> > that an abstraction called a resource lurks behind the bits.
>
> I stopped believing in "resources" on my third or fourth
> attempt to read the RDF M&S spec.
>
> If you look hard enough, you can see that the whole thing
> boils down to:
> "A URI is a thing that that identifies a Resource"
> and
> "A Resource is anything that is identified by a URI".
>
> So I gave up trying to figure out what a resource is
> and re-read the spec thinking only in terms of URIs
> (which at least have an EBNF grammar, so you can tell
> one when you see one). RDF finally made more sense.
>
> Now it's still not clear to me that anything useful will ever
> come out of making Statements about Resources and Properties,
> but you can do a lot today by resolving a URI and getting back
> a Document, or POSTing one to a Web server. I don't care if
> that Document is really just a Representation of a Resource,
> since I'll never get my hands on the Resource anyway.
>
> --Joe English (Yow! Am I enlightened yet?)
>
> jenglish@flightlab.com
>
> (P.S. to Simon -- it sounds like using java.net.URI instead
> of lava.lang.String for URIs is just making more work for
> yourself unless you're going to be resolving them. In fact
> the equals() method isn't even correct for XML namespace names.)
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|
