LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  January 2016

BIBFRAME January 2016

Subject:

Re: Events proposal for BIBFRAME 2.0

From:

Martynas Jusevičius <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Wed, 20 Jan 2016 23:38:14 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (196 lines)

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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager