hmm, that's an interesting perpsective. This made me look closer at
repository-source, and I am a little muddy now...

It looks like repository-source ties 0 or 1 repositories to 0 or 1
sources to 0 or 1 activities (searches).  It seems to me that this opens
the door for data redundancy - there could be (and I think would be)
many searches in one repository/source combination. But with
repository-source as it is we have to duplicate not only the repository
and source ids, but also the call-number and description.  I don't see
why search has repository-id and source-id and repository-source has
activity-id. Why not take activity-id out of repository-source, leaving
it only to link repositories and sources, and take out the
repository-id and source-id from search? What am I missing - why did the
Lexicon Group do it this way?


* Stan Mitchell [Tue,  9 Jul 2002 at 10:35 -0700]
> A few thoughts on repository-source ...
> IMHO & from an OO point-of-view, repository-source seems to be a
> separate class. It represents the association between no or one instance
> of source and no or one instance of repository, with the constraint that
> there be at least one source or one repository. When a search succeeds,
> then a source and repository are tied together, and information such as
> call-number and description of the condition of the particular source,
> are stored in the repository-source instance.
> Another way of looking at it, is as the link between the Administration
> and Evidence submodels, but with perhaps a closer link to Admin.
> Maybe <repository-source> could be a child of <search>.
> Stan Mitchell
> Hans Fugal wrote:
> >One repository exists in one place, so it seems natural to make
> >repository a child element of place. I've also made place-part a child
> >of place for the same reason.  
> >
> >The GDM calls for a sequence number on each place-part of a place, and
> >an ordering scheme of the place-parts of a place. With XML order matters
> >(unless we say it doesn't) so I see no need for a sequence number; it is
> >implied.
> >
> >On those many-to-many relationships: repository-source isn't as clean
> >cut in my mind as source-group-source was, and now I'm not as clear
> >about that either.  For one thing, the naming becomes hairy. Naturally
> >we don't want to make source a child element of repository, because a
> >source could exist in more than one repository; the other way around
> >is even more ludicrous.  So, we need to reference the sources in the
> >repository or reference the repositories in the sources. So I think 
> >perhaps:
> >
> > <source id="film0049002">
> >   <citation-part citation-part-type="film">0049002</citation-part>
> >   <repository-source idref="fhl"/>
> > </source>
> >
> >That name, "repository-source", makes perfect sense in database context,
> >but I think it's confusing in this context, where it is a child element
> >of the source element. Perhaps "repository-ref".  
> >
> >Maybe we can even allow a repository-source element from either a source
> >element or a repository element - that may be harder to deal with in
> >implementation though, and there is no way to avoid the possibilitiy of
> >duplicates.  So my question for anyone who has an opinion is which is
> >better: to put it in one of the elements (i.e. a source element has a
> >repository-ref child element), or to have a separate (non-child)
> >repository-source element?
> >
> ><hans/>
> >
> > 
> >
> _______________________________________________
> gdmxml mailing list

"Everybody is talking about the weather but nobody does anything about it."
        -- Mark Twain

gdmxml mailing list

Reply via email to