Print

Print


On Thu, 20 Mar 1997 15:32:01 -0600 (CST) Dan LaLiberte said:
> > > <URL:http://www.uic.edu/~cmsmcq/tech/metadata.factoring.html>
>
>Charles Wicksteed writes:
> > Michael's paper helps to clarify the problem with multiple instances
> > of a document,
>
>I'm not so clear on that.  Michael's position seems to be that a
>single resource is described by a set of <and>ed terms, one for
>each attribute, whereas for multiple instances, the set of <and>ed
>attributes of each instance are <or>ed together.  This assumes there
>indeed is this logical relationship between attributes, which I am not
>really convinced about.  But in any case, other relationships may
>exist that are not reflected by either <and> or <or>.  One example is
>a signature attached to a set of attributes.

Signatures attached to sets of attributes were not defined in the
Dublin Core at the time I prepared that paper, and so do not figure
in the argument, which is restricted to the problems raised in
Warwick relative to the use of the Dublin Core.  But a digital
signature of a metadata record (which is what I take you to be
referring to) is in any case an attribute of the metadata record,
not of the object being described. It thus seems wholly orthogonal
to the problem I was trying to address, namely the problem of deciding
which attributes (fields) describing an object in a metadata record
describe the same object, and which describe different objects.  The
addition of attributes which describe the metadata record itself does
not seem to complicate this problem, any more than it simplifies it,
and doesn't seem to require any kind of solution.

>But Michael's main argument seems to be that more than one kind of
>grouping construct is needed, regardless of what those kinds of
>constructs are (<and> and <or> are two kinds of grouping construct).

I'm not sure what the phrase 'regardless of what those kinds of
constructs are' means.  I do believe that the relationship among
attributes describing some objects is usefully described by saying
that some given pair of attributes either does or does not describe
the same object.  The addition of new types of objects to be described
does not shake me in this conviction.

>My answer to that is, yes and no.  One kind of grouping construct
>would be sufficient if we could attach some qualifier to it to
>indicate what kind we really mean.  So we really do need more than

A single construct with two variants is two constructs.  If you think
my argument was in favor of <and> and <or> and against <group type
= and|or>, then I apologize for misleading you.

>one kind of grouping construct at the semantic level.  But two is not
>enough either.

Not enough for what?  I've not been reading this discussion in
full, but I don't remember seeing examples of records which have
semantics not susceptible to treatment with AND and OR.  What kind
of extension to traditional Boolean logic do you have in mind that
is going to require a new kind of logical primitive?

>I'd prefer to see a more generic but extensible grouping construct
>rather than a small or large set of very specific constructs, because
>no matter how large that set is, more will be needed.  The SGML

Examples, please.

>approach seems to be to hard code the predefined grouping constructs
>(and anything else) in a DTD without any runtime extensibility or even
>much composability.  My SGML knowledge is limited, so that is mostly
>an intuition.

Many SGML users do have a strong preference for analysing a problem
thoroughly enough that it's possible to see in advance what will be
required, and build it into a DTD.  This also aids in implementations,
since implementors can know what they need to support; run-time
extensions tend to be hard to handle usefully.

But there is nothing in SGML that prevents extensibility, either
document-level extensions to the DTD or semantic extensions.  The
DL mechanism you are arguing for is also SGML.

My apologies if I have misunderstood your point, but you seem to
be arguing that Boolean logic is insufficient to render an account
of what metadata records mean, and this strikes me as inherently
implausible.

-C. M. Sperberg-McQueen