On mån, 2008-08-18 at 10:58 -0700, Karen Coyle wrote:
>
> 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?
This is stated again and again, and still I don't see anyone in the
library world seriously considering the most widely deployed protocol in
existence - HTTP.
It works. It's reliable. W3C has guidelines for deploying information
about abstract entities over HTTP. What is lacking?
/Mikael
>
> 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
> ------------------------------------
>
>
--
<[log in to unmask]>
Plus ça change, plus c'est la même chose
|