- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 12 Aug 2010 09:57:40 -0700
- To: "Young,Jeff (OR)" <jyoung@oclc.org>
- Cc: William Waites <ww-keyword-okfn.193365@styx.org>, public-xg-lld@w3.org
Quoting "Young,Jeff (OR)" <jyoung@oclc.org>: > 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. No, not really. Still doesn't fit with *my* concept of metadata. But mainly I want to know what this does for information seekers, how it fits into their activities and needs. What does it gain us in our development of services for them? Beyond that, we can call it "X" or "apples" as far as I am concerned, as long we we know what we are doing and why. And the arguments about getting http codes back doesn't tell me what service it provides to users. Users should not be given http codes as a response. So what is the user view? kc > > 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 >> > > > > -- 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:58:19 UTC