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?
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
------------------------------------
|