What about a purely electronic resource such a work contained in a file? It has a URN. It has a URL, and a URI. What is the carrier? In a linked dataverse, nobody cares if it's stored on a hard drive or a SSD. The carrier is irrelevant even if it can be determined at all what the carrier is. Yet, the file's content is an instance (occurence) of a work and so if the carrier is the hard drive, then it is not an instance. OTOH, if the file is considered the carrier, then the carrier and instance might be one and the same. No?

-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 4, 2015, at 11:22 PM, Steven Folsom <[log in to unmask]> wrote:

[I think I may have turned others off by keeping this thread going so long, but I’ll respond openly in case someone has more to add… a counter point… etc.]

carrier: would be the prefix for  http://id.loc.gov/vocabulary/carrierscarrier:sd is then short for <http://id.loc.gov/vocabulary/carriers/sd>, the URI for audio disc.

A general carrier:Carrier class could be said to be owl:sameAs bf:Instance, and then any subclass of carrier:Carrier would also then be the subclass of bf:Instance.

The advantage is that if someone said: <SomeWork> bf:hasInstance <SomeRDFResource> . … it could be inferred that <SomeRDFResource> a <bf:Instance>, <carrier:Carrier> . Both classes wouldn’t have to be directly asserted because the range of bf:hasInstance is bf:Instance, and bf:Instance is the sameAs carrier:Carrier. Also, ontology engineers/RDA practitioners would be confident that it’s ok to use Carriers as bf:Instance subtypes. It makes the semantic intent clearer for both classes, ensuring appropriate ontology reuse.

The disadvantage is the ontological commitment of saying <carrier:Carrier> owl:sameAs <bf:Instance>. There may be cases (I truly don’t know, but can’t think of any) where a Carrier type isn’t an Instance type. The way I think of Instance and Carrier types is that they are types of artifacts that carry bf:Works. If I’m wrong, and Instances and Carriers don’t always have the same meaning… then you don’t want to have the owl:sameAs assertion between carrier:Carrier and bf:Instance.

Again, thanks for the open discussion,, 
Steven

————
Steven Folsom
Metadata Strategist and Standards Advocate
Cornell University Library


From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of "Denenberg, Ray" <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Friday, December 4, 2015 at 10:20 AM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] Categories proposal

In other words, we could say:
<http://id.loc.gov/vocabulary/carriers/sd>  a  bf:Instance, carrier:sd  ;
 
(Where ‘carrier:sd’  is a prefix for http://id.loc.gov/vocabulary/carriers .)
 
Where http://id.loc.gov/vocabulary/carriers/sd  is NOT  declared to be a subclass of bf:Instance.
 
(And of course as you suggest these would never be declared disjoint.)
 
Which all makes sense to me and my question would be, what advantage then, if any, is there to making http://id.loc.gov/vocabulary/carriers/sd  a subclass of bf:Instance.
 
Ray
 
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Steven Folsom
Sent: Thursday, December 03, 2015 8:51 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Categories proposal
 
In a closed system (relational db, etc.) or even a triplestore I could use an ID URI and say as much as I want about it, but if I wanted to publish the information as linked data through a dereferenceable URI, either I need to be able to write to the ID server, or I need to write the data to a local (or other global) domain that I have access to. Another way to say it is I can’t publish data to http://id.loc.gov/vocabulary/carriers/sd because I don’t have access to it. Instead, I would have to have access to a system with a different URI for the same thing and assert a sameAs relationship.
 
No, I wasn’t trying to say all subclasses of Work and Instance would have to be included in ID. Part of the open world assumption and ontology reuse is that someone can extend ontologies for themselves. I hope they/we do; it’s a sign of a good ontology if others are reusing it. What I was suggesting is that if ID decides that they do want to always consider the Content and Carrier types as subclasses of Works and Instances respectively, they/you could. If not, the Content and Carrier types don’t have to be treated formally as subclasses. One could still say a particular thing is both an Instance and Carrier as long as the classes aren’t asserted to be disjoint. Interoperability is just easier if the alignment is asserted in ontologies, assuming the semantics make sense. 
 
If/when libraries start creating/consuming BIBFRAME, schema.org, etc. in concert these alignments will become more and more important.
 
Thanks for the continued conversation,
Steven
 
 
From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of "Denenberg, Ray" <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Thursday, December 3, 2015 at 5:56 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] Categories proposal
 
Sorry, I spoke too fast, didn’t mean to say
But rather 
<http://id.loc.gov/vocabulary/carriers/sdrdfs: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://id.loc.gov/vocabulary/carriers/sdrdfs:subClassOf <bf:Instance> ;
 
 
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]> on behalf of "Denenberg, Ray" <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Thursday, December 3, 2015 at 3:29 PM
To: "[log in to unmask]" <[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:
 
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]
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]> on behalf of "Denenberg, Ray" <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Wednesday, December 2, 2015 at 3:45 PM
To: "[log in to unmask]" <[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]
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/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> ;
 
 
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]> on behalf of Joseph Kiegel <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Monday, November 30, 2015 at 1:15 PM
To: "[log in to unmask]" <[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:
 
               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.