As it's a slow day, and the question of adoption has arisen, I venture
to stir the pot with something I wrote awhile back but did not post.
Since writing this I've reviewed the list archive, but didn't find much
discussion of the points I make here.
As I missed the conference, I may just be ignorant of discussion there
that would answer all my questions.
In any event, I agree with Stu that adoption by a badge-issuing authority
is important, and (despite my minor reservations about the possibility
of confusion with the URN effort) I think the IETF is the place to talk
about MIME types. But is it a MIME type for DC or WF that's wanted?
Here goes ...
27 July 1996
I regret that I was unable to attend the Warwick conference, and apologize
for the tardiness of these comments on its outcome. I am concerned that the
Warwick Framework has seized the wrong stick by the wrong end.
The theme of the conference was "identifying and resolving impediments to
deployment of a Dublin Core style record for resource description," which
I applaud.
The result was the specification of "a container architecture for aggregating
metadata objects for interchange." I have not been able to discover in what
way this differs from the more homely "packaging A, B, and C, and saying
that they're all somehow about X." I think that's too vague to be useful.
We already possess many architectures for aggregating objects; the WF
notion of containers that contain packages, but that may have meta attached
to them so that they would in turn have to be contained in containers,
is no advance on any of them, and explicitly permits infinite regress
without practical advantage. It's enough for me that the information
is collocated by some process my system understands (e.g., MIME's
multipart/related); that process doesn't need any WF containment syntax.
But totally aside from regress and the question of whether specifying
a containment architecture is useful (I think of this as the "wrong stick"),
the WF makes no advance on the issue of the semantics of the "packages"
(thus the "wrong end").
I really don't care what wrapper the bibliographic data comes in (my
application can either use it or it can't), but I need to have the content
labelled as bibliographic data, as distinct from discursive literary reviews
or ISO 9000 evaluations or interpretive essays (such as may be included
in finding aids). I want to know that this multipart/related stuff,
or that tar file, contains one kind of thing or another.
I don't need the trivial formalism of containers and packages; I need
refinement of the semantics "these are somehow about X," so that when
I search for "stuff about X" I can extract from the results "bibliographic
data" for one process (e.g., locating and retrieving the information so as to
show my professor that I actually found it) and "interpretive essays" for
another (e.g., plagiarizing them for my term paper).
The issue is how to attach these semantics to or encapsulate them within
existing and deployed container mechanisms; the MIME implementation
sketched for the WF (though a nice piece of work in itself) ignores this
issue entirely, so far as I can see.
What am I missing? Or, how can we attach semantics about content or
relatedness to such MIME types as multipart/*?
Regards,
--
Terry Allen O'Reilly & Associates, Inc. [log in to unmask]
"In going on with these experiments, how many pretty systems do we build,
which we soon find ourselves obliged to destroy?" - Benjamin Franklin
A Davenport Group sponsor http://www.ora.com/davenport/
|