The good night's sleep version: On 9/23/14 3:29 PM, "Murray, Ronald" <[log in to unmask]> wrote: >I don't think that expressing an assertion in a "machine-processable" way >must require (1.) turning catalogers into triple-generating machines-or >failing that ‹ (2.) stripping out sophisticated community temporal, >calendric, etc., descriptions en route to Triple-Land. > >As far as date* and calendar** manipulations go, existing domain-aware >natural language processing systems seem to be able to meet us (maybe more >than) halfway: > > http://www.wolframalpha.com/input/?i=three+weeks+after+Christmas+1882 > > http://www.wolframlpha.com/input/?i=the+first+weekend+of+last+year >(click on the "More Calendars" button) > >And the venerable: > > http://www.wolframalpha.com/input/?i=quarterly > >Can BIBFRAME designers tell themselves "we can generate a set of >BIBFRAME-friendly triples from ^these^ well-defined natural language >words/phrases/statements" ‹ while at the same time taking steps to create >key >community "open source software" functionality capable of >domain-aware triple-generation? >A glance at financial/date/time/place, >etc. manipulations (e.g., as are found in relational databases) >demonstrates that >much complexity can usefully be offoaded to domain-aware information >processing >systems. > >* http://reference.wolfram.com/language/guide/DateAndTime.html >** http://reference.wolfram.com/languag/ref/CalendarConvert.html > >Ron Murray > >----------------- > >On 9/17/14 10:22 AM, [log in to unmask]" <[log in to unmask]> wrote: > >>One of the advantages of the kind of clear, coherent, understandable >>model for which folks re reaching with their critiques (I'm looking at >>you, Rob Sanderson {grin}) is the provisin of a technical base for >>descriptive practice in which it's easy and quick to express some >>assertion in a machine-processable way, not hard and tedious (or >>practically impossible). >> >>Surely, it'soften appropriate to record information that can only be >>understood by human, but when that's happening because it's too >>difficult to do otherwise, tat implies a problem with the practice or >>the tools. >> >>--- >>A. Soroka >>The University of Virginia Library >> >>On Sep 17, 2014, at 9:49 AM, "Anderson, Kristin" <[log in to unmask]> wrote: >> >>> As a working cataloger, the notes fields are really helpful for data >>>that would be useful for keywod searching, but that you can't figure >>>out how to encode in existing ields under existing rules. >>> >>> My cataloging professor, Dr. Judy Tessier, always said "Why not add a >>>note?" >>> >>> I hope those of you working on BIBFRAME will consider the value of >>>retaining a "Notes" field for unstructured data. >>> >>> People of good will can only retain so much information. We need to >>>make things simple enough so that working catalogers can get their work >>>done. >>> >>> Kristin Anderson >>> (working cataloger, not speaking on behalf of her employer, standard >>>disclaimers apply, etc.) >>> >>> -----Original Message----- >>> From: Bibliographic Framework Transition Initiative Forum >>>[mailto:[log in to unmask]] On Behalf Of BIBFRAME automatic >>>digest system >>> ent: Wednesday, September 17, 2014 12:00 AM >>> To: [log in to unmask] >>> Subject: BIBFRAME Digest - 10 Sep 2014 to 16 Sep 2014 (#2014-119) >>> >>> There are 9 messages totalling 1401 lines in this issue. >>> >>> Topics of the day: >>> >>> 1. Literal Properties vs Notes (4) >>> 2. Specific Questions (4) >>> 3. bfLanguage and Parts >>> >>> --------------------------------------------------------------------- >>> >>> Date: Tue, 16 Sep 2014 06:32:32 +0000 >>> From: Karen Coyle <listsKCOYLE.NET> >>> Subject: Re: Literal Properties vs Notes >>> >>> Frequency is a good example of the mess that we have today in >>> AACR-typ cataloging. There is a way to code frequency as a calculable >>> value in the MARC holdings record. That should suffice and there >>> should be no need for a note field if the value i provided. But notes >>> are "notes" because they are uncontrolled strings created by the >>> cataloger. Where other data in the record are either transcribed >>> strings or controlled headings, notes are neither. But the notes ARE >>> required by the cataloging rules. >>> >>> This is evidence, to me, of the gap between the cataloging rules and >>> the actual practice of creating machine-readable catalog records. AACR >>> does not recognize that coded data (e.g. MARC fixed fields) exists. >>> Many notes repeat information that could be encoded elsewhere, but >>> because the note is what is required by the cataloging rules and also >>> displays in the catalog, the tendency has been to provie the note but >>> often not to provide the actionable data element. Obvously, it would >>> be a mistake to carry forward this practice, and instead the >>> actionable daa element must be the primary source of data, from which >>> user-friendly notes can be derived if neded. That "if needed" part is >>> also something we should think about, becaue in fact in many system >>> displays notes are not included, so catalog usersrarely see them. >>> Because notes have been favored over actionable data,there is a whole >>> host of information that is 1) not usable for any automated functions >>> and 2) rarely seen by users. Surely this is a wase of cataloger time, >>> and a disservice to our users. >>> >>> kc >>> >>> Quoting Tim Thompson <[log in to unmask]>: >>> >>>> Havin a bf:Note class makes sense to e. The current approach seems >>>> exhaustive enough to be cumbersome, but probably not exhaustive enough >>>>to >>>> capture the full range of possibilities in the source data. Not all >>>>notes >>>> come rom 5XX fields. Here is a sample marc2bibframe conversion of a >>>>record >>>> for a srial: >>>> >>>> MARC: http://bibframe.org/resources/Jqc1410365115/marcxml.xml >>>> BF: http://bibframe.org/resources/Jqc1410365115/bibframe.rdf >>>> >>>> Here, bf:frequencyNote map to the 310 field (Current Publication >>>> Frequency). Unfortunately, italso maps to the 321 field (Former >>>> Publication Frequency). This would seem to be a not insgnificant loss >>>>of >>>> information. 5XX fields that are distinct in MARC ar mapped to generic >>>> bf:note properties (515, 588). bf:frequency doesn't ppear, but maybe >>>>it >>>> was meant to correspond o the 008 fix field for continuing resources, >>>> which also has a value for frequency (position 18). The need for tw >>>> distinct properties remains unclear. >>>> >>>> In short, a bf:Note class with bf:noteTpe values might provide greater >>>> flexibility and preserve more of the oiginal semantics. >>>> >>>> Tim >>>> >>>> -- >>>> Tim A. Thompson >>>> Metadata Librarian (Spnish/Portuguese Specialty) >>>> Princeton University Library >>>> >>> >>>> On Tue, Sep 9, 2014 at 5:38 PM, Robert Sanderson <[log in to unmask]> >>>> wrote: >>> >>>>> >>>>> Y'all ready for this? ;) [1] >>>>> >>>>> When is a literal property a 'somehingNote' and when is it just a >>>>> 'something'? >>>>> >>>>> I assume (lacking preiously mentioned MARC to BibFrame mapping >>>>>document) >>>>> that all of the Ntes come from 5XX fields, which seems like >>>>>something that >>>>> could easily be ratinalized along with some of the other properties, >>>>>again >>>>> assuming thy're not 5XX and hence didn't get the Note moniker. >>>>> >>>>> For example, these two lok ... well ... identical: >>>>> >>>>> frequency: Intervals at which the issues orparts of a serial or the >>>>> updates to an integrating resource are issued. >>>>>frequencyNote: Current or former publication frequency of a resource. >>>>> >>>>> >>>>> Current notes are: >>>>> copyNote >>>>> awardNote >>>>> contentsNote >>>>> graphicScaleNote >>>>> illustrationNote >>>>> supplementaryContentNote >>>>> dissertationNote >>>>> geographicCoverageNote >>>>> languageNote >>>>> temporalCoverageNote >>>>> creditsNote >>>>> performerNote >>>>> frequencyNote >>>>> note (!) >>>>> musicMediumNote >>>>> findingAidNote >>>>> >>>>> And the following seem like they're intended to be "notes" in the >>>>>more >>>>> generic sense of added description by a cataloguer or other: >>>>> >>>>> frequency >>>>> custodialHistory >>>>> immediateAcquisition >>>>> notation >>>>> responsibilityStatement >>>>> providerStatement -- or are "Statements" transcriptions from the >>>>> Instance? >>>>> editionResponsibility >>>>> contentAccessibility (though c.f. schema.org/accessibilityFeature) >>>>> >>>>> Given the discussion regarding assigners of URIs being important, it >>>>>seems >>>>> that creators of notes would be also important? And thus Notes could >>>>>be >>>>> their own class, bf:Note, with properties including value, assigner, >>>>>type >>>>> and so forth. >>>>> >>>>> Rob >>>>> >>>>> [1] https://www.youtube.com/watch?v=avcS0aYJ2a8 Warning: seizure >>>>> inducing flashing, terrible animation, poppy 90s music, ... >>>>> >>>>> -- >>>>> Rob Sanderson >>>>> Technology Collaboration Facilitator >>>>> Digital Library Systems and Services >>>>> Stanford, CA 94305 >>>>> >>> >>> ------------------------------ >>> >>> Date: Tue, 16 Sep 2014 15:38:01 +0000 >>> From: Ed Jones <[log in to unmask]> >>> Subject: Re: Literal Properties vs Notes >>> >>> >>>S2FyZW4sDQoNClRoZSBmYXVsdCBpcyBub3QgaW4gb3VyIGNhdGFsb2dpbmcgY29kZSBidXQg >>>a >>>W4g >>> >>>b3Vyc2VsdmVzLiBSREEgdHJlYXRzIGZyZXF1ZW5jeSBhcyBhIGRpc3RpbmN0IGVsZW1lbnQg >>>K >>>DIu >>> >>>MTQpLCBhbmQgcmVxdWlyZXMgYSBub3RlIG9ubHkgd2hlbiBhbiBhcHByb3ByaWF0ZSB0ZXJt >>>I >>>Glz >>> >>>IHVuYXZhaWxhYmxlLiBUaGUgdGVybXMgYXQgUkRBIDIuMTQuMS4zIGNvcnJlc3BvbmQgdG8g >>>d >>>Ghl >>> >>>IGNvZGVzIGF2YWlsYWJsZSBpbiB0aGUgTUFSQyBiaWJsaW9ncmFwaGljIGZvcm1hdCAoMDA4 >>>L >>>zE4 >>> >>>KSwgYW5kIGV2ZW4gbW9yZSBlbGFib3JhdGUgY29kZWQgZnJlcXVlbmN5IGRhdGEgY2FuIGJl >>>I >>>HN0 >>> >>>b3JlZCBpbiB0aGUgTUFSQyBob2xkaW5ncyBmb3JtYXQuIFJhdGhlciwgdGhlIHByb2xpZmVy >>>Y >>>XRp >>> >>>b24gb2Ygbm90ZXMgaXMgb2Z0ZW4gYSByZXN1bHQgb2YgaW1wbGVtZW50YXRpb24gZGVjaXNp >>>b >>>25z >>> >>>LCBhbmQgdGhlc2UgYXJlIG9mdGVuIGluZm9ybWVkIGJ5IHRoZSBwZXJjZWl2ZWQgY2FwYWJp >>>b >>>Gl0 >>> >>>aWVzIG9mIGV4aXN0aW5nIG1hY2hpbmUgc3lzdGVtcy4gRm9yIGV4YW1wbGUsIHRoZXJlIGlz >>>I >>>G5v >>> >>>IHJlYXNvbiB0aGF0IGNvZGVzIGNvdWxkIG5vdCBoYXZlIGJlZW4gZGV2ZWxvcGVkIGZvciB0 >>>a >>>GUg >>> >>>cGxldGhvcmEgb2YgcmVsYXRpb25zaGlwIGRlc2lnbmF0b3JzIGluIFJEQSBhcHBlbmRpY2Vz >>>I >>>Ekt >>> >>>TCwgYnV0IGluc3RlYWQgd2Ugc3VwcGx5IHRoZSB0ZXJtcyB2ZXJiYXRpbSAoYW5kIGluIEVu >>>Z >>>2xp >>> >>>c2gpIGZyb20gUkRBLiBMaWtld2lzZSB3aXRoIHRoZSBjYXJyaWVyLCBtZWRpYSwgYW5kIGNv >>>b >>>nRl >>> >>>bnQgdHlwZXM7IGZvciB0aGUgZmlyc3QgdHdvLCBjb2RlZCBlcXVpdmFsZW50cyB3ZXJlIGFs >>>c >>>mVh >>> >>>ZHkgaW4gZXhpc3RlbmNlIGZvciB0aGUgbW9zdCBwYXJ0LCBzbyB0aGUgdGV4dCByZWNvcmRl >>>Z >>>CAo >>> >>>aW4gRW5nbGlzaCkgaW4gZmllbGRzIDMzNyBhbmQgMzM4IGlzIG9mdGVuIHJlZHVuZGFudCB3 >>>a >>>XRo >>> >>>IGNvZGVkIHZhbHVlcyBhbHJlYWR5IHByZXNlbnQgaW4gMDA3LzAwLTAxLiBJLCBmb3Igb25l >>>L >>>CB3 >>> >>>b3VsZCBiZSBoYXBweSB0byBzZWUgbm90ZXMgeWllbGQgdG8gY29kZWQgZGF0YSB3aGVuZXZl >>>c >>>iBw >>> >>>b3NzaWJsZSwgaWYgb25seSB0byBzYXZlIGtleXN0cm9rZXMuDQoNCg0KRWQgSm9uZXMNCkFz >>>c >>>29j >>> >>>aWF0ZSBEaXJlY3RvciwgTGlicmFyeSBBc3Nlc3NtZW50IGFuZCBUZWNobmljYWwgU2Vydmlj >>>Z >>>XMN >>> >>>Ck5hdGlvbmFsIFVuaXZlcnNpdHkgTGlicmFyeQ0KOTM5MyBMaWdodHdhdmUgQXZlbnVlDQpT >>>Y >>>W4g >>> >>>RGllZ28sIENhbGlmb3JuaWHCoCA5MjEyMy0xNDQ3DQrCoA0KKzEgODU4IDU0MSA3OTIwICh2 >>>b >>>2lj >>> >>>ZSkNCisxIDg1OCA1NDEgNzk5NyAoZmF4KQ0KDQpodHRwOi8vbmF0aW9uYWwuYWNhZGVtaWEu >>>Z >>>WR1 >>> >>>L0VkSm9uZXMNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog >>>Q >>>mli >>> >>>bGlvZ3JhcGhpYyBGcmFtZXdvcmsgVHJhbnNpdGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWls >>>d >>>G86 >>> >>>QklCRlJBTUVATElTVFNFUlYuTE9DLkdPVl0gT24gQmVoYWxmIE9mIEthcmVuIENveWxlDQpT >>>Z >>>W50 >>> >>>OiBNb25kYXksIFNlcHRlbWJlciAxNSwgMjAxNCAxMTozMyBQTQ0KVG86IEJJQkZSQU1FQExJ >>>U >>>1RT >>> >>>RVJWLkxPQy5HT1YNClN1YmplY3Q6IFJlOiBbQklCRlJBTUVdIExpdGVyYWwgUHJvcGVydGll >>>c >>>yB2 >>> >>>cyBOb3Rlcw0KDQpGcmVxdWVuY3kgaXMgYSBnb29kIGV4YW1wbGUgb2YgdGhlIG1lc3MgdGhh >>>d >>>CB3 >>> >>>ZSBoYXZlIHRvZGF5IGluIEFBQ1ItdHlwZSBjYXRhbG9naW5nLiBUaGVyZSBpcyBhIHdheSB0 >>>b >>>yBj >>> >>>b2RlIGZyZXF1ZW5jeSBhcyBhIGNhbGN1bGFibGUgdmFsdWUgaW4gdGhlIE1BUkMgaG9sZGlu >>>Z >>>3Mg >>> >>>cmVjb3JkLiBUaGF0IHNob3VsZCBzdWZmaWNlIGFuZCB0aGVyZSBzaG91bGQgYmUgbm8gbmVl >>>Z >>>CBm >>> >>>b3IgYSBub3RlIGZpZWxkIGlmIHRoZSB2YWx1ZSBpcyBwcm92aWRlZC4gQnV0IG5vdGVzIGFy >>>Z >>>SAi >>> >>>bm90ZXMiIGJlY2F1c2UgdGhleSBhcmUgdW5jb250cm9sbGVkIHN0cmluZ3MgY3JlYXRlZCBi >>>e >>>SB0 >>> >>>aGUgY2F0YWxvZ2VyLiBXaGVyZSBvdGhlciBkYXRhIGluIHRoZSByZWNvcmQgYXJlIGVpdGhl >>>c >>>iB0 >>> >>>cmFuc2NyaWJlZCBzdHJpbmdzIG9yIGNvbnRyb2xsZWQgaGVhZGluZ3MsIG5vdGVzIGFyZSBu >>>Z >>>Wl0 >>> >>>aGVyLiBCdXQgdGhlIG5vdGVzIEFSRSByZXF1aXJlZCBieSB0aGUgY2F0YWxvZ2luZyBydWxl >>>c >>>y4N >>> >>>Cg0KVGhpcyBpcyBldmlkZW5jZSwgdG8gbWUsIG9mIHRoZSBnYXAgYmV0d2VlbiB0aGUgY2F0 >>>Y >>>Wxv >>> >>>Z2luZyBydWxlcyBhbmQgdGhlIGFjdHVhbCBwcmFjdGljZSBvZiBjcmVhdGluZyBtYWNoaW5l >>>L >>>XJl >>> >>>YWRhYmxlIGNhdGFsb2cgcmVjb3Jkcy4gQUFDUiBkb2VzIG5vdCByZWNvZ25pemUgdGhhdCBj >>>b >>>2Rl >>> >>>ZCBkYXRhIChlLmcuIE1BUkMgZml4ZWQgZmllbGRzKSBleGlzdHMuICANCk1hbnkgbm90ZXMg >>>c >>>mVw >>> >>>ZWF0IGluZm9ybWF0aW9uIHRoYXQgY291bGQgYmUgZW5jb2RlZCBlbHNld2hlcmUsIGJ1dCBi >>>Z >>>WNh >>> >>>dXNlIHRoZSBub3RlIGlzIHdoYXQgaXMgcmVxdWlyZWQgYnkgdGhlIGNhdGFsb2dpbmcgcnVs >>>Z >>>XMg >>> >>>YW5kIGFsc28gZGlzcGxheXMgaW4gdGhlIGNhdGFsb2csIHRoZSB0ZW5kZW5jeSBoYXMgYmVl >>>b >>>iB0 >>> >>>byBwcm92aWRlIHRoZSBub3RlIGJ1dCBvZnRlbiBub3QgdG8gcHJvdmlkZSB0aGUgYWN0aW9u >>>Y >>>WJs >>> >>>ZSBkYXRhIGVsZW1lbnQuIE9idmlvdXNseSwgaXQgd291bGQgYmUgYSBtaXN0YWtlIHRvIGNh >>>c >>>nJ5 >>> >>>IGZvcndhcmQgdGhpcyBwcmFjdGljZSwgYW5kIGluc3RlYWQgdGhlIGFjdGlvbmFibGUgZGF0 >>>Y >>>SBl >>> >>>bGVtZW50IG11c3QgYmUgdGhlIHByaW1hcnkgc291cmNlIG9mIGRhdGEsIGZyb20gd2hpY2gg >>>d >>>XNl >>> >>>ci1mcmllbmRseSBub3RlcyBjYW4gYmUgZGVyaXZlZCBpZiBuZWVkZWQuIFRoYXQgImlmIG5l >>>Z >>>WRl >>> >>>ZCIgcGFydCBpcyBhbHNvIHNvbWV0aGluZyB3ZSBzaG91bGQgdGhpbmsgYWJvdXQsIGJlY2F1 >>>c >>>2Ug >>> >>>aW4gZmFjdCBpbiBtYW55IHN5c3RlbSBkaXNwbGF5cyBub3RlcyBhcmUgbm90IGluY2x1ZGVk >>>L >>>CBz >>> >>>byBjYXRhbG9nIHVzZXJzIHJhcmVseSBzZWUgdGhlbS4gIA0KQmVjYXVzZSBub3RlcyBoYXZl >>>I >>>GJl >>> >>>ZW4gZmF2b3JlZCBvdmVyIGFjdGlvbmFibGUgZGF0YSwgdGhlcmUgaXMgYSB3aG9sZSBob3N0 >>>I >>>G9m >>> >>>IGluZm9ybWF0aW9uIHRoYXQgaXMgMSkgbm90IHVzYWJsZSBmb3IgYW55IGF1dG9tYXRlZCBm >>>d >>>W5j >>> >>>dGlvbnMgYW5kIDIpIHJhcmVseSBzZWVuIGJ5IHVzZXJzLiBTdXJlbHkgdGhpcyBpcyBhIHdh >>>c >>>3Rl >>> >>>IG9mIGNhdGFsb2dlciB0aW1lLCBhbmQgYSBkaXNzZXJ2aWNlIHRvIG91ciB1c2Vycy4NCg0K >>>a >>>2MN >>> >>>Cg0KUXVvdGluZyBUaW0gVGhvbXBzb24gPHRpbWF0aG9tQGdtYWlsLmNvbT46DQoNCj4gSGF2 >>>a >>>W5n >>> >>>IGEgYmY6Tm90ZSBjbGFzcyBtYWtlcyBzZW5zZSB0byBtZS4gVGhlIGN1cnJlbnQgYXBwcm9h >>>Y >>>2gg >>> >>>c2VlbXMgDQo+IGV4aGF1c3RpdmUgZW5vdWdoIHRvIGJlIGN1bWJlcnNvbWUsIGJ1dCBwcm9i >>>Y >>>WJs >>> >>>eSBub3QgZXhoYXVzdGl2ZSBlbm91Z2ggDQo+IHRvIGNhcHR1cmUgdGhlIGZ1bGwgcmFuZ2Ug >>>b >>>2Yg >>> >>>cG9zc2liaWxpdGllcyBpbiB0aGUgc291cmNlIGRhdGEuIE5vdCBhbGwgDQo+IG5vdGVzIGNv >>>b >>>WUg >>> >>>ZnJvbSA1WFggZmllbGRzLiBIZXJlIGlzIGEgc2FtcGxlIG1hcmMyYmliZnJhbWUgY29udmVy >>>c >>>2lv >>> >>>biANCj4gb2YgYSByZWNvcmQgZm9yIGEgc2VyaWFsOg0KPg0KPiBNQVJDOiBodHRwOi8vYmli >>>Z >>>nJh >>> >>>bWUub3JnL3Jlc291cmNlcy9KcWMxNDEwMzY1MTE1L21hcmN4bWwueG1sDQo+IEJGOiBodHRw >>>O >>>i8v >>> >>>YmliZnJhbWUub3JnL3Jlc291cmNlcy9KcWMxNDEwMzY1MTE1L2JpYmZyYW1lLnJkZg0KPg0K >>>P >>>iBI >>> >>>ZXJlLCBiZjpmcmVxdWVuY3lOb3RlIG1hcHMgdG8gdGhlIDMxMCBmaWVsZCAoQ3VycmVudCBQ >>>d >>>WJs >>> >>>aWNhdGlvbiANCj4gRnJlcXVlbmN5KS4gVW5mb3J0dW5hdGVseSwgaXQgYWxzbyBtYXBzIHRv >>>I >>>HRo >>> >>>ZSAzMjEgZmllbGQgKEZvcm1lciANCj4gUHVibGljYXRpb24gRnJlcXVlbmN5KS4gVGhpcyB3 >>>b >>>3Vs >>> >>>ZCBzZWVtIHRvIGJlIGEgbm90IGluc2lnbmlmaWNhbnQgbG9zcyANCj4gb2YgaW5mb3JtYXRp >>>b >>>24u >>> >>>IDVYWCBmaWVsZHMgdGhhdCBhcmUgZGlzdGluY3QgaW4gTUFSQyBhcmUgbWFwcGVkIHRvIA0K >>>P >>>iBn >>> >>>ZW5lcmljIGJmOm5vdGUgcHJvcGVydGllcyAoNTE1LCA1ODgpLiBiZjpmcmVxdWVuY3kgZG9l >>>c >>>24n >>> >>>dCBhcHBlYXIsIA0KPiBidXQgbWF5YmUgaXQgd2FzIG1lYW50IHRvIGNvcnJlc3BvbmQgdG8g >>>d >>>Ghl >>> >>>IDAwOCBmaXggZmllbGQgZm9yIA0KPiBjb250aW51aW5nIHJlc291cmNlcywgd2hpY2ggYWxz >>>b >>>yBo >>> >>>YXMgYSB2YWx1ZSBmb3IgZnJlcXVlbmN5IChwb3NpdGlvbiANCj4gMTgpLiBUaGUgbmVlZCBm >>>b >>>3Ig >>> >>>dHdvIGRpc3RpbmN0IHByb3BlcnRpZXMgcmVtYWlucyB1bmNsZWFyLg0KPg0KPiBJbiBzaG9y >>>d >>>Cwg >>> >>>YSBiZjpOb3RlIGNsYXNzIHdpdGggYmY6bm90ZVR5cGUgdmFsdWVzIG1pZ2h0IHByb3ZpZGUg >>>D >>>Qo+ >>> >>>IGdyZWF0ZXIgZmxleGliaWxpdHkgYW5kIHByZXNlcnZlIG1vcmUgb2YgdGhlIG9yaWdpbmFs >>>I >>>HNl >>> >>>bWFudGljcy4NCj4NCj4gVGltDQo+DQo+IC0tDQo+IFRpbSBBLiBUaG9tcHNvbg0KPiBNZXRh >>>Z >>>GF0 >>> >>>YSBMaWJyYXJpYW4gKFNwYW5pc2gvUG9ydHVndWVzZSBTcGVjaWFsdHkpIFByaW5jZXRvbiBV >>>b >>>ml2 >>> >>>ZXJzaXR5IA0KPiBMaWJyYXJ5DQo+DQo+DQo+IE9uIFR1ZSwgU2VwIDksIDIwMTQgYXQgNToz >>>O >>>CBQ >>> >>>TSwgUm9iZXJ0IFNhbmRlcnNvbiA8YXphcm90aDQyQGdtYWlsLmNvbT4NCj4gd3JvdGU6DQo+ >>>D >>>Qo+ >>> >>>Pg0KPj4gWSdhbGwgcmVhZHkgZm9yIHRoaXM/IDspIFsxXQ0KPj4NCj4+IFdoZW4gaXMgYSBs >>>a >>>XRl >>> >>>cmFsIHByb3BlcnR5IGEgJ3NvbWV0aGluZ05vdGUnIGFuZCB3aGVuIGlzIGl0IGp1c3QgYSAN >>>C >>>j4+ >>> >>>ICdzb21ldGhpbmcnPw0KPj4NCj4+IEkgYXNzdW1lIChsYWNraW5nIHByZXZpb3VzbHkgbWVu >>>d >>>Glv >>> >>>bmVkIE1BUkMgdG8gQmliRnJhbWUgbWFwcGluZyANCj4+IGRvY3VtZW50KSB0aGF0IGFsbCBv >>>Z >>>iB0 >>> >>>aGUgTm90ZXMgY29tZSBmcm9tIDVYWCBmaWVsZHMsIHdoaWNoIHNlZW1zIA0KPj4gbGlrZSBz >>>b >>>21l >>> >>>dGhpbmcgdGhhdCBjb3VsZCBlYXNpbHkgYmUgcmF0aW9uYWxpemVkIGFsb25nIHdpdGggc29t >>>Z >>>SBv >>> >>>ZiANCj4+IHRoZSBvdGhlciBwcm9wZXJ0aWVzLCBhZ2FpbiBhc3N1bWluZyB0aGV5J3JlIG5v >>>d >>>CA1 >>> >>>WFggYW5kIGhlbmNlIGRpZG4ndCBnZXQgdGhlIE5vdGUgbW9uaWtlci4NCj4+DQo+PiBGb3Ig >>>Z >>>Xhh >>> >>>bXBsZSwgdGhlc2UgdHdvIGxvb2sgLi4uIHdlbGwgLi4uIGlkZW50aWNhbDoNCj4+DQo+PiBm >>>c >>>mVx >>> >>>dWVuY3k6IEludGVydmFscyBhdCB3aGljaCB0aGUgaXNzdWVzIG9yIHBhcnRzIG9mIGEgc2Vy >>>a >>>WFs >>> >>>IG9yIHRoZSANCj4+IHVwZGF0ZXMgdG8gYW4gaW50ZWdyYXRpbmcgcmVzb3VyY2UgYXJlIGlz >>>c >>>3Vl >>> >>>ZC4NCj4+IGZyZXF1ZW5jeU5vdGU6IEN1cnJlbnQgb3IgZm9ybWVyIHB1YmxpY2F0aW9uIGZy >>>Z >>>XF1 >>> >>>ZW5jeSBvZiBhIHJlc291cmNlLg0KPj4NCj4+DQo+PiBDdXJyZW50IG5vdGVzIGFyZToNCj4+ >>>I >>>CBj >>> >>>b3B5Tm90ZQ0KPj4gIGF3YXJkTm90ZQ0KPj4gIGNvbnRlbnRzTm90ZQ0KPj4gIGdyYXBoaWNT >>>Y >>>2Fs >>> >>>ZU5vdGUNCj4+ICBpbGx1c3RyYXRpb25Ob3RlDQo+PiAgc3VwcGxlbWVudGFyeUNvbnRlbnRO >>>b >>>3Rl >>> >>>DQo+PiAgZGlzc2VydGF0aW9uTm90ZQ0KPj4gIGdlb2dyYXBoaWNDb3ZlcmFnZU5vdGUNCj4+ >>>I >>>CBs >>> >>>YW5ndWFnZU5vdGUNCj4+ICB0ZW1wb3JhbENvdmVyYWdlTm90ZQ0KPj4gIGNyZWRpdHNOb3Rl >>>D >>>Qo+ >>> >>>PiAgcGVyZm9ybWVyTm90ZQ0KPj4gIGZyZXF1ZW5jeU5vdGUNCj4+ICBub3RlICghKQ0KPj4g >>>I >>>G11 >>> >>>c2ljTWVkaXVtTm90ZQ0KPj4gIGZpbmRpbmdBaWROb3RlDQo+Pg0KPj4gQW5kIHRoZSBmb2xs >>>b >>>3dp >>> >>>bmcgc2VlbSBsaWtlIHRoZXkncmUgaW50ZW5kZWQgdG8gYmUgIm5vdGVzIiBpbiB0aGUgDQo+ >>>P >>>iBt >>> >>>b3JlIGdlbmVyaWMgc2Vuc2Ugb2YgYWRkZWQgZGVzY3JpcHRpb24gYnkgYSBjYXRhbG9ndWVy >>>I >>>G9y >>> >>>IG90aGVyOg0KPj4NCj4+ICBmcmVxdWVuY3kNCj4+ICBjdXN0b2RpYWxIaXN0b3J5DQo+PiAg >>>a >>>W1t >>> >>>ZWRpYXRlQWNxdWlzaXRpb24NCj4+ICBub3RhdGlvbg0KPj4gIHJlc3BvbnNpYmlsaXR5U3Rh >>>d >>>GVt >>> >>>ZW50DQo+PiAgcHJvdmlkZXJTdGF0ZW1lbnQgLS0gb3IgYXJlICJTdGF0ZW1lbnRzIiB0cmFu >>>c >>>2Ny >>> >>>aXB0aW9ucyBmcm9tIHRoZSANCj4+IEluc3RhbmNlPw0KPj4gIGVkaXRpb25SZXNwb25zaWJp >>>b >>>Gl0 >>> >>>eQ0KPj4gIGNvbnRlbnRBY2Nlc3NpYmlsaXR5ICAodGhvdWdoIGMuZi4gc2NoZW1hLm9yZy9h >>>Y >>>2Nl >>> >>>c3NpYmlsaXR5RmVhdHVyZSkNCj4+DQo+PiBHaXZlbiB0aGUgZGlzY3Vzc2lvbiByZWdhcmRp >>>b >>>mcg >>> >>>YXNzaWduZXJzIG9mIFVSSXMgYmVpbmcgaW1wb3J0YW50LCBpdCANCj4+IHNlZW1zIHRoYXQg >>>Y >>>3Jl >>> >>>YXRvcnMgb2Ygbm90ZXMgd291bGQgYmUgYWxzbyBpbXBvcnRhbnQ/ICBBbmQgdGh1cyBOb3Rl >>>c >>>yAN >>> >>>Cj4+IGNvdWxkIGJlIHRoZWlyIG93biBjbGFzcywgYmY6Tm90ZSwgd2l0aCBwcm9wZXJ0aWVz >>>I >>>Glu >>> >>>Y2x1ZGluZyB2YWx1ZSwgDQo+PiBhc3NpZ25lciwgdHlwZSBhbmQgc28gZm9ydGguDQo+Pg0K >>>P >>>j4g >>> >>>Um9iDQo+Pg0KPj4gWzFdIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9YXZjUzBh >>>W >>>Uoy >>> >>>YTggIFdhcm5pbmc6IHNlaXp1cmUgDQo+PiBpbmR1Y2luZyBmbGFzaGluZywgdGVycmlibGUg >>>Y >>>W5p >>> >>>bWF0aW9uLCBwb3BweSA5MHMgbXVzaWMsIC4uLg0KPj4NCj4+IC0tDQo+PiBSb2IgU2FuZGVy >>>c >>>29u >>> >>>DQo+PiBUZWNobm9sb2d5IENvbGxhYm9yYXRpb24gRmFjaWxpdGF0b3INCj4+IERpZ2l0YWwg >>>T >>>Gli >>> >>>cmFyeSBTeXN0ZW1zIGFuZCBTZXJ2aWNlcw0KPj4gU3RhbmZvcmQsIENBIDk0MzA1DQo+Pg0K >>> >>> ------------------------------ >>> >>> Date: Tue, 16 Sep 2014 08:47:00 -0700 >>> From: Robert Sanderson <[log in to unmask]> >>> Subject: Re: Literal Properties vs Notes >>> >>> --f46d043892578497fd050330a925 >>> Content-Type: text/plain; charset=UTF-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>> Tim, Adam, >>> >>> I would personally prefer subclasses as then additional note types >>>beyond >>> the main specification are using the constructs of the language, rather >>> than relying on string uniqueness in a (doubtless not URI) noteType. >>> >>> Yes, there's a choice between subclasses of bf:Note, and sub-properties >>>of >>> bf:hasNote ... and I'm not religious as to which ... but it can't be >>>both. >>> In this regard see the identifier decision regarding sub-properties and >>> scheme. My preference for sub-classes is the same as Adam's -- easier >>> machine inferencing and human understanding. >>> >>> Rob >>> >>> >>> On Wed, Sep 10, 2014 at 12:45 PM, [log in to unmask] >>><[log in to unmask]> >>> wrote: >>> >>>> I'm not too familiar with the full range of possibilities here, so >>>>this >>>> may be a very naive question: >>>> >>>> Would it be better to have a type attribute on a hypothetical bf:Note >>>> class, or would it be better to build out a hierarchy of subtypes to >>>>that >>>> class? The type attribute has the advantage of tremendous flexibility >>>>at >>>> low cost. The class hierarchy has a little more "readability" and >>>>makes >>>> many kinds of automated facilities operate more efficiently (e.g. >>>> inferencing, some kinds of querying=E2=80=A6). >>>> >>>> --- >>>> A. Soroka >>>> The University of Virginia Library >>>> >>>> On Sep 10, 2014, at 12:51 PM, Tim Thompson <[log in to unmask]> wrote: >>>> >>>>> Having a bf:Note class makes sense to me. The current approach seems >>>> exhaustive enough to be cumbersome, but probably not exhaustive enough >>>>to >>>> capture the full range of possibilities in the source data. Not all >>>>notes >>>> come from 5XX fields. Here is a sample marc2bibframe conversion of a >>>>reco= >>> rd >>>> for a serial: >>>>> >>>>> MARC: http://bibframe.org/resources/Jqc1410365115/marcxml.xml >>>>> BF: http://bibframe.org/resources/Jqc1410365115/bibframe.rdf >>>>> >>>>> Here, bf:frequencyNote maps to the 310 field (Current Publication >>>> Frequency). Unfortunately, it also maps to the 321 field (Former >>>> Publication Frequency). This would seem to be a not insignificant loss >>>>of >>>> information. 5XX fields that are distinct in MARC are mapped to >>>>generic >>>> bf:note properties (515, 588). bf:frequency doesn't appear, but maybe >>>>it >>>> was meant to correspond to the 008 fix field for continuing resources, >>>> which also has a value for frequency (position 18). The need for two >>>> distinct properties remains unclear. >>>>> >>>>> In short, a bf:Note class with bf:noteType values might provide >>>>>greater >>>> flexibility and preserve more of the original semantics. >>>>> >>>>> Tim >>>>> >>>>> -- >>>>> Tim A. Thompson >>>>> Metadata Librarian (Spanish/Portuguese Specialty) >>>>> Princeton University Library >>>>> >>>>> >>>>> On Tue, Sep 9, 2014 at 5:38 PM, Robert Sanderson >>>>><[log in to unmask]> >>>> wrote: >>>>> >>>>> Y'all ready for this? ;) [1] >>>>> >>>>> When is a literal property a 'somethingNote' and when is it just a >>>> 'something'? >>>>> >>>>> I assume (lacking previously mentioned MARC to BibFrame mapping >>>> document) that all of the Notes come from 5XX fields, which seems like >>>> something that could easily be rationalized along with some of the >>>>other >>>> properties, again assuming they're not 5XX and hence didn't get the >>>>Note >>>> moniker. >>>>> >>>>> For example, these two look ... well ... identical: >>>>> >>>>> frequency: Intervals at which the issues or parts of a serial or the >>>> updates to an integrating resource are issued. >>>>> frequencyNote: Current or former publication frequency of a resource. >>>>> >>>>> >>>>> Current notes are: >>>>> copyNote >>>>> awardNote >>>>> contentsNote >>>>> graphicScaleNote >>>>> illustrationNote >>>>> supplementaryContentNote >>>>> dissertationNote >>>>> geographicCoverageNote >>>>> languageNote >>>>> temporalCoverageNote >>>>> creditsNote >>>>> performerNote >>>>> frequencyNote >>>>> note (!) >>>>> musicMediumNote >>>>> findingAidNote >>>>> >>>>> And the following seem like they're intended to be "notes" in the >>>>>more >>>> generic sense of added description by a cataloguer or other: >>>>> >>>>> frequency >>>>> custodialHistory >>>>> immediateAcquisition >>>>> notation >>>>> responsibilityStatement >>>>> providerStatement -- or are "Statements" transcriptions from the >>>> Instance? >>>>> editionResponsibility >>>>> contentAccessibility (though c.f. schema.org/accessibilityFeature) >>>>> >>>>> Given the discussion regarding assigners of URIs being important, it >>>> seems that creators of notes would be also important? And thus Notes >>>>cou= >>> ld >>>> be their own class, bf:Note, with properties including value, >>>>assigner, >>>> type and so forth. >>>>> >>>>> Rob >>>>> >>>>> [1] https://www.youtube.com/watch?v=3DavcS0aYJ2a8 Warning: seizure >>>> inducing flashing, terrible animation, poppy 90s music, ... >>>>> >>>>> -- >>>>> Rob Sanderson >>>>> Technology Collaboration Facilitator >>>>> Digital Library Systems and Services >>>>> Stanford, CA 94305 >>>>> >>>> >>> >>> >>> >>> --=20 >>> Rob Sanderson >>> Technology Collaboration Facilitator >>> Digital Library Systems and Services >>> Stanford, CA 94305 >>> >>> --f46d043892578497fd050330a925 >>> Content-Type: text/html; charset=UTF-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>> <div dir=3D"ltr"><br><div>Tim, Adam,</div><div><br></div><div>I would >>>perso= >>> nally prefer subclasses as then additional note types beyond the main >>>speci= >>> fication are using the constructs of the language, rather than relying >>>on s= >>> tring uniqueness in a (doubtless not URI) >>>noteType.</div><div><br></div><di= >>> v>Yes, there's a choice between subclasses of bf:Note, and >>>sub-properti= >>> es of bf:hasNote ... and I'm not religious as to which ... but it >>>can&#= >>> 39;t be both.=C2=A0 In this regard see the identifier decision >>>regarding su= >>> b-properties and scheme.=C2=A0 My preference for sub-classes is the >>>same as= >>> Adam's -- easier machine inferencing and human >>>understanding.</div><di= >>> v><br></div><div>Rob</div><div><br></div></div><div >>>class=3D"gmail_extra"><= >>> br><div class=3D"gmail_quote">On Wed, Sep 10, 2014 at 12:45 PM, <a >>>href=3D"= >>> mailto:[log in to unmask]">[log in to unmask]</a> <span >>>dir=3D"ltr"><<a = >>> href=3D"mailto:[log in to unmask]" >>>target=3D"_blank">[log in to unmask]</a>= >>> ></span> wrote:<br><blockquote class=3D"gmail_quote" >>>style=3D"margin:0 0= >>> 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not too >>>famili= >>> ar with the full range of possibilities here, so this may be a very >>>naive q= >>> uestion:<br> >>> <br> >>> Would it be better to have a type attribute on a hypothetical bf:Note >>>class= >>> , or would it be better to build out a hierarchy of subtypes to that >>>class?= >>> The type attribute has the advantage of tremendous flexibility at low >>>cost= >>> . The class hierarchy has a little more "readability" and >>>makes m= >>> any kinds of automated facilities operate more efficiently (e.g. >>>inferencin= >>> g, some kinds of querying=E2=80=A6).<br> >>> <br> >>> ---<br> >>> A. Soroka<br> >>> The University of Virginia Library<br> >>> <div class=3D"HOEnZb"><div class=3D"h5"><br> >>> On Sep 10, 2014, at 12:51 PM, Tim Thompson <<a >>>href=3D"mailto:timathom@G= >>> MAIL.COM">[log in to unmask]</a>> wrote:<br> >>> <br> >>> > Having a bf:Note class makes sense to me. The current approach >>>seems e= >>> xhaustive enough to be cumbersome, but probably not exhaustive enough >>>to ca= >>> pture the full range of possibilities in the source data. Not all notes >>>com= >>> e from 5XX fields. Here is a sample marc2bibframe conversion of a >>>record fo= >>> r a serial:<br> >>> ><br> >>> > MARC: <a >>>href=3D"http://bibframe.org/resources/Jqc1410365115/marcxml.x= >>> ml" >>>target=3D"_blank">http://bibframe.org/resources/Jqc1410365115/marcxml.x= >>> ml</a><br> >>> > BF: <a >>>href=3D"http://bibframe.org/resources/Jqc1410365115/bibframe.rd= >>> f" >>>target=3D"_blank">http://bibframe.org/resources/Jqc1410365115/bibframe.r >>>= >>> df</a><br> >>> ><br> >>> > Here, bf:frequencyNote maps to the 310 field (Current Publication >>>Freq= >>> uency). Unfortunately, it also maps to the 321 field (Former >>>Publication Fr= >>> equency). This would seem to be a not insignificant loss of >>>information. 5X= >>> X fields that are distinct in MARC are mapped to generic bf:note >>>properties= >>> (515, 588). bf:frequency doesn't appear, but maybe it was meant to >>>cor= >>> respond to the 008 fix field for continuing resources, which also has a >>>val= >>> ue for frequency (position 18). The need for two distinct properties >>>remain= >>> s unclear.<br> >>> ><br> >>> > In short, a bf:Note class with bf:noteType values might provide >>>greate= >>> r flexibility and preserve more of the original semantics.<br> >>> ><br> >>> > Tim<br> >>> ><br> >>> > --<br> >>> > Tim A. Thompson<br> >>> > Metadata Librarian (Spanish/Portuguese Specialty)<br> >>> > Princeton University Library<br> >>> ><br> >>> ><br> >>> > On Tue, Sep 9, 2014 at 5:38 PM, Robert Sanderson <<a >>>href=3D"mailto= >>> :[log in to unmask]">[log in to unmask]</a>> wrote:<br> >>> ><br> >>> > Y'all ready for this? ;) [1]<br> >>> ><br> >>> > When is a literal property a 'somethingNote' and when is >>>it ju= >>> st a 'something'?<br> >>> ><br> >>> > I assume (lacking previously mentioned MARC to BibFrame mapping >>>docume= >>> nt) that all of the Notes come from 5XX fields, which seems like >>>something = >>> that could easily be rationalized along with some of the other >>>properties, = >>> again assuming they're not 5XX and hence didn't get the Note >>>monike= >>> r.<br> >>> ><br> >>> > For example, these two look ... well ... identical:<br> >>> ><br> >>> > frequency: Intervals at which the issues or parts of a serial or >>>the u= >>> pdates to an integrating resource are issued.<br> >>> > frequencyNote: Current or former publication frequency of a >>>resource.<= >>> br> >>> ><br> >>> ><br> >>> > Current notes are:<br> >>> >=C2=A0 =C2=A0copyNote<br> >>> >=C2=A0 =C2=A0awardNote<br> >>> >=C2=A0 =C2=A0contentsNote<br> >>> >=C2=A0 =C2=A0graphicScaleNote<br> >>> >=C2=A0 =C2=A0illustrationNote<br> >>> >=C2=A0 =C2=A0supplementaryContentNote<br> >>> >=C2=A0 =C2=A0dissertationNote<br> >>> >=C2=A0 =C2=A0geographicCoverageNote<br> >>> >=C2=A0 =C2=A0languageNote<br> >>> >=C2=A0 =C2=A0temporalCoverageNote<br> >>> >=C2=A0 =C2=A0creditsNote<br> >>> >=C2=A0 =C2=A0performerNote<br> >>> >=C2=A0 =C2=A0frequencyNote<br> >>> >=C2=A0 =C2=A0note (!)<br> >>> >=C2=A0 =C2=A0musicMediumNote<br> >>> >=C2=A0 =C2=A0findingAidNote<br> >>> ><br> >>> > And the following seem like they're intended to be >>>"notes&quo= >>> t; in the more generic sense of added description by a cataloguer or >>>other:= >>> <br> >>> ><br> >>> >=C2=A0 =C2=A0frequency<br> >>> >=C2=A0 =C2=A0custodialHistory<br> >>> >=C2=A0 =C2=A0immediateAcquisition<br> >>> >=C2=A0 =C2=A0notation<br> >>> >=C2=A0 =C2=A0responsibilityStatement<br> >>> >=C2=A0 =C2=A0providerStatement -- or are "Statements" >>>transcr= >>> iptions from the Instance?<br> >>> >=C2=A0 =C2=A0editionResponsibility<br> >>> >=C2=A0 =C2=A0contentAccessibility=C2=A0 (though c.f. <a >>>href=3D"http://= >>> schema.org/accessibilityFeature" >>>target=3D"_blank">schema.org/accessibility= >>> Feature</a>)<br> >>> ><br> >>> > Given the discussion regarding assigners of URIs being important, >>>it s= >>> eems that creators of notes would be also important?=C2=A0 And thus >>>Notes c= >>> ould be their own class, bf:Note, with properties including value, >>>assigner= >>> , type and so forth.<br> >>> ><br> >>> > Rob<br> >>> ><br> >>> > [1] <a href=3D"https://www.youtube.com/watch?v=3DavcS0aYJ2a8" >>>target= >>> =3D"_blank">https://www.youtube.com/watch?v=3DavcS0aYJ2a8</a>=C2=A0 >>>Warning= >>> : seizure inducing flashing, terrible animation, poppy 90s music, >>>...<br> >>> ><br> >>> > --<br> >>> > Rob Sanderson<br> >>> > Technology Collaboration Facilitator<br> >>> > Digital Library Systems and Services<br> >>> > Stanford, CA 94305<br> >>> ><br> >>> </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- >>><br>= >>> <div dir=3D"ltr">Rob Sanderson<div>Technology Collaboration >>>Facilitator</di= >>> v><div>Digital Library Systems and Services</div><div>Stanford, CA >>>94305</d= >>> iv></div> >>> </div> >>> >>> --f46d043892578497fd050330a925-- >>> >>> ------------------------------ >>> >>> Date: Tue, 16 Sep 2014 20:26:47 +0200 >>> From: Karen Coyle <[log in to unmask]> >>> Subject: Re: Literal Properties vs Notes >>> >>> Ed, you're talking about RDA as conceived (at least partly) but not >>>as=20 >>> implemented. I was talking about AACR, which is what informed MARC.=20 >>> Since RDA as conceived cannot be implemented in MARC, we're in a bit >>>of=20 >>> a no man's land - we really don't know how we would implement >>>RDA/RDA=20 >>> and not RDA/MARC. >>> >>> Also note that although RDA does "allow" distinct elements in some=20 >>> cases, and even identifiers, it has not defined its elements in a=20 >>> machine-actionable way.* This is why there is a group working on >>>making=20 >>> extent machine-actionable. RDA as a cataloging code !=3D RDA as a >>>data=20 >>> structure. And what always boggles my mind is that RDA was declared=20 >>> "finished" without any implementation plan. How can it be "done" if >>>you=20 >>> can't use it to create the data the rules allow? >>> >>> Your statement that "the fault is not in our cataloging code but in=20 >>> ourselves" should be "the fault is in our cataloging code and in=20 >>> ourselves" because "we" created the cataloging code. >>> >>> kc >>> * The reason behind this was that the developers of RDA wanted it to >>>be=20 >>> "technology neutral." But instead it is "technology blind." Stating >>>that = >>> >>> a data element is a date and must follow a standard date format is >>>not=20 >>> favoring any particular technology. Yet allowing nearly all fields to >>>be = >>> >>> represented, optionally, with strings *is* a technological decision >>>-=20 >>> technologically hostile, actually. >>> >>> On 9/16/14, 5:38 PM, Ed Jones wrote: >>>> Karen, >>>> >>>> The fault is not in our cataloging code but in ourselves. RDA treats >>>>fr= >>> equency as a distinct element (2.14), and requires a note only when an >>>ap= >>> propriate term is unavailable. The terms at RDA 2.14.1.3 correspond to >>>th= >>> e codes available in the MARC bibliographic format (008/18), and even >>>mor= >>> e elaborate coded frequency data can be stored in the MARC holdings >>>forma= >>> t. Rather, the proliferation of notes is often a result of >>>implementation= >>> decisions, and these are often informed by the perceived capabilities >>>of= >>> existing machine systems. For example, there is no reason that codes >>>cou= >>> ld not have been developed for the plethora of relationship designators >>>i= >>> n RDA appendices I-L, but instead we supply the terms verbatim (and in >>>En= >>> glish) from RDA. Likewise with the carrier, media, and content types; >>>for= >>> the first two, coded equivalents were already in existence for the most >>>= >>> part, so the text recorded (in English) in fields 337 and 338 is often >>>re= >>> dundant with coded values already present in 007/00-01. I, for one, >>>would= >>> be happy to see notes yield to coded data whenever possible, if only to >>>= >>> save keystrokes. >>>> >>>> >>>> Ed Jones >>>> Associate Director, Library Assessment and Technical Services >>>> National University Library >>>> 9393 Lightwave Avenue >>>> San Diego, California 92123-1447 >>>> =20 >>>> +1 858 541 7920 (voice) >>>> +1 858 541 7997 (fax) >>>> >>>> http://national.academia.edu/EdJones >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Bibliographic Framework Transition Initiative Forum >>>>[mailto:BIBFR= >>> [log in to unmask]] On Behalf Of Karen Coyle >>>> Sent: Monday, September 15, 2014 11:33 PM >>>> To: [log in to unmask] >>>> Subject: Re: [BIBFRAME] Literal Properties vs Notes >>>> >>>> Frequency is a good example of the mess that we have today in >>>>AACR-type= >>> cataloging. There is a way to code frequency as a calculable value in >>>th= >>> e MARC holdings record. That should suffice and there should be no need >>>f= >>> or a note field if the value is provided. But notes are "notes" because >>>t= >>> hey are uncontrolled strings created by the cataloger. Where other data >>>i= >>> n the record are either transcribed strings or controlled headings, >>>notes= >>> are neither. But the notes ARE required by the cataloging rules. >>>> >>>> This is evidence, to me, of the gap between the cataloging rules and >>>>th= >>> e actual practice of creating machine-readable catalog records. AACR >>>does= >>> not recognize that coded data (e.g. MARC fixed fields) exists. >>>> Many notes repeat information that could be encoded elsewhere, but >>>>beca= >>> use the note is what is required by the cataloging rules and also >>>display= >>> s in the catalog, the tendency has been to provide the note but often >>>not= >>> to provide the actionable data element. Obviously, it would be a >>>mistake= >>> to carry forward this practice, and instead the actionable data element >>>= >>> must be the primary source of data, from which user-friendly notes can >>>be= >>> derived if needed. That "if needed" part is also something we should >>>thi= >>> nk about, because in fact in many system displays notes are not >>>included,= >>> so catalog users rarely see them. >>>> Because notes have been favored over actionable data, there is a whole >>>>= >>> host of information that is 1) not usable for any automated functions >>>and= >>> 2) rarely seen by users. Surely this is a waste of cataloger time, and >>>a= >>> disservice to our users. >>>> >>>> kc >>>> >>>> Quoting Tim Thompson <[log in to unmask]>: >>>> >>>>> Having a bf:Note class makes sense to me. The current approach seems >>>>> exhaustive enough to be cumbersome, but probably not exhaustive >>>>>enough= >>> >>>>> to capture the full range of possibilities in the source data. Not >>>>>all= >>> >>>>> notes come from 5XX fields. Here is a sample marc2bibframe conversion >>>>> of a record for a serial: >>>>> >>>>> MARC: http://bibframe.org/resources/Jqc1410365115/marcxml.xml >>>>> BF: http://bibframe.org/resources/Jqc1410365115/bibframe.rdf >>>>> >>>>> Here, bf:frequencyNote maps to the 310 field (Current Publication >>>>> Frequency). Unfortunately, it also maps to the 321 field (Former >>>>> Publication Frequency). This would seem to be a not insignificant >>>>>loss= >>> >>>>> of information. 5XX fields that are distinct in MARC are mapped to >>>>> generic bf:note properties (515, 588). bf:frequency doesn't appear, >>>>> but maybe it was meant to correspond to the 008 fix field for >>>>> continuing resources, which also has a value for frequency (position >>>>> 18). The need for two distinct properties remains unclear. >>>>> >>>>> In short, a bf:Note class with bf:noteType values might provide >>>>> greater flexibility and preserve more of the original semantics. >>>>> >>>>> Tim >>>>> >>>>> -- >>>>> Tim A. Thompson >>>>> Metadata Librarian (Spanish/Portuguese Specialty) Princeton >>>>>University= >>> >>>>> Library >>>>> >>>>> >>>>> On Tue, Sep 9, 2014 at 5:38 PM, Robert Sanderson >>>>><[log in to unmask]>= >>> >>>>> wrote: >>>>> >>>>>> Y'all ready for this? ;) [1] >>>>>> >>>>>> When is a literal property a 'somethingNote' and when is it just a >>>>>> 'something'? >>>>>> >>>>>> I assume (lacking previously mentioned MARC to BibFrame mapping >>>>>> document) that all of the Notes come from 5XX fields, which seems >>>>>> like something that could easily be rationalized along with some of >>>>>> the other properties, again assuming they're not 5XX and hence >>>>>>didn't= >>> get the Note moniker. >>>>>> >>>>>> For example, these two look ... well ... identical: >>>>>> >>>>>> frequency: Intervals at which the issues or parts of a serial or the >>>>>> updates to an integrating resource are issued. >>>>>> frequencyNote: Current or former publication frequency of a >>>>>>resource.= >>> >>>>>> >>>>>> >>>>>> Current notes are: >>>>>> copyNote >>>>>> awardNote >>>>>> contentsNote >>>>>> graphicScaleNote >>>>>> illustrationNote >>>>>> supplementaryContentNote >>>>>> dissertationNote >>>>>> geographicCoverageNote >>>>>> languageNote >>>>>> temporalCoverageNote >>>>>> creditsNote >>>>>> performerNote >>>>>> frequencyNote >>>>>> note (!) >>>>>> musicMediumNote >>>>>> findingAidNote >>>>>> >>>>>> And the following seem like they're intended to be "notes" in the >>>>>> more generic sense of added description by a cataloguer or other: >>>>>> >>>>>> frequency >>>>>> custodialHistory >>>>>> immediateAcquisition >>>>>> notation >>>>>> responsibilityStatement >>>>>> providerStatement -- or are "Statements" transcriptions from the >>>>>> Instance? >>>>>> editionResponsibility >>>>>> contentAccessibility (though c.f. >>>>>>schema.org/accessibilityFeature)= >>> >>>>>> >>>>>> Given the discussion regarding assigners of URIs being important, it >>>>>> seems that creators of notes would be also important? And thus >>>>>>Notes= >>> >>>>>> could be their own class, bf:Note, with properties including value, >>>>>> assigner, type and so forth. >>>>>> >>>>>> Rob >>>>>> >>>>>> [1] https://www.youtube.com/watch?v=3DavcS0aYJ2a8 Warning: seizure >>>>>> inducing flashing, terrible animation, poppy 90s music, ... >>>>>> >>>>>> -- >>>>>> Rob Sanderson >>>>>> Technology Collaboration Facilitator >>>>>> Digital Library Systems and Services >>>>>> Stanford, CA 94305 >>>>>> >>> >>> --=20 >>> Karen Coyle >>> [log in to unmask] http://kcoyle.net >>> m: +1-510-435-8234 >>> skype: kcoylenet/+1-510-984-3600 >>> >>> ------------------------------ >>> >>> Date: Tue, 16 Sep 2014 13:24:59 -0700 >>> From: Robert Sanderson <[log in to unmask]> >>> Subject: Specific Questions >>> >>> --001a11c238c0a7de1b0503348b68 >>> Content-Type: text/plain; charset=UTF-8 >>> >>> Some specific questions: >>> >>> --- Range/Domain --- >>> >>> * bf:dissertationInstitution has a range of bf:Agent, not >>>bf:Institution. >>> Are there really people that give out dissertations (and how much do >>>they >>> cost? :D) >>> >>> * bf:edition (and bf:editionResponsibility, which looks like a Note) >>>has a >>> domain of Instance, as expected from the Provider discussion that >>>different >>> editions (and hence dates) must be different Instances. However, >>> bf:otherEdition has domain and range of bf:Work. This seems like a >>>mistake? >>> >>> * Relatedly, bf:musicVersion has a range of Literal and no domain. This >>> seems like it should be Work or Instance? >>> * And similarly, bf:treatySignator has a range of Literal and no >>>domain. >>> Seems like it should be a range of bf:Person? >>> >>> --- No Semantics --- >>> >>> * bf:agent doesn't seem to say anything beyond "Here is an agent >>>somehow >>> related to this resource", and has no domain. Also, afaict, it has no >>> sub-properties. Can anyone shed some light on what the meaning of the >>> relationship is, and thus when a producer would create it and what a >>> consumer would do with it? >>> * bf:event is the same as bf:agent. >>> * bf:place used to exist, but no longer ... should agent and event also >>>be >>> deleted? (temporal and topic never existed) >>> >>> * bf:relatedInstance seems to only have the semantics of relatedTo, but >>> with specific range and domain. Why would a consumer/producer use this >>> instead of relatedTo? >>> * Ditto bf:relatedWork >>> >>> * bf:legalDate seems to have the description of Date of a work that's >>>legal >>> in nature, or the date a treaty was signed, or the date a law went into >>> effect. This seems so indistinct to the point of being worthless? >>> >>> --- Inconsistency --- >>> >>> * bf:originPlace, bf:originDate ... but bf:Provider, and the previous >>> discussion about providerName and providerDate. So when its an >>>Instance, >>> the event gets its own resource, but when its a Work, it doesn't? >>> >>> Thanks! >>> >>> Rob >>> >>> -- >>> Rob Sanderson >>> Technology Collaboration Facilitator >>> Digital Library Systems and Services >>> Stanford, CA 94305 >>> >>> --001a11c238c0a7de1b0503348b68 >>> Content-Type: text/html; charset=UTF-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>> <div dir=3D"ltr"><div><br></div><div>Some specific >>>questions:</div><div><br= >>>> </div><div>--- Range/Domain ---</div><div><br></div><div>* >>>>bf:dissertation= >>> Institution has a range of bf:Agent, not bf:Institution.=C2=A0 Are >>>there re= >>> ally people that give out dissertations (and how much do they cost? >>>:D)</di= >>> v><div><br></div><div>* bf:edition (and bf:editionResponsibility, which >>>loo= >>> ks like a Note) has a domain of Instance, as expected from the Provider >>>dis= >>> cussion that different editions (and hence dates) must be different >>>Instanc= >>> es. However, bf:otherEdition has domain and range of bf:Work.=C2=A0 >>>This se= >>> ems like a mistake?</div><div><br></div><div>* Relatedly, >>>bf:musicVersion h= >>> as a range of Literal and no domain. This seems like it should be Work >>>or I= >>> nstance?</div><div>* And similarly, bf:treatySignator has a range of >>>Litera= >>> l and no domain.=C2=A0 Seems like it should be a range of >>>bf:Person?<br></d= >>> iv><div><br></div><div>--- No Semantics ---</div><div><br></div><div>* >>>bf:a= >>> gent doesn't seem to say anything beyond "Here is an agent >>>somehow= >>> related to this resource", and has no domain.=C2=A0 Also, afaict, >>>it = >>> has no sub-properties. =C2=A0 Can anyone shed some light on what the >>>meanin= >>> g of the relationship is, and thus when a producer would create it and >>>what= >>> a consumer would do with it?</div><div>* bf:event is the same as >>>bf:agent.= >>> <br></div><div>* bf:place used to exist, but no longer ... should agent >>>and= >>> event also be deleted? =C2=A0(temporal and topic never >>>existed)</div><div>= >>> <br></div>* bf:relatedInstance seems to only have the semantics of >>>relatedT= >>> o, but with specific range and domain.=C2=A0 Why would a >>>consumer/producer = >>> use this instead of relatedTo?<div>* Ditto >>>bf:relatedWork</div><div><br></d= >>> iv><div>* bf:legalDate seems to have the description of Date of a work >>>that= >>> 's legal in nature, or the date a treaty was signed, or the date a >>>law = >>> went into effect. This seems so indistinct to the point of being >>>worthless?= >>> </div><div><br></div><div>--- Inconsistency >>>---</div><div><br></div><div>* = >>> bf:originPlace, bf:originDate ... but bf:Provider, and the previous >>>discuss= >>> ion about providerName and providerDate. =C2=A0 So when its an >>>Instance, th= >>> e event gets its own resource, but when its a Work, it >>>doesn't?</div><d= >>> >>>iv><br></div><div>Thanks!</div><div><br></div><div>Rob</div><div><div><b >>>r >>>><= >>> /div>-- <br><div dir=3D"ltr">Rob Sanderson<div>Technology Collaboration >>>Fac= >>> ilitator</div><div>Digital Library Systems and >>>Services</div><div>Stanford,= >>> CA 94305</div></div> >>> </div></div> >>> >>> --001a11c238c0a7de1b0503348b68-- >>> >>> ------------------------------ >>> >>> Date: Tue, 16 Sep 2014 13:46:41 -0700 >>> From: Robert Sanderson <[log in to unmask]> >>> Subject: bf:Language and Parts >>> >>> --001a11c3b55a3c0c89050334d9f2 >>> Content-Type: text/plain; charset=UTF-8 >>> >>> It seems that bf:Language has been living two lives. In one life, it >>>is a >>> hard working predicate that relates a resource with the global identity >>>of >>> a language, such as http://id.loc.gov/vocabulary/languages/eng. >>> >>> The other life is lived outside of the RDF model, where it is specific >>>to a >>> particular resource and not in any way reusable. The definition of the >>> part of the resource is a string, not a URI, but clearly is meant as >>>one as >>> it is re-used. It also has another URI and a scheme [sorry, source] and >>>a >>> name [sorry, languageOfPart]. >>> >>> One of these lives has a future, and one of them does not. I'm going >>>to be >>> as forthcoming as I can: in order to make this coherent, along with >>> bf:(absorbed/continued/superseded)InPart[By], a Part of a Resource >>>should >>> have its own identity in the same way that an Edition does. It could be >>> just a blank node, like so many others, but at least be a node with the >>> potential for identity. >>> >>> My colleagues believe that I am wasting my time with this, but I >>>believe >>> that you want to do the right thing. We're willing to wipe this part >>>of >>> the ontology clean ... all we're asking in return is your cooperation >>>in >>> bringing a known issue to resolution. >>> >>> Agent Sanderson >>> -- >>> Rob Sanderson >>> Technology Collaboration Facilitator >>> Digital Library Systems and Services >>> Stanford, CA 94305 >>> >>> --001a11c3b55a3c0c89050334d9f2 >>> Content-Type: text/html; charset=UTF-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>> <div dir=3D"ltr"><div><br></div><div>It seems that bf:Language has been >>>liv= >>> ing two lives.=C2=A0 In one life, it is a hard working predicate that >>>relat= >>> es a resource with the global identity of a language, such as <a >>>href=3D"ht= >>> >>>tp://id.loc.gov/vocabulary/languages/eng">http://id.loc.gov/vocabulary/l >>>a >>>ng= >>> uages/eng</a>.</div><div><br></div><div>The other life is lived outside >>>of = >>> the RDF model, where it is specific to a particular resource and not in >>>any= >>> way reusable.=C2=A0 The definition of the part of the resource is a >>>string= >>> , not a URI, but clearly is meant as one as it is re-used. It also has >>>anot= >>> her URI and a scheme [sorry, source] and a name [sorry, >>>languageOfPart].</d= >>> iv><div><br></div><div>One of these lives has a future, and one of them >>>doe= >>> s not.=C2=A0 I'm going to be as forthcoming as I can: in order to >>>make = >>> this coherent, along with bf:(absorbed/continued/superseded)InPart[By], >>>a P= >>> art of a Resource should have its own identity in the same way that an >>>Edit= >>> ion does. It could be just a blank node, like so many others, but at >>>least = >>> be a node with the potential for >>>identity.<br></div><div><br></div><div>My = >>> colleagues believe that I am wasting my time with this, but I believe >>>that = >>> you want to do the right thing.=C2=A0 We're willing to wipe this >>>part o= >>> f the ontology clean ... all we're asking in return is your >>>cooperation= >>> in bringing a known issue to resolution.</div><div><br></div><div>Agent >>>Sa= >>> nderson</div>-- <br><div dir=3D"ltr">Rob Sanderson<div>Technology >>>Collabora= >>> tion Facilitator</div><div>Digital Library Systems and >>>Services</div><div>S= >>> tanford, CA 94305</div></div> >>> </div> >>> >>> --001a11c3b55a3c0c89050334d9f2-- >>> >>> ------------------------------ >>> >>> Date: Tue, 16 Sep 2014 17:11:12 -0400 >>> From: "Trail, Nate" <[log in to unmask]> >>> Subject: Re: Specific Questions >>> >>> >>>Um9iLCB0aGFua3MgZm9yIHRoaXMgZGV0YWlsZWQgbG9vay4gIEkgY2Fu4oCZdCBhbnN3ZXIg >>>Y >>>Wxs >>> >>>IG9mIHRoZW0gcXVpY2tseSwgYnV0IEkga25vdyBhIGZldyBvZmYgdGhlIHRvcCBvZiBteSBo >>>Z >>>WFk >>> >>>Og0KDQrigKIgZGlzc2VydGF0aW9uSW5zdGl0dXRpb27igJlzIHJhbmdlIGlzIHByb2JhYmx5 >>>I >>>GEg >>> >>>bWlzdGFrZS4NCg0K4oCiIG11c2ljVmVyc2lvbiAgYW5kIG90aGVyIHByb3BlcnRpZXMgd2l0 >>>a >>>G91 >>> >>>dCBhIGRvbWFpbjogd2UgYXJlIHVzdWFsbHkgdW5jZXJ0YWluICBvciBhZ25vc3RpYyBhcyB0 >>>b >>>yB3 >>> >>>aGV0aGVyIGl0IGJlbG9uZ3Mgb24gV29yayBvciBJbnN0YW5jZSwgYXMgeW91IGd1ZXNzZWQs >>>I >>>GFu >>> >>>ZCBzbyB3ZSBsZWZ0IGl0IHVuY29uc3RyYWluZWQuIFdlIGRvbuKAmXQgcmVhbGx5IG1lYW4g >>>d >>>Ghh >>> >>>dCBpdCBjb3VsZCBiZSBvbiBhbnkgQ2xhc3MsIGxpa2UgUGVyc29uLCBidXQgdGhhdOKAmXMg >>>Y >>>SBz >>> >>>aWRlIGVmZmVjdCBvZiBsZWF2aW5nIHRoZSBkb21haW4gYmxhbmsuIA0KDQrigKIgSWRlYWxs >>>e >>>Swg >>> >>>dHJlYXR5U2lnbmF0b3Igd291bGQgYmUgYSBiZjpQZXJzb24gb3IgcmVhbGx5IGEgZ292ZXJu >>>b >>>WVu >>> >>>dCBib2R5LCBidXQgdGhlIGRhdGEgZnJvbSBNQVJDIGlzIGdvaW5nIHRvIGJlIHN0cmluZ3ku >>>I >>>FRo >>> >>>aXMgaXMgeWV0IGFub3RoZXIgZXhhbXBsZSB3aGVyZSBpZiB3ZSBoYWQgb3VyIGRydXRoZXJz >>>L >>>CB3 >>> >>>ZeKAmWQgaGF2ZSBhIHN0cmluZyB2ZXJzaW9uIG9mIGEgcHJvcGVydHkgZm9yIGxlZ2FjeSBk >>>Y >>>XRh >>> >>>LCBhbmQgYSB1cmkgdmVyc2lvbiBmb3IgYm9ybiBiZjogZGF0YS4NCg0K4oCiIGJmOmFnZW50 >>>I >>>Dog >>> >>>b2Z0ZW4sIHRoZXJlIGlzIGEgbmFtZSBsaXN0ZWQgaW4gdGhlIDd4eCBmaWVsZHMsIGJ1dCBu >>>b >>>yBy >>> >>>ZWxhdGlvbnNoaXAgc3RhdGVkLCBub3IgdHlwZSBvZiBtYXRlcmlhbCwgc28geW91IGNhbuKA >>>m >>>XQg >>> >>>Z3Vlc3MgYXQgdGhlIHJvbGUgdGhlIHBlcnNvbiBwbGF5cyB3aXRoIHJlc3BlY3QgdG8gdGhh >>>d >>>CBy >>> >>>ZXNvdXJjZQ0KDQrigKIgKiBiZjplZGl0aW9uIDogTUFSQyAyNTAkYSAgYmY6ZWRpdGlvblJl >>>c >>>3Bv >>> >>>bnNpYmlsaXR5IDI1MCRiIGJmOm90aGVyRWRpdGlvbiBNQVJDIDc3NS4gDQoNCglvIFRoZSBm >>>a >>>XJz >>> >>>dCB0d28gZGVzY3JpYmUgdGhpcyBlZGl0aW9uLCB0aGUgb3RoZXJFZGl0aW9uIHBvaW50cyB0 >>>b >>>yBh >>> >>>IGRpZmZlcmVudCByZXNvdXJjZToNCg0KCQlvIEJGIGVkaXRpb24gYW5kIHJlc3BvbnNpYmls >>>a >>>XR5 >>> >>>OiA6IGh0dHA6Ly9iaWJmcmFtZS5vcmcvdG9vbHMvY29tcGFyZS9iaWJpZC83ODEwNDYxDQoJ >>>C >>>W8g >>> >>>YmZvdGhlckVkaXRpb246IGh0dHA6Ly9iaWJmcmFtZS5vcmcvdG9vbHMvY29tcGFyZS9iaWJp >>>Z >>>C8x >>> >>>MTM0NjY4NQ0KDQpJ4oCZbGwgdHJ5IHRvIGFuc3dlciB0aGUgb3RoZXJzIHNlcGFyYXRlbHku >>>D >>>QpU >>> >>>aGFua3MsIE5hdGUNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t >>>L >>>S0N >>> >>>Ck5hdGUgVHJhaWwNCkxTL1RFQ0gvTkRNU08NCkxBMzA4LCBNYWlsIFN0b3AgNDQwMg0KTGli >>>c >>>mFy >>> >>>eSBvZiBDb25ncmVzcw0KV2FzaGluZ3RvbiBEQyAyMDU0MA0KLS0tLS0tLS0tLS0tLS0tLS0t >>>L >>>S0t >>> >>>LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KRnJvbTogQmlibGlvZ3JhcGhpYyBGcmFtZXdvcmsg >>>V >>>HJh >>> >>>bnNpdGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWlsdG86QklCRlJBTUVATElTVFNFUlYuTE9D >>>L >>>kdP >>> >>>Vl0gT24gQmVoYWxmIE9mIFJvYmVydCBTYW5kZXJzb24NClNlbnQ6IFR1ZXNkYXksIFNlcHRl >>>b >>>WJl >>> >>>ciAxNiwgMjAxNCA0OjI1IFBNDQpUbzogQklCRlJBTUVATElTVFNFUlYuTE9DLkdPVg0KU3Vi >>>a >>>mVj >>> >>>dDogW0JJQkZSQU1FXSBTcGVjaWZpYyBRdWVzdGlvbnMNCg0KDQpTb21lIHNwZWNpZmljIHF1 >>>Z >>>XN0 >>> >>>aW9uczoNCg0KLS0tIFJhbmdlL0RvbWFpbiAtLS0NCg0KKiBiZjpkaXNzZXJ0YXRpb25JbnN0 >>>a >>>XR1 >>> >>>dGlvbiBoYXMgYSByYW5nZSBvZiBiZjpBZ2VudCwgbm90IGJmOkluc3RpdHV0aW9uLsKgIEFy >>>Z >>>SB0 >>> >>>aGVyZSByZWFsbHkgcGVvcGxlIHRoYXQgZ2l2ZSBvdXQgZGlzc2VydGF0aW9ucyAoYW5kIGhv >>>d >>>yBt >>> >>>dWNoIGRvIHRoZXkgY29zdD8gOkQpDQoNCiogYmY6ZWRpdGlvbiAoYW5kIGJmOmVkaXRpb25S >>>Z >>>XNw >>> >>>b25zaWJpbGl0eSwgd2hpY2ggbG9va3MgbGlrZSBhIE5vdGUpIGhhcyBhIGRvbWFpbiBvZiBJ >>>b >>>nN0 >>> >>>YW5jZSwgYXMgZXhwZWN0ZWQgZnJvbSB0aGUgUHJvdmlkZXIgZGlzY3Vzc2lvbiB0aGF0IGRp >>>Z >>>mZl >>> >>>cmVudCBlZGl0aW9ucyAoYW5kIGhlbmNlIGRhdGVzKSBtdXN0IGJlIGRpZmZlcmVudCBJbnN0 >>>Y >>>W5j >>> >>>ZXMuIEhvd2V2ZXIsIGJmOm90aGVyRWRpdGlvbiBoYXMgZG9tYWluIGFuZCByYW5nZSBvZiBi >>>Z >>>jpX >>> >>>b3JrLsKgIFRoaXMgc2VlbXMgbGlrZSBhIG1pc3Rha2U/DQoNCiogUmVsYXRlZGx5LCBiZjpt >>>d >>>XNp >>> >>>Y1ZlcnNpb24gaGFzIGEgcmFuZ2Ugb2YgTGl0ZXJhbCBhbmQgbm8gZG9tYWluLiBUaGlzIHNl >>>Z >>>W1z >>> >>>IGxpa2UgaXQgc2hvdWxkIGJlIFdvcmsgb3IgSW5zdGFuY2U/DQoqIEFuZCBzaW1pbGFybHks >>>I >>>GJm >>> >>>OnRyZWF0eVNpZ25hdG9yIGhhcyBhIHJhbmdlIG9mIExpdGVyYWwgYW5kIG5vIGRvbWFpbi7C >>>o >>>CBT >>> >>>ZWVtcyBsaWtlIGl0IHNob3VsZCBiZSBhIHJhbmdlIG9mIGJmOlBlcnNvbj8NCg0KLS0tIE5v >>>I >>>FNl >>> >>>bWFudGljcyAtLS0NCg0KKiBiZjphZ2VudCBkb2Vzbid0IHNlZW0gdG8gc2F5IGFueXRoaW5n >>>I >>>GJl >>> >>>eW9uZCAiSGVyZSBpcyBhbiBhZ2VudCBzb21laG93IHJlbGF0ZWQgdG8gdGhpcyByZXNvdXJj >>>Z >>>SIs >>> >>>IGFuZCBoYXMgbm8gZG9tYWluLsKgIEFsc28sIGFmYWljdCwgaXQgaGFzIG5vIHN1Yi1wcm9w >>>Z >>>XJ0 >>> >>>aWVzLiDCoCBDYW4gYW55b25lIHNoZWQgc29tZSBsaWdodCBvbiB3aGF0IHRoZSBtZWFuaW5n >>>I >>>G9m >>> >>>IHRoZSByZWxhdGlvbnNoaXAgaXMsIGFuZCB0aHVzIHdoZW4gYSBwcm9kdWNlciB3b3VsZCBj >>>c >>>mVh >>> >>>dGUgaXQgYW5kIHdoYXQgYSBjb25zdW1lciB3b3VsZCBkbyB3aXRoIGl0Pw0KKiBiZjpldmVu >>>d >>>CBp >>> >>>cyB0aGUgc2FtZSBhcyBiZjphZ2VudC4NCiogYmY6cGxhY2UgdXNlZCB0byBleGlzdCwgYnV0 >>>I >>>G5v >>> >>>IGxvbmdlciAuLi4gc2hvdWxkIGFnZW50IGFuZCBldmVudCBhbHNvIGJlIGRlbGV0ZWQ/IMKg >>>K >>>HRl >>> >>>bXBvcmFsIGFuZCB0b3BpYyBuZXZlciBleGlzdGVkKQ0KDQoqIGJmOnJlbGF0ZWRJbnN0YW5j >>>Z >>>SBz >>> >>>ZWVtcyB0byBvbmx5IGhhdmUgdGhlIHNlbWFudGljcyBvZiByZWxhdGVkVG8sIGJ1dCB3aXRo >>>I >>>HNw >>> >>>ZWNpZmljIHJhbmdlIGFuZCBkb21haW4uwqAgV2h5IHdvdWxkIGEgY29uc3VtZXIvcHJvZHVj >>>Z >>>XIg >>> >>>dXNlIHRoaXMgaW5zdGVhZCBvZiByZWxhdGVkVG8/DQoqIERpdHRvIGJmOnJlbGF0ZWRXb3Jr >>>D >>>QoN >>> >>>CiogYmY6bGVnYWxEYXRlIHNlZW1zIHRvIGhhdmUgdGhlIGRlc2NyaXB0aW9uIG9mIERhdGUg >>>b >>>2Yg >>> >>>YSB3b3JrIHRoYXQncyBsZWdhbCBpbiBuYXR1cmUsIG9yIHRoZSBkYXRlIGEgdHJlYXR5IHdh >>>c >>>yBz >>> >>>aWduZWQsIG9yIHRoZSBkYXRlIGEgbGF3IHdlbnQgaW50byBlZmZlY3QuIFRoaXMgc2VlbXMg >>>c >>>28g >>> >>>aW5kaXN0aW5jdCB0byB0aGUgcG9pbnQgb2YgYmVpbmcgd29ydGhsZXNzPw0KDQotLS0gSW5j >>>b >>>25z >>> >>>aXN0ZW5jeSAtLS0NCg0KKiBiZjpvcmlnaW5QbGFjZSwgYmY6b3JpZ2luRGF0ZSAuLi4gYnV0 >>>I >>>GJm >>> >>>OlByb3ZpZGVyLCBhbmQgdGhlIHByZXZpb3VzIGRpc2N1c3Npb24gYWJvdXQgcHJvdmlkZXJO >>>Y >>>W1l >>> >>>IGFuZCBwcm92aWRlckRhdGUuIMKgIFNvIHdoZW4gaXRzIGFuIEluc3RhbmNlLCB0aGUgZXZl >>>b >>>nQg >>> >>>Z2V0cyBpdHMgb3duIHJlc291cmNlLCBidXQgd2hlbiBpdHMgYSBXb3JrLCBpdCBkb2Vzbid0 >>>P >>>w0K >>> >>>DQpUaGFua3MhDQoNClJvYg0KDQotLSANClJvYiBTYW5kZXJzb24NClRlY2hub2xvZ3kgQ29s >>>b >>>GFi >>> >>>b3JhdGlvbiBGYWNpbGl0YXRvcg0KRGlnaXRhbCBMaWJyYXJ5IFN5c3RlbXMgYW5kIFNlcnZp >>>Y >>>2Vz >>> DQpTdGFuZm9yZCwgQ0EgOTQzMDUNCg== >>> >>> ------------------------------ >>> >>> Date: Tue, 16 Sep 2014 14:27:16 -0700 >>> From: Robert Sanderson <[log in to unmask]> >>> Subject: Re: Specific Questions >>> >>> --001a1133a8386894460503356ac0 >>> Content-Type: text/plain; charset=UTF-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>> Thanks Nate! >>> >>> On Tue, Sep 16, 2014 at 2:11 PM, Trail, Nate <[log in to unmask]> wrote: >>> >>>> =E2=80=A2 musicVersion and other properties without a domain: we are >>>>usu= >>> ally >>>> uncertain or agnostic as to whether it belongs on Work or Instance, >>>>as y= >>> ou >>>> guessed, and so we left it unconstrained. We don=E2=80=99t really mean >>>>th= >>> at it >>>> could be on any Class, like Person, but that=E2=80=99s a side effect >>>>of l= >>> eaving the >>>> domain blank. >>>> >>> >>> Yup, and (sorry for not being clear in the original mail) the same >>> rationale as other literals for why it's a literal not another >>> Work/Instance? Eg otherEdition is a relationship, and this seems like >>>the >>> musical equivalent? >>> >>> >>>> =E2=80=A2 Ideally, treatySignator would be a bf:Person or really a >>>>govern= >>> ment >>>> body, but the data from MARC is going to be stringy. This is yet >>>>another >>>> example where if we had our druthers, we=E2=80=99d have a string >>>>version = >>> of a >>>> property for legacy data, and a uri version for born bf: data. >>>> >>> >>> We need to get you a druthers provider :) >>> What about treatySignator domain bf:Agent (so as to be neutral about >>> organization/person) with a label of the string content? >>> >>> >>>> =E2=80=A2 bf:agent : often, there is a name listed in the 7xx fields, >>>>but= >>> no >>>> relationship stated, nor type of material, so you can=E2=80=99t guess >>>>at = >>> the role >>>> the person plays with respect to that resource >>>> >>> >>> Gotcha :( Or likely even whether it should be the Work or the >>>Instance. >>> >>> >>> =E2=80=A2 * bf:edition : MARC 250$a bf:editionResponsibility 250$b >>>bf:othe= >>> rEdition >>>> MARC 775. >>>> o The first two describe this edition, the otherEdition points >>>>to >>>> a different resource: >>>> o BF edition and responsibility: : >>>> http://bibframe.org/tools/compare/bibid/7810461 >>>> o bfotherEdition: >>>> http://bibframe.org/tools/compare/bibid/11346685 >>>> >>> >>> 250$a and $b I [believe I] understand. And the discussion that there's >>>no >>> need to merge them as the bf:editionResponsibility must always belong >>>to >>> the bf:edition ... as any other edition must be a new _bf:Instance_ so >>>each >>> Instance can only ever have one of each. >>> >>> But then bf:otherEdition should be a relationship between Instances, >>>not >>> between Works? >>> >>> Rob >>> >>> >>> >>> >>> --- Range/Domain --- >>>> >>>> * bf:dissertationInstitution has a range of bf:Agent, not >>>>bf:Institution. >>>> Are there really people that give out dissertations (and how much do >>>>they >>>> cost? :D) >>>> >>>> * bf:edition (and bf:editionResponsibility, which looks like a Note) >>>>has = >>> a >>>> domain of Instance, as expected from the Provider discussion that >>>>differe= >>> nt >>>> editions (and hence dates) must be different Instances. However, >>>> bf:otherEdition has domain and range of bf:Work. This seems like a >>>>mista= >>> ke? >>>> >>>> * Relatedly, bf:musicVersion has a range of Literal and no domain. >>>>This >>>> seems like it should be Work or Instance? >>>> * And similarly, bf:treatySignator has a range of Literal and no >>>>domain. >>>> Seems like it should be a range of bf:Person? >>>> >>>> --- No Semantics --- >>>> >>>> * bf:agent doesn't seem to say anything beyond "Here is an agent >>>>somehow >>>> related to this resource", and has no domain. Also, afaict, it has no >>>> sub-properties. Can anyone shed some light on what the meaning of >>>>the >>>> relationship is, and thus when a producer would create it and what a >>>> consumer would do with it? >>>> * bf:event is the same as bf:agent. >>>> * bf:place used to exist, but no longer ... should agent and event >>>>also b= >>> e >>>> deleted? (temporal and topic never existed) >>>> >>>> * bf:relatedInstance seems to only have the semantics of relatedTo, >>>>but >>>> with specific range and domain. Why would a consumer/producer use >>>>this >>>> instead of relatedTo? >>>> * Ditto bf:relatedWork >>>> >>>> * bf:legalDate seems to have the description of Date of a work that's >>>> legal in nature, or the date a treaty was signed, or the date a law >>>>went >>>> into effect. This seems so indistinct to the point of being worthless? >>>> >>>> --- Inconsistency --- >>>> >>>> * bf:originPlace, bf:originDate ... but bf:Provider, and the previous >>>> discussion about providerName and providerDate. So when its an >>>>Instance= >>> , >>>> the event gets its own resource, but when its a Work, it doesn't? >>>> >>>> Thanks! >>>> >>>> Rob >>>> >>>> -- >>>> Rob Sanderson >>>> Technology Collaboration Facilitator >>>> Digital Library Systems and Services >>>> Stanford, CA 94305 >>>> >>> >>> >>> >>> --=20 >>> Rob Sanderson >>> Technology Collaboration Facilitator >>> Digital Library Systems and Services >>> Stanford, CA 94305 >>> >>> --001a1133a8386894460503356ac0 >>> Content-Type: text/html; charset=UTF-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>> <div dir=3D"ltr"><br><div>Thanks Nate!</div><div><br></div><div >>>class=3D"gm= >>> ail_extra"><div class=3D"gmail_quote">On Tue, Sep 16, 2014 at 2:11 PM, >>>Trai= >>> l, Nate <span dir=3D"ltr"><<a href=3D"mailto:[log in to unmask]" >>>target=3D"_bl= >>> ank">[log in to unmask]</a>></span> wrote:<br><blockquote >>>class=3D"gmail_quote= >>> " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc >>>solid;padding-left:1ex">= >>> =E2=80=A2 musicVersion=C2=A0 and other properties without a domain: we >>>are = >>> usually uncertain=C2=A0 or agnostic as to whether it belongs on Work or >>>Ins= >>> tance, as you guessed, and so we left it unconstrained. We >>>don=E2=80=99t re= >>> ally mean that it could be on any Class, like Person, but >>>that=E2=80=99s a = >>> side effect of leaving the domain >>>blank.<br></blockquote><div><br></div><di= >>> v>Yup, and (sorry for not being clear in the original mail) the same >>>ration= >>> ale as other literals for why it's a literal not another >>>Work/Instance?= >>> =C2=A0 Eg otherEdition is a relationship, and this seems like the >>>musical e= >>> quivalent?</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" >>>styl= >>> e=3D"margin:0 0 0 .8ex;border-left:1px #ccc >>>solid;padding-left:1ex">=E2=80= >>> =A2 Ideally, treatySignator would be a bf:Person or really a government >>>bod= >>> y, but the data from MARC is going to be stringy. This is yet another >>>examp= >>> le where if we had our druthers, we=E2=80=99d have a string version of >>>a pr= >>> operty for legacy data, and a uri version for born bf: >>>data.<br></blockquot= >>> e><div><br></div><div>We need to get you a druthers provider :) >>>=C2=A0</div= >>>> <div>What about treatySignator domain bf:Agent =C2=A0(so as to be >>>>neutral = >>> about organization/person) with a label of the string >>>content?<br></div><di= >>> v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 >>>.8ex;= >>> border-left:1px #ccc solid;padding-left:1ex">=E2=80=A2 bf:agent : >>>often, th= >>> ere is a name listed in the 7xx fields, but no relationship stated, nor >>>typ= >>> e of material, so you can=E2=80=99t guess at the role the person plays >>>with= >>> respect to that resource<br></blockquote><div><br></div><div>Gotcha :( >>>=C2= >>> =A0Or likely even whether it should be the Work or the Instance. >>>=C2=A0</di= >>> v><div><br></div><div><br></div><blockquote class=3D"gmail_quote" >>>style=3D"= >>> margin:0 0 0 .8ex;border-left:1px #ccc >>>solid;padding-left:1ex">=E2=80=A2 * = >>> bf:edition : MARC 250$a=C2=A0 bf:editionResponsibility 250$b >>>bf:otherEditio= >>> n MARC 775.<br> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 o The first two describe this edition, the >>>othe= >>> rEdition points to a different resource:<br> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o BF edition >>>and re= >>> sponsibility: : <a >>>href=3D"http://bibframe.org/tools/compare/bibid/7810461"= >>> >>>target=3D"_blank">http://bibframe.org/tools/compare/bibid/7810461</a><br >>>> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o >>>bfotherEdition: <= >>> a href=3D"http://bibframe.org/tools/compare/bibid/11346685" >>>target=3D"_blan= >>> >>>k">http://bibframe.org/tools/compare/bibid/11346685</a><br></blockquote> >>>< >>>di= >>> v><br></div><div>250$a and $b I [believe I] understand.=C2=A0 And the >>>discu= >>> ssion that there's no need to merge them as the >>>bf:editionResponsibilit= >>> y must always belong to the bf:edition ... as any other edition must be >>>a n= >>> ew _bf:Instance_ so each Instance can only ever have one of >>>each.</div><div= >>>> <br></div><div>But then bf:otherEdition should be a relationship >>>>between I= >>> nstances, not between >>>Works?</div><div><br></div><div>Rob</div><div><br></d= >>> iv><div><br></div><div><br></div><div><br></div><blockquote >>>class=3D"gmail_= >>> quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc >>>solid;padding-left:1= >>> ex"><div class=3D"HOEnZb"><div class=3D"h5">--- Range/Domain ---<br> >>> <br> >>> * bf:dissertationInstitution has a range of bf:Agent, not >>>bf:Institution.= >>> =C2=A0 Are there really people that give out dissertations (and how >>>much do= >>> they cost? :D)<br> >>> <br> >>> * bf:edition (and bf:editionResponsibility, which looks like a Note) >>>has a = >>> domain of Instance, as expected from the Provider discussion that >>>different= >>> editions (and hence dates) must be different Instances. However, >>>bf:otherE= >>> dition has domain and range of bf:Work.=C2=A0 This seems like a >>>mistake?<br= >>>> >>> <br> >>> * Relatedly, bf:musicVersion has a range of Literal and no domain. This >>>see= >>> ms like it should be Work or Instance?<br> >>> * And similarly, bf:treatySignator has a range of Literal and no >>>domain.=C2= >>> =A0 Seems like it should be a range of bf:Person?<br> >>> <br> >>> --- No Semantics ---<br> >>> <br> >>> * bf:agent doesn't seem to say anything beyond "Here is an >>>agent s= >>> omehow related to this resource", and has no domain.=C2=A0 Also, >>>afaic= >>> t, it has no sub-properties. =C2=A0 Can anyone shed some light on what >>>the = >>> meaning of the relationship is, and thus when a producer would create >>>it an= >>> d what a consumer would do with it?<br> >>> * bf:event is the same as bf:agent.<br> >>> * bf:place used to exist, but no longer ... should agent and event also >>>be = >>> deleted? =C2=A0(temporal and topic never existed)<br> >>> <br> >>> * bf:relatedInstance seems to only have the semantics of relatedTo, but >>>wit= >>> h specific range and domain.=C2=A0 Why would a consumer/producer use >>>this i= >>> nstead of relatedTo?<br> >>> * Ditto bf:relatedWork<br> >>> <br> >>> * bf:legalDate seems to have the description of Date of a work >>>that's l= >>> egal in nature, or the date a treaty was signed, or the date a law went >>>int= >>> o effect. This seems so indistinct to the point of being worthless?<br> >>> <br> >>> --- Inconsistency ---<br> >>> <br> >>> * bf:originPlace, bf:originDate ... but bf:Provider, and the previous >>>discu= >>> ssion about providerName and providerDate. =C2=A0 So when its an >>>Instance, = >>> the event gets its own resource, but when its a Work, it >>>doesn't?<br> >>> <br> >>> Thanks!<br> >>> <br> >>> Rob<br> >>> <br> >>> --<br> >>> Rob Sanderson<br> >>> Technology Collaboration Facilitator<br> >>> Digital Library Systems and Services<br> >>> Stanford, CA 94305<br> >>> </div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- >>><br>= >>> <div dir=3D"ltr">Rob Sanderson<div>Technology Collaboration >>>Facilitator</di= >>> v><div>Digital Library Systems and Services</div><div>Stanford, CA >>>94305</d= >>> iv></div> >>> </div></div> >>> >>> --001a1133a8386894460503356ac0-- >>> >>> ------------------------------ >>> >>> Date: Tue, 16 Sep 2014 16:51:52 -0500 >>> From: "Mark K. Ehlert" <[log in to unmask]> >>> Subject: Re: Specific Questions >>> >>> --e89a8ff1cf922a90bf050335c474 >>> Content-Type: text/plain; charset=UTF-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>> Robert Sanderson <[log in to unmask]> wrote: >>> >>>> =E2=80=A2 * bf:edition : MARC 250$a bf:editionResponsibility 250$b >>>>> bf:otherEdition MARC 775. >>>>> o The first two describe this edition, the otherEdition points >>>>>t= >>> o >>>>> a different resource: >>>>> o BF edition and responsibility: : >>>>> http://bibframe.org/tools/compare/bibid/7810461 >>>>> o bfotherEdition: >>>>> http://bibframe.org/tools/compare/bibid/11346685 >>>>> >>>> >>>> 250$a and $b I [believe I] understand. And the discussion that >>>>there's n= >>> o >>>> need to merge them as the bf:editionResponsibility must always belong >>>>to >>>> the bf:edition ... as any other edition must be a new _bf:Instance_ so >>>>ea= >>> ch >>>> Instance can only ever have one of each. >>>> >>>> But then bf:otherEdition should be a relationship between Instances, >>>>not >>>> between Works? >>>> >>> >>> >>> In a FRBR/RDA sense, an edition statement found on the instance (RDA: >>> manifestation) indicates the edition or "edition-ness" to which it >>>belongs >>> (RDA: expression). >>> >>> --=20 >>> Mark K. Ehlert Minitex >>> Coordinator University of Minnesota >>> Digitization, Cataloging & 15 Andersen Library >>> Metadata Education (DCME) 222 21st Avenue South >>> Phone: 612-624-0805 Minneapolis, MN 55455-0439 >>> <http://www.minitex.umn.edu/> >>> >>> "Experience is by industry achieved // And perfected by >>> the swift course of time." -- Shakespeare, "Two Gentlemen >>> of Verona," Act I, scene iii >>> >>> --e89a8ff1cf922a90bf050335c474 >>> Content-Type: text/html; charset=UTF-8 >>> Content-Transfer-Encoding: quoted-printable >>> >>> <div dir=3D"ltr"><div class=3D"gmail_extra"><div >>>class=3D"gmail_quote">Robe= >>> rt Sanderson <span dir=3D"ltr"><<a >>>href=3D"mailto:[log in to unmask]" t= >>> arget=3D"_blank">[log in to unmask]</a>></span> >>>wrote:<br><blockquote c= >>> lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc >>>solid;= >>> padding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquote >>>class=3D"gm= >>> ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc >>>solid;padding-le= >>> ft:1ex">=E2=80=A2 * bf:edition : MARC 250$a=C2=A0 >>>bf:editionResponsibility = >>> 250$b bf:otherEdition MARC 775.<br> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 o The first two describe this edition, the >>>othe= >>> rEdition points to a different resource:<br> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o BF edition >>>and re= >>> sponsibility: : <a >>>href=3D"http://bibframe.org/tools/compare/bibid/7810461"= >>> >>>target=3D"_blank">http://bibframe.org/tools/compare/bibid/7810461</a><br >>>> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 o >>>bfotherEdition: <= >>> a href=3D"http://bibframe.org/tools/compare/bibid/11346685" >>>target=3D"_blan= >>> >>>k">http://bibframe.org/tools/compare/bibid/11346685</a><br></blockquote> >>>< >>>di= >>> v><br></div></span><div>250$a and $b I [believe I] understand.=C2=A0 >>>And th= >>> e discussion that there's no need to merge them as the >>>bf:editionRespon= >>> sibility must always belong to the bf:edition ... as any other edition >>>must= >>> be a new _bf:Instance_ so each Instance can only ever have one of >>>each.</d= >>> iv><div><br></div><div>But then bf:otherEdition should be a >>>relationship be= >>> tween Instances, not between >>>Works?</div></div></blockquote><div><br><br></= >>> div><div>In a FRBR/RDA sense, an edition statement found on the >>>instance (R= >>> DA: manifestation) indicates the edition or "edition-ness" to >>>whi= >>> ch it belongs (RDA: expression).<br><br></div></div>-- <br><div >>>dir=3D"ltr"= >>>> <div><span style=3D"font-family:courier new,monospace">Mark K. Ehlert >>>>=C2= >>> =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>Minitex<br>Coordinator= >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>=C2=A0Unive= >>> rsity of Minnesota<br>Digitization, Cataloging & =C2=A0 =C2=A0 15 >>>Ander= >>> sen Library<br>=C2=A0 Metadata Education (DCME) =C2=A0 =C2=A0222 21st >>>Avenu= >>> e South<br>Phone: 612-624-0805 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>=C2=A0Min= >>> neapolis, MN 55455-0439<br><<a href=3D"http://www.minitex.umn.edu/" >>>targ= >>> et=3D"_blank">http://www.minitex.umn.edu/</a>><br><br>=C2=A0 >>>"Exper= >>> ience is by industry achieved // And perfected by<br>the swift course >>>of ti= >>> me." -- Shakespeare, "Two Gentlemen<br></span></div><span >>>style= >>> =3D"font-family:courier new,monospace">of Verona," Act I, scene >>>iii<br= >>>> </span><div><br></div></div> >>> </div></div> >>> >>> --e89a8ff1cf922a90bf050335c474-- >>> >>> ------------------------------ >>> >>> End of BIBFRAME Digest - 10 Sep 2014 to 16 Sep 2014 (#2014-119) >>> ***************************************************************