Print

Print


Sorry, I spoke too fast, didn’t mean to say
<http://id.loc.gov/vocabulary/carriers/sd>  a  bf:Instance.
But rather
<http://id.loc.gov/vocabulary/carriers/sd> rdfs:subClassOf <bf:Instance>

I’m not quite sure why your assertion would be lost (without ID making the same assertion), but let’s say it’s so.  Theoretically, we could add the assertions to ID.  (I say “theoretically” because I cannot commit to that, we’d have to discuss it, and I haven’t discussed it yet here.)   But if we take that approach then are we saying that all potential subclasses of Work or Instance would have to be included in ID?  (Because we can’t assume that other vocabularies with potential subclasses of Work or Instance will include these assertions.)

Hope I’m understanding you correctly, and I appreciate your persistence in this issue.

Ray

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

Ray,

[Sorry, I’m not trying to be a nag.] What I’m trying to say is that the following IS an implementation of RDA because it provides category, carrier and media information about the library resource.

<http://bibframe.example.org/instance/xyz>  a  <http://id.loc.gov/vocabulary/carriers/sd> ,  <http://vocab.getty.edu/aat/300265800> .

<http://id.loc.gov/vocabulary/carriers/sd> rdfs:subClassOf <bf:Instance> ;
  bf:hasMedia <http://id.loc.gov/vocabulary/mediaTypes/s> .


Notice here that I’ve asserted that the audio disc carrier is a subclass of bf:Instance (which is different from saying it is an individual of a bf:Instance) and that it has audio as a media. In a linked data environment, I can’t really say these things without minting my own URI for for the concept of audio disc carrier and stating that it’s the sameAs ID’s. Without ID making those same assertions on it’s URI, when someone resolved to it, my assertions would be lost.

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 "Denenberg, Ray" <[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: Thursday, December 3, 2015 at 3:29 PM
To: "[log in to unmask]<mailto:[log in to unmask]>" <[log in to unmask]<mailto:[log in to unmask]>>
Subject: Re: [BIBFRAME] Categories proposal

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]<mailto:[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]<mailto:[log in to unmask]>> on behalf of "Denenberg, Ray" <[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: Wednesday, December 2, 2015 at 3:45 PM
To: "[log in to unmask]<mailto:[log in to unmask]>" <[log in to unmask]<mailto:[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]<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.

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<http://id.loc.gov/vocabulary/carriers/sd>/carriers/sd<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> ;
  <bf:hasGenre> <http://id.loc.gov/authorities/subjects/sh99001678<http://id.loc.gov/authorities/subjects/sh99001678.skos.rdf%3e>> .


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