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

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:
>> From: Thomas Baker <>
>> Subject: Use Case: "Expressing FRBR Descriptions using Named Graphs"
>> Date: April 4, 2012 23:44:38 GMT+02:00
>> To:
>> Cc: Ron Murray <>, Barbara Tillett <>, Gordon Dunsire <>
>> Archived-At: <>
>> List-Id: <>
>> 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]
>> [2]
>> [3]
>> [4]
>> [5]
>> ----------------------------------------------------------------------
>> 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
>>   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
>>   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]
>> [2]
>> [3]
>> [4]
>> [5]
>> -- 
>> Tom Baker <>
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home:
> mobile: +31-641044153

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

Received on Wednesday, 11 April 2012 05:51:42 UTC