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)
>> ***************************************************************
