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