Print

Print


Dear Niklas:

I am not sure whose “mapping” from MARC to BIBFRAME you’re talking about, but I can try to clarify the situation. bf:Contribution is used in the sense of a person or organization making a contribution, not a Work as contribution. And the 700 field can include only the person/organization making a contribution or, if there’s a $t, a reference to a work. In the case of the latter, where it has a $t it is considered a related resource, so would be another work with a person/organization who made the contribution and a title of the work. 

I am not sure what your needs are in terms of when ind2=2 and why hasPart doesn’t suffice. What is the difference between hasPart (defined as: Resource that is included either physically or logically in the described resource) and “constituent” (which is used in the field name of MARC 774 but defined in a similar way to hasPart) and “includes” (which is used in the definition of hasPart). In BIBFRAME there are more specific relationships hasSeries and isSeriesOf, which are subproperties of hasPart and isPartOf. Is there some other more specific relationship you have in mind?

As for 100 vs. 700, yes, we want to move beyond the concept of main entry and rely on roles to express the particular type of contribution that was made (it could be the case that one domain’s contribution is another domain’s creator).  One way you could retain the distinction is to use the role creator (http://id.loc.gov/vocabulary/relators/cre) or contributor (http://id.loc.gov/vocabulary/relators/ctb). 

Rebecca

Rebecca Squire Guenther
215 W. 75th St. Apt. 16H
New York, NY 10023
703-298-0157
[log in to unmask]
http://www.meetyourdata.com



On Jan 17, 2017, at 5:27 AM, Niklas Lindström <[log in to unmask]> wrote:

​​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 alsused 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


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