Yes, you're right, it is a three-way association with 0-1 instances of
From a database perspective, repository-source is an associative table -
no primary key only foreign keys. So it would be useful for performing
queries on various combinations of the foreign keys.
I think the three ids (activity, repository, source) serve to identify a
specific search. In Activity/Search, activity-id is a primary key.
Each record defines one of three possible kinds of searches:
1- source without a known repository (search for a repository?)
2- repository without a particular source in mind (search for sources?)
3- a source known to exist in a specific repository (normal search)
On the other hand, repository-source is indexed by the three ids.
If a repository has several copies of a source, then a given search
in one of those copies, would require a separate repository-source
record to store the call number, etc. If you were interested in which
copies (call-numbers) of the source you had looked at in a repository,
a query of just those repository-source records which match
repository-id and source-id would give that info.
BTW, I'm a software engineer in the San Francisco bay area.
Genealogy is a side interest of mine. I have studied the gdm
spec and have an idea to represent it using UML. My background
is more in C++, OOP, and systems programming. XML is still
new to me.
Hans Fugal wrote:
>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>.
>>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
>>>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
>>> <citation-part citation-part-type="film">0049002</citation-part>
>>> <repository-source idref="fhl"/>
>>>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)
>>gdmxml mailing list
gdmxml mailing list