LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  October 2017

BIBFRAME October 2017

Subject:

Re: Resource relationships

From:

Steven Michael Folsom <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Fri, 20 Oct 2017 19:30:40 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

In the LD4L analysis and adoption of BF2 we chose simply to extend BF2 using select RDAU properties. [1]

RDAU isn’t perfect, but sticking to the general properties would get us pretty far. Our biggest reason for only using *select* RDAU properties is proliferation caused by the anti-pattern of minting new properties to account for the type of things being related; we don’t need “is opera adaptation of” if we have the more general “is adaptation of” and an Opera class/genre term. 

Similarly, using relationships to create new classes (as described in Joe’s bf:ChoreographicAdaption example below) causes unnecessary Class proliferation; each class would then require parallel classes for all the different types of relationships between resources.

The other option being floated below (using bflc:Relationship) seems like over engineering for a problem that could be solved with just reusing the parts of RDAU that are well designed.

Is this under consideration?

Respectfully,
Steven

[1] For more information on the LD4L analysis of BIBFRAME, see:
- https://bibliotek-o.org/overview/overview.html
- https://wiki.duraspace.org/display/LD4P/bibliotek-o 

-- 
Steven Folsom
Metadata Specialist
Cornell University Library
http://orcid.org/0000-0003-3427-5769
@sf433
 



