Thanks, John! Very interesting addition, which clarifies a few things.


lör 2007-08-04 klockan 00:13 -0400 skrev John Attig:
> But a publisher is ALSO a label that appears in a 
> particular form on a specific resource. 

I can see the need to describe the label itself.

BUT - and this is the important part - a Label is not the same thing as
a Publisher. If you see the label as a resource in its own right, it has
attributes that can e very different from the attributes a Publisher
might have:

Label:
  Publisher name
  Publisher address
  Font size
  color
  dimensions

Publisher:
  name
  address
  no of employees
  legal contact
  website
  owned by
  

Saying that these things are the SAME object makes no sense whatsoever
for me.

And this is again why the one-to-one principle comes into play - what is
it that RDA wants to describe? The label or the publisher or both?


>  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.

Well, I think the Publisher *is* an external entity, but that there is a
third entity that comes into play here, the Label...

And the fact that one label is closely tied to a single resource is
really just a constraint on the model (one-to-one relationship between a
label and a resource). It does not mean that DCAM cannot capture the
descriptions or that a hierarchical description is somehow more suited.

What I am hearing is that the label is an important resource itself -
and that fact should be recorded in RDA.

Maybe RDA needs a rda:publisher property that gives the actual
Publisher, and a separate rda:publisherlabel that presents the label.

/Mikael

> 
> 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
> 
-- 
<[log in to unmask]>

Plus ça change, plus c'est la même chose