Re: HREF Property in Thai Restaurant

At 11:29 PM 10/31/99 +0000, Mark Birbeck wrote:
>Hello everyone,
>
>I have recently begun to implement a WebDAV layer and I interpreted the
>HREF part of a RESPONSE to be the URI of the object for which the
>PROPSTAT properties applied.

That's true for WebDAV, and true for DASL too, but in a somewhat different way.

> However, looking at the Thai restaurant
>example in the DASL document the HREF property is being used to point to
>the web site of the Thai restaurant, and not the entry in the underlying
>data store:

Indeed, the URL in the href element of the response is the URL of the
object whose properties are being returned,  but there are two differences
from plain WebDAV

1) in an (ordinary  WebDAV) PROPFIND, all the hrefs within a a PROPFIND are
components of the parent URL.  (WebDAV uses PROPFIND as a way to list the
contents of collections.)  But in a DASL propfind, there is no hierarchical
relation between the URL of the search arbiter and the URLs of the
resources it describes.  

2) The properties of the resource are not necessarily stored at resource
itself.  This is the main point you are concerned with I think.

In the simplest case,  search arbiter runs on a web server and contains
only information about other resources on that same web server.  In a more
complex (and, I think, more valuable) case, the  arbiter (such as in the
example) contains information about many other web resources, such as the
thai restaurant.  It's really not very different from the way a web search
engine works.

As you point out in your email, the resource being indexed might not even
be on a WebDAV server.  For that matter, the URI might not even be a URL...
it makes perfect sense to use DASL to search a database where the URIs
correspond to species of birds, or people.

>I can imagine a scenario where the underlying data being queried is
>actually an index, and so the data stored is 'about' an object, rather
>than the object itself.

Yes, that's what is going on in this example.

> ....To pose the question in a different
>way: should I be able to do a PROPFIND on one of the results of a query
>and get back exactly what the query returned? In this case I wouldn't,
>because I would be performing a PROPFIND on a server that might not even
>support WebDAV.

That's true.  

So, just to elaborate, if one does a DASL search and gets back a result
with some URI and some set of properties, one should not expect to be able
to do a PROPFIND on that URI  to read the same set of properties.    One
should certainly not expect to be able to do a PROPPATCH (the Thai
restaurant would like to increase its rating to five stars but alas it can not)

So you ask why we wanted to support this.  I think the main reason comes
from experience in the digital library and hypertext communities.  You gain
a lot of expressive power by being able to have third party indexes such as
rating or review services.  As you observe, the price we pay is that one
can't tell, from the PROPFIND response alone, whether these are "third
party" properties or not.

Do you see a problem in this?

best regards

Jim

Received on Monday, 1 November 1999 03:28:08 UTC