Sorry, trying to understand this --
If Stuart wishes to have multiple subject types in his metadata, can he
define a description template with more than one statement Template,
each of which has the property "http://purl.org/dc/terms/subject" but
with different constraints?
I'm assuming not because there is no identifier for a statement
template, therefore I can't see how a particular one would be addressed.
So it seems that any particular property can be defined once and only
once in a statement template. (Although, Example 11 of the DSP document
shows otherwise... in error?)
Would the inclusion of an identifier on the statement template make it
possible to define and address multiple constraints on a single
property? (Without attempting to resolve the "either/or" relationships
between them.) Or is it better to seek out separate defined properties
where different constraints will need to be applied?
And if I'm way off course....
Thanks,
kc
Mikael Nilsson wrote:
> mån 2009-08-31 klockan 08:15 -0700 skrev Stuart Sutton:
>
>> Thanks, Mikael, as usual, your explanations are quite clear. This
>> makes sense although my last question regarding how to infer this
>> result from the documentation remains.
>>
>
> We'll have to do another pass trough the DSP at any rate, ad there have
> been some talk about a DCAM2.0 building directly on RDF, deferring the
> issue of defining literals/non-literals to RDF, sp we'll se where all
> this ends up.
>
>
>> 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.
>>
>
> It's not apparent to me that you cannot use your
>
>
>> PATTERN #5: Value string only ("Collection")
>>
>
> for this property. My instinct tells me this would, generally, be the
> best way. But let's assume that is not the case, but you want a literal
> value too.
>
>
>> Now, (unfortunately?) the scenario I just described is not a case of
>> "no further constraining".
>>
>
> True.
>
>
>> When it comes to the VES, there are several constraints. In such a
>> case, how can I represent this in a DSP?
>>
>
> You cannot. The DSP model does not handle this case. The reason is
> relatively simple: The DSP model does not allow for any kind of
> branching, of alternatives. Cases like "either this statement or that
> statement", "no subtitle unless there is a title", "two value strings OR
> a VES URI and a single value string". None of those cases can be
> described by a DSP.
>
> A DSP can thus only really describe the scaffolding structure of a
> metadata record, not all constraints within that scaffolding.
>
> The reason for that, in turn, is that designing a complete constraint
> language is a pretty complex task, and implementing it is even worse.
> The DSP model was intended to be straightforward so that it could easily
> be translated to other constraint languages (such as XML schema, or a
> SPARQL-based validation tool). Thus, alternatives were dismissed early
> on. If one wants to describe records in that level of detail, one is
> better off using something much closer to the metal (like SPARQL or
> Schematron).
>
> I'm willing to revisit that assumption, I should say. But the result
> would be a DSP model based rather more directly on something well-proven
> like SPARQL.
>
>
>> Am I talking about two separate statements representing subject (one
>> literal and another nonliteral with VES constraints)?
>>
>
> No, the DSP model comes with the explicit assumption that a single
> property must match one Statement Template only.
>
>
>> 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?
>>
>
> No, there are real cases like yours. I would argue that often (but not
> always), such cases demonstrate that the metadata design has issues
> (using dc:creator with both literal and non-literal values helps noone,
> for example).
>
> The same cases that will make it difficult for the DSP, will likely also
> make it problematic for applications (that need alternative code paths
> to cover different metadata substructures) and inference engines (that
> will have little or no semantics to work with).
>
> But, in short, there are cases that the DSP as it is formulated today
> cannot handle. I'm sure both Karen and Pete can give further examples.
>
> The open question is: is it good enough? Or are those cases so important
> that the DSP is simply insufficient? That's why I'm so happy that you're
> trying it out, because there is no other way to find out :-)
>
>
>> Getting this straight makes a big difference for me since, in the end,
>> a technical implementer is going to inherit an XML or RDF/XML
>> representation of this DSP and should be able to determine appropriate
>> behavior in configuring my scenario in a metadata generation tool...or
>> so I would think.
>>
>
> Yes, absolutely.
>
> /Mikael
>
>
>> Again, thanks, Mikael for your quick response.
>>
>> Stuart
>>
>>
>> -----Original Message-----
>> From: DCMI Architecture Forum [mailto:[log in to unmask]] On Behalf Of Mikael Nilsson
>> Sent: Monday, August 31, 2009 6:48 AM
>> To: [log in to unmask]
>> Subject: Re: DSP statement template "type" constraint question
>>
>> Hi Stuart!
>>
>> There are obviously some unclear parts of the documentation. I believe
>> the intended meaning is well-defined, even though the text is not
>> perfect. Let me try to sort it out:
>>
>> sön 2009-08-30 klockan 17:47 -0700 skrev Stuart Sutton:
>>
>>> I am trying to wrap my head around the DSP statement template "type"
>>> constraint. According to the specification at section 6.3, permitted
>>> values are "literal" or "nonliteral" with the default being "both
>>> allowed".[1] It further states that "[i]f no value is given, no
>>> further constraining on the value surrogate can be made." So, here is
>>> my question...are "no further constraining on the value surrogate" and
>>> "both allowed" equivalent?
>>>
>> Yes. The language is intended to convey the fact that the default value
>> "both allowed" cannot actually be explicitly set - it is only achieved
>> by not setting a value at all for that attribute. Maybe that is not a
>> very good idea, but that's what the current text is supposed to say.
>>
>>
>>
>>> If so, what is the *USEFUL* result of a statement in a DSP that uses
>>> the type default and, therefore, has no value surrogate constraints?
>>>
>> The result is that absolutely anything goes. (With the caveat that a
>> related description of the value in the Statement might be invalid due
>> to other contraints). Whether that is useful or not... well, that
>> depends on what you're doing.
>>
>>
>>> Is a system consuming the DSP with such a statement type default to
>>> assume that it is dealing with the equivalent of a non-literal where
>>> every possible variation is optional--optional Value URI, optional VES
>>> URI, optional 0-n Value strings, optional language designations, and
>>> optional SES URI?
>>>
>> No. It might also be a literal value.
>>
>>
>>> Is that what "no further constraint" means? Or is such system
>>> consuming the DSP with a statement default type declaration simply
>>> intended to stare back at me asking "what do you want"? (And,
>>> further, what does "further" mean?)
>>>
>> "further" in the text refers to the fact that you're not allowed to add
>> any Literal value constraints or Non-literal value constraints to the
>> Statement Template. You ARE allowed to add property constraints and
>> occurence constraints on the Statement, though.
>>
>>
>>> I come to this question because I am working on a DSP that has a
>>> statement where the desired result is that "both [are] allowed". Now,
>>> it seems to me that if I want "both allowed" and I take the
>>> specification of the Abstract Model literally, all I need to do is set
>>> the statement type as "nonliteral" and make all the component parts of
>>> that non-literal "optional".
>>>
>> No. That would not give you the option of using a literal value.
>>
>>
>>> The Abstract Model defines a nonliteral as follows: "A nonliteral
>>> value surrogate is a value surrogate for a non-literal value, and is
>>> made up of zero or one value URI (a URI that identifies the
>>> non-literal value associated with the property), zero or one
>>> vocabulary encoding scheme URI (a URI that identifies the vocabulary
>>> encoding scheme of which the non-literal value is a member), and zero
>>> or more value strings. Each value string is a literal which represents
>>> the non-literal value."[2] So, it appears that everything in a
>>> nonliteral is optional (i.e., "zero or more"). As a result, I can
>>> express the equivalent of a literal value using a nonliteral where I
>>> optionally do not use either a Value URI or VES URI. And, of course,
>>> for a pure literal, I'd need to limit my value to one value string.
>>>
>> It's true that you can express "the equivalent" of a literal value using
>> a non-literal and a single value string. Though the contained amount of
>> information is the same, the semantics are very different which is
>> evident from the RDF representation of the two cases.
>>
>> This is the non-literal case (using only resources without URIs)
>>
>> _:book dcterms:creator _:adam
>> _:adam rdf:value "Adam Taylor"
>>
>> while this is the literal case
>>
>> _:book dcterms:creator "Adam Taylor"
>>
>> It was an explicit requirement on the DSP spec to be able to distinguish
>> between these two cases, declaring one valid and the other invalid. The
>> second form actually IS invalid according to the semantics of
>> dcterms:creator, which is defined with values in the class of Agents.
>> The string "Adam Taylor" is not an Agent.
>>
>> Thus, while from a certain application's point of view the two contain
>> the same information, from another application's POV they are very
>> different. For example, an application that wants to add a statement
>> about the email address of the author can do so only in one of the cases
>> (the first).
>>
>> It boils down to the fact that in DCAM, a "literal value" is NOT the
>> same thing as a "value string".
>>
>> A "literal value" IS the value, while a "value string" only REPRESENTS
>> the value, and in a vague sense too.
>>
>>
>>> So, it seems to me that if I truly want "both" enabled, setting the
>>> statement type to "nonliteral" and making all components of that
>>> nonliteral functionally "optional" explicitly enables at least all of
>>> the following value patterns (in other words, "both"):
>>>
>>> PATTERN #1:
>>> Value URI (only) (e.g., http://purl.org/dc/dcmitype/Collection)
>>>
>>> PATTERN #2:
>>> Value URI + VES URI (e.g., http://purl.org/dc/dcmitype/Collection +
>>> http://purl.org/dc/terms/DCMIType)
>>>
>>> PATTERN #3:
>>> Value URI + Value string (e.g., http://purl.org/dc/dcmitype/Collection
>>> + "Collection")
>>>
>>> PATTERN #4: VES URI + Value string (e.g.,
>>> http://purl.org/dc/terms/DCMIType + "Collection")
>>>
>>> PATTERN #5: Value string only ("Collection")
>>>
>>> PATTERN #6: Value string + language designation (e.g., "Collection" +
>>> en (or, if appropriate, an SES))
>>>
>> Yes, this is all true. But you're missing pattern #7: Literal value.
>>
>>
>>> While there may be other rational (or irrational) patterns possible,
>>> these seem to me to exhaust the patterns for what the Abstract Model
>>> permits for "both" literal and nonliteral value surrogates.
>>>
>>> Now, I have been on the planet long enough to know that I am probably
>>> messed up! So, please straighten me out. How would one explicitly
>>> declare a statement with a type that is "both" without relying on the
>>> ill-defined default. And, if relying on the default is the key, then
>>> how exactly are we to infer as much reliably from the DSP and Abstract
>>> Model documentation as they stand.
>>>
>> I'm not sure how to answer that last question, but I would be happy to
>> hear any suggestions for improvement of the DSP text.
>>
>> And, thanks for the interesting feedback!
>>
>> /Mikael
>>
>>
>>> Stuart
>>>
>>>
>>> [1] http://dublincore.org/documents/2008/03/31/dc-dsp/
>>> [2] http://dublincore.org/documents/2007/06/04/abstract-model/#sect-2.2
>>>
>>> Associate Professor & Chair,
>>> MLIS Degree Program
>>> The Information School
>>> Mary Gates Hall, Suite 370
>>> Box: 352840
>>> University of Washington
>>> Seattle, WA 98195-2840
>>> Tel. 206-685-6618
>>>
>>>
>
>
>
--
-----------------------------------
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
------------------------------------
