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