On 10/20/17, 12:14 PM, "Bibliographic Framework Transition Initiative Forum on behalf of McCallum, Sally" <[log in to unmask] on behalf of [log in to unmask]> wrote:

    Joe,
    I can see why you were confused about the treatment of relationships in BIBFRAME as we had to use bflc:  namespace ourselves to enable the expression of the hundreds of relationships that RDA lists and to express relationships from other sources.   As we progressed through our MARC to BF conversion specs and programs we added an extended capability, the property bflc:relationship along with corresponding class bflc:Relationship,  modeled on bf:contribution/bf:Contribution .  We added this to bflc because the bf: vocabulary was already published and we were not comfortable just adding what we "felt like".  I think you found it buried in the specs but here is it again:
    
    RDF for relationships
    
    <resource>	bf:relatedTo*		URI.		(of resource being related to)
    *bf:relatedTo may instead be one of the other bibframe relation properties.
    
    Or to express a specific relation label and/or have the URI for another special relation:
    <resource>	bflc:relationship   	[a 	bflc:Relationship;
                              	bf:relatedTo		URI;  		 (of resource being related to);
                              	bflc:relation*		URI;  		 (for relation )
                                 bflc:relation*		[rdfs:label  "name of relation"] ] .
    * one or both of these
     
    Thanks for highlighting this.  We will check our conversion specs and programs to see that they are working as planned.  We also need to add this to the BIBFRAME notes on the web site so it is not so hard to find.     
    
    Sally
    
    -----Original Message-----
    From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Joseph Kiegel
    Sent: Thursday, October 19, 2017 12:09 PM
    To: [log in to unmask]
    Subject: Re: [BIBFRAME] Resource relationships
    
    My mapping is the test of whether the same concepts can be expressed in both schemas.  BIBFRAME currently has no other means beyond these properties to express resource relationships, so BIBFRAME is not as expressive as RDA.
    
    As far as catalogers are concerned, they will catalog in RDA in an interface like RIMMF or the LC Editor.  The rendering of their work into linked data happens behind the scenes, so there is no question of "easier to work with".  As long as RDA is the cataloging standard, the intellectual distinctions of RDA are what catalogers work with.
    
    I would like to see the full range of resource relationships incorporated directly into BIBFRAME (rather than, say, being an extension).  Since BIBFRAME avoids a proliferation of properties, this will involve creating more classes.   For the purpose of the examples, new class names are drawn directly from RDA terminology.  Note that unconstrained RDA is needed because BIBFRAME does not make a distinction between Work and Expression.
    
    A simple way to express the relationship of choreographic adaptation is:
    
    <bf:WorkA> bf:derivativeOf <bf:WorkB> .
    <bf:WorkA>  a  bf:ChoreographicAdaptation.
    
    A more complex way is possible, along the lines of what the LC converter does, using classes and the LC extensions bflc:relationship and bflc:relation.  (In the example below, I pull these properties into BIBFRAME as well, as I have suggested elsewhere.).  bf:relationship is used to create a node containing  1) bf:relatedTo with a URI for the related resource and 2) bf:relation with a class for the appropriate relationship and optionally a label for the name of the relationship.  New classes are defined as subclasses of bf:Relation.
    
    For example, the relationship can be rendered as:
    
    <bf:Work A> bf:relationship [ a bf:Relationship ;
    	bf:relation [ a bf:Relation,
    		bf:ChoreographicAdaptation ;
    	rdfs:label "Choreographic adaptation" ] ;
    	bf:relatedTo <bf:Work B> ] .
    
    
    -----Original Message-----
    From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
    Sent: Wednesday, October 18, 2017 9:18 AM
    To: [log in to unmask]
    Subject: Re: [BIBFRAME] Resource relationships
    
    RDA and BIBFRAME have definitely taken different approaches to this problem. It would be interesting to know whether the final functionality of the two approaches is similar. For example, RDA has:
    
    choreographicAdaptationOfExpression
    
    while BIBFRAME has:
    
    derivativeOf
    
    Statements would look like:
    
    <A> <rdae:choreographicAdaptationOfExpression> <B> and <X> <bf:derivativeOf> <Y>
    
    These could actually have the same semantics if X has the quality of being a choreographic adaptation (or a choreography, I suppose) and Y is an expression. That statement's semantics would then be: "this choreographical thing(X) is a derivative of the following expression(Y)."
    
    It seems to me that RDA has some redundancy by adding "OfWork"
    "OfExpression" to each of the properties, and I am guessing that is because the entities WEMI are defined as disjoint and therefore you cannot have a relationship that has an open range ("derivativeOf" with range being any group 1 entity). BIBFRAME opts for fewer distinct properties, and probably less control built into the vocabulary, but the same semantics may be inferred from the triple rather than being encoded in the property.
    
    These are philosophical differences, in a sense, but checking to see if the same concepts can be expressed in both languages would be an interesting test. The other test would be to see if catalogers working in the two environments find one easier to work with. It could be that user interfaces could alleviate some of the difference between them.
    
    kc
    
    On 10/17/17 10:31 AM, Joseph Kiegel wrote:
    > One area where we can compare the relative expressiveness of RDA and 
    > BIBFRAME is the properties for describing relationships between 
    > resources, that is, between works, expressions, manifestations and 
    > items in terms of RDA and between works, instances and items in 
    > BIBFRAME.  In RDA, these relationships are given in Appendix J 
    > (relationship designators).  In BIBFRAME, they are listed in the 
    > category view in the two sections labelled Cataloging Resource 
    > Relationships - Specific and Cataloging Resource Relationships - Detailed.
    > 
    > I have created mappings of resource relationships from constrained RDA 
    > to BIBFRAME for each of the four resource types in RDA.  They can be 
    > found on the University of Washington linked data page:
    > http://www.lib.washington.edu/msd/pubcat/ld.
    > 
    >  
    > 
    > The first observation is that RDA provides a much more finely grained 
    > description of resource relationships.  For example, for Works there 
    > are over 150 properties in RDA and 32 in BIBFRAME.  For some types of 
    > relationships, e.g. referential relationships and whole-part 
    > relationships, the RDA-BIBFRAME mapping is one-to-one.  For sequential 
    > relationships, the correspondence is close, with 22 relationships in 
    > RDA and 14 in BIBFRAME.  (It was closer in BF1, but BF2 lost most of 
    > the "in part" relationships.)
    > 
    > For derivative relationships and accompanying relationships, however, 
    > there is a great discrepancy between the expressiveness of RDA and 
    > BIBFRAME.  There are over 70 derivative work relationships in RDA but 
    > only two in BIBFRAME.  For accompanying relationships, RDA has over 50 
    > and BIBFRAME has 8.
    > 
    > The result is that much detail is lost when RDA concepts are expressed 
    > in BIBFRAME.  RDA differentiates "abridgement of" from "graphic 
    > novelization of" from "verse adaptation of" from "digest of" from 
    > "parody of".  In BIBFRAME, we have a single choice for expressing all 
    > of these relationships:  derivativeOf.  RDA allows distinctions 
    > between addenda, appendices, concordances and errata but in BIBFRAME 
    > they must be rendered identically as accompaniedBy.
    > 
    >  
    > 
    > My second observation is that BIBFRAME's treatment of resource 
    > relationships does not support the user experience we hope to provide 
    > under RDA.  The elaboration of resource relationships is one of the 
    > significant advances that RDA has made over AACR2.  When catalogers 
    > invest intellectual effort to determine resource relationships, this 
    > information should be displayed to users in our library catalogs.
    > BIBFRAME-encoded cataloging does not fully allow us to do so.
    > 
    >  
    > 
    >  
    > 
    >  
    > 
    
    --
    Karen Coyle
    [log in to unmask] http://kcoyle.net
    m: +1-510-435-8234
    skype: kcoylenet/+1-510-984-3600
    

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager