Hi Karen,

Is that one Instance with two publishers working together? Or is it two
Instances, each with one publisher?
The latter is clearly not a problem, so I guess it's the former?

To try and break it down further... is this correct:

In the lifecycle of the Work, there was an Instance published.
There were agents involved in that publication event were University of
Chicago Press and Gauther-Villars.
University of Chicago Press is in Chicago.
Gauther-Villars is in Paris.
The event occurred in 1955.

And thus we would need something like:

[ a bf:Instance
  bf:publicationEvent [ a bf:Event
    bf:agent [ a bf:Organization ; bf:label "University of Chicago Press" ;
bf:place [ bf:label "Chicago" ] ]
    bf:agent [ a bf:Organization ; bf:label "Gauther-Villars ; bf:place [
bf:label "Paris" ] ]
    bf:date "1955"^xsd:date


On Thu, Jul 31, 2014 at 11:04 AM, Karen Coyle <[log in to unmask]> wrote:

>  Kevin,
> Removing these layers between the subject and the description would
> simplify use of the data, IMO. In particular, anyplace where one can NOT
> use a blank node there is a gain in ease of use.
> Unfortunately, this is possible input from the AACRs and RDA:
>   *260* *##**$a*Paris :*$b*Gauthier-Villars ;*$a*Chicago :*$b*University
> of Chicago Press,*$c*1955.
> e.g. Paris : Gauthier-Villars; Chicago : University of Chicago Press, 1955.
> That could logically be expressed as two separate publication statements
> (I assume the current display form harks back to limited space on cards):
> Paris : Gauthier-Villars, 1955.
> Chicago : University of Chicago Press, 1955.
> As simple triples, though, there is nothing to retain the connection
> between the individual places and the publishers since there is no order
> inherent between triples.
> x bf:publisher "Gauther-Villars" .
> x bf:publisher "University of Chicago Press" .
> x bf:date "1955" .
> x bf:pubPlace "Chicago" .
> x bf:pubPlace "Paris" .
> (NB: this is not the only place in our data that repetition of data
> elements and the reliance on the order of elements creates difficulties.
> That is another reason to do some re-thinking of our data in light of new
> technologies.)
> We struggled with this when developing the RDF for RDA, and I don't think
> that there is (yet) a solution that works well in practice. RDA retains the
> concept of "publisher statement" that is conceived of as a single
> multi-part description. Thus, in RDF the RDA "publisher statement" would be
> a node with place, publisher and date. The complex statement above could be
> two different nodes and that would solve the issue of connecting places and
> publishers (while relying on UI developers to provide the traditional
> display), but means creating a publisher node like the one BIBFRAME has
> today. Assigning those nodes identifiers doesn't really make them
> re-usable, though, as you point out.
> Given that BIBFRAME has a property for the display form of the "publisher
> statement," it may come down to a question of purpose: apart from display,
> what do we anticipate doing with places and providers, and do those
> functions (e.g. search, linking to maps, creating timelines) require us to
> maintain the proper place/provider relationship when there is more than one?
> My 2 cents is that this is one of those areas where separating display
> from data could have some practical advantages. Your solution provides
> both.
> kc
> p.s. This gives me additional respect for the document + data method,
> which relies on the document for structure and display, and still surfaces
> useful data. See how WorldCat does this with -
> On 7/31/14, 9:50 AM, Ford, Kevin wrote:
> 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:
> <> <> 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:
> <> <> 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
> --
> Karen [log in to unmask]
> m: 1-510-435-8234
> skype: kcoylenet

Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305