+1

Thanks,
Shlomo Sanders
CTO
Ex Libris a ProQuest company

-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Martynas Jusevi?ius
Sent: Thursday, January 21, 2016 00:38
To: [log in to unmask]
Subject: Re: [BIBFRAME] Events proposal for BIBFRAME 2.0

Excuse me for crashing the librarians' party, but what the heck does a bibliographic vocabulary have to do with events?

There is already schema:Event, dbpedia:Event and a whole Event ontology (actually just one of them):
http://linkedevents.org/ontology/

But hey, lets invent another one! Because events in the bibliographic context are somehow special compared to all other events, right?
(Wrong.)

bf:Content sounds even more worrysome but maybe I don't know the details, so I'll leave it at that for now.

If this is intended as a direct mapping of some MARC fields, or a wish to control every term by putting it under BF namespace -- these are all the wrong reasons in the Linked Data world. RDF terms and vocabularies are meant to be shared, reused, combined, extended etc.

BIBFRAME only needs to describe the bibliographic domain (authors, works, translations, ISBNs etc.), not every domain the bibliographic data can be about. It's impossible in general, but if you try hard enough you might end up with another schema.org (just much less known and used).

That was my 2 cents.

Martynas
graphityhq.com

On Tue, Jan 19, 2016 at 10:40 PM, Tim Thompson <[log in to unmask]> wrote:
> I agree, the proposed usage of bf:Content does seem somewhat
> counterintuitive. It is the bf:Event that provides content to the
> derivative bf:Work, not the other way around--which is just another
> way of saying that the bf:Work depicts or captures the bf:Event.
>
> For examples of Events that could be modeled as Works, wouldn't things
> like performance art qualify, or jazz or hip-hop performances (the
> latter are examples that Karen Coyle cites in her book on FRBR)? As
> Works, their temporal quality is a defining aspect of how they are expressed.
>
> Out of curiosity, I just did a search in the Name Authority File and
> found a few authority records for performance art works, for example:
> http://id.loc.gov/authorities/names/n2013032123.html. So there is
> precedent even under current practice, although we lack the vocabulary
> or conceptual model to encode Temporal Works adequately.
>
> Which leads to another thorny issue. What about bf:Meetings as bf:Events?
> There is no mention of them in the Event proposal, but it seems like
> another area that could lead to confusion. Would it be more consistent
> to make bf:Meeting a subclass of bf:Event, rather than bf:Agent, or to
> make it a subclass of both?
>
> In our current cataloging practice, we throw a lot of things into the
> MARC
> 111 field. Sometimes we treat those things as agents. For example, we
> might treat a conference as the corporate author of its proceedings.
> In other cases, however, it might not be an agent at all, but rather an event.
>
> I recently cataloged a book about a dramatic performance of Brazilian
> indigenous culture that occurred in 1550 in Rouen, France, performed
> by 50 members of the Brazilian Tabajara and Tupinamba tribes and 250
> French sailors To my surprise, someone had already created an
> authority record for this event:
> http://id.loc.gov/authorities/names/no2010085847.html. However, it wasn't cataloged as a MARC 150 topic, but as a MARC 111 "conference"
> (i.e., bf:Meeting). LC even has a list of "Ambiguous Entities," some
> of which can be "names," and other of which can be "subjects."
> "Generic" events (funerals are cited) are treated as subjects, whereas
> "named" events (exhibitions, conferences, contests) are treated as
> agents[1]. So, can Events be Agents as well as Works?
>
> Tim
>
> [1] http://www.loc.gov/aba/pcc/saco/alpha405.html
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty) Princeton University
> Library
>
> On Tue, Jan 19, 2016 at 2:13 PM, Denenberg, Ray <[log in to unmask]> wrote:
>>
>> > 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
>>
>>
>
>