“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 L. Schiff
University of Washington Libraries
Seattle, WA 98195-2900
(206) 685-8782 fax
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> .
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> ;
<bf:hasGenre> <http://id.loc.gov/authorities/subjects/sh99001678> .
Reactions? Rotten Tomatoes?
Metadata Strategist and Standards Advocate
Cornell University Library
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:
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.