Add bf:provisionActivityStatement to BF target ontology file or create bib:statement and remove bf:responsibilityStatement from the BF target file

[sfolsom]

Currently we have bf:responsibilityStatement in the BF ontology target file, but not bf:provisionActivityStatement.

While working through the Activities pattern we thought that an activity statement could be asserted directly off the Activity, and since we no longer make the contribution/provision distinctions we could replace bf:responsibilityStatement and bf:provisionActivityStatement with a single bib:statement or bib:activityStatement.

But because the statement can involve more than one Agent and Activities are about a single agent, we decided the activity statement needs to be asserted off the Instance (similar domain of bf:responsibilityStatement and bf:provisionActivityStatement). Now, if we're asserting bib:statements directly on the Instance (and not a specific Activity) then we don't know whether the statement is about creative contributions or provision activities. Does this matter that with bib:statement we don't know the type of statement? Or is the distinction important enough to keep both bf:responsibilityStatement and bf:provisionActivityStatement?

Note: linking these statements to the Instance where the statement is found is important for disambiguating difference Instances of the same Work, which can be confusing because sometimes these statements are about the Work itself.

[sfolsom]

I vote add bf:provisionActivityStatement until we have more evidence that we can get by with lesser semantics of something link bib:activityStatement.

[rjyounes]

From the definition of responsibilityStatement it seems it could apply to either a Work or an Instance, if "creation" is interpreted broadly; however, BF has domain Instance. provisionActivityStatement is specific to Instances, both in terms of the domain specification and the definition.

[rjyounes]

@sfolsom I changed the name of this issue because I think it's what you mean. Please change back if I've misunderstood.

[sfolsom]

The data comes from an instance. It's transcribed to help identify the instance (regardless of whether is describing the work. It makes sense to me that the domain or "expected Domain" would be an Instance.

[eslao]

@rjyounes I agree that responsibilityStatement has the potential to be interpreted broadly, but I expect that it won't: the definition is centered on the word "content" and the phrase "statement of responsibility" means something really specific in the context of library metadata.

[rjyounes]

@sfolsom I strongly disagree! I think we should model the data according to what makes sense, not according to where the field comes from. And anyway, doesn't ALL the data come from the instance (i.e., the record), and is interpreted to apply to work/instance/item according to real world semantics?

@eslao I thought we always use "content" to refer to a work.

[eslao]

@rjyounes Yes, but, even if we didn't always, the definition of bf:responsibilityStatement would have to be changed to encompass "publication, printing, distribution, issue, release, production, etc. of a resource."

@rjyounes (following on what @sfolsom said) It's meant to capture something about the instance, as counterintuitive as it seems. The meaning of the statement might be about the creation of the content (work), but the specific way that it's expressed -- transcribed verbatim text of the statement -- is like a marker on a physical item (instance). It might not be a unique identifier, but it's used to aid in matching between a description of an instance and an item of an instance "in hand."

[sfolsom]

Yes, kind of like a "fingerprint" on the Instance, some text found on the instance to help tell if you're looking at the same instance as someone else might have already described.

[rjyounes]

Done