RE: is FRBR relevant?

Sorry, that was poorly worded. Try this instead:

Does it help knowing that Linked Data admits that "real world objects"
can't be XXXXXXXXX -> transferred/transmitted/delivered via the Web as a
byte stream message? 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: Young,Jeff (OR)
> Sent: Thursday, August 12, 2010 11:53 AM
> To: 'Karen Coyle'
> Cc: William Waites; public-xg-lld@w3.org
> Subject: 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 16:04:44 UTC