 |
 |
Thanks, Tom. You captured (depicted?) exactly what I was thinking. The decision to model conferences as Agent, as Rebecca Guenther mentioned, can be traced back to card catalog conventions and the need for a "main entry," and this is a constraint that no longer pertains. For ease of conversion, could we abstract things a step further, and just say: example:work123 bf:captures example:conference456 This would work for things like Olympiads as well as conferences. More specific subproperties could also be defined, of course, for particular resource types. -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library On Thu, Jan 21, 2016 at 4:58 AM, Meehan, Thomas <[log in to unmask]> wrote: > I find this really interesting, partly because it sometimes seems that the > more common-sense view of the world we would ideally like (or that perhaps > others have already built) is being constrained by the rules. In those > cases, I wonder if we should use some “cataloguer judgement” on the rules > if they’re holding us back. > > > > BIBFRAME seems already happy not to slavishly follow a particular > rule-set, and has declared broad intentions of “accommodating different > content models and cataloging rules”. Not directly using the FRBR model > (including this discussion) seems an example of this anyway. > > > That said, couldn’t Bibframe for example take the view that Event isn’t an > Agent and define a more common-sense relationship between work and > conference such as: > > > > example:work123 bf:proceedingsOf example:conference456 > > > > In RDA terms, example:work123 is then (in most cases) an edited > compilation edited by an editor, the constituent works of which may indeed > have proper authors who actually wrote things. > > > > I imagine converting records with 111s along those lines would work even > if the RDA creator relationship is converted into something else. > > > > Thanks, > > > Tom > > > > > > *From:* Bibliographic Framework Transition Initiative Forum [mailto: > [log in to unmask]] *On Behalf Of *Trail, Nate > *Sent:* 20 January 2016 21:36 > > *To:* [log in to unmask] > *Subject:* Re: [BIBFRAME] Events proposal for BIBFRAME 2.0 > > > > A good argument for changing cataloging rules, but meanwhile, doesn’t > bibframe need to have a place to put the 111s that have been created under > the existing rules? > > > > *From:* Bibliographic Framework Transition Initiative Forum [ > mailto:[log in to unmask] <[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] > <[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] <[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 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. > http://kcoyle.blogspot.com/2016/01/sub-types-in-frbr.html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__kcoyle.blogspot.com_2016_01_sub-2Dtypes-2Din-2Dfrbr.html&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=DEbn9pYQwcNGJ8XtoP1klVtcsRk6bucK0yE6KQfLf7A&s=t09CSqKb5uRz6PJVAHOJE8uwBTgOfmPFKCxvYpBI7lc&e=> > 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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__speroni.web.cs.unibo.it_cgi-2Dbin_lode_req.py-3Freq-3Dhttp-3A_purl.org_spar_fabio&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=DEbn9pYQwcNGJ8XtoP1klVtcsRk6bucK0yE6KQfLf7A&s=xmUnmqZcfeCLxZK4FhKE3jW1g5N3ag5oUzas8icwMqo&e=> > > The frbrCore vocabulary introduced just a few sample subtypes: > http://vocab.org/frbr/core.html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__vocab.org_frbr_core.html&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=DEbn9pYQwcNGJ8XtoP1klVtcsRk6bucK0yE6KQfLf7A&s=DRxSw9D5BvcyD37ggmTgN3D8iGVgYw9H1tm_FxGnCaM&e=> > > kc > > > > Best regards, > > Oddrun Pauline Ohren > > > > *Fra:* Bibliographic Framework Transition Initiative Forum [ > mailto:[log in to unmask] <[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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__kcoyle.net&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=DEbn9pYQwcNGJ8XtoP1klVtcsRk6bucK0yE6KQfLf7A&s=Zj4o607JRUBgOoESo47CyrbGP_UsyAeBby7EakqgH4M&e=> > > m: +1-510-435-8234 > > skype: kcoylenet/+1-510-984-3600 > > > > >