MUSEUM-L Archives

Museum discussion list

MUSEUM-L@HOME.EASE.LSOFT.COM

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Museum Informatics Project <[log in to unmask]>
Reply To:
Museum discussion list <[log in to unmask]>
Date:
Wed, 28 Sep 1994 16:12:00 PDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (41 lines)
On Date: Wed, 28 Sep 1994 16:17:26 EST
From: Eric Siegel <[log in to unmask]>
says, among other things which I deleted:
 
>    Dare I suggest that this is a revenue stream to the museum,
>    analagous to a publishing program. I mean its *expensive* to
>    database this stuff.
 
Of course, the original specimens/artifacts also were *expensive* to
acquire/curate. That, in and of itself, hasn't been adequate reason
for most museums to think of their collections as "revenue streams."
On the other hand, creative financing of operations is nothing to ignore,
as you suggest.
 
>    In another example, imagine that there is a standard engine
>    for interpolating video images (actually I assume that there
>    is, but I'm not technically up with it.) This is stored
>    locally as software or firmware or whatever on the client.
>    Then all that would be required is the transmission of
>    "clues" from the Museum to provide a full motion video tour
>    of the museum, or whatever interactive content the museum
>    wanted to offer.
 
And, some "engines" already exist and are in wide use. The general
concept for images is "compression", for which a number of standards
exist. The "clues" are the compressed data and the algorithm for
decompression resides on the client, as software/firmware/hardware.
Whether you agree that today's technology is sufficient is another story.
 
>    All I am saying that Negroponte suggested is that taking
>    advantage of computing power on the client side could reduce
>    the  clogging in the pipeline. I mean we all have pretty
>    zippy machines as clients nowadays, and I am pretty sure
>    that the bottlenecks don't take place in our processors,
>    hard drives, or video sub-systems.
 
Today's "zippy" machines are not up to the tasks that many envision
tossing at them. And, processors, hard drives, busses, and video subsystems
_are_ definitely each bottlenecks, along with the networks, to these visions.
Peter Rauch

ATOM RSS1 RSS2