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? <hans/> * Stan Mitchell [Tue, 9 Jul 2002 at 10:35 -0700] <quote> > 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 > [EMAIL PROTECTED] > http://fugal.net/cgi-bin/mailman/listinfo/gdmxml </quote> -- "Everybody is talking about the weather but nobody does anything about it." -- Mark Twain _______________________________________________ gdmxml mailing list [EMAIL PROTECTED] http://fugal.net/cgi-bin/mailman/listinfo/gdmxml
