Re: Working on glossary

At 01:35 PM 9/11/01 -0500, you wrote:
>>Problem statement:
>>
>>The web currently contains many things, identified by URIs, that 
>>correspond to ideas like "the current weather".  I think this is 
>>something that makes the web truly valuable -- the ability to deliver 
>>dynamic information.  If RDF cannot describe these things then I think it 
>>falls very short of the goal to be able to describe all things that are 
>>"on the Web".
>
>I've never beleived for a second that RDF can describe all the things that 
>are on the web. RDF is really a very, very small language with very 
>limited expressiveness. It isn't a miracle cure for the whole of semiotics.

Yes... I'd have thought the things that are "on the web" (resources with 
retrievable entities) are similarly limited when compared with the world of 
experience available to and described by us humans.

>>Some tangential background:
>>
>>One of the challenges of functional programming, in its strictest form in 
>>which all values are immutable, is its use in applications that deal with 
>>inherrently dynamic things (text editors, real-time control, etc.).  The 
>>approach that I have seen adopted is to treat such things as sequences of 
>>values, or time-varying functions. Coupled with techniques like lazy 
>>evaluation that only evaluate values as they are required, a program can 
>>represent and handle such possibly-infinite values.
>
>Right, continuations and that kind of thi ng.

Well, there are some similarities, but I wasn't (yet) going as far as 
continuations (which I see as a device for representing state-changing and 
-dependent processes as pure functions).  But I can imagine a 
continuation-like approach would be required to handle web state updates 
(HTTP POST, PUT, etc.).

>>Possible solution?
>>
>>(This may be a horrible abuse of a new trick, but I must try...)
>>
>>The functional programming trick seems not dissimilar to the 
>>relational-extension trick used in the MT denotation of RDF 
>>predicates.  Can it also be applied to the denotation of resources?
>>
>>So, a "resource" is the thing identified by a URI.  Why not have the idea 
>>of a resource extension that corresponds to the set of entities that can 
>>be retrieved via a resource, where each entity is a static sequence of 
>>octet data?
>
>But there is something basically wrong with that picture. Entities (and 
>resources) are *not* streams of octet or any other data, in general: they 
>can be real solid things like books and people. (This may be tangential to 
>your main point.)

Not so much tangential as an alternative view, I think...

>>(At this stage, for the purpose of testing the resource extension idea, 
>>I've deliberately stuck to things that can actually be retrieved on the 
>>web, and left unspecified any correspondence there may be between the 
>>data and other real-world objects.)
>
>As I understand it, the real-world objects *are* resources, so the idea of 
>being retrievable on the web simply isn't applicable to resources in general.

You may be right, but...

The alternative view I'm trying to offer here is that real-world objects 
are not resources, per se.  In addition to the octet-sequences that are 
web-retrievable entities, I'm suggesting that the real world objects are 
(also) part of the resource extension I mentioned previously, rather than 
the resource directly.

>>Then, the resource can correspond to the current weather forecast, but 
>>its extension includes the set of all weather forecasts for all 
>>times;  the particular member of that extension one retrieves depends on 
>>when the retrieval is performed.
>
>We could do something like this, but this is what I meant by a modal 
>(possible-world) semantics, since the denotation here ought to be not the 
>entire extension (in your extended sense) but the particular member of it 
>at the time the query was made. The semantics on this case would need to 
>introduce a notion of times and time-relations in order to make snes eof 
>this notion of 'now'. (It could be a very simple notion, eg points with a 
>total order, but the point is that we would need to say *something* about it.)

Yes, indeed, but such (time-sensitive) semantics would be part of the 
semantics of a resource, about which the RDF model theory you have 
described seems to be agnostic.

>In the meantime however we could also just put this issue off to the 
>future, and the current MT be thought of as kind of instantaneous 
>time-slice of this extended temporal semantics.

Yes, it's another approach.  But it doesn't seem to adequately capture 
(fairly common) web resources like the current weather forecast without 
explicitly introducing the machinery to isolate a time slice.

If this were a curried-function exercise, it seems like a choice of 
parameter ordering of a supposed (GET) function that retrieves information 
about the universe of discource:

    (GET) (http://example.com/weatherforecast) (time)
or
    (GET) (time) (http://example.com/weatherforecast)

In the latter case, which you seem to argue for, one can create a composed 
function
    ( (GET) (date) )
which would query some aspect of the universe of discourse at a given 
time.  Even for non time-varying resources, the time parameter would have 
to be supplied before the result can be applied to the URI parameter.

What I am suggesting is more like the former case, in which the URI 
parameter is supplied first.  Depending on the nature of the resource, the 
result of that may be a curried function that accepts a time parameter to 
select the required (sub-)entity.

I think these are both reasonable design choices, but ...

>>It seems to me that this treatment of resources is allowed by, and 
>>orthogonal to the current model theory, because it still provides a fixed 
>>denotation for each URI, just one a that is more complex than originally 
>>envisaged.  It also seems, to me, to capture something of the intent of 
>>RFC2396.
>
>I wonder what the intent of RFC2396 actually was, I have to confess. It 
>just seems to me to be confused.

Well, I don't know if a document can be confused ;-)  But when I've spoken 
to authors of RFC2396, they don't seem to be confused about what they meant 
(which isn't proof that they weren't).  The alternative to  your view I am 
suggesting seems to be consistent with the view I have understood them to 
express.

It might be worth noting that one of the authors of RFC 2396 (Larry 
Masinter) has recently published an Internet draft in which he seeks to 
distinguish between URIs that directly identify a web-retrievable entity, 
and URIs that identify a possibly web-retrievable *description of* some 
entity. (See 
http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-00.txt)

#g


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
------------------------------------------------------------

Received on Tuesday, 11 September 2001 15:57:52 UTC