But a publisher is ALSO a label that appears in a
particular form on a specific resource. In fact,
in the context of resource identification, this
is perhaps its most important function. The
publisher is NOT (or at least not exclusively)
an external entity that can be related to many
bibliographic resources; it is an attribute of one particular resource.
Yes, the aggregation of publication,
distribution, etc., information comes from ISBD,
but the basic reason for the aggregation is not
its source in any particular standard, but the
important relationships that exist between these
aggregated elements -- and between individual
instances of the elements (in other words,
between an instance of the place of publication
and an instance of the name of the publisher, for
example). These are important relationships that
exist in the bibliographic world we are trying to
represent in our metadata, and the structure of
our metadata needs to be able to represent these
relationships. While I can accept that a
hierarchical structure may not be the only (or
most appropriate) way to do this, the need remains.
John Attig
ALA representative to the JSC
At 04:38 PM 8/3/2007, Diane I. Hillmann wrote:
>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
|