Lou Burnard writes:
 > [...] So far as I know, when one
 > is combining logical assertions such as "metadata fragment x
 > applies to this resource" just two options exist for interpreting
 > any pair of such assertions: either they both apply, or one applies
 > to the exclusion of the other. I am not aware of any other way of
 > grouping pairs meaningfully -- if you are, please tell us, and show
 > why it cannot be reduced to some combination of these two.

Concerning logical combinations of assertions, what about negation?
We don't have a complete logic until we have the equivalent of
negation.  If we are in a pedantic pinch, we could live with just one
operator: the not-both operator.

The single term "or" is ambiguous about an important distinction: it
might mean that the alternative assertions are true of the same
resource or are true of different resources.  (This is different from
the distinction between exclusive-or and inclusive-or.)

But my point was that there are relationships other than logical <and>
and <or> to consider.  We have more than just assertions.  Here are
some examples.

There might be metadata about the metadata, such as a signature
applied to a few of the attributes (assertions, whatever), but not to
all of them.  This meta-meta data could be segregated out to a different 
pile of bits, but should we require that?

There might be a complex qualification of one attribute with a number
of subattributes, such as the details of an address, or the many
contributors and their detailed attributes.  You might say you could
decompose this complex set of attributes into several separate
assertions, but there is still a need to express the assertion about
the assertion, that they are components of a composite.

Even <and> and <or> are assertions about the assertions, but why only
allow those two kinds of meta-assertions?

 > As to SGML -- you can make it as tight or as loose as you want. The easiest
 > SGML dtd to write is one that says any element can be combined with any
 > other in any way you please -- but that does put rather a burden on the
 > application.

But what elements are allowed in the first place?  My understanding is
that it is only a fixed set of elements.  Thus any kinds of
relationships between elements that we want to express must be either
encoded in one of those elements or we need a generic mechanism to let
any relationship be specified.  Yes, such a generic mechanism puts the
burden on the application, but the flip side is, it allows the
application to do more while still taking advantage SGML.  Another
flip side is that if the SGML language doesnt provide this level of
extensibility, the equivalent will be done anyway but as a higher-level
layer on top of SGML, and in an ad-hoc manner until it can be
standardized.

 > To make this a touch more concrete: if I get two metadata fragments
 > that seem to be saying something about a date, I need to know
 > whether

 > (a) the two are to be interpreted together, for example as a date range
 > (b) one of the two applies in some situations and the other in others (e.g.
 >    one is a publication date, and the other an expiry date)
 > 
 > I can't think of any third thing.

So either the fragments are related or they are not related.  But
instead of specifying a date range, the relationship between the
metadata fragments might be something else.  They might be two
alternative dates (exclusive) because it is not known which is
correct.  One fragment might give the type of date or qualifier for
the other.  Etc.  Being able to say what the relationship is, in addition
to the fact that the fragments are related, is what I am talking about.

--
Daniel LaLiberte ([log in to unmask])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/