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:

"Heuvelmann, Reinhold" <[log in to unmask]>

Reply-To:

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

Date:

Thu, 21 Jan 2016 09:25:08 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1 lines)

Ray wrote:

> They are different resources; the two URIs are different.

I think I disagree.

In the GND (Gemeinsame Normdatei, Integrated Authority File) we only have _one_ entity:  http://d-nb.info/gnd/10202681-6  .  In addition, there are _different_ _roles_ that this entity has played with regards to several resources.

As you can see in the DNB catalog context, it is used for resources created by this entity ("Urheber von", MARC 111), or resources that this entity participated during creation ("Beteiligt an", MARC 711), or resources that are created about this entity ("Thema in", MARC 611).

Best wishes

Reinhold


Von: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] Im Auftrag von Denenberg, Ray
Gesendet: Mittwoch, 20. Januar 2016 22:50
An: [log in to unmask]
Betreff: Re: [BIBFRAME] Events proposal for BIBFRAME 2.0

"Olympic Games (29th : 2008 : Beijing, China)" is simply a label.   Hypothetically there is a URI for an event resource, which uses that label.  And, hypothetically, there is a URI for an agent resource, which uses that label.  They are different resources; the two URIs are different. You don’t have to make that choice: is it an agent or is it an event. 
Ray

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Tim Thompson
Sent: Wednesday, January 20, 2016 4:29 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Events proposal for BIBFRAME 2.0

But what do we do about cases like "Olympic Games (29th : 2008 : Beijing, China)"? Only in an insular, bibliocentric universe (in my opinion) does it make sense to say that this in an Agent rather than an Event. But it seems the only current option in BIBFRAME would be to call it a bf:Meeting. How well is that going to play on the open Web?
Tim

[1] http://id.loc.gov/authorities/names/no2001038783.html


--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library

On Wed, Jan 20, 2016 at 4:10 PM, Denenberg, Ray <[log in to unmask]> wrote:
Nevermind “publisher”, “ALA 2016” would be the “creator” of the proceedings, right?
 
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Gordon, Bruce J.
Sent: Wednesday, January 20, 2016 3:49 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Events proposal for BIBFRAME 2.0
 
I don't know about the ALA meeting, but the publisher of the proceedings of a conference is not the conference but the organization that holds the conference or some other entity responsible for publishing. An event isn't an agent and can't publish anything, but there are fruits of that event that can be published by an agent. There seem to have been shortcuts taken that end up conflating meanings perhaps for the sake of expediency or brevity, or the lack of a better place in which to describe. 
 
Best,
 
-Bruce
 
Bruce J. Gordon
Audio Engineer
Audio Preservation Services - a shared service of the Harvard Library
Harvard University
Cambridge, Massachusetts 02138
U.S.A
tel. +1(617) 495-1241
fax +1(617) 496-4636
 
On Jan 20, 2016, at 3:38 PM, Steven Folsom <[log in to unmask]> wrote:
 
Is "ALA Midwinter 2016" a publisher? 
 
Or is ALA (or some contracted service) the Publisher of the Proceedings of the ALA Midwinter 2016 Meeting? 
 
From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of "Trail, Nate" <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Wednesday, January 20, 2016 at 3:31 PM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] SV: [BIBFRAME] Events proposal for BIBFRAME 2.0
 
Meetings as Agent and Meetings as Events: maybe they can be both, and we’re conflating them because they have the same label?
 
“ALA Midwinter 2016” is both a publisher and an event, and probably should have two uris, one as a madsrdf:Meeting and one as a bf:Event , each with different properties describing the different aspects of the same idea.
 
Nate
 
-----------------------------------------
Nate Trail
Network Development & MARC Standards Office
LS/ABA/NDMSO
LA308, Mail Stop 4402
Library of Congress
Washington DC 20540
 
 
 
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Steven Folsom
Sent: Wednesday, January 20, 2016 3:20 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] SV: [BIBFRAME] Events proposal for BIBFRAME 2.0
 
This has been a really interesting thread to monitor. Some reactions to various discussions:
 
1.) I think it’s worth clarifying what happens with subclassing. (I think everyone participating understands this, but it might help tease out some problematic terms.) If one class is asserted as a subclass of another, every instance of the former is always an instance of the latter. E.g.
 
If:  ex:Meeting rdfs:subclassOf ex:Event .
 
Then this statement: <Some Meeting> a ex:Meeting .
 
*Always* entails: <Some Meeting> a ex:Event . [Perhaps this is what was originally meant by hierarchies are “static”? Totally agree that in RDF something can exist in multiple hierarchies, but subclasses aren’t for "sometimes situations”.]
 
2.) Regardless of historic practice, I’m not sure I would want a Meeting to be a subclass of Agent. It’s more fitting for Meetings be treated as Events that Agents participate in.
 
3.) Because bf:Work and bf:Event are not (to my knowledge) asserted to be disjoint, there is nothing formal stopping us for asserting that something is both a bf:Work and bf:Event when it is the case (e.g. the performances that Tim alluded to). Depending on the Event and its relationships to other entities, it may or not BE a Work. It may or may not generate/depict/be the subject of a Work. What I’m trying to say is that because there will be so many ways we will want to refer to bf:Event they shouldn’t be pigeonholed, but there may be some Event types that we want to treat always as works (e.g. Performances). 
 
4.) The points I made about Works/Events above apply for Contributions and Provisions and Events. I could see a case where we want to say the “event” represented as an AuthorContribution is the subject of a book. Or occasionally wanting to use schema:Event properties (I believe suggested by Amanda) to better describe a Contribution.
 
5.) I too, don’t understand what the Content class adds.
 
 
 
 
 
 
 
 
 
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: Wednesday, January 20, 2016 at 11:33 AM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] SV: [BIBFRAME] Events proposal for BIBFRAME 2.0
 
 
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 ☺.
 
(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. 
    http://kcoyle.blogspot.com/2016/01/sub-types-in-frbr.html
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 areas).

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:
    http://speroni.web.cs.unibo.it/cgi-bin/lode/req.py?req=http:/purl.org/spar/fabio

The frbrCore vocabulary introduced just a few sample subtypes:
    http://vocab.org/frbr/core.html

 kc

 
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] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600
 

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