Print

Print


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