[crm-sig] Re: Physical carrier

martin martin at ics.forth.gr
Sun Jun 9 20:34:05 EEST 2002


Dear Nick,

I think we can summarize:

We can propose an entity "Information Carrier", subclass of Physical Man-Made Object, superclass of Iconographic Object, with property: "is carrier of (is materialized by) : Information Object". Types
of Information Carriers are books, letters, video-tapes, roles, statues, paintings etc. I do not see so critical the question, if the carrier can be viewed
directly or not. I think more important is, that it it tied to the existence of the Information Object:

Even though the immaterial Information Object cannot been destroyed, it is lost when the last carrier is destroyed.
I do not propose to make a model out of that, because I regard it unlikely, that we know what has been the last
carrier (even though in the burning of the library of Alexandria there seems to exist knowledge about some lost
infomation), but I regard this aspect as vital for the definition.

I would not extend Information Carrier to coins etc. Any Physical Stuff can be regarded as carrier of some
information, but I think this is not very helpful for the culturally relevant cases we want to describe here,
and the CRM already foresees that any Physical Man-Made Object can show a Visual Item. I think we should
restrict the definition to things which are primarily made for that purpose, like books, letters, CDs etc.,
and I agree with you to imply paintings. Equally statues are often depictions of real people, and so clearly
used to render an information.

In the sequence, I propose to disconnect "Iconographic Object" from "Conceptual Object". The double
inheritance will cause logical problems, when we want to distinguish between material and immaterial.
Iconographic Object would then link to an Image it materializes. We can extend the scope of image to
imply 3D images, be it surfaces like classical statues, but it could also be transparent structures.

best,

Martin



Nicholas Crofts wrote:

> I've been thinking along similar lines. Some supports
> carry only one element, while others may carry
> multiple elements (e.g. cd roms). This would imply
> that the support needs to be described independently
> as an instance of a some suitable class such as
> "information carrier".
>
> There is a potential difference in the *way* that
> certain bear their information objects. Magnetic
> disks, tapes etc. are encoded in some way but and
> require appropriate equipment to be interpreted as,
> say, images. Supports such as photographic
> reproductions, coins or prints, on the other hand, can
> be seen directly. In the former case I can't tell
> whether or not the supports "bears" the image without
> technical manipulation. There are also intermediate
> cases, such as microfilm, where I can look at the film
> and see something, but not as much as with a film
> viewer. The point I'm trying to make (I think) is that
> not all information carriers bear their information in
> an explicit way. I'd hesitate to call a disquette with
> a jpeg file on it an 'iconongraphic object' in the
> same way as, say, a photograph. This is a logical and
> practical distinction but I don't know if it has any
> real consequences for documentation practice, and
> hence for our model. Further discussion may be useful.
>
> A characteristic of supports which is being used here
> in the departement I work for is their "reference"
> quality - pretty much equivalent to how far down the
> reproduction chain they come, or "distance from the
> original". This implies that there is a notion of an
> "original" or source document, and also that there is
> assumed to be some level of degrading with each
> generation. With digital reference material, the
> notion of loss through copying may be inappropriate.
>
> Talking in generic terms, it seems clear to me that we
> need an "information carrier" class, which deals with
> the physical nature of documents, and an "information
> object" class, which is the immaterial, conceptual
> document.
>
> I take it you're suggesting that we should avoid
> having hybrid physico-intellectual type objects
> altogether, and instead have two separate entities
> with a link between them. Fine arts are likely to be
> the area most put out by this approach - the original
> painting is not usually seen as a "carrier" of an
> "image" - though personally I can't see that we lose
> anything in this description, particularly if the
> carrier in question is identified as having special
> status as the (unique) reference copy, by which all
> others are judged. Separating the intellectual content
> from the physical support makes it far easier to deal
> with multiple copies of prints, copies of sculpture,
> etc. as well as photographs of paintings.
>
> Cheers
>
> nick
>
>  --- martin <martin at ics.forth.gr> wrote: > Hi Nick,
> >
> > Here my thoughts about  Physical carrier:
> >
> > Probably similar to "Iconographic Object", tapes,
> > diskettes, books,maps, qipus, wampums etc. are
> > objects designed to be
> > carriers of specific categories of information
> > objects.
> > In order to deal logically consistent with the Type
> > issue, we should introduce the structural property
> > "disjoint with",
> > on the level of subclass/superclass. In that case,
> > the difference between material and immaterial is
> > like mortal and
> > immortal, too deep to make a loose hybrid, like
> > Iconographic Object.
> >
> > I propose to introduce some kind of  Information
> > Carrier, superclass of Iconograhic Object, with link
> > "implements"
> > an Information Object.
> >
> > The problem of (German) "Unikat" , unique
> > intellectual creations of physical nature remains
> > interesting. Probably,
> > the better solution, IFF there is any need to model
> > that explicitly, is to have a simultaneous
> > Conceptual Creation
> > and Production, rather than a hybrid product. A
> > unique as a statue may be, I can copy it with all
> > the shortcomings
> > of any other copies of paintings etc., and
> > nevertheless preserve most of the intellectual
> > contents. The degree to
> > which we can copy, may be a bad crioterion, as it is
> > just a question of technology and not of nature.
> >
> > Martin
> >
> > --
> >
> >
> --------------------------------------------------------------
> >  Dr. Martin Doerr              |  Vox:+30(81)391625
> >         |
> >  Principle Researcher          |  Fax:+30(81)391609
> >         |
> >                                |  Email:
> > martin at ics.forth.gr |
> >
> >         |
> >                Information Systems Laboratory
> >         |
> >                 Institute of Computer Science
> >         |
> >    Foundation for Research and Technology - Hellas
> > (FORTH)   |
> >
> >         |
> >  Vassilika Vouton,P.O.Box1385,GR71110
> > Heraklion,Crete,Greece |
> >
> >         |
> >          Web-site: http://www.ics.forth.gr/proj/isst
> >         |
> >
> --------------------------------------------------------------
> >
> >
>
> =====
> Nicholas Crofts
> DAEL / DSI
> rue David-Dufour 5
> Case postale 22
> CH - 1211 Genève 8
> tél +41 22 327 5271
> fax +41 22 328 4382
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com

--

--------------------------------------------------------------
 Dr. Martin Doerr              |  Vox:+30(810)391625         |
 Principle Researcher          |  Fax:+30(810)391609         |
 Project Leader SIS            |  Email: martin at ics.forth.gr |
                                                             |
               Information Systems Laboratory                |
                Institute of Computer Science                |
   Foundation for Research and Technology - Hellas (FORTH)   |
                                                             |
 Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
                                                             |
         Web-site: http://www.ics.forth.gr/proj/isst         |
--------------------------------------------------------------





More information about the Crm-sig mailing list