 |
 |
Please remove me from this list. Robin T. Rutledge Price, Jerry wrote: > -----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 >> >> > ************************************************************************ > ******** > >> >> > > -- Robin T. Rutledge, CEO MediaRecall Holdings, LLC USA HQ/Digital Studios 3363 Commercial Ave. Northbrook, Illinois, 60062 847.513.6810 Office 847.881.0703 F 312.622.4777 M [log in to unmask] http://www.mediarecall.com