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

Help for DC-COLLECTIONS Archives


DC-COLLECTIONS Archives

DC-COLLECTIONS Archives


DC-COLLECTIONS@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-COLLECTIONS Home

DC-COLLECTIONS Home

DC-COLLECTIONS  April 2005

DC-COLLECTIONS April 2005

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

DCAPs, value strings and value URIs

From:

Pete Johnston <[log in to unmask]>

Reply-To:

DCMI Collection Description Group <[log in to unmask]>

Date:

Fri, 15 Apr 2005 20:53:07 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (152 lines)

This has come up independently in a couple of messages I've had
off-list, so I thought I'd post something here, as it raises a general
point about the DC CD AP and DCAPs in general, which I think we may need
to extend the DC CD AP to cover.

According to the DCMI Abstract Model [1], a DC metadata description is a
set of statements about a single resource, where each statement asserts
a relationship between that "subject" resource and a second resource,
and the DCAM calls that second resource the "value".

A statement consists of:

- exactly one reference to a property ("property URI");
- a reference to a value ("value URI"), or a representation of the value
("value string"), or both;
- optionally a reference to a class that indicates the type of the value
("vocabulary encoding scheme URI")

(A representation can be something other than a value string, and value
strings can be associated with syntax encoding schemes, but let's stick
to the simple case.)

So, e.g., to represent the fact that a book is authored by a person. In
terms of the DCAM, the resource is the book, and the value is the
person. I could construct a description using a value string

Description
  Resource URI : http://example.org/book/1234
  Statement
    Property URI : http://purl.org/dc/elements/1.1/creator
    Value String : "Fred Smith"

This just says the creator is some resource represented by the string
"Fred Smith"; it doesn't tell me which "Fred Smith" it is.

Or I could use a value URI (I know there is the question that people
typically don't have URIs assigned to them, but let's suppose they did):

Description
  Resource URI : http://example.org/book/1234
  Statement
    Property URI : http://purl.org/dc/elements/1.1/creator
    Value URI : http://example.org/person/Fred

Now I know that the relationship is between two uniquely identified
resources, but I don't have any human-readable information about that
value.

Or I could use both a value string and a value URI:

Description
  Resource URI : http://example.org/book/1234
  Statement
    Property URI : http://purl.org/dc/elements/1.1/creator
    Value URI : http://example.org/person/Fred
    Value String : "Fred Smith"

And I could add a vocabulary encoding scheme URI too to indicate the
type of the value:

Description
  Resource URI : http://example.org/book/1234
  Statement
    Property URI : http://purl.org/dc/elements/1.1/creator
    Value URI : http://example.org/person/Fred
    Value String : "Fred Smith"
    Vocabulary Encoding Scheme URI : http://some.org/type/Person


Now, what a DCAP is doing (well, this is my take on it - unfortunately
DCMI doesn't currently have a formal description of what a DCAP actually
is, so it's difficult to say this with any authority!) is: for some
class of descriptions (actually, description sets, but let's stick with
the simple case for the purposes of this discussion) e.g. those used
within a particular application, or those that describe some class of
resources, it specifies

- what properties I should use in statements in that class of
descriptions
- additional information about how those properties are deployed in that
class of descriptions, which includes
- information about the types of value that those properties should take
(i.e. the vocabulary encoding schemes to be used) in that class of
descriptions

So I sometimes think a DCAP might be better named a "description (set)
profile": it describes how to construct a description (set).

OK, looking back to the example above. I emphasised that I could include
in my statement either a value string "Fred Smith" or a value URI
http://example.org/person/Fred or both.

And further, the choice of vocabulary encoding scheme is independent of
whether I use a value URI or a value string. I do not use a vocabulary
encoding scheme to signal the use of a value URI.

So the question that has come up regarding the DC CD AP is:

(For some property specified by the DC CD AP), should I use a (value)
string or a (value) URI?

The answer (as the DC CD AP stands at the moment) is that _any_ of the
properties specified (except maybe dc:identifier) may be used with
either a value string or a value URI or both.  e.g. to specify that the
owner of my collection is Fred Smith, I can use any of the forms of
description above with a property URI of
http://www.loc.gov/marc.relators/own

i.e. the DC CD AP is silent on whether a value string or value URI is
used in the statement.

So the question is whether this is what we want, or whether we should
include in the DC CD AP an indication that (for some specified
properties e.g. the relationships between collections?) a value URI
should be deployed. That would not rule out the use of a value string as
well as a value URI.

This is not done by specifying that the "vocabulary encoding scheme" is
dcterms:URI - that would state that the value, the resource, _is_ a URI,
but in the example above the value is a person. And I don't think it is
done by saying that the "syntax encoding scheme" is dcterms:URI because
value URIs are distinct from value strings in the DCAM.

Indeed none of the specifications for guidance for creating DCAPs (that
I've seen) address this point. So I think it would require a separate
statement in the "property usage" - the description of how the property
is used in the DC CD AP - to state that the use of a value URI is
required.

i.e. an additional row in the tables like

http://www.ukoln.ac.uk/metadata/dcmi/collection-application-profile/#dct
ermshaspart

to say something like:

Requires Value URI = Yes

Similarly - I'm less sure about this - there may be cases where we want
to indicate that, for specified properties, the use of a value string is
required. That would not exclude the use of a value URI too. Again, I
think that would require a separate statement in the property usage.

Pete
-------
Pete Johnston
Research Officer (Interoperability)
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 383619    fax: +44 (0)1225 386838
mailto:[log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

March 2011
November 2010
September 2010
August 2010
May 2010
April 2010
February 2010
September 2009
April 2009
January 2009
July 2008
May 2008
March 2008
January 2008
October 2007
September 2007
August 2007
July 2007
June 2007
April 2007
December 2006
November 2006
September 2006
August 2006
July 2006
June 2006
February 2006
January 2006
December 2005
November 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
February 2003
December 2002
September 2002
August 2002
July 2002
June 2002
April 2002
March 2002
February 2002


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager