-----Original Message-----
From: General DCMI discussion list [mailto:[log in to unmask]] On
Behalf Of Karen Coyle
Sent: Monday, August 18, 2008 1:59 PM
To: [log in to unmask]
Subject: [Fwd: Re: non-literal values; qualified or simple DC]
Sorry, I didn't send this to the list. Got to remember to "reply all."
kc
-------- Original Message --------
Subject: Re: non-literal values; qualified or simple DC
Date: Mon, 18 Aug 2008 07:37:10 -0700
From: Karen Coyle <[log in to unmask]>
To: Hammond, Tony <[log in to unmask]>
References: <[log in to unmask]>
Tony, I don't think that the issue is that URIs are hard for humans to
read -- actually, humans shouldn't have to read them. I think the issue
is that until we have some standard resolution for our URIs there isn't
much we can do with them. A URI on its own is just a dumb identifier.
It's what it identifies that we want to work with. How useful would an
ISBN be if you couldn't plug it into Amazon or a library catalog and get
the book? So it's what we can DO with URIs that matters, and right now
if I get a URI for a vocabulary term ... well, what do I do?
It's that part that is missing. And that's why I think we have been slow
to adopt URIs. Maintaining a dependable, usable resolution service is a
big job, and we will want a strong standard that makes using URIs
automatic and easy.
kc
Hammond, Tony wrote:
> I must agree with Karen:
>
>> 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.
>
> URIs have many issues associated with them, but one that many will
agree on
> is that they are unwieldy.
>
> One of the outstanding successes of URIs is their capacity for
> "transcription" [1]. The fact that you can paint them on the side of a
bus
> and someone will remember that (or jot it down) and then look it up
later on
> the Web. But this is also a key weakness of URIs as identifiers
because they
> can be just too darn long.
>
> Leaving aside the scheme prefix (because, well let's just say because
;), we
> have at minimum the DNS name/IP address which must be added as a
network
> name authority to the path component which provides the namespace and
may
> (or may not) include the subject term depending on whether fragment
notation
> is being used. Gets messy, quickly:
>
> example.org/term
> example.org/name1/term
> example.org/name1/name2/term
> ...
>
> Marketing with branded URIs may alleviate this somewhat by jettisoning
> namespaces and/or folding subject terms into authority components,
e.g.
>
> www.mammamiamovie.com/
>
> But in reality many URIs tend to be longer and more "difficult" (see
e.g.
> the referenced URIs below). And BTW have you seen many RDF graphs
(which
> generally depict URIs in absolute form) that are really fit for
viewing?
>
> I am curious why the CURIE [2] effort to abbreviate URIs by
introducing
> compact URI forms is taking so long to be realized. This may help out
some
> in taming URIs for humans where prefixes are used to provide a simple
> mnemonic mechanism. Indeed in XML namespaces a similar convention for
> abbreviating URIs is used, with a number of well known namespace names
> emerging, e.g. "dc:", "xsd:", "rdf:".
>
> Think the humans should get a look-in.
>
> Tony
>
> [1] http://www.apps.ietf.org/rfc/rfc3986.html#sec-1.2.1
> [2] http://www.w3.org/TR/2007/WD-curie-20070307/
>
>
>
> On 18/8/08 14:29, "Karen Coyle" <[log in to unmask]> wrote:
>
>> 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.
>>
>> kc
>>
>> 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
>>>
>>>
http://efoundations.typepad.com/efoundations/2008/08/the-importance.html
>>>
>>> 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.
>>>
>>> Andy
>>> --
>>> Head of Development, Eduserv Foundation
>>> http://www.eduserv.org.uk/foundation/
>>> http://efoundations.typepad.com/
>>> [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
>>>>
>>>> Karen,
>>>>
>>>> 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:
>>>> http://www.oclc.org/dewey/ddc22/973.13
>>>> 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.
>>>>
>>>> kc
>>>>
>>>>
>>>> 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]
>>>> http://www.kcoyle.net
>>>> ph.: 510-540-7596 skype: kcoylenet
>>>> fx.: 510-848-3913
>>>> mo.: 510-435-8234
>>>> ------------------------------------
>>>>
>>>
>
>
>
************************************************************************
********
> DISCLAIMER: This e-mail is confidential and should not be used by
anyone who is
> not the original intended recipient. If you have received this e-mail
in error
> please inform the sender and delete it from your mailbox or any other
storage
> mechanism. Neither Macmillan Publishers Limited nor any of its agents
accept
> liability for any statements made which are clearly the sender's own
and not
> expressly made on behalf of Macmillan Publishers Limited or one of its
agents.
> Please note that neither Macmillan Publishers Limited nor any of its
agents
> accept any responsibility for viruses that may be contained in this
e-mail or
> its attachments and it is your responsibility to scan the e-mail and
> attachments (if any). No contracts may be concluded on behalf of
Macmillan
> Publishers Limited or its agents by means of e-mail communication.
Macmillan
> Publishers Limited Registered in England and Wales with registered
number 785998
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
>
************************************************************************
********
>
>
>
--
-----------------------------------
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
------------------------------------
--
-----------------------------------
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
------------------------------------
|
