Steven – RDA is not one of my strong points (to put it mildly) so I’m afraid I’m not going to be able to offer any insight, but others here might weigh in.

 

You’re certainly correct that the set of built-in Work and Instance subclasses is not intended to describe all possible Work and Instance types.  So let’s say you want to describe some Instance as being of type http://id.loc.gov/vocabulary/carriers/sd .  Certainly you can do that.

http://id.loc.gov/vocabulary/carriers/sd.rdf  already defines it to be a class. Though is does not define it to be a BIBFRAME Instance, you could say:

<http://bibframe.example.org/instance/xyz>  a  (http://id.loc.gov/vocabulary/carriers/sd> .

<http://id.loc.gov/vocabulary/carriers/sd>  a  bf:Instance.

 

Sorry, I did not mean to imply that you could not do that.  I was simply saying that the ability to do this would not  obviate the need to support the method described in the category proposal.

 

Ray

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Steven Folsom
Sent: Thursday, December 03, 2015 10:42 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Categories proposal

 

Ray,

 

Thanks for the response. I’m curious about your thoughts on implementing RDA in BIBFRAME and extending BIBFRAME going forward.

 

RDA is a content standard (independent of how it is serialized). To my knowledge there nothing prescriptive in RDA explaining how to implement it MARC; similarly we are left to decide how to implement it in BIBFRAME.

 

In RDF classes are used to say some individual thing is a certain type of thing. We don’t need a separate property/pattern; we just say it is that type of thing using rdf:type. A specific bf:Work refers to an individual of a type/s of intellectual content, and a specific bf:Instance refers to an individual of a type/s of material embodiments (carriers) of the Work. Right?

 

Yes, there are the built in bf:Work and bf:Instance subclasses, but clearly they are not enough to sufficiently describe with specificity Work and Instance types. We’ll need to extend BIBFRAME using classes defined elsewhere… with The Getty AAT, RDA Content/Carrier Types, etc.

 

To have multiple ways to query whether something is a type of thing (through classes/subclasses and the category patterns) doesn’t seem necessary.

 

Respectfully,

Steven

 

————

Steven Folsom

Metadata Strategist and Standards Advocate

Cornell University Library

 

 

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of "Denenberg, Ray" <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Wednesday, December 2, 2015 at 3:45 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] Categories proposal

 

There are several subclasses of bf:Work and there are subclasses of bf:Instance.  (Both are listed below for 1.0, and BIBFRAME 2.0 will similarly have subclasses of Work and Instance although they might not be exactly the same.)

The Work subclasses overlap to some extent with content values  - “text” for example. For the Instance subclasses there is very little (if any) overlap with the carrier values.  

 

So, no, I don’t think that these content and carrier values can be instantiated as Work and Instance subclasses.

 

Content, carrier, and media are essentially RDA concepts and the main purpose of these in BIBFRAME is support for RDA.  The inclusion of these within BIBFRAME RDF is completely optional and those with no interest in RDA probably will not include this information.

 

Subclasses of bf:Work (1.0)

Audio

Cartography

dataset

MixedMaterial

MovingImage

Multimedia

NotatedMovement

NotatedMusic

StillImage

Text

ThreeDimensionalObject

 

Subclasses of bf:Instance (1.0)

Archival

Collection

Electronic

Integrating

Manuscript

Monograph

MultipartMonograph

Print

Serial

Tactile

 

Ray

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Steven Folsom
Sent: Monday, November 30, 2015 4:05 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Categories proposal

 

Joe, 

 

Not sure if you noticed, but it looks like LOC has published Carriers as bf:Carriers, see: http://id.loc.gov/vocabulary/carriers/sd

 

I haven’t fully formed my thoughts on the new Categories proposal, but I’ve been wondering… Can some or all the new bf:Carrier, bf:Content, bf:Media, and bf:GenreForm be handled by treating them as bf:Work and bf:Instance subclasses? 

 

Couldn’t/shouldn’t the new bf:hasContent be covered by part/whole Work relationships and bf:Work subclasses?

 

Couldn’t/shouldn’t the new bf:hasCarrier be covered by bf:Instance subclasses?

 

Example 1 would then look like:

<ex:SomeWork> <bf:hasInstance>  <ex:SomeInstance> .

<ex:SomeInstance> a <http://id.loc.gov/vocabulary/carriers/sd > .


Based on what we’ve attempted to say about media in MARC (see, 
http://www.loc.gov/marc/bibliographic/bd337.html), it seems like bf:hasMedia could also be covered by Work or Instance subclasses.

 

If/when form and genre are decoupled, form types could then too be used as subclasses of Works or Instances. Genre is possibly the one hold-out. For example, a movie isn’t science fiction, but rather it has a genre of science fiction.  Instead of having science fiction as a subtype of work, we would need a bf:hasGenre property.

 

Example 4 would then possibly look like:

 

<ex:SomeWork> a <bf:Text> ;

 

 

Reactions? Rotten Tomatoes?

 

Thanks,

Steven

 

————

Steven Folsom

Metadata Strategist and Standards Advocate

Cornell University Library

 

 

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Joseph Kiegel <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Monday, November 30, 2015 at 1:15 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: [BIBFRAME] Categories proposal

 

In the Categories proposal, when the carrier (etc.) is asserted as a resource, additional assertions are made about that resource.  This is shown in example 1, where we see:

 

<http://id.loc.gov/vocabulary/carriers/sd>

               a                            bf:Carrier

               rdfs:label             “audio disc”

 

This is an excellent opportunity to simplify by incorporating this type of assertion into the carrier, content, media and genre schemes themselves, in particular since they are maintained by LC.  This would spare libraries the work of making such assertions for each Instance, and reduce the clutter of identical assertions on a lot of different servers.