Print

Print


Dear All,

Recording "Provider" information, such as who published, produced, 
manufactured, or distributed something, where that happened, and when, 
is presently modelled in such a way that a resource is devoted to this 
information.  An example:

<http://example.org/1> a bf:Instance,
     bf:publication [
         a bf:Provider ;
         bf:providerDate "1966" ;
         bf:providerName [ a bf:Organization ; bf:label "Hamlyn" ] ;
         bf:providerPlace [ a bf:Place ; bf:label "London" ]
     ] .

In the above, the resource employs a blank node, but it would not need 
to.  Regardless, this approach has a couple of significant problems:

1) Semantically, "providerDate" is unclear because it is actually 
supposed to convey the "publication date."  And the (publication) date, 
in fact, is an attribute of the Instance (the manifestation basically) 
and not the "Provider" resource. (And simply bf:provider would be better 
than bf:providerName, but that is a small point.)

2) It is not very reusable.  The above bf:Provider is only applicable to 
things published by Hamlyn in London in 1966.

We'd like to explore simplifying how this information is handled in 
bibframe by eliminating the bf:Provider resource altogether and creating 
12 properties, 3 each for publisher, manufacturer, distributor, and 
producer, all of which represent the major use cases as has long been 
expressible in MARC.  These properties would be associated directly with 
the Instance.  As an example, the above would become:

<http://example.org/1> a bf:Instance,
     bf:publishedBy [ a bf:Organization ; bf:label "Hamlyn" ] ;
     bf:publishedAt [ a bf:Place ; bf:label "London" ] ;
     bf:publishedOn "1966" .

You can imagine 3 each for manufactured*, distributed*, produced*.

This would clarify the semantics and do away with a resource that would 
probably often be identified via a blank node because it is reusable in 
only fairly specific circumstances.  (The above solution does not 
preclude being able determine all the things published by Hamlyn in 
London in 1966, if that is of specific interest.)

FYI: There has been no discussion whether bf:providerStatement would 
change in any way, and I see no reason for it to change (except, 
perhaps, to add publisherStatement, distributorStatement, etc. for 
clarity and parity purposes, versus the one catch-all 
providerStatement).  bf:providerStatement is really designed to address 
the transcription aspect expected in RDA whereas the proposed properties 
are designed to capture more structured data.  It's an undesirable 
duplication, but it is what it is.

Can anyone foresee issues with this approach?

Yours,
Kevin

--
Kevin Ford
Network Development and MARC Standards Office
Library of Congress
Washington, DC