RE: on documents and terms [was: RE: [WNET] new proposal WN URIs and related issues]

> From: Pat Hayes [mailto:phayes@ihmc.us] 
> >> From: David Booth
> . . . 
> >>  3. The Web page itself: a document, consisting of  
> >> characters, which 
> >> conform to XHTML syntactic  rules.
> >
> >If it conforms to XHTML syntactic rules it
> >sounds like you are talking about a particular 
> >instance of a document rather than a document in 
> >the abstract sense (which may change over time)
> 
> No, a document does not change over time, in 
> either the abstract or concrete sense. To refer 
> to documents changing over time is simply an 
> ontological error. 

It's not an ontological error, it's a different definition of
"document".  Your notion of "document" is static, which is fine, that's
one meaning of the word.  It's what I would call a "document instance"
-- a particular chunk of information -- if I were trying to
disambiguate.  (Incidentally, I'm restricting my attention to
information objects -- not physical, paper documents.)  

But the word "document" is also often used to refer to an abstraction of
information whose content may change over time -- what I would call an
"abstract document" to disambiguate.  Whenever someone speaks of
"modifying a document" they are necessarily talking about an abstract
document, since it is not possible to modify a particular chunk of
information.  (If you try, you simply get a different chunk of
information.)  

The "Previous version" link at the top of the WebArch document[10] is
implicitly saying that there is an abstract document and the information
content of the abstract document changed from the previous version to
the current version.

> There is nothing in the XML 
> spec that refers to documents changing over time. 

True.  Specs like that often use the word "document" to mean "document
instance" rather than "abstract document".

> Literary documents, legal documents and other 
> documents do not change over time. 

Well, yes and no.  Document instances don't change; abstract documents
do.  For example: "My lawyer and I just finished several iterations of
editing and updating an important legal document".  That's referring to
an abstract document.

> In many cases, 
> it is part of the very reason for having the 
> document that it does not change over time. RDF 
> graphs do not change over time. According to the 
> TAG and REST, resources are defined to be able to 
> change over time (more properly, to be functions 
> from times to representations) but that does not 
> imply that documents are resources: this is in 
> fact one of the issues that we need to get clear. 
> It seems that they cannot be, in fact, for this 
> very reason: the only way to describe this 
> situation coherently is to say that a resource 
> can be a function from times to documents (the 
> 'version' at that time).

Exactly.  (Assuming you mean document *instances*: ". . . a function
from times to document *instances*".)  That's why I believe the TAG
necessarily means "abstract document" when the WebArch says: "This
document is an example of an information resource."[10]

> . . . Something is classified 
> as a 'representation' simply by virtue of it not 
> changing over time? 

"Not changing over time" is a necessary but not sufficient condition of
something being a "representation", because a "representation" is a
particular chunk of information, whereas an information resource is an
abstraction.

> This is the most 
> extraordinary idea, and bears absolutely no 
> relationship to the normal uses of this 
> terminology. How can an abstract document be a 
> representation of one of its own instances or 
> tokens? 

It's the other way around: a "representation" (in the WebArch sense) is
an instance (i.e., a snapshot) of an abstract document.

> . . .
> >True, but if one is discussing the TAG's WebArch
> >document ( at http://www.w3.org/TR/webarch/ ), 
> >it is essential to make this distinction, 
> >because the difference between a 
> >"representation" and an "information resource" 
> >is essential to the WebArch.
> 
> I repeat, the WebArch is incomprehensible. The 
> point, for me, of this entire discussion is to 
> try to make sense of it. I know that the WebArch 
> makes this distinction between "representation" 
> and "information resource", but it never defines 
> either of these terms, so I have no idea WHAT 
> distinction this is supposed to actually BE. To 
> be told that an incomprehensible distinction is 
> 'essential' is not very much help.

Sorry!  I'm trying to make sense of them too!  :)

> >>  . . .
> >>  An RDF ontology, at any rate, is either an RDF
> >>  graph or an RDF/XML XML document. Either way, it
> >>  is not an HTTP endpoint or an abstraction of an
> >>  HTTP endpoint. So it cannot be an information
> >>  resource in David's sense, seems to me.
> >
> >Yes, it can be if instances of it are intended to be served via HTTP.
> 
> No, I am sorry, it cannot. The fact is that an 
> HTTP endpoint, given your answer above to my 
> question, is not even in the same category as an 
> RDF ontology: it not the same KIND of thing. So 
> if an information resource is an HTTP endpoint, 
> then it cannot possibly be an RDF ontology. If 
> you want an RDF ontology to be an information 
> resource, then you must change your definition. 
> This has got nothing to do with the transfer 
> protocol.

Again, it depends on what you mean by "RDF ontology".  If you are
talking about an RDF ontology as a particular chunk of information then
I agree it cannot be a logical HTTP endpoint.  But if someone is talking
about an RDF ontology as an abstract thing (which may have various
versions at different times), then you can think of that as a logical
HTTP endpoint: it is a function from times to instances a/k/a
"representations".

[1] DBooth proposed definition of "information resource":
http://lists.w3.org/Archives/Public/public-swbp-wg/2006Apr/0053.html

[10] WebArch definition of "information resource":
http://www.w3.org/TR/2004/REC-webarch-20041215/#def-information-resource

David Booth

Received on Saturday, 29 April 2006 03:53:56 UTC