RE: HREF Property in Thai Restaurant

Hi Jim,

Thanks for your time on this one - I hope I'm not just being dim!

Jim Davis wrote:
> So yes indeed, in this case, as you say, when you send the 
> query to DASL, you get a set of response elements with hrefs
> not necessarily on the same server as the arbiter.  You shouldn't
> expect to be able to manipulate either the index data the server
> operates on, or the resources that you get back, any more than you
> can change the index data that say Google uses, nor to be able to
> delete the URLs that it returns for you.

Not sure on this. Surely I should be able to manipulate *my* indexes? In
the example given, haven't *I* created the restaurant index, which
happens to point to a restaurant's web site? Of course I can't delete
their web site. But I am using WebDAV to manipulate *my* index entries,
and DASL to search them, and so I should be able to manipulate them. And
even if the index entry is on Google, all that does is shift the problem
up a level; at some point I have my own information in WebDAV that I can
change - say, my information *about* the index entry on Google.

So my point is that at some stage I need to be able to search the WebDAV
information itself - lock, creation date, etc. - to get back WebDAV
items, not what those items represent.

> >My feeling so far is that this approach caters for one use of DASL,
> >which is to hold indexes to other resources. But by gearing
everything
> >to that, don't we lose the ability to search the index entries
> >themselves?
> 
> Perhaps the draft document is faulty in giving the impression that
> "everything" is geared to this means of use?  You can use DASL in many
> ways, this is just one.  Have I given you the impression that 
> everything works in the way the restaurant finder does?

I suppose you have, since as far as I can see the 'href' is always set
to point to the resource being described, and not the resource
description. It's a bit like with RDF descriptions; there's the resource
that the RDF description is about, and then there's the RDF description
itself. My problem is that with DASL as I see it in the restaurant
example, I can do a search on a list of RDF descriptions and return all
the resources referenced, but I can't do a search on those descriptions
and return the descriptions themselves.

> >To pose it a different way; why should the format of the result of a
> >PROPFIND on a known URI be different to a DASL query on some
container
> >that includes that same URI? In other words, there is no notion of
"what
> >are the properties of this object", since the answer is "depends on
how
> >you ask the question".
> 
> Well yes, but in fact even on a plain old WebDAV server, the 
> answer could depend on your authentication -- I might get a
> different answer than you get.

I accept that - but at least in that case the 'href' would be the same
for both you and me. With DASL versus a straight PROPFIND that is not
the case.

To sum up my view, I'm suggesting that I need the 'href' of the WebDAV
object so that it can be manipulated - for example, delete all indexes
relating to Thai restaurants because we're becoming a burger bar search
engine instead  - and I need the 'href' of the restaurant's web site for
user search results. As it stands I can never get the former.

Best regards,

Mark

Mark Birbeck
Managing Director
x-port.net Ltd.
220 Bon Marché Centre
241-251 Ferndale Road
London
SW9 8BJ
w: http://www.iedigital.net/
t: +44 (171) 501 9502
e: Mark.Birbeck@iedigital.net

Received on Thursday, 18 November 1999 11:51:19 UTC