On 1/20/16 3:25 AM, Oddrun Ohren wrote:
> Thanks Ray Denenberg for your clarifications! It might well be that 
> life-cycle events are best kept separate from events as entities 
> described or captured in works.
> However, I still think that bf:Content (or bf:EventContent) is 
> unnecessary, and I hope you BIBFRAME 2.0 developers will come round to 
> the same way of thinking J.
> (Concerning examples of events modeled as works, I think  Tim Thompson 
> provided several good examples. Referring to the draft proposal, 
> perhaps the battle re-enactment  event may be considered a work)
> IMHO one should always think long and hard before solving any need for 
> increased granularity by subclassing existing classes. Class 
> hierarchies are static structures, and should express fairly stable 
> knowledge. Therefore, I am wondering if you plan to do something about 
> the bf:Work class and its subclassing into media specific sub-classes 
> in BIBFRAME 2.0?  As far as I can see, none of the Work subclasses has 
> additional properties (compared to Work), a fact which in itself 
> rather defeats the purpose of subclassing. A more flexible solution 
> would be to introduce a property “type” or similar to Work, and offer 
> a controlled vocabulary of work types  as potential value set. A work 
> type vocabulary would at any rate be easier to maintain through 
> changing media types than would a set of subclasses.  Moreover, it 
> will then be possible to use other type vocabularies in domains where 
>  these are more relevant than the “recommended” one.

It so happens that I just did a short blog post on subclassing Work, 
albeit related to FRBR but possibly valid also for BIBFRAME.
There are indeed additional properties, they just haven't been singled 
out as such. Any property, like "bf:musicKey" is a de facto indicator of 
a sub-type (aka sub-class). BIBFRAME has a number of properties whose 
names begin with "cartographic..." and others that begin with "music..." 
So the type-specific properties exist they just haven't been organized 
as such (something which might be useful for folks cataloging in those 

I disagree that subclassing is static -- at least not in RDF. Any 
subject can be an instance of more than one class, and classes only have 
impact when operated upon, as in querying. It is my understanding that 
in RDF it is very convenient to operate on data using classes, much more 
so than indicating types using values. So there may be a practical 
reason for sub-typing, but it doesn't have to impose limitations, AFAIK. 
Anyway, it's worth thinking about.

Note also that some non-library implementations of FRBR have made use of 
sub-typing of WEM, some even quite extensively:

The frbrCore vocabulary introduced just a few sample subtypes:


> Best regards,
> Oddrun Pauline Ohren
> *Fra:*Bibliographic Framework Transition Initiative Forum 
> [mailto:[log in to unmask]] *På vegne av* Denenberg, Ray
> *Sendt:* 19. januar 2016 20:13
> *Til:* [log in to unmask]
> *Emne:* Re: [BIBFRAME] Events proposal for BIBFRAME 2.0
> > From: Oddrun Ohren
> > • Not being sure how explicitly point *1.c*of the proposal is meant, I’d just like
> > to point out that events may play other roles than being the *subject* of some
> > work,
> The line "A bf:Event will be described in the same manner as other 
> BIBFRAME Subject Types.."  is poorly worded (my fault). Probably 
> better would be: "An event will be described in the same manner as 
> other external resources."
> For example, a person.  While a bf:Person is a BIBFRAME resource, it 
> consists of simply a label, and a link to an external description of 
> the person (a MADS description, FOAF, VIAF, etc.).  That's really all 
> that that was trying to say: the concept of a  bf:Event relies on the 
> availability of an external description of that event. (Except that 
> for the event, there may be some basic properties besides just the 
> label within the BIBFRAME resource, for example date and time, but for 
> any additional description there will have to be an external resource 
> describing the event.)
>  it might be useful to
> > represent  life-cycle events of a work (launching, publication, recording)
> > explicitly in some cases. At any rate we should take care that the Event class is
> > not modelled in such a way that one specific role is assumed.
> Event, as we currently envision it to be modeled, will not include 
> these life-cycle events, we plan to model these differently. 
> Tentatively, there will be a property with name something like 
> bf:originationActivity and class bf:OriginationActivity, with 
> subclasses like bf:Publication, bf:Distribution, and so on, and each 
> of these will have properties like agent, date, place.
> > I am not
> > able to see what bf:Content contributes other than extra
> > (unnecessary)  complexity… o Firstly,  it is problematic to constrain something as
> > general-sounding as Content to be a capture of an Event.
> We are currently considering changing the name to EventContent.
> > o Secondly, if bf:depicts/bf:captures are defined as properties of both Work and
> > Event (like their parent bf:subject) with expected value *any resource*
> > (instances of any BIBFRAME class, including Work), there should be no need for
> > bf:Content. This way, bf:depicts/bf:captures could also be used to represent the
> > fact that some works capture other works (e.g. photographs of paintings).
> > o Lastly, seeing that the existing subclasses of Work are more or less disjunct,
> > bf:Content will create confusion, as it clearly overlaps several of the existing
> > subclasses.
> These are good points and we will need to discuss them.
> > It will also be possible to represent
> > events as a work where appropriate, without losing the possibility to express
> > information about capturing
> Do you have an example of an Event that could be modelled as a Work?
> Thanks much for your comments and suggestions.
> Ray

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