W3C home > Mailing lists > Public > public-awwsw@w3.org > November 2010

Re: another crack at 'information resource'

From: David Booth <david@dbooth.org>
Date: Mon, 08 Nov 2010 14:34:28 -0500
To: Jonathan Rees <jar@creativecommons.org>
Cc: AWWSW TF <public-awwsw@w3.org>
Message-ID: <1289244868.5492.19751.camel@dbooth-laptop>
hi Jonathan,

On Mon, 2010-11-08 at 17:50 +0000, Jonathan Rees wrote:
> Another attempt at an 'information resource' theory.
> 
> (I mean 'information resource' in a sense close to TimBL's, not
> in David's sense.)

I'm not sure what TimBL's sense of "information resource" is, but what
you describe below does not sound at all inconsistent with my sense of
an information resource being a function from time and request to
representation:
http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/0046.html 

> 
> As I said earlier, if you assume you're doing design (architecture)
> and not ontology (what exists), the problem gets easier, since you're not
> constrained by reality, truth, etc.; you don't have to be able to
> "identify" information resources in the sense of pointing your
> finger at them, or falsify the "is a representation of" relation.
> 
> Rather than try to figure out what IRs are, let's try talking about what we
> would like to say about them, i.e. properties that they're supposed to
> have, 

Sounds good.

> and then if the question remains, speculate on what we'd like
> them to be like in general.
> 
> Many of the properties that one would like to assert are about
> content: author, title, date written or published, subject matter.
> These properties can vary from one observer to the next, or
> through time: the author, etc. might vary, so we have to decide how
> the properties of the IR relate to the properties of its
> 'representations.'

Yes -- sounds good.

> 
> It doesn't do much good to assert a content property if it can't be
> corroborated by someone else observing the IR [credit Larry
> Masinter], therefore I propose the
> principle that a content property is true of an information resource
> iff it's true of *all* of the resource's representations.  E.g.
> 
> <http://www.w3.org/TR/2010/WD-rdfa-core-20100422/> dc:creator :Ben_Adida.
> 

I'm not sure we want to restrict ourselves to universal quantification.
It is also useful to make statements based on existential
quantification, such as "Fred is the author of *some* respresentation of
Z".

> The quantification is time-bounded in the same way any RDF statement
> is, thus reducing the time problem to one that's previously unsolved.

Sounds good as a starting simplification.

> 
> A "fixed resource" in TimBL's sense of the word would be an IR that
> shares in all the content properties of its representation.

Excellent.

> 
> An annoyance: Suppose that Fred is the author of some
> representations of Z, and that Fred is not an author of
> some other representations of Z. We can infer that Fred
> is not an author of Z (assuming "is not an author of" is not
> considered a content property).  - This will surprise some people, but
> the alternatives are nasty.  Existential instead of universal
> quantification would very quickly lead to inconsistencies.
> Having the implication go only one way is too inferentially weak to be useful.
> Having no connection between representation properties and
> resource properties gets us back to total representation/resource divorce.

I think both existential and universal quantification will be needed.

Think of a series of representations as being like the various volumes
of a periodical publication.  Some facts about it are universally
quantified (such as the publisher name and journal name) and others are
existentially quantified, such as authors and article titles.

> There's another set of properties having to with ways the IR *does* vary,
> e.g. http://news.google.com/ is a news site (representations are
> lawfully related to current events), the weather in Oaxaca example from AWWW,
> http://en.wikipedia.org/wiki/Special:Random ,
> http://www.w3.org/TR/rdfa-core/ (related in a particular way to a
> social process overseen by W3C), and so on.  The content
> properties of representations vary, but they do so in a regular way.

Right: in reality representations may vary by two parameters: time and
the given request.  The time parameter causes http://news.google.com/ to
return different representations on different days; the request
parameter causes it to return different representations to different
users (e.g., based on location or preferred language).

> 
> This leads me to the suggestion that an IR is (or is induced by, or is
> pretty much the same as, or is characterized by, or is a theory of) a
> lawful regularity among representations.  (Compare computer science
> 'invariant'.  Also similar to API.) I don't see any way to make them
> more definite than that without tying them to their incarnations in
> ways we've been trying to avoid.  They are inventions, theories, phlogiston,
> monads. Like FRBR works or expressions only worse.

Hmm . . "lawful regularity"?  That sounds a lot like a function.  :)

> 
> Maybe IRs need a few more conditions.  I would think that physical
> realizability is a condition, i.e. if it can't be put on the web at
> least in principle, it doesn't qualify.  

Now you're getting into mushy territory.  What's wrong with considering
it a function?  Very simple, very will understood, and captures what it
does.  Remember, we're doing architectural design here, so the whole
thing is an idealization anyway.

> And of course our two
> conditions "no physical properties" and "not mathematical" -
> IRs are like other abstractions such as promises and songs in
> this regard, so we ought to be able to make those conditions stick.

Huh?  Where did those come from?  Why are they needed?  IMO they're not,
and they cause harm by leading the reader down the wrong mental path.



-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.
Received on Monday, 8 November 2010 19:35:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 8 November 2010 19:35:07 GMT