Hi Stuart,
On Mon, Aug 31, 2009 at 08:15:48AM -0700, Stuart Sutton wrote:
> I hope you do not mind if I press the example a bit further.
> Setting aside the wisdom of having a property with "both
> allowed", it does happen. For example, a project I am working
> on wants to make it possible to include "subjects" in a form I
> might call 'keywords' (free text--i.e., no URI) AND/OR terms
> drawn from specific VES (some VES with Value URI and some others
> with VES URI and no Value URI). And, let's assume, that we
> intend those keywords to be legitimate literals in terms of the
> Abstract Model as you just described, Mikael. Now,
> (unfortunately?) the scenario I just described is not a case of
> "no further constraining". When it comes to the VES, there are
> several constraints. In such a case, how can I represent this
> in a DSP? Am I talking about two separate statements
> representing subject (one literal and another nonliteral with
> VES constraints)? With DC creator in your example, Mikael, a
> similar scenario might be handled by using both the dc:creator
> (for literal) and dcterms:creator (for nonliteral) if I wanted
> data that modeled true to the Abstract Model. But I do not seem
> to have the same luxury with dc:subject/dcterms:subject. Or do
> I? Or have I again wandered off base? Or is my scenario
> absolutely untenable?
This reminds me of an issue that the Usage Board encountered in
its review of the Scholarly Works Application Profile [1] (see
excerpt below).
The problem we found was that SWAP, as written, could be used to
make statements that would match not just one statement
template, but (in this case) two statement templates -- a
condition that violated the matching algorithm outlined in
Section 3 of the DSP draft.
In the discussion, Mikael wrote [2]:
> To begin with, SWAP is the authority here, not the DSP model. Don't
> adjust SWAP to reflect DSP quirks unless the changes are well motivated
> by other arguments.
>
> Second, SWAP is obviously stretching the processing model of the DSP.
> This is to be expected - the DSP processing model was intentionally made
> simple so as not to need a full SPARQL-like query processor to work.
>
> Third, if the DSP model is not useful for important use cases, that is a
> failure of the DSP model. I'm not surprised by that either, to be honest
> - there's a reason we left the DSP model in Workin Draft status: so we
> could gather this kind of feedback.
>
> So: I think the right conclusion is that you're running into limitations
> of the DSP model that we will need to feed back into improvements of the
> DSP model itself.
Stuart, I see your requirement as related because you also want
to have two distinct statement templates using the same property
constraint. I'm not sure the SWAP case helps answer your
question, but it does shine more light on an aspect of DSP that
clearly needs further discussion.
Tom
[1] http://dublincore.org/usage/reviews/2009/swap/index.shtml
[2] https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0901&L=DC-USAGE&P=4493
---------------------------------------------------------------------
Excerpt from: http://dublincore.org/usage/reviews/2009/swap/index.shtml
A discrepancy between the DSP specification and the SWAP profile
The reviewers found a discrepancy between the SWAP profile and
the DSP specification with implications for "conformance".
The DSP working draft (2008-08-31) defines an approach to
describing the structure of a description set in terms of a set
of constraints against which an individual description set can
be "matched" -- i.e. analyzed to test whether the description
set satisfies those constraints or not.
Section 3 of the DSP draft describes how that matching process
works. The process has three stages:
* 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.
The version of SWAP submitted for review provides a DSP
containing five description templates.
The "Expression" description template contains sixteen statement
templates. Of these sixteen statement templates, two templates
(the template labeled "Entity Type" and the template labeled
"Type") use an identical Property Constraint -- a Property List
Constraint referring to a single property
http://purl.org/dc/elements/1.1/type. The consequence of this
is that when a statement using the dc:type property is analyzed,
it will always result in matches against two statement
templates, i.e. it is impossible for step 2 of the process
above to complete successfully; it will always fail to match the
statement to a single statement template.
In light of this discrepancy, the Usage Board was obliged to
conclude that the review criteria do not match the reviewed
application profile on this point, and that SWAP therefore
cannot be said to conform with the criteria.
Possible revisions to SWAP which might have resolved the
discrepancy, such as combining the two statement templates into
one single, "weaker" statement, or changing one of the statement
templates to use a different property list constraint (e.g., by
using rdf:type for one of the two) were, in the end, considered
to be outside the boundaries of "minor editorial correction" and
more properly an issue for the SWAP maintenance community.
Indeed, it was suggested that the matching algorithm defined in
the draft DSP specification itself be re-evaluated in light of
the SWAP example -- a task for the DCMI Architecture Forum.
While the Usage Board review did not produce a "positive"
result, it had the effect of uncovering an issue of more general
significance for the automated processing of metadata.
--
Thomas Baker <[log in to unmask]>
