W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2012

Re: Use Case: "Expressing FRBR Descriptions using Named Graphs"

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 10 Apr 2012 22:51:05 -0700
Cc: W3C RDF WG <public-rdf-wg@w3.org>, tom@tombaker.org
Message-Id: <24C4A41F-61CC-45EE-966F-A33163314008@ihmc.us>
To: Ivan Herman <ivan@w3.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...


> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:04 UTC