On Nov 30, 2015, at 10:23 PM, Steven Folsom <[log in to unmask]> wrote:
If this list is exhaustive: http://id.loc.gov/search/?q=memberOf:http://id.loc.gov/vocabulary/carriers/collection_AudioCarriers
...then new classes in the namespace would need to be created to get to the 45rpm level of specificity.
Or better yet we could use the already established Getty Art and Architecture Thesaurus entities for 45's and 78's.
On Nov 30, 2015, at 5:06 PM, Gordon, Bruce J. <[log in to unmask]> wrote:
To a non-cataloger this sounds reasonable.
Does it enhance or better enable potential searches?
Coupling of Genre and Form just seems like a logical rat's nest to me. It is a human language conflation problem turned gospel, and then what about searching by form for 45 rpm records (audio discs) or long-playing records (more audio discs), or 78 rpm records, or Compact Discs (audio discs too, no?)
Bruce J. GordonAudio EngineerAudio Preservation Services - a shared service of the Harvard LibraryHarvard UniversityCambridge, Massachusetts 02138U.S.Atel. +1(617) 495-1241fax +1(617) 496-4636
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.