On Wed, Sep 02, 2009 at 02:24:20PM -0700, Karen Coyle wrote:
> Mikael Nilsson wrote:
> >Well, they *are* dependent due to them using the same property. An
> >implementation deciding whether a metadata record matched this DSP would
> >need to test if any of the two variants matched. There is no way to
> >indicate in the metadata record which variant is intended. This would
> >break the current matching algorithm.
> >
> >I don't see how an identifier would help, but I might be missing
> >something?
> >
> >
>
> Probably you aren't, but I must say that I don't have any knowledge of
> the "current matching algorithm" so I could be missing a key piece of
> the puzzle here. Is it an actual algorithm, or is it implicit in the DSP
> language?
Hi Karen,
The DSP matching algorithm is summarized in the Usage Board document
quoted in an earlier posting [1] as follows:
* First, each description in the description set is compared
with the description templates in the DSP. A match is
detected if the description satisfies the Resource
Constraint in a description template. Each description must
match one description template.
* If a single match is found, the process moves on to
comparing the statements within the description and the
statement templates within the matched description template.
A match is detected when a statement satisfies the Property
Constraint in a statement template. Each statement must
match one statement template.
* If a single match is found, the process then moves on to
comparing the value surrogate within the statement and the
value constraints.
Mikael says that "if the DSP model is not useful for important
use cases, that is a failure of the DSP model" and suggests it
should perhaps be changed. As I understand it, the matching
algorithm could be made more flexible, but at a price in terms
of implementation complexity.
Tom
[1] http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0908&L=DC-ARCHITECTURE&P=31673
>
> What I am concluding, however, is that while constraining properties in
> terms of occurrence works well at the application profile level, any
> constraints relating to what value types are valid for the property
> should probably take place outside of the DSP. As a matter of fact, it
> appears to me that a change in value type (if that is the correct term)
> necessarily results in a different property. So in my mind, [dct:subject
> <- literal value] is very different from [dct:subject <-VES]. Each one
> of these is distinct enough to require its own identity, and they would
> not be interchangeable in an application.
>
> Which means that my reply to Stuart would be that he will need to define
> different subject properties, each with a unique identity. SubjectA and
> SubjectB would then be properties in his DSP. I'm not sure, though, how
> those might usefully relate to dct:subjects.
>
> This seems to me to be a fairly common case, and it came up earlier when
> I was working on the AP design patterns. I don't remember what was
> concluded at that point; it may have just gotten dropped. But I would
> like to give guidance for developers because many will find themselves
> with this need. There has been some agonizing over this relating to
> RDA... again, I don't remember the conclusion, if there was one, but I'm
> sure it will come up again.
>
> 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
> ------------------------------------
--
Thomas Baker <[log in to unmask]>
|