JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-ARCHITECTURE Archives


DC-ARCHITECTURE Archives

DC-ARCHITECTURE Archives


DC-ARCHITECTURE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-ARCHITECTURE Home

DC-ARCHITECTURE Home

DC-ARCHITECTURE  September 2009

DC-ARCHITECTURE September 2009

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: DSP statement template "type" constraint question

From:

Mikael Nilsson <[log in to unmask]>

Reply-To:

DCMI Architecture Forum <[log in to unmask]>

Date:

Tue, 1 Sep 2009 17:37:22 +0200

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (349 lines)

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
> >>>
> >>>       
> >
> >
> >   
> 

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
November 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
December 2000
November 2000
October 2000


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0909&L=DC-ARCHITECTURE&D=1&P=62
www.jiscmail.ac.uk
crawl=CC-MAIN-2016-40
81049
application/http; msgtype=response
sha1:AJEKM2RI5E72CSREMKWQETAHKIQAU5TU
<urn:uuid:0691eef6-0cf6-4076-b865-9b7d34bdad5a>
2016-09-29T01:53:00Z
54.229.126.31
sha1:PJ7PU4KCHQHHUXHEPZK4FXLAGJYO3WL5
<urn:uuid:51efbad9-061a-4194-985f-477fcebecc8b>
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0909&L=DC-ARCHITECTURE&D=1&P=62
length
response
<urn:uuid:891f4939-3702-46b9-9b5b-a2fce691c7e2>
robots: classic
hostname: ip-10-143-35-109.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2016-40
operator: CommonCrawl Admin
description: Wide crawl of the web for September 2016
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf