On Nov 30, 2015, at 4:05 PM, Steven Folsom <[log in to unmask]> wrote:
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?
————Steven FolsomMetadata Strategist and Standards AdvocateCornell 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:
a bf:Carrierrdfs: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.