LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  September 2014

BIBFRAME September 2014

Subject:

Re: Literal Properties vs Notes

From:

"Murray, Ronald" <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Tue, 23 Sep 2014 15:29:38 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (2184 lines)

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&#39;s a choice between subclasses of bf:Note, and
>>sub-properti=
>> es of bf:hasNote ... and I&#39;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&#39;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">&lt;<a =
>> href=3D"mailto:[log in to unmask]"
>>target=3D"_blank">[log in to unmask]</a>=
>> &gt;</span> wrote:<br><blockquote class=3D"gmail_quote"
>>style=3D"margin:0 0=
>> 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;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 &quot;readability&quot; 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 &lt;<a
>>href=3D"mailto:timathom@G=
>> MAIL.COM">[log in to unmask]</a>&gt; wrote:<br>
>> <br>
>> &gt; 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>
>> &gt;<br>
>> &gt; 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>
>> &gt; 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>
>> &gt;<br>
>> &gt; 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&#39;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>
>> &gt;<br>
>> &gt; In short, a bf:Note class with bf:noteType values might provide
>>greate=
>> r flexibility and preserve more of the original semantics.<br>
>> &gt;<br>
>> &gt; Tim<br>
>> &gt;<br>
>> &gt; --<br>
>> &gt; Tim A. Thompson<br>
>> &gt; Metadata Librarian (Spanish/Portuguese Specialty)<br>
>> &gt; Princeton University Library<br>
>> &gt;<br>
>> &gt;<br>
>> &gt; On Tue, Sep 9, 2014 at 5:38 PM, Robert Sanderson &lt;<a
>>href=3D"mailto=
>> :[log in to unmask]">[log in to unmask]</a>&gt; wrote:<br>
>> &gt;<br>
>> &gt; Y&#39;all ready for this? ;) [1]<br>
>> &gt;<br>
>> &gt; When is a literal property a &#39;somethingNote&#39; and when is
>>it ju=
>> st a &#39;something&#39;?<br>
>> &gt;<br>
>> &gt; 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&#39;re not 5XX and hence didn&#39;t get the Note
>>monike=
>> r.<br>
>> &gt;<br>
>> &gt; For example, these two look ... well ... identical:<br>
>> &gt;<br>
>> &gt; frequency: Intervals at which the issues or parts of a serial or
>>the u=
>> pdates to an integrating resource are issued.<br>
>> &gt; frequencyNote: Current or former publication frequency of a
>>resource.<=
>> br>
>> &gt;<br>
>> &gt;<br>
>> &gt; Current notes are:<br>
>> &gt;=C2=A0 =C2=A0copyNote<br>
>> &gt;=C2=A0 =C2=A0awardNote<br>
>> &gt;=C2=A0 =C2=A0contentsNote<br>
>> &gt;=C2=A0 =C2=A0graphicScaleNote<br>
>> &gt;=C2=A0 =C2=A0illustrationNote<br>
>> &gt;=C2=A0 =C2=A0supplementaryContentNote<br>
>> &gt;=C2=A0 =C2=A0dissertationNote<br>
>> &gt;=C2=A0 =C2=A0geographicCoverageNote<br>
>> &gt;=C2=A0 =C2=A0languageNote<br>
>> &gt;=C2=A0 =C2=A0temporalCoverageNote<br>
>> &gt;=C2=A0 =C2=A0creditsNote<br>
>> &gt;=C2=A0 =C2=A0performerNote<br>
>> &gt;=C2=A0 =C2=A0frequencyNote<br>
>> &gt;=C2=A0 =C2=A0note (!)<br>
>> &gt;=C2=A0 =C2=A0musicMediumNote<br>
>> &gt;=C2=A0 =C2=A0findingAidNote<br>
>> &gt;<br>
>> &gt; And the following seem like they&#39;re intended to be
>>&quot;notes&quo=
>> t; in the more generic sense of added description by a cataloguer or
>>other:=
>> <br>
>> &gt;<br>
>> &gt;=C2=A0 =C2=A0frequency<br>
>> &gt;=C2=A0 =C2=A0custodialHistory<br>
>> &gt;=C2=A0 =C2=A0immediateAcquisition<br>
>> &gt;=C2=A0 =C2=A0notation<br>
>> &gt;=C2=A0 =C2=A0responsibilityStatement<br>
>> &gt;=C2=A0 =C2=A0providerStatement -- or are &quot;Statements&quot;
>>transcr=
>> iptions from the Instance?<br>
>> &gt;=C2=A0 =C2=A0editionResponsibility<br>
>> &gt;=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>
>> &gt;<br>
>> &gt; 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>
>> &gt;<br>
>> &gt; Rob<br>
>> &gt;<br>
>> &gt; [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>
>> &gt;<br>
>> &gt; --<br>
>> &gt; Rob Sanderson<br>
>> &gt; Technology Collaboration Facilitator<br>
>> &gt; Digital Library Systems and Services<br>
>> &gt; Stanford, CA 94305<br>
>> &gt;<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&#39;t seem to say anything beyond &quot;Here is an agent
>>somehow=
>> related to this resource&quot;, 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=
>> &#39;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&#39;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&#39;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&#39;re willing to wipe this
>>part o=
>> f the ontology clean ... all we&#39;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">&lt;<a href=3D"mailto:[log in to unmask]"
>>target=3D"_bl=
>> ank">[log in to unmask]</a>&gt;</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&#39;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&#39;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&#39;t seem to say anything beyond &quot;Here is an
>>agent s=
>> omehow related to this resource&quot;, 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&#39;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&#39;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">&lt;<a
>>href=3D"mailto:[log in to unmask]" t=
>> arget=3D"_blank">[log in to unmask]</a>&gt;</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&#39;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 &quot;edition-ness&quot; 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 &amp; =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>&lt;<a href=3D"http://www.minitex.umn.edu/"
>>targ=
>> et=3D"_blank">http://www.minitex.umn.edu/</a>&gt;<br><br>=C2=A0
>>&quot;Exper=
>> ience is by industry achieved // And perfected by<br>the swift course
>>of ti=
>> me.&quot; -- Shakespeare, &quot;Two Gentlemen<br></span></div><span
>>style=
>> =3D"font-family:courier new,monospace">of Verona,&quot; 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)
>> ***************************************************************

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager