Print

Print



On 1/26/16 12:39 PM, Rebecca Guenther wrote:
> Karen, where you ask “did the group consider, either in addition to or 
> instead of the superclass, defining this as relationships between 
> events and works”— what is the “this” that you are referring to?

Rebecca, I can see more than one possible way of adding Event to the 
model. One way is to have a superclass, like Content. Another is to have 
Events be simply entities that can have a relationship to Work (this 
event -> inspired -> this work) or that can have a direct relationship 
to Instance (this event -> is instantiated -> in this instance). 
Presumably they also have relationships to Person and other entities in 
the model.

Since the latter makes more sense to me, I'm trying to understand the 
purpose of the superclass. In OO design, a superclass usually has 
properties and methods that are true for all subclasses, so it's an 
efficiency issue (both for program design and perhaps for execution). 
Classes and superclass in RDF have a different meaning. They don't have 
properties or methods, but RDF properties can define classes ("if it has 
a child then it is of class Parent). If there are no properties that are 
of the domain of Content then I don't understand its purpose in the design.

>
> Kevin mentions the 2 reasons why Content was proposed— one was because 
> of the baggage associated with the word “Work” that traditionally 
> means “creative work” (although it isn’t defined as such in the 
> BIBFRAME vocabulary) and the problem that Work had domain and range 
> restrictions that shouldn’t apply to some of the things that are 
> considered events in the AV world. Kevin suggests below that perhaps 
> Content isn’t needed once the domain and range restrictions are lifted 
> from Work (and, yes, many of these restrictions will be removed from 
> the revised BF vocabulary). And that an Instance (i.e. the recorded 
> knowledge) could be directly linked to an Event (if Events were 
> defined as a class in BIBFRAME). That is, the instance has a 
> relationship to an event without necessarily an intervening Work. A 
> Work also could have a relationship with an Event, for instance a 
> performance of an opera where the opera is the work and the specific 
> performance is an event. There would be properties to define those 
> relationships, e.g. captures or whatever.

Right. So if this is the plan, then I reiterate that I'm not clear on 
the function of the superclass Content.

>
> When you say that the only one discussed in this thread is the 
> authorship relationship I think that is because the thread started by 
> talking about conferences as authors— and that they were also events. 
> And, as someone said, some events are capable of authorship when they 
> can be considered to be a group of people.

Right. So I'd like to hear ideas for other relationships between Events 
and other entities.

kc

