Mark
I still think you miss the point of whole lots of things on the Web
that just aren't documents.
We have databases, Geographic Information Systems that produce
map overlays and a whole host of scientific models produced on the
fly, etc.
The Web is more than just an electronic version of books and music
(and games) and it is these that we find are the most difficult to find
in search engines.
regards
arthur
ENvironment Australia
>I'd been doing some thinking on the relationship between FORMAT and some
>of
>the issues coming up with TYPE. FORMAT specifies the encoding of an
>object, useful
> for programs rendering the data stream described by the DC record for
>users, content-independent. TYPEs will look a lot like the major MIME
> types but instead of providing readable output to a renderer, usually
>will
> be used to filter or aggregate objects based on a common semantics for
>how
> the content fits into a larger body of information. FORMAT answers the
>question, "how do I decode this object?" and TYPE answers the question
>"once decoded, where do I place this object?"
>
>For example, a FORMAT might be image/tiff and the TYPE would be
appropriate
>to place a scanned page image in the context of an article, monograph,
>etc.
>
>That which is needed to describe the relationship of this object to
> others near it in semantic space should be
> specified in TYPE. So, we would probably need to establish at the top
>level of FORMAT name space a set of descriptors that would look a lot
like
>top-level MIME major types but expressed object semantics instead of
>encoding. I'd like to consider just the text or document namespace
right
>now.
>
>Instead of building an exhaustive list of TYPES, I'd like to push the
>complexity of that down one level. How about establishing a set of 2d
>level document types as follows:
>
>doc is the top-level TYPE category that describes DLO's. I can think
of
>four broad classifications of text-based electronic content:
>
>doc.pub document is catalogued as a traditional publication type
>doc.msg document is catalogued as a message in an online
conversation
>doc.file document is catalogued as a computer file
>doc.form fill in the blank form
>
>It is possible to have more than one TYPE associated with a DC
description
>of an object, so none of this is exclusive.
>
>
>doc.pub.novel
>doc.pub.novel.chapter
>doc.pub.serial
>doc.pub.serial.article
>doc.pub.serial.article.section
>
>doc.msg.email
>doc.msg.news
>doc.msg.ad
>doc.msg.press-release
>doc.msg.promotion
>
>doc.file
>doc.file.homepage
>doc.file.README
>doc.file.archive
>doc.file.db
>
>doc.form.voters-registration
>
>=o=o=
>
>Ideas for the other semantic TYPEs:
>
>two-dimensional visual data:
>pic - image/* picture
>photo
> ,painting
>, drawing
>, graph
>, table
> ,chart
>
>3 or 4 dimensional visual + sound data:
>vid - video/* (pic + [sound] + [*]) * time
>feature
>, short
>, ad
>, documentary, clip
>
>sound data:
>sou - audio/* sound
>music
>, talk
>, ambient
>
>program files:
>prog - application/* program
>prog.bin
>prog.src
>
>miscellaneous types:
>
>dat - data/* data
>env - application/? simulated environment
>con - multipart/* object container (xml <EMBED>-like aggregation,
>CORBA,OLE)
>
>-marc
>
>
>
>
|