Re: is FRBR relevant?

Karen,

I think that's the point of our use case approach: to show how we are trying
to build is relevant for users. I think it's probably a bit challenging,
because one of the key features of Linked Data is to allow unexpected uses
;-) But as a librarian, I see your point.

In my opinion, "real world things" are what users are interested about. They
don't care about Web representation of WWII or any other concept, they care
about the real thing, they want info about the real thing. So, what we need
to do is create assertions about the real thing, so we need URIs for them.

But re-reading your previous posts, I believe we fondamentally agree...
(quoting : "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.")

It's just probably we don't use the same vocabulary to explain it.

Wouldn't it be useful if the group could
- provide a specific use case for subject search (which was the beginning of
this thread)
- identify the terminology gaps between library world and SemWeb world (I
think that this work on terminology is something that we hadn't identified
per se, but I'm currently at IFLA and I hear a lot about records, metadata,
elements and sub-elements, properties, concepts, ontologies, etc. all used
in a very mixed up and not precise way... )

Emmanuelle

On Thu, Aug 12, 2010 at 7:51 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

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


-- 
=====
Emmanuelle Bermès - http://www.bnf.fr
Manue - http://www.figoblog.org

Received on Friday, 13 August 2010 09:07:48 UTC