I don't think that expressing an assertion in a "machine-procesable" way must require (1.) turning catalogers into triple-generating machines- or failing that - (2.) stripping out sophisticated community temporal, calendri, etc., descriptions en route to Triple-Land. As far as date* and calendar** maipulations go, existing domain-aware natural language processing systems seem to be able to meet us (mabe 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 tll themselves "we can generate a set of BIBFRAME-friendly triples from ^these^ well-efined natural language words/phrases/statements" - all the while taking steps to ceate key community "open source software" functionality that can handle domain-awre triple-generation? A glance at financial/date/time/place, etc. manipulations as are found in relational databases demonstrates that much complexity can usefully be offoaded to domain-aware 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 >> >> >>S2FyZW4sDQoNClRoZSBmYXVsdCBpcyBub3QgaW4gb3VyIGNhdGFsb2dpbmcgY29kZSBidXQga >>W4g >> >>b3Vyc2VsdmVzLiBSREEgdHJlYXRzIGZyZXF1ZW5jeSBhcyBhIGRpc3RpbmN0IGVsZW1lbnQgK >>DIu >> >>MTQpLCBhbmQgcmVxdWlyZXMgYSBub3RlIG9ubHkgd2hlbiBhbiBhcHByb3ByaWF0ZSB0ZXJtI >>Glz >> >>IHVuYXZhaWxhYmxlLiBUaGUgdGVybXMgYXQgUkRBIDIuMTQuMS4zIGNvcnJlc3BvbmQgdG8gd >>Ghl >> >>IGNvZGVzIGF2YWlsYWJsZSBpbiB0aGUgTUFSQyBiaWJsaW9ncmFwaGljIGZvcm1hdCAoMDA4L >>zE4 >> >>KSwgYW5kIGV2ZW4gbW9yZSBlbGFib3JhdGUgY29kZWQgZnJlcXVlbmN5IGRhdGEgY2FuIGJlI >>HN0 >> >>b3JlZCBpbiB0aGUgTUFSQyBob2xkaW5ncyBmb3JtYXQuIFJhdGhlciwgdGhlIHByb2xpZmVyY >>XRp >> >>b24gb2Ygbm90ZXMgaXMgb2Z0ZW4gYSByZXN1bHQgb2YgaW1wbGVtZW50YXRpb24gZGVjaXNpb >>25z >> >>LCBhbmQgdGhlc2UgYXJlIG9mdGVuIGluZm9ybWVkIGJ5IHRoZSBwZXJjZWl2ZWQgY2FwYWJpb >>Gl0 >> >>aWVzIG9mIGV4aXN0aW5nIG1hY2hpbmUgc3lzdGVtcy4gRm9yIGV4YW1wbGUsIHRoZXJlIGlzI >>G5v >> >>IHJlYXNvbiB0aGF0IGNvZGVzIGNvdWxkIG5vdCBoYXZlIGJlZW4gZGV2ZWxvcGVkIGZvciB0a >>GUg >> >>cGxldGhvcmEgb2YgcmVsYXRpb25zaGlwIGRlc2lnbmF0b3JzIGluIFJEQSBhcHBlbmRpY2VzI >>Ekt >> >>TCwgYnV0IGluc3RlYWQgd2Ugc3VwcGx5IHRoZSB0ZXJtcyB2ZXJiYXRpbSAoYW5kIGluIEVuZ >>2xp >> >>c2gpIGZyb20gUkRBLiBMaWtld2lzZSB3aXRoIHRoZSBjYXJyaWVyLCBtZWRpYSwgYW5kIGNvb >>nRl >> >>bnQgdHlwZXM7IGZvciB0aGUgZmlyc3QgdHdvLCBjb2RlZCBlcXVpdmFsZW50cyB3ZXJlIGFsc >>mVh >> >>ZHkgaW4gZXhpc3RlbmNlIGZvciB0aGUgbW9zdCBwYXJ0LCBzbyB0aGUgdGV4dCByZWNvcmRlZ >>CAo >> >>aW4gRW5nbGlzaCkgaW4gZmllbGRzIDMzNyBhbmQgMzM4IGlzIG9mdGVuIHJlZHVuZGFudCB3a >>XRo >> >>IGNvZGVkIHZhbHVlcyBhbHJlYWR5IHByZXNlbnQgaW4gMDA3LzAwLTAxLiBJLCBmb3Igb25lL >>CB3 >> >>b3VsZCBiZSBoYXBweSB0byBzZWUgbm90ZXMgeWllbGQgdG8gY29kZWQgZGF0YSB3aGVuZXZlc >>iBw >> >>b3NzaWJsZSwgaWYgb25seSB0byBzYXZlIGtleXN0cm9rZXMuDQoNCg0KRWQgSm9uZXMNCkFzc >>29j >> >>aWF0ZSBEaXJlY3RvciwgTGlicmFyeSBBc3Nlc3NtZW50IGFuZCBUZWNobmljYWwgU2VydmljZ >>XMN >> >>Ck5hdGlvbmFsIFVuaXZlcnNpdHkgTGlicmFyeQ0KOTM5MyBMaWdodHdhdmUgQXZlbnVlDQpTY >>W4g >> >>RGllZ28sIENhbGlmb3JuaWHCoCA5MjEyMy0xNDQ3DQrCoA0KKzEgODU4IDU0MSA3OTIwICh2b >>2lj >> >>ZSkNCisxIDg1OCA1NDEgNzk5NyAoZmF4KQ0KDQpodHRwOi8vbmF0aW9uYWwuYWNhZGVtaWEuZ >>WR1 >> >>L0VkSm9uZXMNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ >>mli >> >>bGlvZ3JhcGhpYyBGcmFtZXdvcmsgVHJhbnNpdGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWlsd >>G86 >> >>QklCRlJBTUVATElTVFNFUlYuTE9DLkdPVl0gT24gQmVoYWxmIE9mIEthcmVuIENveWxlDQpTZ >>W50 >> >>OiBNb25kYXksIFNlcHRlbWJlciAxNSwgMjAxNCAxMTozMyBQTQ0KVG86IEJJQkZSQU1FQExJU >>1RT >> >>RVJWLkxPQy5HT1YNClN1YmplY3Q6IFJlOiBbQklCRlJBTUVdIExpdGVyYWwgUHJvcGVydGllc >>yB2 >> >>cyBOb3Rlcw0KDQpGcmVxdWVuY3kgaXMgYSBnb29kIGV4YW1wbGUgb2YgdGhlIG1lc3MgdGhhd >>CB3 >> >>ZSBoYXZlIHRvZGF5IGluIEFBQ1ItdHlwZSBjYXRhbG9naW5nLiBUaGVyZSBpcyBhIHdheSB0b >>yBj >> >>b2RlIGZyZXF1ZW5jeSBhcyBhIGNhbGN1bGFibGUgdmFsdWUgaW4gdGhlIE1BUkMgaG9sZGluZ >>3Mg >> >>cmVjb3JkLiBUaGF0IHNob3VsZCBzdWZmaWNlIGFuZCB0aGVyZSBzaG91bGQgYmUgbm8gbmVlZ >>CBm >> >>b3IgYSBub3RlIGZpZWxkIGlmIHRoZSB2YWx1ZSBpcyBwcm92aWRlZC4gQnV0IG5vdGVzIGFyZ >>SAi >> >>bm90ZXMiIGJlY2F1c2UgdGhleSBhcmUgdW5jb250cm9sbGVkIHN0cmluZ3MgY3JlYXRlZCBie >>SB0 >> >>aGUgY2F0YWxvZ2VyLiBXaGVyZSBvdGhlciBkYXRhIGluIHRoZSByZWNvcmQgYXJlIGVpdGhlc >>iB0 >> >>cmFuc2NyaWJlZCBzdHJpbmdzIG9yIGNvbnRyb2xsZWQgaGVhZGluZ3MsIG5vdGVzIGFyZSBuZ >>Wl0 >> >>aGVyLiBCdXQgdGhlIG5vdGVzIEFSRSByZXF1aXJlZCBieSB0aGUgY2F0YWxvZ2luZyBydWxlc >>y4N >> >>Cg0KVGhpcyBpcyBldmlkZW5jZSwgdG8gbWUsIG9mIHRoZSBnYXAgYmV0d2VlbiB0aGUgY2F0Y >>Wxv >> >>Z2luZyBydWxlcyBhbmQgdGhlIGFjdHVhbCBwcmFjdGljZSBvZiBjcmVhdGluZyBtYWNoaW5lL >>XJl >> >>YWRhYmxlIGNhdGFsb2cgcmVjb3Jkcy4gQUFDUiBkb2VzIG5vdCByZWNvZ25pemUgdGhhdCBjb >>2Rl >> >>ZCBkYXRhIChlLmcuIE1BUkMgZml4ZWQgZmllbGRzKSBleGlzdHMuICANCk1hbnkgbm90ZXMgc >>mVw >> >>ZWF0IGluZm9ybWF0aW9uIHRoYXQgY291bGQgYmUgZW5jb2RlZCBlbHNld2hlcmUsIGJ1dCBiZ >>WNh >> >>dXNlIHRoZSBub3RlIGlzIHdoYXQgaXMgcmVxdWlyZWQgYnkgdGhlIGNhdGFsb2dpbmcgcnVsZ >>XMg >> >>YW5kIGFsc28gZGlzcGxheXMgaW4gdGhlIGNhdGFsb2csIHRoZSB0ZW5kZW5jeSBoYXMgYmVlb >>iB0 >> >>byBwcm92aWRlIHRoZSBub3RlIGJ1dCBvZnRlbiBub3QgdG8gcHJvdmlkZSB0aGUgYWN0aW9uY >>WJs >> >>ZSBkYXRhIGVsZW1lbnQuIE9idmlvdXNseSwgaXQgd291bGQgYmUgYSBtaXN0YWtlIHRvIGNhc >>nJ5 >> >>IGZvcndhcmQgdGhpcyBwcmFjdGljZSwgYW5kIGluc3RlYWQgdGhlIGFjdGlvbmFibGUgZGF0Y >>SBl >> >>bGVtZW50IG11c3QgYmUgdGhlIHByaW1hcnkgc291cmNlIG9mIGRhdGEsIGZyb20gd2hpY2ggd >>XNl >> >>ci1mcmllbmRseSBub3RlcyBjYW4gYmUgZGVyaXZlZCBpZiBuZWVkZWQuIFRoYXQgImlmIG5lZ >>WRl >> >>ZCIgcGFydCBpcyBhbHNvIHNvbWV0aGluZyB3ZSBzaG91bGQgdGhpbmsgYWJvdXQsIGJlY2F1c >>2Ug >> >>aW4gZmFjdCBpbiBtYW55IHN5c3RlbSBkaXNwbGF5cyBub3RlcyBhcmUgbm90IGluY2x1ZGVkL >>CBz >> >>byBjYXRhbG9nIHVzZXJzIHJhcmVseSBzZWUgdGhlbS4gIA0KQmVjYXVzZSBub3RlcyBoYXZlI >>GJl >> >>ZW4gZmF2b3JlZCBvdmVyIGFjdGlvbmFibGUgZGF0YSwgdGhlcmUgaXMgYSB3aG9sZSBob3N0I >>G9m >> >>IGluZm9ybWF0aW9uIHRoYXQgaXMgMSkgbm90IHVzYWJsZSBmb3IgYW55IGF1dG9tYXRlZCBmd >>W5j >> >>dGlvbnMgYW5kIDIpIHJhcmVseSBzZWVuIGJ5IHVzZXJzLiBTdXJlbHkgdGhpcyBpcyBhIHdhc >>3Rl >> >>IG9mIGNhdGFsb2dlciB0aW1lLCBhbmQgYSBkaXNzZXJ2aWNlIHRvIG91ciB1c2Vycy4NCg0Ka >>2MN >> >>Cg0KUXVvdGluZyBUaW0gVGhvbXBzb24gPHRpbWF0aG9tQGdtYWlsLmNvbT46DQoNCj4gSGF2a >>W5n >> >>IGEgYmY6Tm90ZSBjbGFzcyBtYWtlcyBzZW5zZSB0byBtZS4gVGhlIGN1cnJlbnQgYXBwcm9hY >>2gg >> >>c2VlbXMgDQo+IGV4aGF1c3RpdmUgZW5vdWdoIHRvIGJlIGN1bWJlcnNvbWUsIGJ1dCBwcm9iY >>WJs >> >>eSBub3QgZXhoYXVzdGl2ZSBlbm91Z2ggDQo+IHRvIGNhcHR1cmUgdGhlIGZ1bGwgcmFuZ2Ugb >>2Yg >> >>cG9zc2liaWxpdGllcyBpbiB0aGUgc291cmNlIGRhdGEuIE5vdCBhbGwgDQo+IG5vdGVzIGNvb >>WUg >> >>ZnJvbSA1WFggZmllbGRzLiBIZXJlIGlzIGEgc2FtcGxlIG1hcmMyYmliZnJhbWUgY29udmVyc >>2lv >> >>biANCj4gb2YgYSByZWNvcmQgZm9yIGEgc2VyaWFsOg0KPg0KPiBNQVJDOiBodHRwOi8vYmliZ >>nJh >> >>bWUub3JnL3Jlc291cmNlcy9KcWMxNDEwMzY1MTE1L21hcmN4bWwueG1sDQo+IEJGOiBodHRwO >>i8v >> >>YmliZnJhbWUub3JnL3Jlc291cmNlcy9KcWMxNDEwMzY1MTE1L2JpYmZyYW1lLnJkZg0KPg0KP >>iBI >> >>ZXJlLCBiZjpmcmVxdWVuY3lOb3RlIG1hcHMgdG8gdGhlIDMxMCBmaWVsZCAoQ3VycmVudCBQd >>WJs >> >>aWNhdGlvbiANCj4gRnJlcXVlbmN5KS4gVW5mb3J0dW5hdGVseSwgaXQgYWxzbyBtYXBzIHRvI >>HRo >> >>ZSAzMjEgZmllbGQgKEZvcm1lciANCj4gUHVibGljYXRpb24gRnJlcXVlbmN5KS4gVGhpcyB3b >>3Vs >> >>ZCBzZWVtIHRvIGJlIGEgbm90IGluc2lnbmlmaWNhbnQgbG9zcyANCj4gb2YgaW5mb3JtYXRpb >>24u >> >>IDVYWCBmaWVsZHMgdGhhdCBhcmUgZGlzdGluY3QgaW4gTUFSQyBhcmUgbWFwcGVkIHRvIA0KP >>iBn >> >>ZW5lcmljIGJmOm5vdGUgcHJvcGVydGllcyAoNTE1LCA1ODgpLiBiZjpmcmVxdWVuY3kgZG9lc >>24n >> >>dCBhcHBlYXIsIA0KPiBidXQgbWF5YmUgaXQgd2FzIG1lYW50IHRvIGNvcnJlc3BvbmQgdG8gd >>Ghl >> >>IDAwOCBmaXggZmllbGQgZm9yIA0KPiBjb250aW51aW5nIHJlc291cmNlcywgd2hpY2ggYWxzb >>yBo >> >>YXMgYSB2YWx1ZSBmb3IgZnJlcXVlbmN5IChwb3NpdGlvbiANCj4gMTgpLiBUaGUgbmVlZCBmb >>3Ig >> >>dHdvIGRpc3RpbmN0IHByb3BlcnRpZXMgcmVtYWlucyB1bmNsZWFyLg0KPg0KPiBJbiBzaG9yd >>Cwg >> >>YSBiZjpOb3RlIGNsYXNzIHdpdGggYmY6bm90ZVR5cGUgdmFsdWVzIG1pZ2h0IHByb3ZpZGUgD >>Qo+ >> >>IGdyZWF0ZXIgZmxleGliaWxpdHkgYW5kIHByZXNlcnZlIG1vcmUgb2YgdGhlIG9yaWdpbmFsI >>HNl >> >>bWFudGljcy4NCj4NCj4gVGltDQo+DQo+IC0tDQo+IFRpbSBBLiBUaG9tcHNvbg0KPiBNZXRhZ >>GF0 >> >>YSBMaWJyYXJpYW4gKFNwYW5pc2gvUG9ydHVndWVzZSBTcGVjaWFsdHkpIFByaW5jZXRvbiBVb >>ml2 >> >>ZXJzaXR5IA0KPiBMaWJyYXJ5DQo+DQo+DQo+IE9uIFR1ZSwgU2VwIDksIDIwMTQgYXQgNTozO >>CBQ >> >>TSwgUm9iZXJ0IFNhbmRlcnNvbiA8YXphcm90aDQyQGdtYWlsLmNvbT4NCj4gd3JvdGU6DQo+D >>Qo+ >> >>Pg0KPj4gWSdhbGwgcmVhZHkgZm9yIHRoaXM/IDspIFsxXQ0KPj4NCj4+IFdoZW4gaXMgYSBsa >>XRl >> >>cmFsIHByb3BlcnR5IGEgJ3NvbWV0aGluZ05vdGUnIGFuZCB3aGVuIGlzIGl0IGp1c3QgYSANC >>j4+ >> >>ICdzb21ldGhpbmcnPw0KPj4NCj4+IEkgYXNzdW1lIChsYWNraW5nIHByZXZpb3VzbHkgbWVud >>Glv >> >>bmVkIE1BUkMgdG8gQmliRnJhbWUgbWFwcGluZyANCj4+IGRvY3VtZW50KSB0aGF0IGFsbCBvZ >>iB0 >> >>aGUgTm90ZXMgY29tZSBmcm9tIDVYWCBmaWVsZHMsIHdoaWNoIHNlZW1zIA0KPj4gbGlrZSBzb >>21l >> >>dGhpbmcgdGhhdCBjb3VsZCBlYXNpbHkgYmUgcmF0aW9uYWxpemVkIGFsb25nIHdpdGggc29tZ >>SBv >> >>ZiANCj4+IHRoZSBvdGhlciBwcm9wZXJ0aWVzLCBhZ2FpbiBhc3N1bWluZyB0aGV5J3JlIG5vd >>CA1 >> >>WFggYW5kIGhlbmNlIGRpZG4ndCBnZXQgdGhlIE5vdGUgbW9uaWtlci4NCj4+DQo+PiBGb3IgZ >>Xhh >> >>bXBsZSwgdGhlc2UgdHdvIGxvb2sgLi4uIHdlbGwgLi4uIGlkZW50aWNhbDoNCj4+DQo+PiBmc >>mVx >> >>dWVuY3k6IEludGVydmFscyBhdCB3aGljaCB0aGUgaXNzdWVzIG9yIHBhcnRzIG9mIGEgc2Vya >>WFs >> >>IG9yIHRoZSANCj4+IHVwZGF0ZXMgdG8gYW4gaW50ZWdyYXRpbmcgcmVzb3VyY2UgYXJlIGlzc >>3Vl >> >>ZC4NCj4+IGZyZXF1ZW5jeU5vdGU6IEN1cnJlbnQgb3IgZm9ybWVyIHB1YmxpY2F0aW9uIGZyZ >>XF1 >> >>ZW5jeSBvZiBhIHJlc291cmNlLg0KPj4NCj4+DQo+PiBDdXJyZW50IG5vdGVzIGFyZToNCj4+I >>CBj >> >>b3B5Tm90ZQ0KPj4gIGF3YXJkTm90ZQ0KPj4gIGNvbnRlbnRzTm90ZQ0KPj4gIGdyYXBoaWNTY >>2Fs >> >>ZU5vdGUNCj4+ICBpbGx1c3RyYXRpb25Ob3RlDQo+PiAgc3VwcGxlbWVudGFyeUNvbnRlbnROb >>3Rl >> >>DQo+PiAgZGlzc2VydGF0aW9uTm90ZQ0KPj4gIGdlb2dyYXBoaWNDb3ZlcmFnZU5vdGUNCj4+I >>CBs >> >>YW5ndWFnZU5vdGUNCj4+ICB0ZW1wb3JhbENvdmVyYWdlTm90ZQ0KPj4gIGNyZWRpdHNOb3RlD >>Qo+ >> >>PiAgcGVyZm9ybWVyTm90ZQ0KPj4gIGZyZXF1ZW5jeU5vdGUNCj4+ICBub3RlICghKQ0KPj4gI >>G11 >> >>c2ljTWVkaXVtTm90ZQ0KPj4gIGZpbmRpbmdBaWROb3RlDQo+Pg0KPj4gQW5kIHRoZSBmb2xsb >>3dp >> >>bmcgc2VlbSBsaWtlIHRoZXkncmUgaW50ZW5kZWQgdG8gYmUgIm5vdGVzIiBpbiB0aGUgDQo+P >>iBt >> >>b3JlIGdlbmVyaWMgc2Vuc2Ugb2YgYWRkZWQgZGVzY3JpcHRpb24gYnkgYSBjYXRhbG9ndWVyI >>G9y >> >>IG90aGVyOg0KPj4NCj4+ICBmcmVxdWVuY3kNCj4+ICBjdXN0b2RpYWxIaXN0b3J5DQo+PiAga >>W1t >> >>ZWRpYXRlQWNxdWlzaXRpb24NCj4+ICBub3RhdGlvbg0KPj4gIHJlc3BvbnNpYmlsaXR5U3Rhd >>GVt >> >>ZW50DQo+PiAgcHJvdmlkZXJTdGF0ZW1lbnQgLS0gb3IgYXJlICJTdGF0ZW1lbnRzIiB0cmFuc >>2Ny >> >>aXB0aW9ucyBmcm9tIHRoZSANCj4+IEluc3RhbmNlPw0KPj4gIGVkaXRpb25SZXNwb25zaWJpb >>Gl0 >> >>eQ0KPj4gIGNvbnRlbnRBY2Nlc3NpYmlsaXR5ICAodGhvdWdoIGMuZi4gc2NoZW1hLm9yZy9hY >>2Nl >> >>c3NpYmlsaXR5RmVhdHVyZSkNCj4+DQo+PiBHaXZlbiB0aGUgZGlzY3Vzc2lvbiByZWdhcmRpb >>mcg >> >>YXNzaWduZXJzIG9mIFVSSXMgYmVpbmcgaW1wb3J0YW50LCBpdCANCj4+IHNlZW1zIHRoYXQgY >>3Jl >> >>YXRvcnMgb2Ygbm90ZXMgd291bGQgYmUgYWxzbyBpbXBvcnRhbnQ/ICBBbmQgdGh1cyBOb3Rlc >>yAN >> >>Cj4+IGNvdWxkIGJlIHRoZWlyIG93biBjbGFzcywgYmY6Tm90ZSwgd2l0aCBwcm9wZXJ0aWVzI >>Glu >> >>Y2x1ZGluZyB2YWx1ZSwgDQo+PiBhc3NpZ25lciwgdHlwZSBhbmQgc28gZm9ydGguDQo+Pg0KP >>j4g >> >>Um9iDQo+Pg0KPj4gWzFdIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9YXZjUzBhW >>Uoy >> >>YTggIFdhcm5pbmc6IHNlaXp1cmUgDQo+PiBpbmR1Y2luZyBmbGFzaGluZywgdGVycmlibGUgY >>W5p >> >>bWF0aW9uLCBwb3BweSA5MHMgbXVzaWMsIC4uLg0KPj4NCj4+IC0tDQo+PiBSb2IgU2FuZGVyc >>29u >> >>DQo+PiBUZWNobm9sb2d5IENvbGxhYm9yYXRpb24gRmFjaWxpdGF0b3INCj4+IERpZ2l0YWwgT >>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><br >>><= >> /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/la >>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 >> >> >>Um9iLCB0aGFua3MgZm9yIHRoaXMgZGV0YWlsZWQgbG9vay4gIEkgY2Fu4oCZdCBhbnN3ZXIgY >>Wxs >> >>IG9mIHRoZW0gcXVpY2tseSwgYnV0IEkga25vdyBhIGZldyBvZmYgdGhlIHRvcCBvZiBteSBoZ >>WFk >> >>Og0KDQrigKIgZGlzc2VydGF0aW9uSW5zdGl0dXRpb27igJlzIHJhbmdlIGlzIHByb2JhYmx5I >>GEg >> >>bWlzdGFrZS4NCg0K4oCiIG11c2ljVmVyc2lvbiAgYW5kIG90aGVyIHByb3BlcnRpZXMgd2l0a >>G91 >> >>dCBhIGRvbWFpbjogd2UgYXJlIHVzdWFsbHkgdW5jZXJ0YWluICBvciBhZ25vc3RpYyBhcyB0b >>yB3 >> >>aGV0aGVyIGl0IGJlbG9uZ3Mgb24gV29yayBvciBJbnN0YW5jZSwgYXMgeW91IGd1ZXNzZWQsI >>GFu >> >>ZCBzbyB3ZSBsZWZ0IGl0IHVuY29uc3RyYWluZWQuIFdlIGRvbuKAmXQgcmVhbGx5IG1lYW4gd >>Ghh >> >>dCBpdCBjb3VsZCBiZSBvbiBhbnkgQ2xhc3MsIGxpa2UgUGVyc29uLCBidXQgdGhhdOKAmXMgY >>SBz >> >>aWRlIGVmZmVjdCBvZiBsZWF2aW5nIHRoZSBkb21haW4gYmxhbmsuIA0KDQrigKIgSWRlYWxse >>Swg >> >>dHJlYXR5U2lnbmF0b3Igd291bGQgYmUgYSBiZjpQZXJzb24gb3IgcmVhbGx5IGEgZ292ZXJub >>WVu >> >>dCBib2R5LCBidXQgdGhlIGRhdGEgZnJvbSBNQVJDIGlzIGdvaW5nIHRvIGJlIHN0cmluZ3kuI >>FRo >> >>aXMgaXMgeWV0IGFub3RoZXIgZXhhbXBsZSB3aGVyZSBpZiB3ZSBoYWQgb3VyIGRydXRoZXJzL >>CB3 >> >>ZeKAmWQgaGF2ZSBhIHN0cmluZyB2ZXJzaW9uIG9mIGEgcHJvcGVydHkgZm9yIGxlZ2FjeSBkY >>XRh >> >>LCBhbmQgYSB1cmkgdmVyc2lvbiBmb3IgYm9ybiBiZjogZGF0YS4NCg0K4oCiIGJmOmFnZW50I >>Dog >> >>b2Z0ZW4sIHRoZXJlIGlzIGEgbmFtZSBsaXN0ZWQgaW4gdGhlIDd4eCBmaWVsZHMsIGJ1dCBub >>yBy >> >>ZWxhdGlvbnNoaXAgc3RhdGVkLCBub3IgdHlwZSBvZiBtYXRlcmlhbCwgc28geW91IGNhbuKAm >>XQg >> >>Z3Vlc3MgYXQgdGhlIHJvbGUgdGhlIHBlcnNvbiBwbGF5cyB3aXRoIHJlc3BlY3QgdG8gdGhhd >>CBy >> >>ZXNvdXJjZQ0KDQrigKIgKiBiZjplZGl0aW9uIDogTUFSQyAyNTAkYSAgYmY6ZWRpdGlvblJlc >>3Bv >> >>bnNpYmlsaXR5IDI1MCRiIGJmOm90aGVyRWRpdGlvbiBNQVJDIDc3NS4gDQoNCglvIFRoZSBma >>XJz >> >>dCB0d28gZGVzY3JpYmUgdGhpcyBlZGl0aW9uLCB0aGUgb3RoZXJFZGl0aW9uIHBvaW50cyB0b >>yBh >> >>IGRpZmZlcmVudCByZXNvdXJjZToNCg0KCQlvIEJGIGVkaXRpb24gYW5kIHJlc3BvbnNpYmlsa >>XR5 >> >>OiA6IGh0dHA6Ly9iaWJmcmFtZS5vcmcvdG9vbHMvY29tcGFyZS9iaWJpZC83ODEwNDYxDQoJC >>W8g >> >>YmZvdGhlckVkaXRpb246IGh0dHA6Ly9iaWJmcmFtZS5vcmcvdG9vbHMvY29tcGFyZS9iaWJpZ >>C8x >> >>MTM0NjY4NQ0KDQpJ4oCZbGwgdHJ5IHRvIGFuc3dlciB0aGUgb3RoZXJzIHNlcGFyYXRlbHkuD >>QpU >> >>aGFua3MsIE5hdGUNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tL >>S0N >> >>Ck5hdGUgVHJhaWwNCkxTL1RFQ0gvTkRNU08NCkxBMzA4LCBNYWlsIFN0b3AgNDQwMg0KTGlic >>mFy >> >>eSBvZiBDb25ncmVzcw0KV2FzaGluZ3RvbiBEQyAyMDU0MA0KLS0tLS0tLS0tLS0tLS0tLS0tL >>S0t >> >>LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KRnJvbTogQmlibGlvZ3JhcGhpYyBGcmFtZXdvcmsgV >>HJh >> >>bnNpdGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWlsdG86QklCRlJBTUVATElTVFNFUlYuTE9DL >>kdP >> >>Vl0gT24gQmVoYWxmIE9mIFJvYmVydCBTYW5kZXJzb24NClNlbnQ6IFR1ZXNkYXksIFNlcHRlb >>WJl >> >>ciAxNiwgMjAxNCA0OjI1IFBNDQpUbzogQklCRlJBTUVATElTVFNFUlYuTE9DLkdPVg0KU3Via >>mVj >> >>dDogW0JJQkZSQU1FXSBTcGVjaWZpYyBRdWVzdGlvbnMNCg0KDQpTb21lIHNwZWNpZmljIHF1Z >>XN0 >> >>aW9uczoNCg0KLS0tIFJhbmdlL0RvbWFpbiAtLS0NCg0KKiBiZjpkaXNzZXJ0YXRpb25JbnN0a >>XR1 >> >>dGlvbiBoYXMgYSByYW5nZSBvZiBiZjpBZ2VudCwgbm90IGJmOkluc3RpdHV0aW9uLsKgIEFyZ >>SB0 >> >>aGVyZSByZWFsbHkgcGVvcGxlIHRoYXQgZ2l2ZSBvdXQgZGlzc2VydGF0aW9ucyAoYW5kIGhvd >>yBt >> >>dWNoIGRvIHRoZXkgY29zdD8gOkQpDQoNCiogYmY6ZWRpdGlvbiAoYW5kIGJmOmVkaXRpb25SZ >>XNw >> >>b25zaWJpbGl0eSwgd2hpY2ggbG9va3MgbGlrZSBhIE5vdGUpIGhhcyBhIGRvbWFpbiBvZiBJb >>nN0 >> >>YW5jZSwgYXMgZXhwZWN0ZWQgZnJvbSB0aGUgUHJvdmlkZXIgZGlzY3Vzc2lvbiB0aGF0IGRpZ >>mZl >> >>cmVudCBlZGl0aW9ucyAoYW5kIGhlbmNlIGRhdGVzKSBtdXN0IGJlIGRpZmZlcmVudCBJbnN0Y >>W5j >> >>ZXMuIEhvd2V2ZXIsIGJmOm90aGVyRWRpdGlvbiBoYXMgZG9tYWluIGFuZCByYW5nZSBvZiBiZ >>jpX >> >>b3JrLsKgIFRoaXMgc2VlbXMgbGlrZSBhIG1pc3Rha2U/DQoNCiogUmVsYXRlZGx5LCBiZjptd >>XNp >> >>Y1ZlcnNpb24gaGFzIGEgcmFuZ2Ugb2YgTGl0ZXJhbCBhbmQgbm8gZG9tYWluLiBUaGlzIHNlZ >>W1z >> >>IGxpa2UgaXQgc2hvdWxkIGJlIFdvcmsgb3IgSW5zdGFuY2U/DQoqIEFuZCBzaW1pbGFybHksI >>GJm >> >>OnRyZWF0eVNpZ25hdG9yIGhhcyBhIHJhbmdlIG9mIExpdGVyYWwgYW5kIG5vIGRvbWFpbi7Co >>CBT >> >>ZWVtcyBsaWtlIGl0IHNob3VsZCBiZSBhIHJhbmdlIG9mIGJmOlBlcnNvbj8NCg0KLS0tIE5vI >>FNl >> >>bWFudGljcyAtLS0NCg0KKiBiZjphZ2VudCBkb2Vzbid0IHNlZW0gdG8gc2F5IGFueXRoaW5nI >>GJl >> >>eW9uZCAiSGVyZSBpcyBhbiBhZ2VudCBzb21laG93IHJlbGF0ZWQgdG8gdGhpcyByZXNvdXJjZ >>SIs >> >>IGFuZCBoYXMgbm8gZG9tYWluLsKgIEFsc28sIGFmYWljdCwgaXQgaGFzIG5vIHN1Yi1wcm9wZ >>XJ0 >> >>aWVzLiDCoCBDYW4gYW55b25lIHNoZWQgc29tZSBsaWdodCBvbiB3aGF0IHRoZSBtZWFuaW5nI >>G9m >> >>IHRoZSByZWxhdGlvbnNoaXAgaXMsIGFuZCB0aHVzIHdoZW4gYSBwcm9kdWNlciB3b3VsZCBjc >>mVh >> >>dGUgaXQgYW5kIHdoYXQgYSBjb25zdW1lciB3b3VsZCBkbyB3aXRoIGl0Pw0KKiBiZjpldmVud >>CBp >> >>cyB0aGUgc2FtZSBhcyBiZjphZ2VudC4NCiogYmY6cGxhY2UgdXNlZCB0byBleGlzdCwgYnV0I >>G5v >> >>IGxvbmdlciAuLi4gc2hvdWxkIGFnZW50IGFuZCBldmVudCBhbHNvIGJlIGRlbGV0ZWQ/IMKgK >>HRl >> >>bXBvcmFsIGFuZCB0b3BpYyBuZXZlciBleGlzdGVkKQ0KDQoqIGJmOnJlbGF0ZWRJbnN0YW5jZ >>SBz >> >>ZWVtcyB0byBvbmx5IGhhdmUgdGhlIHNlbWFudGljcyBvZiByZWxhdGVkVG8sIGJ1dCB3aXRoI >>HNw >> >>ZWNpZmljIHJhbmdlIGFuZCBkb21haW4uwqAgV2h5IHdvdWxkIGEgY29uc3VtZXIvcHJvZHVjZ >>XIg >> >>dXNlIHRoaXMgaW5zdGVhZCBvZiByZWxhdGVkVG8/DQoqIERpdHRvIGJmOnJlbGF0ZWRXb3JrD >>QoN >> >>CiogYmY6bGVnYWxEYXRlIHNlZW1zIHRvIGhhdmUgdGhlIGRlc2NyaXB0aW9uIG9mIERhdGUgb >>2Yg >> >>YSB3b3JrIHRoYXQncyBsZWdhbCBpbiBuYXR1cmUsIG9yIHRoZSBkYXRlIGEgdHJlYXR5IHdhc >>yBz >> >>aWduZWQsIG9yIHRoZSBkYXRlIGEgbGF3IHdlbnQgaW50byBlZmZlY3QuIFRoaXMgc2VlbXMgc >>28g >> >>aW5kaXN0aW5jdCB0byB0aGUgcG9pbnQgb2YgYmVpbmcgd29ydGhsZXNzPw0KDQotLS0gSW5jb >>25z >> >>aXN0ZW5jeSAtLS0NCg0KKiBiZjpvcmlnaW5QbGFjZSwgYmY6b3JpZ2luRGF0ZSAuLi4gYnV0I >>GJm >> >>OlByb3ZpZGVyLCBhbmQgdGhlIHByZXZpb3VzIGRpc2N1c3Npb24gYWJvdXQgcHJvdmlkZXJOY >>W1l >> >>IGFuZCBwcm92aWRlckRhdGUuIMKgIFNvIHdoZW4gaXRzIGFuIEluc3RhbmNlLCB0aGUgZXZlb >>nQg >> >>Z2V0cyBpdHMgb3duIHJlc291cmNlLCBidXQgd2hlbiBpdHMgYSBXb3JrLCBpdCBkb2Vzbid0P >>w0K >> >>DQpUaGFua3MhDQoNClJvYg0KDQotLSANClJvYiBTYW5kZXJzb24NClRlY2hub2xvZ3kgQ29sb >>GFi >> >>b3JhdGlvbiBGYWNpbGl0YXRvcg0KRGlnaXRhbCBMaWJyYXJ5IFN5c3RlbXMgYW5kIFNlcnZpY >>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) >> ***************************************************************