The Resource Constraint has only the "Class" constraint right now, and
there is no other way to match Descriptions to DTs.
The reason that ONLY the RC is used to bind Descriptions to Description
Templates is simplicity. Currently, matching description to DTs is
straightforward - you take each description, and you walk through the
list of DTs to see which one matches. Zero matches => fail, more than 1
matches => fail.
What you're looking at are what SHAME calls "path constraints". That is,
a description can be bound to a DT based on the resource's occurrence as
a value in a separate description.
The problem with this approach is twofold:
1. It makes the matching algorithm MUCH more complex, as you need to
keep track of what resource was bound to what VALUE. And what happens if
an ST does not match inside the description of a value? You need to
backtrack, remove the binding of the non-literal value constraint to
that value, etc. This is doable (we do in SHAME), but a much more
complex method.
2. This problem can be partially remedied by *requiring* that DSPs only
describe hierarchically organized Description Sets. I did not originally
want to make that a requirement, as a DCAP need not necessarily be
hierarchical. But again, that's what we do in SHAME, and it certainly
makes things easier again.
The consequences would be:
1. Resource Constraints can be removed completely. This is not
necessarily a bad thing. RCs are semantic constraints, ("type" needs to
be matched against sub-classes as well).
2. One DT needs to be declared as "root".
3. All DTs need to be connected to the root through a series of
"description template references" in non-literal value constraints.
We might need to think about adjusting the model in that direction.
/Mikael
tor 2009-01-15 klockan 16:00 +0000 skrev Pete Johnston:
> Hi Mikael,
>
> Very, very belatedly, a minor comment on the DSP draft on an issue I
> just noticed...
>
> http://dublincore.org/documents/2008/03/31/dc-dsp/
>
> In section 3, the description of the matching algorithm talks about
> matching descriptions to Description Templates based on the Resource
> Constraint in the DT, and matching statements to Statement Templates
> based on the Property Constraint in the ST.
>
> The second case (matching statements to STs) is OK, because section 6.4
> tells me about the various flavours of Property Constraint.
>
> But for the first case (matching descriptions to DTs), I don't think the
> document defines what a Resource Constraint is. I think the Resource
> Class Constraint (5.5) is one example of a Resource Constraint, but as
> this is optional, I think it is also the intent that one can get a match
> based on a Description Template Reference in a Statement Template in
> another Description Template.
>
> Anyway, I think we need an explanation/definition of what a Resource
> Constraint is?
>
> Pete
> ---
> Pete Johnston
> Technical Researcher, Eduserv Foundation
> [log in to unmask]
> +44 (0)1225 474323
> http://www.eduserv.org.uk/foundation/
> http://efoundations.typepad.com/efoundations/
>
--
<[log in to unmask]>
Varning! E-post till och från Sverige, eller som passerar servrar i
Sverige, avlyssnas av Försvarets Radioanstalt, FRA.
WARNING! E-mail to and from Sweden, or via servers in Sweden, is
monitored by the National Defence Radio Establishment.
|