mån 2009-08-31 klockan 15:39 -0700 skrev Karen Coyle:
> 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?
No. The DSP model is designed not to allow branching (alternatives). A
single property must appear in exactly one Statement Template.
This restrains the possible uses of the DSP model considerably. The
reason is that this restriction allows one to implement a DSP
translation to many other systems without full query language
capablities.
The alternative is to use a more complete constraint language, and we
would then likely need something like SPARQL. I'm not saying I'm against
the idea, but we need to make sure the need is well-defined and
well-motivated before advancing down that route.
> 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?
An identifier would do absolutely no good, because the issue is exactly
that we need to resolve the "either/or" situation without risking being
tied up in a full query language execution.
It's then better to formulate such a constraint only in prose, or to use
two different properties.
/Mikael
>
> 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
> >>>
> >>>
> >
> >
> >
>
|
