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

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

From: Ivan Herman <ivan@w3.org>
Date: Tue, 10 Apr 2012 15:14:36 +0200
Message-Id: <42537FBB-C8E7-4D8B-A69F-05D3AD19671D@w3.org>
To: W3C RDF WG <public-rdf-wg@w3.org>
Just my immediate reaction on this...

What this use case seem to demand is some possibilities to manipulate graphs explicitly, that is to create the union (in the RDF) sense of graphs (that is the way I interpret this 'Frame' concept).

The question is whether this is left in the application domain, via some sort of API on the RDF environment (the RDF environment I know the most, namely RDFLib, has operations to create the union of graphs) or whether we need some declarative/syntax means for that. Something like (using Tom's pseudo-code):

<u> { P has_title "Moby-Dick, or, the Whale"; P has_as_subject "Whaling Ships -- Fiction" }
<v> { Q has_language "English" ; Q has_extent "213711 words" }
  <f> rdf:unionOf ( <u> <v> ) .

or, alternatively, some syntax that explicitly says that the Default Graph includes the union of all those graphs, but I am not sure what syntax one would use for that...


On Apr 10, 2012, at 15:05 , 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
>> One would then want to infer that the Item in hand (described by the statements
>> in Named Graph A) is _also_ described by statements in the Named Graphs at the
>> more abstract levels 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"
>> 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.
>> 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

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

Received on Tuesday, 10 April 2012 13:13:07 UTC

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