LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


[email protected]


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:

"[log in to unmask]" <[log in to unmask]>

Reply-To:

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

Date:

Wed, 17 Sep 2014 10:22:53 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (1420 lines)

One of the advantages of the kind of clear, coherent, understandable model for which folks are reaching with their critiques (I'm looking at you, Rob Sanderson {grin}) is the provision 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's often appropriate to record information that can only be understood by humans, but when that's happening because it's too difficult to do otherwise, that 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 keyword searching, but that you can't figure out how to encode in existing fields 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
> Sent: 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. bf:Language and Parts
> 
> ----------------------------------------------------------------------
> 
> Date:    Tue, 16 Sep 2014 06:32:32 +0000
> From:    Karen Coyle <[log in to unmask]>
> Subject: Re: 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 the MARC holdings record. That should suffice and there
> should be no need for a note field if the value is 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 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 think 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=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
> 
> S2FyZW4sDQoNClRoZSBmYXVsdCBpcyBub3QgaW4gb3VyIGNhdGFsb2dpbmcgY29kZSBidXQgaW4g
> b3Vyc2VsdmVzLiBSREEgdHJlYXRzIGZyZXF1ZW5jeSBhcyBhIGRpc3RpbmN0IGVsZW1lbnQgKDIu
> MTQpLCBhbmQgcmVxdWlyZXMgYSBub3RlIG9ubHkgd2hlbiBhbiBhcHByb3ByaWF0ZSB0ZXJtIGlz
> IHVuYXZhaWxhYmxlLiBUaGUgdGVybXMgYXQgUkRBIDIuMTQuMS4zIGNvcnJlc3BvbmQgdG8gdGhl
> IGNvZGVzIGF2YWlsYWJsZSBpbiB0aGUgTUFSQyBiaWJsaW9ncmFwaGljIGZvcm1hdCAoMDA4LzE4
> KSwgYW5kIGV2ZW4gbW9yZSBlbGFib3JhdGUgY29kZWQgZnJlcXVlbmN5IGRhdGEgY2FuIGJlIHN0
> b3JlZCBpbiB0aGUgTUFSQyBob2xkaW5ncyBmb3JtYXQuIFJhdGhlciwgdGhlIHByb2xpZmVyYXRp
> b24gb2Ygbm90ZXMgaXMgb2Z0ZW4gYSByZXN1bHQgb2YgaW1wbGVtZW50YXRpb24gZGVjaXNpb25z
> LCBhbmQgdGhlc2UgYXJlIG9mdGVuIGluZm9ybWVkIGJ5IHRoZSBwZXJjZWl2ZWQgY2FwYWJpbGl0
> aWVzIG9mIGV4aXN0aW5nIG1hY2hpbmUgc3lzdGVtcy4gRm9yIGV4YW1wbGUsIHRoZXJlIGlzIG5v
> IHJlYXNvbiB0aGF0IGNvZGVzIGNvdWxkIG5vdCBoYXZlIGJlZW4gZGV2ZWxvcGVkIGZvciB0aGUg
> cGxldGhvcmEgb2YgcmVsYXRpb25zaGlwIGRlc2lnbmF0b3JzIGluIFJEQSBhcHBlbmRpY2VzIEkt
> TCwgYnV0IGluc3RlYWQgd2Ugc3VwcGx5IHRoZSB0ZXJtcyB2ZXJiYXRpbSAoYW5kIGluIEVuZ2xp
> c2gpIGZyb20gUkRBLiBMaWtld2lzZSB3aXRoIHRoZSBjYXJyaWVyLCBtZWRpYSwgYW5kIGNvbnRl
> bnQgdHlwZXM7IGZvciB0aGUgZmlyc3QgdHdvLCBjb2RlZCBlcXVpdmFsZW50cyB3ZXJlIGFscmVh
> ZHkgaW4gZXhpc3RlbmNlIGZvciB0aGUgbW9zdCBwYXJ0LCBzbyB0aGUgdGV4dCByZWNvcmRlZCAo
> aW4gRW5nbGlzaCkgaW4gZmllbGRzIDMzNyBhbmQgMzM4IGlzIG9mdGVuIHJlZHVuZGFudCB3aXRo
> IGNvZGVkIHZhbHVlcyBhbHJlYWR5IHByZXNlbnQgaW4gMDA3LzAwLTAxLiBJLCBmb3Igb25lLCB3
> b3VsZCBiZSBoYXBweSB0byBzZWUgbm90ZXMgeWllbGQgdG8gY29kZWQgZGF0YSB3aGVuZXZlciBw
> b3NzaWJsZSwgaWYgb25seSB0byBzYXZlIGtleXN0cm9rZXMuDQoNCg0KRWQgSm9uZXMNCkFzc29j
> aWF0ZSBEaXJlY3RvciwgTGlicmFyeSBBc3Nlc3NtZW50IGFuZCBUZWNobmljYWwgU2VydmljZXMN
> Ck5hdGlvbmFsIFVuaXZlcnNpdHkgTGlicmFyeQ0KOTM5MyBMaWdodHdhdmUgQXZlbnVlDQpTYW4g
> RGllZ28sIENhbGlmb3JuaWHCoCA5MjEyMy0xNDQ3DQrCoA0KKzEgODU4IDU0MSA3OTIwICh2b2lj
> ZSkNCisxIDg1OCA1NDEgNzk5NyAoZmF4KQ0KDQpodHRwOi8vbmF0aW9uYWwuYWNhZGVtaWEuZWR1
> L0VkSm9uZXMNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQmli
> bGlvZ3JhcGhpYyBGcmFtZXdvcmsgVHJhbnNpdGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWlsdG86
> QklCRlJBTUVATElTVFNFUlYuTE9DLkdPVl0gT24gQmVoYWxmIE9mIEthcmVuIENveWxlDQpTZW50
> OiBNb25kYXksIFNlcHRlbWJlciAxNSwgMjAxNCAxMTozMyBQTQ0KVG86IEJJQkZSQU1FQExJU1RT
> RVJWLkxPQy5HT1YNClN1YmplY3Q6IFJlOiBbQklCRlJBTUVdIExpdGVyYWwgUHJvcGVydGllcyB2
> cyBOb3Rlcw0KDQpGcmVxdWVuY3kgaXMgYSBnb29kIGV4YW1wbGUgb2YgdGhlIG1lc3MgdGhhdCB3
> ZSBoYXZlIHRvZGF5IGluIEFBQ1ItdHlwZSBjYXRhbG9naW5nLiBUaGVyZSBpcyBhIHdheSB0byBj
> b2RlIGZyZXF1ZW5jeSBhcyBhIGNhbGN1bGFibGUgdmFsdWUgaW4gdGhlIE1BUkMgaG9sZGluZ3Mg
> cmVjb3JkLiBUaGF0IHNob3VsZCBzdWZmaWNlIGFuZCB0aGVyZSBzaG91bGQgYmUgbm8gbmVlZCBm
> b3IgYSBub3RlIGZpZWxkIGlmIHRoZSB2YWx1ZSBpcyBwcm92aWRlZC4gQnV0IG5vdGVzIGFyZSAi
> bm90ZXMiIGJlY2F1c2UgdGhleSBhcmUgdW5jb250cm9sbGVkIHN0cmluZ3MgY3JlYXRlZCBieSB0
> aGUgY2F0YWxvZ2VyLiBXaGVyZSBvdGhlciBkYXRhIGluIHRoZSByZWNvcmQgYXJlIGVpdGhlciB0
> cmFuc2NyaWJlZCBzdHJpbmdzIG9yIGNvbnRyb2xsZWQgaGVhZGluZ3MsIG5vdGVzIGFyZSBuZWl0
> aGVyLiBCdXQgdGhlIG5vdGVzIEFSRSByZXF1aXJlZCBieSB0aGUgY2F0YWxvZ2luZyBydWxlcy4N
> Cg0KVGhpcyBpcyBldmlkZW5jZSwgdG8gbWUsIG9mIHRoZSBnYXAgYmV0d2VlbiB0aGUgY2F0YWxv
> Z2luZyBydWxlcyBhbmQgdGhlIGFjdHVhbCBwcmFjdGljZSBvZiBjcmVhdGluZyBtYWNoaW5lLXJl
> YWRhYmxlIGNhdGFsb2cgcmVjb3Jkcy4gQUFDUiBkb2VzIG5vdCByZWNvZ25pemUgdGhhdCBjb2Rl
> ZCBkYXRhIChlLmcuIE1BUkMgZml4ZWQgZmllbGRzKSBleGlzdHMuICANCk1hbnkgbm90ZXMgcmVw
> ZWF0IGluZm9ybWF0aW9uIHRoYXQgY291bGQgYmUgZW5jb2RlZCBlbHNld2hlcmUsIGJ1dCBiZWNh
> dXNlIHRoZSBub3RlIGlzIHdoYXQgaXMgcmVxdWlyZWQgYnkgdGhlIGNhdGFsb2dpbmcgcnVsZXMg
> YW5kIGFsc28gZGlzcGxheXMgaW4gdGhlIGNhdGFsb2csIHRoZSB0ZW5kZW5jeSBoYXMgYmVlbiB0
> byBwcm92aWRlIHRoZSBub3RlIGJ1dCBvZnRlbiBub3QgdG8gcHJvdmlkZSB0aGUgYWN0aW9uYWJs
> ZSBkYXRhIGVsZW1lbnQuIE9idmlvdXNseSwgaXQgd291bGQgYmUgYSBtaXN0YWtlIHRvIGNhcnJ5
> IGZvcndhcmQgdGhpcyBwcmFjdGljZSwgYW5kIGluc3RlYWQgdGhlIGFjdGlvbmFibGUgZGF0YSBl
> bGVtZW50IG11c3QgYmUgdGhlIHByaW1hcnkgc291cmNlIG9mIGRhdGEsIGZyb20gd2hpY2ggdXNl
> ci1mcmllbmRseSBub3RlcyBjYW4gYmUgZGVyaXZlZCBpZiBuZWVkZWQuIFRoYXQgImlmIG5lZWRl
> ZCIgcGFydCBpcyBhbHNvIHNvbWV0aGluZyB3ZSBzaG91bGQgdGhpbmsgYWJvdXQsIGJlY2F1c2Ug
> aW4gZmFjdCBpbiBtYW55IHN5c3RlbSBkaXNwbGF5cyBub3RlcyBhcmUgbm90IGluY2x1ZGVkLCBz
> byBjYXRhbG9nIHVzZXJzIHJhcmVseSBzZWUgdGhlbS4gIA0KQmVjYXVzZSBub3RlcyBoYXZlIGJl
> ZW4gZmF2b3JlZCBvdmVyIGFjdGlvbmFibGUgZGF0YSwgdGhlcmUgaXMgYSB3aG9sZSBob3N0IG9m
> IGluZm9ybWF0aW9uIHRoYXQgaXMgMSkgbm90IHVzYWJsZSBmb3IgYW55IGF1dG9tYXRlZCBmdW5j
> dGlvbnMgYW5kIDIpIHJhcmVseSBzZWVuIGJ5IHVzZXJzLiBTdXJlbHkgdGhpcyBpcyBhIHdhc3Rl
> IG9mIGNhdGFsb2dlciB0aW1lLCBhbmQgYSBkaXNzZXJ2aWNlIHRvIG91ciB1c2Vycy4NCg0Ka2MN
> Cg0KUXVvdGluZyBUaW0gVGhvbXBzb24gPHRpbWF0aG9tQGdtYWlsLmNvbT46DQoNCj4gSGF2aW5n
> IGEgYmY6Tm90ZSBjbGFzcyBtYWtlcyBzZW5zZSB0byBtZS4gVGhlIGN1cnJlbnQgYXBwcm9hY2gg
> c2VlbXMgDQo+IGV4aGF1c3RpdmUgZW5vdWdoIHRvIGJlIGN1bWJlcnNvbWUsIGJ1dCBwcm9iYWJs
> eSBub3QgZXhoYXVzdGl2ZSBlbm91Z2ggDQo+IHRvIGNhcHR1cmUgdGhlIGZ1bGwgcmFuZ2Ugb2Yg
> cG9zc2liaWxpdGllcyBpbiB0aGUgc291cmNlIGRhdGEuIE5vdCBhbGwgDQo+IG5vdGVzIGNvbWUg
> ZnJvbSA1WFggZmllbGRzLiBIZXJlIGlzIGEgc2FtcGxlIG1hcmMyYmliZnJhbWUgY29udmVyc2lv
> biANCj4gb2YgYSByZWNvcmQgZm9yIGEgc2VyaWFsOg0KPg0KPiBNQVJDOiBodHRwOi8vYmliZnJh
> bWUub3JnL3Jlc291cmNlcy9KcWMxNDEwMzY1MTE1L21hcmN4bWwueG1sDQo+IEJGOiBodHRwOi8v
> YmliZnJhbWUub3JnL3Jlc291cmNlcy9KcWMxNDEwMzY1MTE1L2JpYmZyYW1lLnJkZg0KPg0KPiBI
> ZXJlLCBiZjpmcmVxdWVuY3lOb3RlIG1hcHMgdG8gdGhlIDMxMCBmaWVsZCAoQ3VycmVudCBQdWJs
> aWNhdGlvbiANCj4gRnJlcXVlbmN5KS4gVW5mb3J0dW5hdGVseSwgaXQgYWxzbyBtYXBzIHRvIHRo
> ZSAzMjEgZmllbGQgKEZvcm1lciANCj4gUHVibGljYXRpb24gRnJlcXVlbmN5KS4gVGhpcyB3b3Vs
> ZCBzZWVtIHRvIGJlIGEgbm90IGluc2lnbmlmaWNhbnQgbG9zcyANCj4gb2YgaW5mb3JtYXRpb24u
> IDVYWCBmaWVsZHMgdGhhdCBhcmUgZGlzdGluY3QgaW4gTUFSQyBhcmUgbWFwcGVkIHRvIA0KPiBn
> ZW5lcmljIGJmOm5vdGUgcHJvcGVydGllcyAoNTE1LCA1ODgpLiBiZjpmcmVxdWVuY3kgZG9lc24n
> dCBhcHBlYXIsIA0KPiBidXQgbWF5YmUgaXQgd2FzIG1lYW50IHRvIGNvcnJlc3BvbmQgdG8gdGhl
> IDAwOCBmaXggZmllbGQgZm9yIA0KPiBjb250aW51aW5nIHJlc291cmNlcywgd2hpY2ggYWxzbyBo
> YXMgYSB2YWx1ZSBmb3IgZnJlcXVlbmN5IChwb3NpdGlvbiANCj4gMTgpLiBUaGUgbmVlZCBmb3Ig
> dHdvIGRpc3RpbmN0IHByb3BlcnRpZXMgcmVtYWlucyB1bmNsZWFyLg0KPg0KPiBJbiBzaG9ydCwg
> YSBiZjpOb3RlIGNsYXNzIHdpdGggYmY6bm90ZVR5cGUgdmFsdWVzIG1pZ2h0IHByb3ZpZGUgDQo+
> IGdyZWF0ZXIgZmxleGliaWxpdHkgYW5kIHByZXNlcnZlIG1vcmUgb2YgdGhlIG9yaWdpbmFsIHNl
> bWFudGljcy4NCj4NCj4gVGltDQo+DQo+IC0tDQo+IFRpbSBBLiBUaG9tcHNvbg0KPiBNZXRhZGF0
> YSBMaWJyYXJpYW4gKFNwYW5pc2gvUG9ydHVndWVzZSBTcGVjaWFsdHkpIFByaW5jZXRvbiBVbml2
> ZXJzaXR5IA0KPiBMaWJyYXJ5DQo+DQo+DQo+IE9uIFR1ZSwgU2VwIDksIDIwMTQgYXQgNTozOCBQ
> TSwgUm9iZXJ0IFNhbmRlcnNvbiA8YXphcm90aDQyQGdtYWlsLmNvbT4NCj4gd3JvdGU6DQo+DQo+
> Pg0KPj4gWSdhbGwgcmVhZHkgZm9yIHRoaXM/IDspIFsxXQ0KPj4NCj4+IFdoZW4gaXMgYSBsaXRl
> cmFsIHByb3BlcnR5IGEgJ3NvbWV0aGluZ05vdGUnIGFuZCB3aGVuIGlzIGl0IGp1c3QgYSANCj4+
> ICdzb21ldGhpbmcnPw0KPj4NCj4+IEkgYXNzdW1lIChsYWNraW5nIHByZXZpb3VzbHkgbWVudGlv
> bmVkIE1BUkMgdG8gQmliRnJhbWUgbWFwcGluZyANCj4+IGRvY3VtZW50KSB0aGF0IGFsbCBvZiB0
> aGUgTm90ZXMgY29tZSBmcm9tIDVYWCBmaWVsZHMsIHdoaWNoIHNlZW1zIA0KPj4gbGlrZSBzb21l
> dGhpbmcgdGhhdCBjb3VsZCBlYXNpbHkgYmUgcmF0aW9uYWxpemVkIGFsb25nIHdpdGggc29tZSBv
> ZiANCj4+IHRoZSBvdGhlciBwcm9wZXJ0aWVzLCBhZ2FpbiBhc3N1bWluZyB0aGV5J3JlIG5vdCA1
> WFggYW5kIGhlbmNlIGRpZG4ndCBnZXQgdGhlIE5vdGUgbW9uaWtlci4NCj4+DQo+PiBGb3IgZXhh
> bXBsZSwgdGhlc2UgdHdvIGxvb2sgLi4uIHdlbGwgLi4uIGlkZW50aWNhbDoNCj4+DQo+PiBmcmVx
> dWVuY3k6IEludGVydmFscyBhdCB3aGljaCB0aGUgaXNzdWVzIG9yIHBhcnRzIG9mIGEgc2VyaWFs
> IG9yIHRoZSANCj4+IHVwZGF0ZXMgdG8gYW4gaW50ZWdyYXRpbmcgcmVzb3VyY2UgYXJlIGlzc3Vl
> ZC4NCj4+IGZyZXF1ZW5jeU5vdGU6IEN1cnJlbnQgb3IgZm9ybWVyIHB1YmxpY2F0aW9uIGZyZXF1
> ZW5jeSBvZiBhIHJlc291cmNlLg0KPj4NCj4+DQo+PiBDdXJyZW50IG5vdGVzIGFyZToNCj4+ICBj
> b3B5Tm90ZQ0KPj4gIGF3YXJkTm90ZQ0KPj4gIGNvbnRlbnRzTm90ZQ0KPj4gIGdyYXBoaWNTY2Fs
> ZU5vdGUNCj4+ICBpbGx1c3RyYXRpb25Ob3RlDQo+PiAgc3VwcGxlbWVudGFyeUNvbnRlbnROb3Rl
> DQo+PiAgZGlzc2VydGF0aW9uTm90ZQ0KPj4gIGdlb2dyYXBoaWNDb3ZlcmFnZU5vdGUNCj4+ICBs
> YW5ndWFnZU5vdGUNCj4+ICB0ZW1wb3JhbENvdmVyYWdlTm90ZQ0KPj4gIGNyZWRpdHNOb3RlDQo+
> PiAgcGVyZm9ybWVyTm90ZQ0KPj4gIGZyZXF1ZW5jeU5vdGUNCj4+ICBub3RlICghKQ0KPj4gIG11
> c2ljTWVkaXVtTm90ZQ0KPj4gIGZpbmRpbmdBaWROb3RlDQo+Pg0KPj4gQW5kIHRoZSBmb2xsb3dp
> bmcgc2VlbSBsaWtlIHRoZXkncmUgaW50ZW5kZWQgdG8gYmUgIm5vdGVzIiBpbiB0aGUgDQo+PiBt
> b3JlIGdlbmVyaWMgc2Vuc2Ugb2YgYWRkZWQgZGVzY3JpcHRpb24gYnkgYSBjYXRhbG9ndWVyIG9y
> IG90aGVyOg0KPj4NCj4+ICBmcmVxdWVuY3kNCj4+ICBjdXN0b2RpYWxIaXN0b3J5DQo+PiAgaW1t
> ZWRpYXRlQWNxdWlzaXRpb24NCj4+ICBub3RhdGlvbg0KPj4gIHJlc3BvbnNpYmlsaXR5U3RhdGVt
> ZW50DQo+PiAgcHJvdmlkZXJTdGF0ZW1lbnQgLS0gb3IgYXJlICJTdGF0ZW1lbnRzIiB0cmFuc2Ny
> aXB0aW9ucyBmcm9tIHRoZSANCj4+IEluc3RhbmNlPw0KPj4gIGVkaXRpb25SZXNwb25zaWJpbGl0
> eQ0KPj4gIGNvbnRlbnRBY2Nlc3NpYmlsaXR5ICAodGhvdWdoIGMuZi4gc2NoZW1hLm9yZy9hY2Nl
> c3NpYmlsaXR5RmVhdHVyZSkNCj4+DQo+PiBHaXZlbiB0aGUgZGlzY3Vzc2lvbiByZWdhcmRpbmcg
> YXNzaWduZXJzIG9mIFVSSXMgYmVpbmcgaW1wb3J0YW50LCBpdCANCj4+IHNlZW1zIHRoYXQgY3Jl
> YXRvcnMgb2Ygbm90ZXMgd291bGQgYmUgYWxzbyBpbXBvcnRhbnQ/ICBBbmQgdGh1cyBOb3RlcyAN
> Cj4+IGNvdWxkIGJlIHRoZWlyIG93biBjbGFzcywgYmY6Tm90ZSwgd2l0aCBwcm9wZXJ0aWVzIGlu
> Y2x1ZGluZyB2YWx1ZSwgDQo+PiBhc3NpZ25lciwgdHlwZSBhbmQgc28gZm9ydGguDQo+Pg0KPj4g
> Um9iDQo+Pg0KPj4gWzFdIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9YXZjUzBhWUoy
> YTggIFdhcm5pbmc6IHNlaXp1cmUgDQo+PiBpbmR1Y2luZyBmbGFzaGluZywgdGVycmlibGUgYW5p
> bWF0aW9uLCBwb3BweSA5MHMgbXVzaWMsIC4uLg0KPj4NCj4+IC0tDQo+PiBSb2IgU2FuZGVyc29u
> DQo+PiBUZWNobm9sb2d5IENvbGxhYm9yYXRpb24gRmFjaWxpdGF0b3INCj4+IERpZ2l0YWwgTGli
> 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/lang=
> 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
> 
> Um9iLCB0aGFua3MgZm9yIHRoaXMgZGV0YWlsZWQgbG9vay4gIEkgY2Fu4oCZdCBhbnN3ZXIgYWxs
> IG9mIHRoZW0gcXVpY2tseSwgYnV0IEkga25vdyBhIGZldyBvZmYgdGhlIHRvcCBvZiBteSBoZWFk
> Og0KDQrigKIgZGlzc2VydGF0aW9uSW5zdGl0dXRpb27igJlzIHJhbmdlIGlzIHByb2JhYmx5IGEg
> bWlzdGFrZS4NCg0K4oCiIG11c2ljVmVyc2lvbiAgYW5kIG90aGVyIHByb3BlcnRpZXMgd2l0aG91
> dCBhIGRvbWFpbjogd2UgYXJlIHVzdWFsbHkgdW5jZXJ0YWluICBvciBhZ25vc3RpYyBhcyB0byB3
> aGV0aGVyIGl0IGJlbG9uZ3Mgb24gV29yayBvciBJbnN0YW5jZSwgYXMgeW91IGd1ZXNzZWQsIGFu
> ZCBzbyB3ZSBsZWZ0IGl0IHVuY29uc3RyYWluZWQuIFdlIGRvbuKAmXQgcmVhbGx5IG1lYW4gdGhh
> dCBpdCBjb3VsZCBiZSBvbiBhbnkgQ2xhc3MsIGxpa2UgUGVyc29uLCBidXQgdGhhdOKAmXMgYSBz
> aWRlIGVmZmVjdCBvZiBsZWF2aW5nIHRoZSBkb21haW4gYmxhbmsuIA0KDQrigKIgSWRlYWxseSwg
> dHJlYXR5U2lnbmF0b3Igd291bGQgYmUgYSBiZjpQZXJzb24gb3IgcmVhbGx5IGEgZ292ZXJubWVu
> dCBib2R5LCBidXQgdGhlIGRhdGEgZnJvbSBNQVJDIGlzIGdvaW5nIHRvIGJlIHN0cmluZ3kuIFRo
> aXMgaXMgeWV0IGFub3RoZXIgZXhhbXBsZSB3aGVyZSBpZiB3ZSBoYWQgb3VyIGRydXRoZXJzLCB3
> ZeKAmWQgaGF2ZSBhIHN0cmluZyB2ZXJzaW9uIG9mIGEgcHJvcGVydHkgZm9yIGxlZ2FjeSBkYXRh
> LCBhbmQgYSB1cmkgdmVyc2lvbiBmb3IgYm9ybiBiZjogZGF0YS4NCg0K4oCiIGJmOmFnZW50IDog
> b2Z0ZW4sIHRoZXJlIGlzIGEgbmFtZSBsaXN0ZWQgaW4gdGhlIDd4eCBmaWVsZHMsIGJ1dCBubyBy
> ZWxhdGlvbnNoaXAgc3RhdGVkLCBub3IgdHlwZSBvZiBtYXRlcmlhbCwgc28geW91IGNhbuKAmXQg
> Z3Vlc3MgYXQgdGhlIHJvbGUgdGhlIHBlcnNvbiBwbGF5cyB3aXRoIHJlc3BlY3QgdG8gdGhhdCBy
> ZXNvdXJjZQ0KDQrigKIgKiBiZjplZGl0aW9uIDogTUFSQyAyNTAkYSAgYmY6ZWRpdGlvblJlc3Bv
> bnNpYmlsaXR5IDI1MCRiIGJmOm90aGVyRWRpdGlvbiBNQVJDIDc3NS4gDQoNCglvIFRoZSBmaXJz
> dCB0d28gZGVzY3JpYmUgdGhpcyBlZGl0aW9uLCB0aGUgb3RoZXJFZGl0aW9uIHBvaW50cyB0byBh
> IGRpZmZlcmVudCByZXNvdXJjZToNCg0KCQlvIEJGIGVkaXRpb24gYW5kIHJlc3BvbnNpYmlsaXR5
> OiA6IGh0dHA6Ly9iaWJmcmFtZS5vcmcvdG9vbHMvY29tcGFyZS9iaWJpZC83ODEwNDYxDQoJCW8g
> YmZvdGhlckVkaXRpb246IGh0dHA6Ly9iaWJmcmFtZS5vcmcvdG9vbHMvY29tcGFyZS9iaWJpZC8x
> MTM0NjY4NQ0KDQpJ4oCZbGwgdHJ5IHRvIGFuc3dlciB0aGUgb3RoZXJzIHNlcGFyYXRlbHkuDQpU
> aGFua3MsIE5hdGUNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
> Ck5hdGUgVHJhaWwNCkxTL1RFQ0gvTkRNU08NCkxBMzA4LCBNYWlsIFN0b3AgNDQwMg0KTGlicmFy
> eSBvZiBDb25ncmVzcw0KV2FzaGluZ3RvbiBEQyAyMDU0MA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
> LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KRnJvbTogQmlibGlvZ3JhcGhpYyBGcmFtZXdvcmsgVHJh
> bnNpdGlvbiBJbml0aWF0aXZlIEZvcnVtIFttYWlsdG86QklCRlJBTUVATElTVFNFUlYuTE9DLkdP
> Vl0gT24gQmVoYWxmIE9mIFJvYmVydCBTYW5kZXJzb24NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJl
> ciAxNiwgMjAxNCA0OjI1IFBNDQpUbzogQklCRlJBTUVATElTVFNFUlYuTE9DLkdPVg0KU3ViamVj
> dDogW0JJQkZSQU1FXSBTcGVjaWZpYyBRdWVzdGlvbnMNCg0KDQpTb21lIHNwZWNpZmljIHF1ZXN0
> aW9uczoNCg0KLS0tIFJhbmdlL0RvbWFpbiAtLS0NCg0KKiBiZjpkaXNzZXJ0YXRpb25JbnN0aXR1
> dGlvbiBoYXMgYSByYW5nZSBvZiBiZjpBZ2VudCwgbm90IGJmOkluc3RpdHV0aW9uLsKgIEFyZSB0
> aGVyZSByZWFsbHkgcGVvcGxlIHRoYXQgZ2l2ZSBvdXQgZGlzc2VydGF0aW9ucyAoYW5kIGhvdyBt
> dWNoIGRvIHRoZXkgY29zdD8gOkQpDQoNCiogYmY6ZWRpdGlvbiAoYW5kIGJmOmVkaXRpb25SZXNw
> b25zaWJpbGl0eSwgd2hpY2ggbG9va3MgbGlrZSBhIE5vdGUpIGhhcyBhIGRvbWFpbiBvZiBJbnN0
> YW5jZSwgYXMgZXhwZWN0ZWQgZnJvbSB0aGUgUHJvdmlkZXIgZGlzY3Vzc2lvbiB0aGF0IGRpZmZl
> cmVudCBlZGl0aW9ucyAoYW5kIGhlbmNlIGRhdGVzKSBtdXN0IGJlIGRpZmZlcmVudCBJbnN0YW5j
> ZXMuIEhvd2V2ZXIsIGJmOm90aGVyRWRpdGlvbiBoYXMgZG9tYWluIGFuZCByYW5nZSBvZiBiZjpX
> b3JrLsKgIFRoaXMgc2VlbXMgbGlrZSBhIG1pc3Rha2U/DQoNCiogUmVsYXRlZGx5LCBiZjptdXNp
> Y1ZlcnNpb24gaGFzIGEgcmFuZ2Ugb2YgTGl0ZXJhbCBhbmQgbm8gZG9tYWluLiBUaGlzIHNlZW1z
> IGxpa2UgaXQgc2hvdWxkIGJlIFdvcmsgb3IgSW5zdGFuY2U/DQoqIEFuZCBzaW1pbGFybHksIGJm
> OnRyZWF0eVNpZ25hdG9yIGhhcyBhIHJhbmdlIG9mIExpdGVyYWwgYW5kIG5vIGRvbWFpbi7CoCBT
> ZWVtcyBsaWtlIGl0IHNob3VsZCBiZSBhIHJhbmdlIG9mIGJmOlBlcnNvbj8NCg0KLS0tIE5vIFNl
> bWFudGljcyAtLS0NCg0KKiBiZjphZ2VudCBkb2Vzbid0IHNlZW0gdG8gc2F5IGFueXRoaW5nIGJl
> eW9uZCAiSGVyZSBpcyBhbiBhZ2VudCBzb21laG93IHJlbGF0ZWQgdG8gdGhpcyByZXNvdXJjZSIs
> IGFuZCBoYXMgbm8gZG9tYWluLsKgIEFsc28sIGFmYWljdCwgaXQgaGFzIG5vIHN1Yi1wcm9wZXJ0
> aWVzLiDCoCBDYW4gYW55b25lIHNoZWQgc29tZSBsaWdodCBvbiB3aGF0IHRoZSBtZWFuaW5nIG9m
> IHRoZSByZWxhdGlvbnNoaXAgaXMsIGFuZCB0aHVzIHdoZW4gYSBwcm9kdWNlciB3b3VsZCBjcmVh
> dGUgaXQgYW5kIHdoYXQgYSBjb25zdW1lciB3b3VsZCBkbyB3aXRoIGl0Pw0KKiBiZjpldmVudCBp
> cyB0aGUgc2FtZSBhcyBiZjphZ2VudC4NCiogYmY6cGxhY2UgdXNlZCB0byBleGlzdCwgYnV0IG5v
> IGxvbmdlciAuLi4gc2hvdWxkIGFnZW50IGFuZCBldmVudCBhbHNvIGJlIGRlbGV0ZWQ/IMKgKHRl
> bXBvcmFsIGFuZCB0b3BpYyBuZXZlciBleGlzdGVkKQ0KDQoqIGJmOnJlbGF0ZWRJbnN0YW5jZSBz
> ZWVtcyB0byBvbmx5IGhhdmUgdGhlIHNlbWFudGljcyBvZiByZWxhdGVkVG8sIGJ1dCB3aXRoIHNw
> ZWNpZmljIHJhbmdlIGFuZCBkb21haW4uwqAgV2h5IHdvdWxkIGEgY29uc3VtZXIvcHJvZHVjZXIg
> dXNlIHRoaXMgaW5zdGVhZCBvZiByZWxhdGVkVG8/DQoqIERpdHRvIGJmOnJlbGF0ZWRXb3JrDQoN
> CiogYmY6bGVnYWxEYXRlIHNlZW1zIHRvIGhhdmUgdGhlIGRlc2NyaXB0aW9uIG9mIERhdGUgb2Yg
> YSB3b3JrIHRoYXQncyBsZWdhbCBpbiBuYXR1cmUsIG9yIHRoZSBkYXRlIGEgdHJlYXR5IHdhcyBz
> aWduZWQsIG9yIHRoZSBkYXRlIGEgbGF3IHdlbnQgaW50byBlZmZlY3QuIFRoaXMgc2VlbXMgc28g
> aW5kaXN0aW5jdCB0byB0aGUgcG9pbnQgb2YgYmVpbmcgd29ydGhsZXNzPw0KDQotLS0gSW5jb25z
> aXN0ZW5jeSAtLS0NCg0KKiBiZjpvcmlnaW5QbGFjZSwgYmY6b3JpZ2luRGF0ZSAuLi4gYnV0IGJm
> OlByb3ZpZGVyLCBhbmQgdGhlIHByZXZpb3VzIGRpc2N1c3Npb24gYWJvdXQgcHJvdmlkZXJOYW1l
> IGFuZCBwcm92aWRlckRhdGUuIMKgIFNvIHdoZW4gaXRzIGFuIEluc3RhbmNlLCB0aGUgZXZlbnQg
> Z2V0cyBpdHMgb3duIHJlc291cmNlLCBidXQgd2hlbiBpdHMgYSBXb3JrLCBpdCBkb2Vzbid0Pw0K
> DQpUaGFua3MhDQoNClJvYg0KDQotLSANClJvYiBTYW5kZXJzb24NClRlY2hub2xvZ3kgQ29sbGFi
> b3JhdGlvbiBGYWNpbGl0YXRvcg0KRGlnaXRhbCBMaWJyYXJ5IFN5c3RlbXMgYW5kIFNlcnZpY2Vz
> 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

March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
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