Andy, taking off from your blog post, where you say:
"Because if the topic is treated as a non-literal value then it can be
assigned a URI and can become the subject of other descriptions. If the
topic is treated as a literal value then it becomes a descriptive
cul-de-sac - no further description of the topic is possible."
I agree with this, but it kind of begs the question of assigning those
URIs and communicating about them, which I think is one of the problems
that we face today. It comes down to that fact that just assigning a URI
isn't enough to make the Web of linked data work. There needs to be a
good way for people and programs to discover those URIs and understand
what they represent. To me this is the primary barrier. If I am creating
a catalog for my users and I harvest records that have URIs in the
subject fields, I need to easily be able to know 1) what I can display
to my human users so that they can understand what the subject is 2)
what to index so my human users can do a search and retrieve what they
are looking for.
URIs are for machines. Taking care of the humans will require more than
a URI. We need to define what that "more" is and how we will make it work.
Andy Powell wrote:
> For the record (1)... I think the use of 'coterie' is somewhat unfair
> (at least in the sense of a 'clique'), since I don't see anyone trying
> to be exclusive - quite the opposite in fact... but I take the point
> about not many people in DCMI being well placed to answer the question -
> which is a serious issue for DCMI I would suggest.
> For the record (2)... I no longer consider myself part of any such
> 'coterie' but I've had a go at answering anyway. See
> Fundamentally, the importance of non-literals vs. literals lies in our
> ability to build a Web of *linked data* (to use the currently accepted
> term) based on assigning 'http' URIs to things that are useful to us in
> describing the world (concepts, places, people and the like), something
> that I think the library community have been very slow to recognise,
> despite the fact that they sit on a vast array of data, knowledge and
> expertise that would be highly valuable in this space. This is a great
> shame IMHO.
> Head of Development, Eduserv Foundation
> [log in to unmask]
> +44 (0)1225 474319
>> -----Original Message-----
>> From: General DCMI discussion list
>> [mailto:[log in to unmask]] On Behalf Of Karen Coyle
>> Sent: 15 August 2008 17:51
>> To: [log in to unmask]
>> Subject: Re: non-literal values; qualified or simple DC
>> I suspect the members of the small coterie that could explain
>> this are all on vacation at this time. I am not in that
>> group, but I will attempt an explanation anyway ;-)
>> Reading the dcterm:subject entry, I can see that there is an
>> expectation that the term will be part of a context -- the
>> context may be an authoritative list that it must come from,
>> or it could be a combination of a list and rules, such as one
>> gets with LCSH, LCC or Dewey. Any term that gets a value from
>> a context like that is considered non-literal in the DCAM
>> sense because the context needs to be included in the formal
>> description of the term. This is somewhat like the 6XX fields
>> in MARC where the indicator (or $2) tells you which
>> vocabulary the subject heading belongs to.
>> That said, this definition seems to exclude the possibility
>> of uncontrolled subject terms, which you mention. Leaving
>> aside the DCAM (which is often puzzling), it seems to me that
>> you need a way to indicate 1) whether or not the values in
>> the subject field are controlled and 2) if they are
>> controlled, what list they come from. I don't think that
>> DCTERMS alone provides this capability, although you could
>> possibly create it by using these value "patterns":
>> 1) a character string alone. This would represent an
>> uncontrolled subject term or terms.
>> 2) A URI for the subject term. This is only an option if the
>> term itself has a URI. I can imagine URIs for things like LCC
>> or Dewey looking something like:
>> 3) A URI for the subject *system* plus a string for the
>> subject heading or term.
>> http://www.nlm.nih.gov/mesh/ "Dipeptidyl-Peptidase IV Inhibitors"
>> I'd love to hear other takes on this because I think it
>> probably has been amply discussed in the DC development process.
>> Karen Arcamonte wrote:
>>> I'm currently involved in the selection of standard fields for a
>>> metadata project and we have some fields that we are calling Dublin
>>> Core fields (Subject and Relation fields), but we are
>> including free
>>> text or uncontrolled terms. I notice that the DC Subject
>> and Relation
>>> fields are "intended to be used with a non-literal value." I'm not
>>> sure what this means. Is there anyone that can explain in simple
>>> terms? I've looked at the DCMI Abstract Model and I'm still
>> not sure what they mean by "non-literal"
>>> value. Also, can you say you are using Qualified Dublin
>> Core for some
>>> fields and Simple Dublin Core for other fields in an
>> application profile?
>> Karen Coyle / Digital Library Consultant [log in to unmask]
>> ph.: 510-540-7596 skype: kcoylenet
>> fx.: 510-848-3913
>> mo.: 510-435-8234
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet