Print

Print


??Hello!

I'm wondering if there are any further plans regarding the mapping of bib 700 name/title ($a + $t) fields in BibFrame 2? Since bf:Contribution is defined as "Agent and its role in relation to the resource.", it clearly excludes work entities.

It seems either there is a need for a new property/class combo, or a generalization of bf:Contribution to mean "Entity and its role in relation to the resource." (and thus defining and using a new bf:entity property instead of bf:agent here).

I'd also like a way of capturing the cases where i2=2 - i.e. the "added entry" is analytical (part of the resource). As with contribution in general, we need a qualified relation [1], so bf:hasPart doesn't suffice. One option would be to define a distinct qualified property/class combo (describing a qualified "composition", "constituent", "inclusion" or whatever domain experts deem distinct enough). Another, building on the possible generalization of bf:contribution, is to just define a subclass of bf:Contribution for this distinction.

Related to that, perhaps complicating matters more, I'd also like to discuss the relative merit of defining the difference of 100 and 700 similarly. While I gather the intent is to move away from this distinction in favour of concrete roles (and ideally no qualified relationships where direct links are possible), it might be good to establish a pattern for those of us to need to keep them (in our case, in order to smooth our cataloguing transition, and for our conversion of RDF back to MARC to work without strenuous effort (such as without inspecting the nature of applied roles in relation to the nature of the resource)). We have currently captured them as two subclasses of Contribution, currently labelled Principal and Additional, for lack of better wording.

I've have previously ("in anger", to invent nothing) mapped bib 700 to prov:qualifiedInfluence [2]. That is rather vague, but at least prov:Influence is an "entity to entity" relationship (i.e. it uses prov:entity for the object of the qualified relation). I also used prov:qualifiedAttribution [3] for bib 100 (since prov:Attribution is "entity to agent"). While that seems hard to justify as appropriate mappings, I still find them alluringly similar...

(Note by the way that I'm not discussing the application of qualified relations (versus direct links) in general at this time. We're in a swamp of MARC and need to take one step at a time. There are complications of qualified forms that merit discussion and mitigation strategies [4], but I'd like to keep that as a separate discussion.)

(For context: At KB (The National Library of Sweden) we are defining an in-house vocabulary, tailored for our new cataloguing system (used among other things as direct configuration for its cataloguing client). It contains various application-specific idiosyncrasies and missing pieces we haven't found in (e.g.) BibFrame. We have adapted it to BibFrame 2, and will, given time, publish more information and provide more feedback in the coming months.)

Cheers,
Niklas

[1]: http://patterns.dataincubator.org/book/qualified-relation.html
[2]: https://www.w3.org/TR/prov-o/#qualifiedInfluence
[3]: https://www.w3.org/TR/prov-o/#qualifiedAttribution
[4]: https://docs.google.com/presentation/d/19BudHqIHQ1AbQVS0fpDQsX17vwC7HuYGAQTj30ae35c/pub?start=false&loop=false&delayms=3000&slide=id.g58f994650_0_149

--
Niklas Lindström
Systems Developer
National Library of Sweden (KB)