[returning this to list, as per Kai's suggestion]
Thanks, Kai. I think we can resolve this with test cases, especially as
we look at the requirements. One place for us to pay attention is where
there are requirements for relationships between statements: exclusive
OR, inclusive OR, NOT. These may be tricky
kc
p.s. BTW, it looks like there may soon be a way to create BIBFRAME data,
although there is already a model for this that just needs a backend.[1]
It includes pull-downs for adding name and subject identifiers. Creating
a profile for a small amount of BIBFRAME data could allow us to make a
number of test records. We could also create a template for a set of DC
Elements that would work with this same software. (Kevin Ford's test DCE
template[2] and editor [3])
kc
[1] http://bibframe.org/tools/editor/
[2] http://3windmills.com/dc-in-bfe/dc.json
[3] http://3windmills.com/dc-in-bfe/
On 10/20/14 4:12 PM, Kai Eckert wrote:
> Am 20.10.2014 01:18, schrieb Thomas Baker:
>> The issue goes back to the "matching algorithm" in the DC-DSP draft [1],
>> which specified that a Description or Statement was to be bound to
>> exactly one Description or Statement _Template_:
>>
>> The fundamental usage model for a DSP is to examine whether a
>> metadata record matches the DSP.
>>
>> Matching of a description set is defined as follows:
>> ...
>> Binding of statements to statement templates
>> For each description, each statement is bound to a Statement
>> Template in the corresponding Description Template by evaluating
>> the Property Constraint. Each statement must be bound to exactly
>> one Statement Template.
>> Evaluating constraints
>> Now that all metadata in the description set has been bound to a
>> template, all constraints can be verified.
>>
>> So the general issue, as I see it, is indeed whether multiple data
>> shapes can be defined for statements using the same property. My
>> spontaneous reaction is that it must be possible to define multiple data
>> shapes for a given property X (e.g., see SWAP [2] and its review [3];
>> see also [4]) and that the question is whether it should _also_ be
>> possible to specify that statements with property X _must_ match a
>> specific template.
>
> Maybe it is just too late but I do not yet get it completely... so
> anyway, this should (1) be on the list of issues to be dealt with when
> DSP gets updated and (2) in this moment be discussed in a call until
> everyone understands what this is about.
>
> I nevertheless try an interpretation and hope I do not add to the
> confusion:
>
> The question is, if we see a set of constraints as a description
> template that provides one statement template per statement or if we see
> a set of constraints as a set of independent constraints, like rules
> determining something about a property-value pair in the context of a
> description. All constraints are evaluated independently.
>
> I see this difference, yet I am not sure if there is a practical
> (negative) consequence of the latter interpretation. I see a positive
> one: it is more flexible and allows indeed several constraints per
> property. This is actually quite convenient, as you could have a strict
> constraint (like: has to be literal) and a soft constraint (like: should
> contain unabbreviated firstname).
>
> Cheers,
>
> Kai
>
> PS: I wouldn't mind if this is transfered back to DC-ARCH, if we
> continue this valuable discussion.
>
>> Tom
>>
>> [1] http://dublincore.org/documents/dc-dsp/#sect-3
>> [2] http://dublincore.org/archives/ukoln/www.ukoln.ac.uk/SWAP/Scholarly_Works_Application_Profile/index.html
>> [3] http://dublincore.org/usage/reviews/2009/swap/
>> [4] http://dublincore.org/usage/meetings/2008/09/berlin/review-swap/SwapConstraints.html
>>
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|