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.

We are getting our languages crossed here. I have been excorciated by 
W3C folk in the past for claiming that only documents are 'on the 
web', and told that this phrase is intended to mean not that 
something is *retrievable* through the Web, but that it can be 
*mentioned* on the Web. So for example, the existence of a URI 
convention for telephone numbers means that every telephone is "on 
the web". So in this sense of "on the web", the entire sum of all 
past and future human experience is indeed on the web. Nothing to do 
with mere retrieval.

>
>>>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.).

Right. OK, I spoke too quickly.

>
>>>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.

That is what I originally assumed, but I gather that my summary is 
the received W3C viewpoint; and since this usage of the word 
"resource" originates with the W3C, I feel obliged to take their word 
for what it is supposed to mean.

> 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.

That would be one way to go. It would complicate both RDF and its 
semantics, though. Presumably for example it would not be correct to 
interpret <s p o> as meaning that a relation holds between s and o, 
since sometimes it would mean that the relation held between the 
'extension' of one or both of s and o. In fact this is what I thought 
would be necessary when I first agred to try to do a model theory, 
and I was considerably relieved to find that it apparently wasn't 
necessary. (It can get awfully complicated. Suppose one URI denotes a 
document which contains another URI, for example; do we have to say 
that the chain of retrievals keeps going until it terminates in 
something with an extension? (Is there any guarantee of termination? 
What about reference loops?) If we don't, what sense can we make of 
the triple?)

>
>>>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.

My one is, yes. But I thought you wanted it to not be.

>
>>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)

Nice point. I'll think about that some more.

>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)

Thanks for the pointer. I like this a LOT. Larry is not confused by 
the use/mention distinction.

Sigh. At the DAML kickoff meeting I asked the assembled WWWebbies 
whether the idea was that this semantic markup was a description of 
the web page, or of what the web page described? And I got the 
cheerful answer that it didn't really matter, but both. I worried 
about that at the time, and think I was right.

Pat

---------------------------------------------------------------------
(650)859 6569 w
(650)494 3973 h (until September)
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Tuesday, 11 September 2001 21:16:55 UTC