>
> But maybe you were asking something different.
>
> Rebecca
>
>
>> On Jan 22, 2016, at 10:10 AM, Karen Coyle <[log in to unmask] 
>> <mailto:[log in to unmask]>> wrote:
>>
>> Kevin, thanks for this. I'm going back through the AV analysis report 
>> trying to learn why the solution was the superclass bf:Content. My 
>> questions, which perhaps you can answer, are:
>>
>> 1) are there properties that have bf:Content as their domain?
>> 2) did the group consider, either in addition to or instead of the 
>> superclass, defining this as relationships between events and works?
>>
>> The latter seems important to me, but I haven't seen it discussed. 
>> The events that library catalogs would be interested in are probably 
>> only those events that lead to some recorded knowledge. The 
>> relationship between the event and the recorded knowledge seems 
>> important, yet the only one discussed in this thread is the 
>> authorship relationship.
>>
>> If I missed something obvious in the report (which I agree is 
>> excellent, and should yield much more than just Content), I apologize.
>>
>> kc
>>
>> On 1/21/16 7:45 AM, Kevin Ford wrote:
>>> Hello!
>>>
>>> We’ve been following this thread with interest.  After all, it was 
>>> an AVPS (AVPreserve) report that introduced the concept of Content 
>>> with respect to bf:Work and bf:Event.
>>>
>>> Kara Van Malssen authored the report, but she is unavailable to 
>>> offer a timely comment on this thread so I’d like to provide a few 
>>> clarifying notes to the conversation and pose a couple of questions 
>>> of my own. The former stems from our internal chatter about this 
>>> thread and represents a general consensus of our thinking on this 
>>> matter.  The latter are all my own and should not be construed as 
>>> representing AVPS.
>>>
>>> Kara’s excellent study does propose the creation a new class, 
>>> bf:Content.  Notably, however, Kara proposed bf:Work and bf:Event 
>>> would be sub-classes of bf:Content (said another way, bf:Content 
>>> would be a super-class of bf:Work and bf:Event). This detail is 
>>> important because 1) the current LC proposal declares bf:Content to 
>>> be a subclass of bf:Work, which is the inverse of what was proposed 
>>> in the 2014 report, and 2) we want to note that the 2014 proposal to 
>>> create bf:Content was partly the expression of a conceptual idea and 
>>> partly to address domain/range restrictions in the Bibframe model. 
>>> Although LC’s proposal on this topic does not reflect, verbatim, 
>>> AVPreserve’s 2014 report recommendations – so please do not construe 
>>> this as a defensive response - we do think the distinction between 
>>> the two proposals worthy of discussion.
>>>
>>> bf:Work connotes that some effort of (intentional?) intellectual or 
>>> artistic creation went into the resource.  Even though bf:Work is 
>>> actually not defined in this way [1], our community has imbued so 
>>> much meaning in the word “Work” that it is has proven impossible to 
>>> approach the concept of Work in a more abstract sense.  An Event, 
>>> however, is not defined in terms of ‘intellectual or artistic 
>>> creation’ but of a moment in time and space, and without any 
>>> assumption that whatever occurred was by design. Skipping over the 
>>> survey of evidence on these points (see the report [2]), the report 
>>> concluded – above everything – that an Event concept is vital for 
>>> description (of A/V material) and that the concept is distinct from 
>>> a Work, but that an Event, when applicable, can be and should be 
>>> related to a Work.
>>>
>>> But the report went further:  bf:Content super-class was proposed as 
>>> an expression of the conceptual recognition that these two things 
>>> are distinct yet strongly related, so strongly in fact that they 
>>> could each be abstracted and recognized as the same thing, which was 
>>> called “Content.”   (There is much more in the report that explores 
>>> this concept and I refer you to it for any further explanation [2]. 
>>> Also, let’s not quibble over the name "Content" – there may be 
>>> something better and there mightn’t – because it’s not the point.)
>>>
>>> Beyond the conceptual recognition, the proposal to create the 
>>> super-class had a practical purpose too: the Bibframe vocabulary 
>>> declares specific domains and ranges for bf:Work and, as noted in 
>>> the 2014 report, a number of properties that define bf:Work as their 
>>> domain are also applicable to bf:Event. With bf:Content as an 
>>> abstract super-class, the domains and ranges that needed to be 
>>> shared between bf:Work and bf:Event could be moved up to bf:Content, 
>>> thereby maintaining the expressed restrictions in the vocabulary 
>>> while allowing those properties to be used by bf:Work or bf:Event.
>>>
>>> If I recall correctly, however, I read somewhere that many of these 
>>> domain/range declarations will be removed in a (near) future version 
>>> of the vocabulary.  This may eliminate that domain/range 
>>> consideration that led to the proposal of bf:Content altogether.  If 
>>> that comes to pass, then only the conceptual idea behind Content 
>>> remains, and that is not a strong enough idea to actually 
>>> instantiate a bf:Content class (whether as sub-class or super-class 
>>> of bf:Work).  What is important and essential to description is that 
>>> a bf:Work can richly relate to a bf:Event and vice-versa within the 
>>> Bibframe model and vocabulary.  This is what Tom Meehan is getting at.
>>>
>>> Which brings me to my personal questions about the LC proposal:
>>>
>>> 1) Is there a reason bf:Event and bf:Work cannot be treated as 
>>> separate but equal?  In which case an Instance can relate directly 
>>> to an Event without the proposed indirection that filters everything 
>>> through Work or, more precisely, a bf:Content resource?  Therefore, 
>>> if you have birdsong recorded at a specific place and time and 
>>> conditions, then that is the Event.  The recording – physical or 
>>> electronic – is the Instance, which is an instanceOf the Event.  No 
>>> need for Content or Work – it’s just a relationship between the 
>>> Instance and the Event.   Such as:
>>>
>>> |<http://example.org/resource/1 <http://example.org/resource/1>>a 
>>> bf:Event;rdfs:label "Sooty oystercatcher song.";|||bf|:eventDate "2016-02-04";|||bf|:eventPlace <http://example.org/places/lady-eilliot-island 
>>> <http://example.org/places/lady-eilliot-island>> 
>>> .<http://example.org/resource/2 <http://example.org/resource/2>>a 
>>> bf:Instance;rdfs:label "Recording of sooty oystercatcher 
>>> song.";bf:instanceOf <http://example.org/resource/1 
>>> <http://example.org/resource/1>> .|
>>>
>>>
>>> 2) Is there a particularly strong reason why the bf:Content 
>>> construct is being proposed here?  Another way to ask this 
>>> question:  if you remove bf:Content from all of the examples in the 
>>> LC proposal, how does that materially change anything?
>>>
>>> 3) I’m also unclear about its definition – what is bf:Content?
>>>
>>> All the best,
>>>
>>> Kevin
>>>
>>> [1]http://bibframe.org/vocab/Work
>>> [2]http://www.loc.gov/bibframe/docs/pdf/bibframe-avmodelingstudy-may15-2014.pdf
>>>
>>>
>>> --
>>> Kevin Ford |*AVPreserve*
>>> Chicago, IL | 773 294 9019 [log in to unmask]
>>>
>>> hq: 253 36th St, Suite C302, Brooklyn, NY 11232
>>> http://www.avpreserve.com 
>>> <http://www.avpreserve.com/>|Facebook.com/AVPreserve 
>>> <http://facebook.com/AVPreserve>|twitter.com/AVPreserve 
>>> <http://twitter.com/AVPreserve>
>>>
>>>
>>>
>>> On 1/21/16 3:58 AM, Meehan, Thomas 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]]*On Behalf Of*Tim Thompson
>>>> *Sent:*Wednesday, January 20, 2016 4:29 PM
>>>> *To:*[log in to unmask] <mailto:[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] <mailto:[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 <tel:%2B1%28617%29%20495-1241>
>>>> fax+1(617) 496-4636 <tel:%2B1%28617%29%20496-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
>>>>     <<mailto:[log in to unmask]>[log in to unmask]>
>>>>     on behalf of "Trail, Nate" <[log in to unmask] <mailto:[log in to unmask]>>
>>>>     *Reply-To: *Bibliographic Framework Transition Initiative Forum
>>>>     <<mailto:[log in to unmask]>[log in to unmask]>
>>>>     *Date: *Wednesday, January 20, 2016 at 3:31 PM
>>>>     *To:
>>>>     *"<mailto:[log in to unmask]>[log in to unmask]"
>>>>     <[log in to unmask] <mailto:[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]>mailto:[log in to unmask]]
>>>>         *On Behalf Of *Steven Folsom
>>>>         *Sent:* Wednesday, January 20, 2016 3:20 PM
>>>>         *To:*
>>>>         <mailto:[log in to unmask]>[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
>>>>         <<mailto:[log in to unmask]>[log in to unmask]>
>>>>         on behalf of Karen Coyle
>>>>         <<mailto:[log in to unmask]>[log in to unmask]>
>>>>         *Reply-To: *Bibliographic Framework Transition Initiative
>>>>         Forum
>>>>         <<mailto:[log in to unmask]>[log in to unmask]>
>>>>         *Date: *Wednesday, January 20, 2016 at 11:33 AM
>>>>         *To:
>>>>         *"<mailto:[log in to unmask]>[log in to unmask]"
>>>>         <<mailto:[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.
>>>>             <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=>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:
>>>>             <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=>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:
>>>>             <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=>http://vocab.org/frbr/core.html
>>>>
>>>>              kc
>>>>
>>>>             Best regards,
>>>>             Oddrun Pauline Ohren
>>>>             *Fra:* Bibliographic Framework Transition Initiative
>>>>             Forum
>>>>             [<mailto:[log in to unmask]>mailto:[log in to unmask]]
>>>>             *På vegne av* Denenberg, Ray
>>>>             *Sendt:* 19. januar 2016 20:13
>>>>             *Til:*
>>>>             <mailto:[log in to unmask]>[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] <mailto:[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 <tel:%2B1-510-435-8234>
>>>>
>>>>             skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>>>>
>>>
>>
>> -- 
>> Karen Coyle
>> [log in to unmask]  http://kcoyle.net
>> m: +1-510-435-8234
>> skype: kcoylenet/+1-510-984-3600
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600