- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 10 Apr 2012 22:51:05 -0700
- To: Ivan Herman <ivan@w3.org>
- Cc: W3C RDF WG <public-rdf-wg@w3.org>, tom@tombaker.org
On Apr 10, 2012, at 6:05 AM, Ivan Herman wrote: > I am not sure all of you read the RDF Comment mailing list, so, to be on the safe side, I forward this mail... Thanks. > > Ivan > > Begin forwarded message: > >> Resent-From: public-rdf-comments@w3.org >> From: Thomas Baker <tom@tombaker.org> >> Subject: Use Case: "Expressing FRBR Descriptions using Named Graphs" >> Date: April 4, 2012 23:44:38 GMT+02:00 >> To: public-rdf-comments@w3.org >> Cc: Ron Murray <kandroma1@me.com>, Barbara Tillett <btil@loc.gov>, Gordon Dunsire <gordon@gordondunsire.com> >> Archived-At: <http://www.w3.org/mid/20120404214438.GA47236@julius> >> List-Id: <public-rdf-comments.w3.org> >> >> Dear Members of the RDF Working Group, >> >> The following text describes a proposed use case for Named Graphs. For anyone >> unfamiliar with "FRBR," the Wikipedia page provides a quick overview [1]. FRBR >> is the foundation for RDA (Resource Description and Access), the new cataloging >> standard towards which major libraries are moving [2]. >> >> This proposal for conceptualizing FRBR entities as Named Graphs is based on >> work by Ronald Murray and Barbara Tillett of the Library of Congress. These >> ideas are illustrated in a visually very engaging slide deck, "From Moby-Dick >> to Mash-Ups: Thinking About Bibliographic Networks" [3]. Gordon Dunsire has >> also contributed to the proposal. >> >> We would be especially grateful for feedback in advance of an event on 27 April >> at the British Library [4]. The event will mark the fifth anniversary of a >> meeting in May 2007 which resulted in a recommendation that RDA and FRBR be >> expressed in RDF [5]. >> >> The Named Graph approach outlined below is a relatively new contribution to >> this ongoing thread. As the approach depends on the resolution of issues still >> under discussion in the RDF Working Group, we would much appreciate your >> comments or suggestions. >> >> Tom >> >> [1] http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records >> [2] http://en.wikipedia.org/wiki/Resource_Description_and_Access >> [3] http://www.slideshare.net/RonMurray/from-mobydick-to-mashups >> [4] http://dcevents.dublincore.org/index.php/BibData/fyo >> [5] http://www.bl.uk/bibliographic/meeting.html >> >> ---------------------------------------------------------------------- >> Expressing FRBR Descriptions using Named Graphs: a proposal >> >> W3C's Resource Description Framework (RDF) Working Group [1] is currently >> discussing proposals for supporting "named graphs" to meet a wide range of use >> cases [2], possibly by extending the TriG Named Graph and RDF Data Language >> [3,4]. This proposal outlines how Named Graphs might be used in resource >> descriptions that are based on the so-called WEMI entities (Work, Expression, >> Manifestation, and Item) of the IFLA model Functional Requirements for >> Bibliographic Records (FRBR) [5]. >> >> This proposal views descriptions of WEMI entities as bundles of statements made >> at different levels of abstraction, from the most concrete Item level to the >> most abstract Work level. Multi-level WEMI descriptions specify the >> characteristics that any given Item shares with other Items at the level of >> Work, Expression, and Manifestation. Ideally, it would be possible to >> incorporate descriptions of resources at the Work, Expression, and >> Manifestation levels, maintained in a distributed manner by various >> institutions, into the local descriptions of particular Items. >> >> Consider the following four Named Graphs, each of which is identified with a >> URI (A, B, C, or D) and contains two statements: >> >> -- Named Graph D, a Work-level description >> P has_title "Moby-Dick, or, the Whale" >> P has_as_subject "Whaling Ships -- Fiction" >> >> -- Named Graph C, an Expression-level description >> Q has_language "English" >> Q has_extent "213711 words" >> >> -- Named Graph B, a Manifestation-level description >> R has_edition_issue "First Edition" >> R has_pub_place "New York NY" >> >> -- Named Graph A, an Item-level description >> X has_OAI_ID http://hdl.handle.net/10150/16470 >> X has_condition "yellowing at page edges" >> >> One might bind these four chunks into a single description by "including" them >> into a common "frame": >> >> FrameL includes NamedGraphA >> FrameL includes NamedGraphB >> FrameL includes NamedGraphC >> FrameL includes NamedGraphD Should we think of this as a graph merge in the RDF sense? (Test: does this FrameL entail all the triples in the four original graphs?) If so, what is gained by calling it a "frame"? If not, what is the intended meaning of 'frame', and what relationship holds between this frame and the content of the four graphs? It seems that a lot of pertinent information is missing here, at the very least the fact that graphA is at the 'item level' and that B is at the manifestation level , etc.. Is this all going to be included in the RDF? How? >> One would then want to infer that the Item in hand (described by the statements >> in Named Graph A) What specifies that X (rather than, say, R or Q) is the "item in hand"? >> is _also_ described by statements in the Named Graphs at the >> more abstract levels What specifies that the other graphs are more "abstract" in "level" than the graph A? What sense of "abstract" is meant here? (Are we talking about classes?) >> of Work, Expression, and Manifestation included in the >> same Frame. In other words, if X is the URI of the Item in hand, one would >> like to infer: >> >> X has_title "Moby-Dick, or, the Whale" >> X has_as_subject "Whaling Ships -- Fiction" >> X has_language "English" >> X has_extent "213711 words" >> X has_edition_issue "First Edition" >> X has_pub_place "New York NY >> X has_OAI_ID http://hdl.handle.net/10150/16470 >> X has_condition "yellowing at page edges" This is certainly not a valid conclusion, in any logic I have ever seen, from the four graphs given. (What justifies substituting X for R, Q and P?) Frankly, all this does not make sense as stated. Unless a better explanation is forthcoming, I suggest that this "case" be ignored as irrelevant to RDF. Pat Hayes >> >> Discussion >> >> 1. Formal notions of Frame, and of "inclusion" in a Frame, would need to be >> defined for the general case. >> >> 2. Formal rules would be needed for interpreting Frames with different >> sets of FRBR descriptions, e.g., for the simple case above, in which >> statements from Work-, Expression-, and Manifestation-level descriptions are >> interpreted as applying to the Item. >> >> 3. Given the complex, even chaotic nature of the Web, flexibility to >> implement this approach in a partial manner is a critical design criterion. >> Particular WEMI descriptions should be useful in a Linked Data environment >> independently of particular Frames and, ideally, even in the absence of an >> understanding of Frames and Inclusion (see 1 above) or of the particular >> rules applicable to FRBR (see 2 above). In the example described above, the >> statements in Named Graph D about Work P would be useful independently of >> FrameL, which (according to rules yet to be defined) would merely apply >> those statements, additionally, to Item X. The above paragraph is incomprehensible, but appears to have nothing to do with linked data. >> >> References >> >> [1] http://www.w3.org/2011/rdf-wg/ >> [2] http://www.w3.org/2011/rdf-wg/wiki/Why_Graphs >> [3] http://dvcs.w3.org/hg/rdf/raw-file/default/trig/index.html# >> [4] http://lists.w3.org/Archives/Public/public-rdf-wg/2012Mar/0123.html >> [5] http://www.ifla.org/VII/s13/frbr/frbr.htm >> >> -- >> Tom Baker <tom@tombaker.org> >> >> > > > ---- > Ivan Herman, W3C Semantic Web Activity Lead > Home: http://www.w3.org/People/Ivan/ > mobile: +31-641044153 > FOAF: http://www.ivan-herman.net/foaf.rdf > > > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Wednesday, 11 April 2012 05:51:42 UTC