RE: is FRBR relevant?

Either we are the W3C Library Linked Data Incubator Group or we're not.
Code4lib is over there somewhere.

Linked Data is a model.

Jeff

> -----Original Message-----
> From: public-xg-lld-request@w3.org [mailto:public-xg-lld-
> request@w3.org] On Behalf Of Karen Coyle
> Sent: Thursday, August 12, 2010 1:52 PM
> To: public-xg-lld@w3.org
> Subject: Re: is FRBR relevant?
> 
> Herbert, as I said to Jeff, show me how this serves users, and I don't
> care what you call it. But we should be emphasizing results, not
> principles. I use metadata to get a job done, not to satisfy a
> philosophical view. So please put this in terms of functionality for
> library users. How does it work in practice? That's all I really care
> about.
> 
> I think that's part of what LLD should be working on: showing WHY
> libraries should embrace linked data. They aren't going to do it
> unless there are clear gains for the library's core services. In the
> end, "real world" may never cross the lips of librarians nor their
> users, yet linked data could be providing some great gains. Let's
> focus on the latter: what are those gains? How do we bring them about?
> 
> kc
> 
> 
> Quoting Herbert Van de Sompel <hvdsomp@gmail.com>:
> 
> > On Aug 12, 2010, at 9:48 AM, Karen Coyle wrote:
> >> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
> >>
> >>>> - everything on the Web is a web thing
> >>>
> >>> Divide and conquer. From a Linked Data perspective, everything
> >>> imaginable is identifiable and decipherable as either a "Web
> document"
> >>> or a "Real World Object".
> >>>
> >>> http://www.w3.org/TR/cooluris/#oldweb
> >>> http://www.w3.org/TR/cooluris/#semweb
> >>
> >>
> >> This is a philosophical difference, and an area where I have a lot
> >>  of trouble with the Semantic Web as written today. In my world
> >> view,  there are no "real world objects" with URIs.
> >
> > Karen, as far as I understand the work of LLD is based on the four
> > principles expressed in <http://www.w3.org/DesignIssues/
> > LinkedData.html>. Fundamental in those principles is the notion of
> > naming things (and "things" stands for "real world objects",
> > "concepts", etc.) with URIs. I don't think LLD should question those
> > basics on which all Linked Data work is based. As a matter of fact,
I
> > would not really know anymore what LLD is about if it would not
> > embrace those fundamental principles. Obviously that does not
prevent
> > any individual from questioning those principles; but I think LLD as
> a
> > group/effort should not.
> >
> > Cheers
> >
> > Herbert
> >
> >> If it's on the web, it's on the web, and it's a web document. What
> >> I  think has been confused here is the document and the content --
> >>  content v. carrier. On the web, the carrier is always bits. The
> >> content is (usually) about something of interest to people. What
> >> the  SEmWeb folks call a real world object I think is what I could
> >> call  "content." Libraries have dealt with this since.... forever.
> >> No one  confuses a library book about cows with a real live
> >> ruminant. People  looking for a real live ruminant do not come to
> >> the library. We  should use metadata methods that respond to actual
> >>  behaviors.
> >>
> >> So basically, for me there are no real world objects in my metadata
> >>   universe. It's all metadata.
> >>
> >> Meanwhile, I must say that I'm more concerned with what my metadata
> >>   conveys than the details of how the URI is constructed, since the
> >>   URI is only for a machine. I will happily use any URI
> >> construction   that best gets my users to the information they
> >> seek. What I will   *not* do is limit my user base to folks who
> >> understand these   semantic web concepts. In fact, I don't want to
> >> limit the set of   potential metadata creators to folks who
> >> understand these concepts.   That would be rather like not allowing
> >> anyone to speak a language   unless they have fully understood
> >> Wittgenstein, Chomsky, and  Saussure.
> >>
> >> kc
> >>
> >>
> >>>
> >>>> - it is not the web thing-ness that is of interest to people
using
> the
> >>> web, but the meaning behind the web thing
> >>>> - therefore, it is best to skip the web-thing layer, and instead
> code
> >>> for the more meaningful layer
> >>>
> >>> Don't skip the web layer, use it. Return 200s for "web things"
> ("Web
> >>> documents") and use hash URIs or return 303s for non-web things.
> >>>
> >>>> For example, you code an ebook as a book in electronic form, not
> as a
> >>> series of bits. You code an mp3 as a song, not as a file.
> >>>>
> >>>> This follows library practice where the physical format (bound
> paper,
> >>> electronic file, CD) is considered secondary.
> >>>
> >>> Yes: "books" and "songs" are "real world objects" that need to be
> >>> modeled. "ebooks" and "mp3s" are Web document "representations" of
> "real
> >>> world objects". This is a good start, but it shouldn't end there.
> >>>
> >>>> That said, it's not entirely unambiguous, there are definitely
> gray
> >>>> areas.
> >>>
> >>> Karen! Poke them harder about the gray areas. The missing concept
> >>> linking "real world object" and "Web document" is
"representation".
> LLD
> >>> XG needs to spend more time thinking and talking about and using
> the
> >>> concept of "representation".
> >>>
> >>>> But I would say that http://id.loc.gov/authorities/sh85148273
> >>>> represents an intellectual construct, an entry in the LC subject
> >>>> authority file which has as its meaning a particular concept.
Then
> you
> >>>> can use some other designation, if you wish, to represent the
LCSH
> >>>> record/web document. This latter is usually considered
> administrative
> >>>> information; it is highly useful, but not the purpose of the
data.
> >>>
> >>> Shame on us for thinking we can guess our way out of this mess! We
> >>> should be grateful to LC for giving us meaningful skos:Concepts
> (think
> >>> frbr:hasAsSubject) while begging them for skosxl:Labels. ;-)
> >>>
> >>> Jeff
> >>>
> >>>>
> >>>> kc
> >>>>
> >>>>
> >>>>>
> >>>>> Currently, there is no HTTP URI to identify the LC subject
> heading
> >>>>> "World War, 1939-1945".
> >>>>>
> >>>>> If LC used SKOS XL they could "fix" that.
> >>>>>
> >>>>> This is a subtle but important point related to Linked Data. I
> >>>> encourage
> >>>>> members of LLD XG to puzzle this out. Asking questions will
help.
> >>>>>
> >>>>> Jeff
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: William Waites [mailto:william.waites@okfn.org]
> >>>>>> Sent: Tuesday, August 10, 2010 2:24 PM
> >>>>>> To: Young,Jeff (OR)
> >>>>>> Cc: public-xg-lld@w3.org
> >>>>>> Subject: Re: is FRBR relevant?
> >>>>>>
> >>>>>> On 10-08-10 03:19, Young,Jeff (OR) wrote:
> >>>>>> > LCSH doesn't need "fixed" exactly. The only problem is that
> too
> >>>> many
> >>>>>> > people believe the following URI identifies "the name of the
> >>>> thing"
> >>>>>> > (i.e. the literal "World War, 1939-1945") rather than "the
> thing"
> >>>>>> (i.e.
> >>>>>> > the concept of WWII):
> >>>>>> >
> >>>>>> > http://id.loc.gov/authorities/sh85148273#concept
> >>>>>> >
> >>>>>> > Switching from skos:prefLabel to skosxl:prefLabel and coining
> a
> >>>> new
> >>>>>> URI
> >>>>>> > for the skosxl:Label would help clarify the difference (IMO):
> >>>>>> >
> >>>>>> > http://id.loc.gov/authorities/sh85148273#heading
> >>>>>> >
> >>>>>>
> >>>>>> Maybe I'm being dense but I don't understand why this is better
> >>>>>> than what http://id.loc.gov/authorities/sh85148273 gives us
now.
> >>>>>> There are a bunch of labels, a main one and some alternates.
You
> >>>>>> can search on them in whatever way you like without any
> >>>>>> ambiguity.
> >>>>>>
> >>>>>> #heading seems to represent "the concept of the name of the
> >>>>>> concept". Do we really need this extra indirection?
> >>>>>>
> >>>>>> The main problem I see is that neither what the LOC is doing
> >>>>>> now, nor any extensions with skosxl isn't compatible with
Dublin
> >>>>>> Core.
> >>>>>>
> >>>>>>     [ dc:subject [
> >>>>>>         dcam:member dc:LCSH;
> >>>>>>         rdf:value "World War, 1939-1945"]]
> >>>>>>
> >>>>>> which appears in the wild. If i put,
> >>>>>>
> >>>>>>     [ dc:subject <http://id.loc.gov/authorities/sh85148273> ]
> >>>>>>
> >>>>>> I need to make an ugly query,
> >>>>>>
> >>>>>>     SELECT ?x WHERE {
> >>>>>>         {
> >>>>>>            ?x a Work .
> >>>>>>            ?x dc:subject ?s.
> >>>>>>            ?s rdf:value "World War, 1939-1945"
> >>>>>>         } UNION {
> >>>>>>            ?x a Work.
> >>>>>>            ?x dc:subject ?s.
> >>>>>>            ?s skos:label "World War, 1939-1945"
> >>>>>>         }
> >>>>>>     }
> >>>>>>
> >>>>>> As I've said before, this can be converted in an automated way
> >>>>>> easily enough, but I think we (or one of the follow-on WGs)
> >>>>>> makes a concrete recommendation that may supercede DC's
> >>>>>> usage with respect to subjects from LCSH (and possibly
> >>>>>> other authorities). At the very least if DC encouraged using
> >>>>>> rdfs:label instead of rdf:value we would get (with description
> >>>>>> logic) compatibility for free. Compatibility is obviously
> >>>>>> not as straightforward with skosxl
> >>>>>>
> >>>>>> Cheers,
> >>>>>> -w
> >>>>>>
> >>>>>> --
> >>>>>> William Waites           <william.waites@okfn.org>
> >>>>>> Mob: +44 789 798 9965    Open Knowledge Foundation
> >>>>>> Fax: +44 131 464 4948                Edinburgh, UK
> >>>>>>
> >>>>>> RDF Indexing, Clustering and Inferencing in Python
> >>>>>> 		http://ordf.org/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Karen Coyle
> >>>> kcoyle@kcoyle.net http://kcoyle.net
> >>>> ph: 1-510-540-7596
> >>>> m: 1-510-435-8234
> >>>> skype: kcoylenet
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Karen Coyle
> >> kcoyle@kcoyle.net http://kcoyle.net
> >> ph: 1-510-540-7596
> >> m: 1-510-435-8234
> >> skype: kcoylenet
> >>
> >>
> >
> > ==
> > Herbert Van de Sompel
> > Digital Library Research & Prototyping
> > Los Alamos National Laboratory, Research Library
> > http://public.lanl.gov/herbertv/
> > tel. +1 505 667 1267
> 
> 
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
> 
>

Received on Thursday, 12 August 2010 19:05:31 UTC