Re: is FRBR relevant?

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