I have to say that I agree with Mikael--a 
publisher is really an organizational entity with 
a specific role, and we deny that at our peril. 
Looking at the problem from a few steps back, 
then, you have an entity with a place attribute, 
a name (that may change as it merges with others) 
and perhaps an ISBN stub (or whatever you'd call 
it).  The date that we associate with the 
publication information is, of course, about the 
resource, not the publisher--yet another reason 
to keep this all straight.

If I recall correctly the aggregation of this 
particular information comes from ISBD, and 
certainly, when we go to map out to ISBD (or 
MARC), it can seem in its familiar relationship, 
without us having to carry it all with us forever.

Diane

>fre 2007-08-03 klockan 11:09 -0700 skrev Karen Coyle:
>>  Pete Johnston wrote:
>>
>>  >
>>  > This "one-to-many" (or indeed "many-to-many", as the same person may be
>>  > the creator of many books) case _is_ covered in the DCAM description
>>  > model, and exactly that example is used in the DCAM document. ;-) It is
>>  > implemented through the notion (described in section 2.4 of [1] that:
>>
>>  Pete, thanks. This makes sense to me, and I'll work to absorb it in
>>  greater detail.
>>
>>  Many of the "structures" in the RDA table parallel the structures we
>>  have today in the MARC record, with the publisher field being an obvious
>>  one. I suspect that we librarians have so thoroughly ingested the MARC
>>  record that we have trouble seeing any other ordering of the data. We
>>  have to get beyond that, but it'll take some mind expansion. That's what
>>  you are providing.
>
>I think this is a very interesting observation - I think this point is
>worth considering a bit more.
>
>RDA is not the first standard to evolve from an encoding towards a more
>abstract framework. IEEE LOM is another one, where much of the standard
>comes from an abstraction of an original XML syntax.
>
>The trouble with this, as you have noted, is that the thinking tends to
>be constrained to this original syntax so that any abstract model
>evolved from this tends to be pretty muddled when it comes to semantics.
>
>Regarding RDA, I stand by one of my arguments at the London meeting -
>the best way to get rid of the MARC baggage and arrive at a semantically
>clear model is to separate descriptions of separate resources.
>
>This is one version of the one-to-one principle, and it's really
>fundamental to both the RDF model and DCAM.
>
>For these documents, it would mean identifying all the resources that
>occur in an RDA "record", namely the "library resource", creators, etc
>etc. and then describing them separately.
>
>Going the sub-element path is risky, as we have seen, as the semantics
>of sub-elements is unclear, and might even vary from case to case!
>
>Case-to-case is really the antithesis to machine-processability, so if
>we can avoid that....
>
>Apart from that addition, I agree with all that Pete said.
>
>/Mikael
>
>>
>>  kc
>>
>--
><[log in to unmask]>
>
>Plus ça change, plus c'est la même chose