At 11:53 AM 01/26/2000 -0500, Stu wrote:
>Various people have expressed concerns about how we meet the dumb-down
>requirement as part of our principles.
>Eric and I have talked about this a bit and offer the following three (not
>necessarily exhaustive) possibilities. We think that choosing any of the
>three is a reasonable thing for any particular application.  Acknowledging
>that these options are all reasonable, and are local decisions, removes them
>from discussion about the merits of the qualifiers, and at the same time
>provides much needed guidance to implementors about how to satisfy the needs
>of their constituents while making their data visible  (and interoperable)
>to others to the degree that they choose to do so.
>
>I believe that we need explicit policy recommendations about these (and
>other?) options at some point, but I don't think we can afford the time to
>ratify them now... we offer them now with the hope that they might simplify
>the discussion of qualifiers.  Hope it helps.
>
>1. Promiscuous Concatenation: take the values of the structured data and
>concatenate them for search/indexing purposes.
>
>This is essentially what the Web search engine model is today, except that
>it does this for full text, not just metadata.  So, retrieval will be
>cluttered with extraneous hits, but this is already the case for web
>retrieval, and at least, since it is only metadata that is being
>concatenated, the "semantic density" of a resulting index will be
>intermediate between a full text index and a fully structured index.  The
>other advantage of this approach is that it has a cool name.

Definitely a cool name, but it oughtta be issued with free condoms or 
something.  It's a dangerous game to play with data, I think, and should 
not be in any way considered a 'default.'

>2. Providing a default dumb-down value:  A fully-structured value (eg. a
>vCard or an authority record) would be made available, and a default value
>(eg. a name) would also be made available, either as a repeated element, or
>through available syntactic constructs (such as the ALT value in RDF).

This is something that we'll need to explore when we start talking 
datamodel again, because I think it's a good interim measure for a lot of 
applications that will want to take advantage of 'smart' options, while not 
leaving their 'dumb' brethren behind.

>This has the deficiency of possibly having to maintain two instances of the
>same data (an engineering no-no), but for any system that maintains a
>collection of authority records, it need not be the case, because the only
>true place the data is maintained is the authority record itself... all
>other instances of the data are an algorithmic extraction from the authority
>record.  I understand this is the strategy that the CORC project uses).

I think what happens in reality is that you only maintain one instance (the 
authorized value), and let the other fade away like the proletariat was 
supposed to.

>3. Applications ALWAYS have the option of not providing a dumb-down
>alternative, or ignoring a structured value which is not understood.
>
>In other words, an application may take the position "we provide this data
>only in the structured form we feel is appropriate to our requirements... if
>you don't understand it, we suggest you don't use it."  This is sub-optimal
>in a global interoperability sense, yes, but let us keep in mind that many
>applications may choose *NOT* to support a dumb down option, and there is
>nothing wrong with that... we just want to give good guidance to those who
>DO want to do this.

This last sentence is definitely important.  We cannot save people from 
their own decisions--all we can do is give them information they can use to 
make the best ones they can.

Diane


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%