RE: is FRBR relevant?

Karen,

Does it help knowing that Linked Data admits that "real world objects"
can't be "represented" as a byte stream? That's why they their HTTP URIs
need to respond with 303 (See Other) to an information resource that
contains information *about* them.

Jeff

> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: Thursday, August 12, 2010 11:48 AM
> To: Young,Jeff (OR)
> Cc: William Waites; public-xg-lld@w3.org
> Subject: RE: is FRBR relevant?
> 
> 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. 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
>

Received on Thursday, 12 August 2010 15:53:29 UTC