Commants on 'Primitive elements' terminology

From: Henrik Frystyk Nielsen (frystyk@w3.org)
Date: Fri, Apr 23 1999 

Message-ID: <3720B058.286DF602@w3.org>
Date: Fri, 23 Apr 1999 13:39:36 -0400
From: Henrik Frystyk Nielsen <frystyk@w3.org>
To: lavoie@oclc.org
CC: www-wca@w3.org
Subject: Commants on 'Primitive elements' terminology


Brian,

Thanks for updating the draft - it looks great - here are my comments on
the first part (I have indicated the proposed changes by prefixing them
with "Change").

>    Primitive Elements
>    Primitive elements are general concepts needed to develop the
>    Web-specific concepts used in Web characterization.
>    
>    Resource
>    A discrete, identifiable collection of network-accessible information,
>    recorded in a physical medium.

I know you may not agree (please see my discussion below after your
discussion) but I would add the sentence that it is identified by a URI.
The part "recorded in a physical medium" is not true for streamed data
like what you get from webcams etc.

Change: "recorded in a physical medium" to "identified by a URI"

>    Examples:
>    Web page, Web site, online-database query results, e-mail message,
>    Java classes ...

A "Web site" is not normally what I consider a resource. I would propose
"a collection of web pages" instead.

Change: "Web site" to "collection of web pages"

If you think of the *result* of a data base query as being what goes
over the wire then this is not a resource - that's an entity (or
manifestation - I like that term!). If you think of the result as having
identify in itself then you are right.

Change: "query results" to "a service that provides information from a
database, or information collected from a database"
    
>    Discussion:
...
>    I threw out the requirement that a resource have a URI. Since we're
>    viewing a resource from a general perspective, we have to think about
>    things that don't have well-defined URIs, but can be identified in
>    other ways. For example, a set of results retrieved through a database
>    query can be identified by the URI of the database search engine
>    combined with the query parameters.

What you are accessing is still a resource and that resource does have a
URI. It is not necessarily the case that all the parameters sent in the
request can be identified as a URI. For example, if you are sending a
(POST) request ordering a pizza then you also have to include payment
and where to send it. That is not a resource but the pizza ordering
service is.

If you are doing a GET request on a weather map where you specify that
it sould be over boston around yesterday noon then this can be expressed
as a URI.

>    Resource Manifestation
>    A rendering of a resource at a specific point in time and space. A
>    conceptual mapping exists between a resource and a resource
>    manifestation (or set of manifestations). A resource remains static
>    even when its content i.e., the set of resource manifestations
>    currently prevailing changes over time, provided that the conceptual
>    mapping does not change.

Change "A resource remains" to "The identity of a resource remains"
    
>    Examples:
>    real-time information accessed from a news Web site on a particular
>    day, a rendering of a multimedia Web page accessed with a particular
>    client ...

Other exmaples that you might add are "today's stock quotes", "today's
news headlines".
    
>    Discussion:
>    Henrik has mentioned that "entity" is the accepted term for this
>    concept, but since I don't think this is a good term, I'll make one
>    more attempt at a different one.

I agree that entity is not a good term - but at that point in time it
was too late to change in HTTP. I like manifestation!

> In the library world, a distinction
>    is made between a work ("Hamlet") and a manifestation of that work (a
>    videotape of a production of "Hamlet"). This seems to be what we're
>    driving at as well. If the term "entity" has wide-spread use, I'll
>    switch back to that in the next draft.

The term "entity" has wide spread use (because of HTTP and MIME) but I
think that if we just make the connection then that's fine:

Add: "The term manifistation is equivalent to the term entity in HTTP"
    
>    Client
>    The role adopted by an application when it is retrieving and/or
>    rendering resources.

Whether the resource goes over the wire is a property of the service
used. An email message (the resource) travels over the net from the
sender to the recipient. A web page served by HTTP doesn't go anywhere
but sends a manifestation of itself.

Change: "rendering resources" to "rendering resources or manifestations
of resources"
    
>    Server
>    The role adopted by an application when it is supplying resources.

Similarly, a server can either ship the resource or a manifestation:

Change: "resources" to "resources or manifestations of resources"
    
>    Discussion:
...
>    One other point on clients: does an application have to make a
>    specific request for a resource to be a client? For example, when a
>    Web server is accepting an HTML form from a user, is it acting as a
>    client, even though it did not specifically request the form?

No, in that case it is still the server - the client posts data to the
server. However, you can think of certain ways of handling PUSH as the
server really turns around and becomes a client.

>    Message
>    A unit of communication exchanged between identical network layers
>    located at different hosts.

Change: "identical network layers" to "equivalent network layers or
services"
   
>    Examples:
>    A datagram sent from one Internet layer to another, an e-mail sent
>    from one e-mail reader and received at another ...
>    
>    Request
>    A message containing an atomic operation to be carried out in the
>    context of a specified resource.
>    
>    Examples:
>    HTTP GET, POST, PUT, and HEAD methods ...
>    
>    Response
>    A message containing the result of an executed request.
>    
>    Example:
>    An HTML file, a server error code ...

Change: "file" to "document"

>    User
>    A human using a client to manually (interactively) retrieve and render
>    resources.
>    
>    Examples:
>    A person using a Web browser, a person using an e-mail reader, a
>    person using a CRT terminal emulator ...
>    
>    Discussion:
>    The notion of a user being human is essential to this definition; we
>    want to separate the behavior of a person from that of an automated
>    client (like a spider).

I agree that the distinction is important and I think this is fine as
long as it is not linked to the application. The point that I tried to
make is that often the behavior of an *application* can change
dynamically over time from being a 'browser' to a 'robot' etc.

Henrik