Re: MGET and machine processing

On Thursday, Nov 27, 2003, at 16:12 Europe/Helsinki, ext Seaborne, Andy 
wrote:

>
>
> -------- Original Message --------
>> From: Patrick Stickler <mailto:patrick.stickler@nokia.com>
>> Date: 26 November 2003 09:59
>>
> <snip/>
>
>> My #1 requirement is that, for any arbitrary URI which is meaningful
>> to the HTTP protocol, and contains a web authority component, a SW 
>> agent
>> should be able to send a request to that web authority to obtain a
>> concise bounded description of the resource denoted by that URI, with
>> a single request, and without any further information than the URI
>> itself
>> (and the generic protocol by which the request is made) and recieve in
>> response either a description, or an error indication of some fashion.
>
> <snip/>
>
>
>
> Patrick - could you spell out a concrete use case?  I understand the
> mechanisms you are proposing, it is the underlying need I am less clear
> about and as to whether this is the only solution.

I can't think of a more concrete, fundamental use case than having
a URI and not knowing what it means, and wishing to get some
authoritative information about the thing it denotes.

And in such a case, all one has is the URI, and one should be able
to, based solely on generic standards, use that URI to obtain the
needed/desired information without having to know anything about
the particular configuration of the web authority (and knowing
which service interface to use is knowing something about the
particular configuration of the web authority).

>
> - - - -
>
> A web authority has a number of responsibilties.  Often there is 
> spearation
> between the responsibility for naming and the responsibility for 
> running the
> server and its software.  Suppose a web authority delegates the naming
> authority for part of a web authority's namespace; this does not lead 
> to
> delegation of all aspects of a HTTP URI, in particular authority for 
> naming
> is not authority for what software to run.

True, but I don't see how URIQA affects that.

>
> We need approaches that enable a wide range of cases for people to put 
> up
> descriptions of resources.

True.

> These could be (may have to be) based on
> convention, not architectural design,

I'm not sure I fully agree with you there. I think there should be
a balance between convention, good architectural design, and common 
sense.

> that enable the situation where naming
> authority only extends to being able to put up static pages (that is, 
> ISP
> hosted pages).

That is certainly one possible means to publish information (but IMO the
least useful, most ambiguous, and most coarsely grained approach that
will fail to scale in the long run -- but yes, possible).

> There is no single answer here.

I never said there was (in fact, I think I've gone out of my way to 
stress
that a protocol such as URIQA is only a part of the big picture, but a 
critical
part nonetheless).

But choosing the least attractive solution, simply because it (barely)
works today, without any change, for a few simple applications is also
not acceptable.

>
> The requirement that we need to modify HTTP, web servers and client net
> libraries, to add a new verb would seem to create a restriction in who 
> can
> easily get descriptions onto the semantic web.

Not necessarily.

The ability of those who do not own/control a given web server to
offer web services will always be a socioeconomic issue. Not everyone
can set up a servlet, or a WebDAV enabled portal, or an eCommerce site,
even if they "rent" web space on a given server.

Yet, IMO, technologies such as RDF and URIQA would make it easier for
server owners to allow their "tennants" to describe their own resources,
within their own subspace of the server namespace, in the same manner
that they might provide for personal account-specific web spaces, by
deploying server solutions which meet that need -- if/when there is
a business motivation to do so.

Chris Lilley and I had a long discussion about "user rights" some
months back, triggered by a discussion of robot.txt files and the
inability of those with personal web sites to influence robot behavior
in terms of their own subspace. I won't repeat that discussion here,
but reiterate that the degree to which those who have no control over
a given web server can control their own information sub-space is
potentially *greater* when technologies such as RDF and URIQA are
deployed, because (if the server owner allow and support it) owners
can describe their resources as they see fit, and just as one might
GET a representation accessible in their web subspace, they could
MGET a description.

As to *how* that occurs, is up to the implementation and deployment
of the server and/or server platform, etc.

> The barrier to entry is high

???

I think the barrier to entry is far less for URIQA than for Joseki,
not that that is a completely fair comparison.

Yes, URIQA represents a higher cost than just exposing RDF/XML instances
on existing web servers. But that cost is, in my experience (not just
opinion) well worth the investment. And if/when the more popular server
platforms embrace such a solution, the cost for web site deployment
including support for resource descriptions will not be so great.

The cost of creating and maintaining the knowledge itself will greatly
overshadow the infrastructure costs (as is the case with most if not
all systems employed for the dissemination of information).

> and it effectively creates two webs - there should not be "web 
> servers" and
> "semantic web enabled web servers".  We have to live with the starting 
> point
> even if it is not the one we might have choosen, given a completely 
> clean
> start.

I can't agree there. That's like saying that two web servers, one that
groks content negotation and another that doesn't indicate two different
webs, a literal web and a content negotiated web. Or WebDAV indicates
two webs, those servers with CM capability and those without.

URIQA is an *extension*, not a reinterpretation or deviation from the 
web
architecture. It does not create two different webs.

Not all web servers support all presently defined HTTP methods. Not all
web servers will support the proposed SW methods. So what? The more 
limited
the capability of a server, the less utility it has. And those who want
to publish descriptions as well as representations (or provide content
negotation, or secure connections, or CM functionality, etc. etc.) will
choose server platforms that provide those features. Those that don't, 
won't.


>
> We also need to have 3rd party descriptions - these could be as 
> important as
> the need for authority descriptions.

Yes. And I've stated *numerous* times that both are necessary, and the 
URIQA
specification discusses and addresses this need *explicitly*. So I'm 
puzzled
why you feel the need to make this point.

Yes, 3rd party descriptions are *very* important. But their importance 
does
not in any way lessen the critical need for authoritative descriptions 
that
can be obtained solely by a given URI.

> A way of associating a knowledge base
> with a URI can be done in a number of ways (not always very nice);
> convention, by asking the server etc etc.

True. I'm proposing what I consider to be the most optimal way (all
things considered, including impact to the currently deployed 
infrastructure).


> You argue against double-tripping
> - doing some operation before every GET.  In practice, its not every 
> GET.
> Doing the discovery operation would yield a range of URIs for the
> description authority and also could be cached making it a one-time
> overhead.

Right, so each agent is going to have to maintain a registry of every
server it has visited, and keep it up to date, checking if anything
has changed since its last visit -- and what if things change in between
two consecutive calls? Will a sudden 404 error be understood as a need
to update its profile of the server?

Sorry, I'm not motivated in the least by any solution that *requires*
such overhead. While it may seem like just a little bit to bother with,
such little bits tend to add up quickly, and before you know it, the
SW is crushing under its own weight.

Caching and the like can be very useful, and that it will be used, and
I expect that there will
exist means to discover and interact with named services hosted by
particular servers, and that information about such services will
likely be maintained by various agents as a matter of efficiency,
but as a fundamental, atomic, primary means of
discovering knowledge about URI denoted resources, I cannot see any
such approach as being acceptable.

It's not a matter of choosing between a more simple protocol such
as URIQA and a more comprehensive protocol such as the RDF Net API.
It's a matter of utilizing both to the greatest benefit.

>
> We are starting from the existing web.  We need to find approaches that
> build on the web.

I agree. And I believe URIQA does so, and that its extensions are
well justified and necessary.

While we should refrain from any unnecessary new machinery, "building
on the web" does not mean being "restricted to the web" as it is 
presently
defined.

Patrick

>
> 	Andy

Received on Friday, 28 November 2003 07:48:20 UTC