Right, on the web no one is looking for some thing typed “Instance”. We are more interested finding things and their relation to other things. But, as Karen suggests we would want those things typed as something we can relate to (e.g. Book, cd, lp, dvd). 

ODP published a pattern similar to Work/Instance, http://ontologydesignpatterns.org/wiki/Submissions:Information_realization, and I’m sure they don’t expect that people will be looking for [literally] InformationRealizations. This pattern is set up to answer the competency questions (kind of like data points): 
  • what are the physical realizations of this information object? 
  • what information objects are realized by this physical object?
It’s the relationship in the pattern that is critical. The reason why I keep pursuing this conversation is if we have clear understanding of the BIBFRAME semantics, then we can better understand how to apply the model and extend it to to specific domains with specific relationships and specific types of things. I’m hoping bf:InstanceOf can be considered similar to odp:Realizes from the ODP pattern. 

Karen, To respond to an earlier question… my instinct is yes, we may want to have a separate Instance for a Epub, Kindle, pdf, etc. The different Instances would likely share some assertions, but with separate Instances we could record specific extents for each Instance. One Instance might have a different number of “pages” than another, maybe even a different “Title”. Items would then refer to specific “copies" of the Instance located on different servers, devices, library shelves... 

I know I’m opening a can of worms by saying this (and maybe this is what you meant by Instances being a mix of bibliographic description and physical), but… the bf:Instance subclasses as they currently stand sometimes refer to physical things and sometimes they refer to how the content is organized/published (see: Integrating, Serial, Monograph). The fact that a journal is published in parts has nothing to do with the physical nature of the carrier it’s published on. Seems like if there were a Content/Carrier divide between Work/Instance we would need Electronic, Print, and Tactile as built-in Instance subclasses. The other Instance subclasses might then move to Work. 

I’m not worried about the translation example below. We can refer to things we don’t have; that’s what ILL is for. :)

Thanks,
Steven


From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Karen Coyle <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Sunday, December 6, 2015 at 11:32 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] Categories proposal



On 12/5/15 5:53 PM, Young,Jeff (OR) wrote:
[log in to unmask]" type="cite">
I would amend this slightly to criticize the obsession with "types of things" rather than "things".

RDF is dependent on belief in *things*, but not on *types*. The belief in specific *relationships* is more interesting.

Well, I find "types of things" interesting and useful, but I don't consider types in RDF to be a kind of top-down organizing principle, the way they are in object-oriented design. I see RDF types as views, which you can apply (or not) as desired; and things can be in lots of different views.

But leaving that aside, FRBR, as written, does have a fair emphasis on relationships, although that aspect doesn't get the same attention today as the definition of entities. I have lots of questions about how one implements those relationships, and a key one is: what do you do about relationships between bibliographic "things" when not all of those things are in your catalog? e.g. in a model with actionable relationships, what is at the receiving end of the relationship in that case?

<WarAndPeace@en><isTranslationOf><??somethingIDoNotHave>

Just something that I'm inclined to worry about, wondering if anyone else does, too.

kc

[log in to unmask]" type="cite">

Jeff

On Dec 5, 2015, at 8:16 PM, Karen Coyle <[log in to unmask]> wrote:

Yes, I think that they are meaningless as "things" because of the level of abstraction. I fully understand how they might be used conceptually in the organization of cataloging rules, but I don't think we should embrace them as actual data points. In fact, I don't think they were initially intended as data points, so I do think that "mistakes have been made" in viewing FRBR as data. I gave a whole talk on this at SWIB2015 -- it was streamed and hopefully it will come available for viewing. I'll try to remember to ping this list when that happens.

kc

On 12/5/15 10:56 AM, Gordon Dunsire wrote:
[log in to unmask]" type="cite">

Karen

 

You say “The entire FRBR WEMI is at a level of abstraction that is nearly meaningless”. Do you really think that the FRBR Review Group, the IFLA Cataloguing Section, and the IFLA Standards Committee are engaged on a useless task? The FRBR semantics are clearly defined; what is “meaningless” about that?

 

Cheers

 

Gordon

(Member of the FRBR Review Group, etc.)

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: 05 December 2015 17:04
To: [log in to unmask]
Subject: Re: [BIBFRAME] Categories proposal

 

 

On 12/4/15 8:22 PM, Steven Folsom 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.


This assumes that a hard copy and a pdf of the same item would be different instances, no? What about a DVD and a Blueray of the same movie? Or a ePub and Kindle edition? Although bf:Instance is defined as being the "carrier" (conceptually) I don't think that it actually does coherently represent the physical carrier. It's really a mish-mosh of things we've called "descriptive cataloging", more or less equivalent to ISBD. But as we know that fell apart with digital equivalents and I don't think it's been resolved. I actually think that Instance needs to be better analyzed, and we might end up with two or more sets of data - separating the bibliographic description and the physical description.

I could, however, get behind an attempt at subclassing bf:Work such that ex:Poem and ex:Symphony, etc., could be works. In the end bf:Work is an abstract super-class that itself may never need to be instantiated. And maybe the same would be true of Instance once we separate bibliographic and physical attributes. The entire FRBR WEMI is at a level of abstraction that is nearly meaningless, so "edition" and "performance" actually could infer frbr:Expression, and no one would need to assign those abstractions.

Hmmm. Worth thinking about. Thanks for the stimulus.

kc




 

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

<http://id.loc.gov/vocabulary/carriers/sd>  a  bf:Instance.

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://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/sdrdfs: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]> 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:

<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]
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:

 

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

 



-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600