From: Peter MATTHEWS (matthews_at_melbpc.org.au)
Date: Thu Jul 18 2002 - 09:44:22 CEST
Return-Path: <owner-cavexml-outgoing_at_ethz.ch> Delivered-To: cavexml-archive_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 1546815912 for <cavexml-outgoing_at_ethz.ch>; Thu, 18 Jul 2002 10:00:29 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id E1D2915902; Thu, 18 Jul 2002 10:00:26 +0200 (CEST) Delivered-To: cavexml-loopcheck_at_ethz.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id DB59815912 for <cavexml-loopcheck_at_ethz.ch>; Thu, 18 Jul 2002 10:00:25 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id B7EAF158BD; Thu, 18 Jul 2002 10:00:23 +0200 (CEST) Delivered-To: cavexml_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 7176715912 for <cavexml_at_cartography.ch>; Thu, 18 Jul 2002 10:00:23 +0200 (CEST) Received: from koala.melbpc.org.au (koala.melbpc.org.au [203.12.152.23]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id F216E14AAB for <cavexml_at_cartography.ch>; Thu, 18 Jul 2002 10:00:19 +0200 (CEST) Received: from localhost.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by koala.melbpc.org.au (8.12.3/8.11.6) with ESMTP id g6I7htwq023061 for <cavexml_at_cartography.ch>; Thu, 18 Jul 2002 17:43:55 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Thu, 18 Jul 2002 17:44:22 +1000 From: Peter MATTHEWS <matthews_at_melbpc.org.au> In-Reply-To: <20020710223309.D28CB7EA9_at_karmail.ethz.ch> Message-Id: <5.1.0.14.1.20020717170732.01d58d00@popa.melbpc.org.au> Received: from koala.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by localhost.melbpc.org.au (AvMailGate-2.0.0.6) id 23042-658FB13F; Thu, 18 Jul 2002 17:43:43 +1000 Received: from peter.melbpc.org.au (a2-79.melbpc.org.au [203.12.157.79]) by koala.melbpc.org.au (8.12.3/8.11.6) with ESMTP id g6I7heut023039 for <cavexml_at_cartography.ch>; Thu, 18 Jul 2002 17:43:41 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) Subject: Re: Comments on the data model To: cavexml_at_cartography.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-Sender: matthews_at_popa.melbpc.org.au X-Loop: cavexml Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
At 18:27 10-07-02 -0400, Richard Knapp wrote:
[snip]
>Under Branch, there is a field of Node type however, Node is an Element not
>an attribute.
The fields shown under Branch are actually called "node names", i.e. the
names of the Nodes which terminate/define each end of the Branch. These
names are therefore properties of the Branch.
>The diagram shows a many-to-many relationship. How is this going to work?
To be honest, as a "beginner" XML person I am not sure of the details. Can
anyone else give an XML example? However, if two real-world things actually
are related many-many, then XML needs to be able to handle it, somehow.
Like with databases, I suspect you would just show or record one direction
at a time, depending on what was the context of the file/document you were
creating.
For example, taking the case of say the two entities, People and
Organisations, which have a many-many relationship: one Person can belong
to many Organisations, and one Organisation can have many People as
members. In the db world this is normally handled by introducing a new
entity between the other two and thereby splitting the link into two
"one-many" relationships, each of which can be handled easily. In the
example, the intermediate entity would be the concept, "Member", and the
two links would become: one Person could have many memberships, and one
Organisation could have many Members. In this example this new entity would
also have its own fields/properties, i.e. for any given Member record you
would have fields such as [membership start date], [membership type],
[latest date paid], etc, etc, i.e. fields which describe only the
membership concept itself. And on a Person screen you could show a list of
the Orgs they were members of (one-many), or alternatively on an Org screen
you could show a list of the Org's members (the other one-many), i.e. one
direction at a time.
I have not introduced any of these possible intermediate entities into the
diagram at this stage, but have left it just with the many-many links,
because at this point we just need to be considering the conceptual data
model, not any actual implementation method. As we work further through the
task list we may or may not decide we need to introduce further entities.
>I was trying to put the diagram into DTD form but there are some
>connections missing. For example, Branch's position in the hierarchy
>is ambiguous (to me). How do you fit Branch under the root node of
>CaveSystem? Or is it Cave? Or Project? Or will the structure be more
>like:
>
><CaveXML>
> <Cave>
> </Cave>
> <Project>
> </Project>
></CaveXML>
>
>?
[snip]
In the diagram, I have shown [cavesystem] as the top of the hierarchy -
[caves] are within [cavesystem], and [projects] are within [cavesystem].
There are many more relationships existing between the entities than I have
shown on the diagram. If you had a hierarchy with say 4 levels, then
obviously there is a relationship between the lowest item and the highest
item, as well as with the next level up. And so on with all the levels. But
if you put them all in, it makes it all too unnecessarily complicated. So
in the diagram I tried to put in only the immediate relationships, together
with any which could not be derived simply by following back up the chain.
The idea I had here is really just to put in enough links to enable us to
understand the overall structure of the data items in a cave survey, and
what is part of what, so that we can then confidently determine all the
fields needed and where to put them.
Peter
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:00 CEST