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