Karen, I support your underlying proposition that having available useful information around such design patterns and the decisions inherent in them would be highly useful. In my courses at the University of Washington that look at, and work with the DSP, these are the issues that arise continuously--these "what if" scenarios around very common use patterns in systems. I cannot imagine that the situation is any better in the implementer community.
Karen, it would seem to me (and I might well be mistaken) that the template (use design pattern) you set out below does not actually raise the user input problem you infer. For your pattern (template) to be complete (and your problem to arise), wouldn't you need an additional ValueStringConstraint to accommodate identification of an actual literal value (optionally, in your example) from the LCSH namespace? At that point, the question of whether any given value is or is not from the optional namespace arises.
Stuart
-----Original Message-----
From: DCMI Architecture Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: Sunday, June 28, 2009 9:55 AM
To: [log in to unmask]
Subject: Design Patterns
I mentioned in a previous mail that I had started work on some design
patterns for DSP elements. I'm going to continue in that direction,
mainly because I like to work with sets of building blocks when tackling
a complex project. The design pattern page that I started is at:
http://dublincore.org/dcmirdataskgroup/apDesigns
I think we can also use this to satisfy one of the criticisms that we
got of the DCAP document: that it didn't provide criteria for
decision-making. An example is the third (and, alas, last) design
pattern on that page where a statement has:
<NonLiteralConstraint>
<VocabularyEncodingSchemeOccurrence>optional
</VocabularyEncodingSchemeOccurrence>
<VocabularyEncodingSchemeURI>http://purl.org/dc/terms/LCSH
</VocabularyEncodingSchemeURI>
</NonLiteralConstraint>
This is legitimate in the DSP sense, but I would probably only choose to
make a vocabulary encoding scheme optional under truly extraordinary
circumstances. The consequence of having an optional encoding scheme is that
1) it will be hard to provide a helpful user interface for the inputter,
since you won't know if the person is attempting to input a term from a
list, or a non-list term. Validation on input will be difficult. The
only solutions I can think of would result in overly complex code and
possibly a messy interface.
2) it will be hard to provide support for linking, for i18n, and for a
lot of other services that are easier you know what the property values
are.
In other words, this VES value will have all of the disadvantages of a
literal value property.
Instead, I would probably create two separate properties, one for the
controlled vocabulary and one for uncontrolled. (How it would look to
the metadata creator during input is open -- there are different ways it
could be handled.)
We could add to the design patterns some of the possible consequences of
different choices. The controlled list section could show different
options for such lists, and what capabilities each best supports. This
is the kind of information that we were criticized for not having in the
DCAP document: Why would I choose this option? What are the consequences
of x vs. y? Or our design patterns could be presented in the form: if
you want to do x, here's your design pattern.
I don't expect that we could cover all cases, but I do think we could
provide real guidance for most of what people need to do. And we'd all
have building blocks that we could re-use in our own projects, saving us
all time.
Comments?
kc
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
|
