On 2/28/12 3:09 PM, Thomas Baker wrote:
> Many of the patterns on [1] -- in my reading -- point to a constraint language.
I wish I could be on this call, but I'm on another one. I do want to say
that an example like:
"A description with a single statement, which uses a literal value with
a Syntax encoding scheme."
is written in terms of an assumed solution rather than a user task which
may lead to a solution. If you've already got things called "literal
value" and "Syntax encoding scheme" you have started with a fair amount
of baggage. I would suggest expressing the examples in terms of things
that people want to do (actions) rather than particular solutions
("syntax encoding scheme") and see what solutions are needed.
And example of 'want to do':
- give a plain text description of something (the title of my book is "")
- give a description of something using a controlled vocabulary of terms
that are listed here ("red" "yellow" "blue")
- give a description of something using a controlled vocabulary that
exists as a list somewhere and can be identified (...)
- express a value that is a known data type (e.g. currency)
- describe something that has multiple parts, all of them plain text
(RDA publisher statement, made up of place, publisher and date)
- etc.
kc
> If so, does a constraint language need to be based on an abstract model the way
> DSP is based on DCAM? What, then, are the requirements for DCAM?
>
> Rather than jump straight to these abstractions, I'd like to use examples to
> clarify the basic requirements.
>
> Tom
>
> [1] http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
