Print

Print


Again, not a cataloger.

In a linked dataverse, there should be the possibility to use the terms "genre" and "form" in a logical, decoupled way, where "Genre" (big 'G') and "Form" (big 'F') are defined as in Websters, and where "genre" (little 'g') and "form" (little 'f') are defined as in the vernacular. The two forms, if you'll pardon me, of the two terms occupy different spaces in the descriptive hierarchy, and any confusion is only in our minds or engraved in our catalogs. It is still possible to separate the vegetables after the salad has been tossed.

Best,

-Bruce

Bruce J. Gordon
Audio Engineer
Audio Preservation Services - a shared service of the Harvard Library
Harvard University
Cambridge, Massachusetts 02138
U.S.A
tel. +1(617) 495-1241
fax +1(617) 496-4636

On Dec 2, 2015, at 7:30 PM, Adam L. Schiff <[log in to unmask]<mailto:[log in to unmask]>> wrote:

Steven wrote:

“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.”

I commented on this here not too long ago: it probably is not advisable to try to decouple form and genre.  A task force of the ALCTS Subject Analysis Committee Subcommittee on Genre/Form Implementation did extensive research on the definitions of genre and form in the context of LCGFT (Library of Congress Genre/Form Terms) and one of its main findings was that the terms are often used interchangeably:

“The terms genre and form are often used interchangeably in authoritative sources, and even when differentiated the resulting definitions are inconsistent and contradictory--formal structure is often cited as a key aspect of genre and intellectual content is considered as a key aspect of form. Many approved genre/form terms represent resource types defined by tightly bound intellectual content and formal structure.”

The task group recommended that LCGFT not attempt to define and present “genres” and “forms” as meaningfully distinct concepts.  We haven’t yet received a response on these recommendations from LC, but we expect to by ALA Midwinter.

Adam

Adam L. Schiff
Principal Cataloger
University of Washington Libraries
Box 352900
Seattle, WA 98195-2900
[log in to unmask]<mailto:[log in to unmask]>
(206) 543-8409
(206) 685-8782 fax

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Steven Folsom
Sent: Monday, November 30, 2015 1:05 PM
To: [log in to unmask]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=http-3A__id.loc.gov_vocabulary_carriers_sd&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=_fd8OLsuetpm0EwDkTRVipw19749mGt6miYOKCoqSTk&s=RXWcOJb0QlFddqvdS5KNnH-Xvkp4v7uei2CEcLPq7_8&e=>.

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__id.loc.gov_vocabulary_carriers_sd&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=_fd8OLsuetpm0EwDkTRVipw19749mGt6miYOKCoqSTk&s=RXWcOJb0QlFddqvdS5KNnH-Xvkp4v7uei2CEcLPq7_8&e=>/carriers/sd<https://urldefense.proofpoint.com/v2/url?u=http-3A__id.loc.gov_vocabulary_carriers_sd&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=_fd8OLsuetpm0EwDkTRVipw19749mGt6miYOKCoqSTk&s=RXWcOJb0QlFddqvdS5KNnH-Xvkp4v7uei2CEcLPq7_8&e=> > .

Based on what we’ve attempted to say about media in MARC (see, http://www.loc.gov/marc/bibliographic/bd337.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.loc.gov_marc_bibliographic_bd337.html&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=_fd8OLsuetpm0EwDkTRVipw19749mGt6miYOKCoqSTk&s=pfc4jyAjig-ViB26e_0vlBJBOgNuLJqXCkdIeJw6hGg&e=>), 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> ;
  <bf:hasGenre> <http://id.loc.gov/authorities/subjects/sh99001678<https://urldefense.proofpoint.com/v2/url?u=http-3A__id.loc.gov_authorities_subjects_sh99001678.skos.rdf-253e&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=_fd8OLsuetpm0EwDkTRVipw19749mGt6miYOKCoqSTk&s=93BDlp9anGfhl2i4WzyQICunANM_pIUptneRSGdcvIg&e=>> .


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]<mailto:[log in to unmask]>> on behalf of Joseph Kiegel <[log in to unmask]<mailto:[log in to unmask]>>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]<mailto:[log in to unmask]>>
Date: Monday, November 30, 2015 at 1:15 PM
To: "[log in to unmask]<mailto:[log in to unmask]>" <[log in to unmask]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=http-3A__id.loc.gov_vocabulary_carriers_sd&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=_fd8OLsuetpm0EwDkTRVipw19749mGt6miYOKCoqSTk&s=RXWcOJb0QlFddqvdS5KNnH-Xvkp4v7uei2CEcLPq7_8&e=>>
               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.