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