From: Paul & Eleanor (goodhill_at_xmission.com)
Date: Tue Jan 30 2001 - 17:01:37 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id QAA08980 for cavexml-outgoing; Tue, 30 Jan 2001 16:58:04 +0100 Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA08976 for <cavexml_at_cartography.ch>; Tue, 30 Jan 2001 16:58:03 +0100 Received: from slc159.modem.xmission.com ([166.70.9.159] helo=xmission.com) by mail.xmission.com with esmtp (Exim 3.12 #1) id 14NdAi-000438-00 for cavexml_at_cartography.ch; Tue, 30 Jan 2001 08:58:20 -0700 Message-ID: <3A76E561.C0AC47A6@xmission.com> Date: Tue, 30 Jan 2001 09:01:37 -0700 From: Paul & Eleanor <goodhill_at_xmission.com> X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Groupings References: <3A704DAE.BE810444_at_earthlink.net> <002601c08787$a6b776f0$0a3c10ac_at_gordon> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Julian Todd wrote:
> Personally, I don't think these higher level groupings are anything more
> than a figment of our imaginations, but that's my own opinion. As
> long as I can get hold of all the distinct individual measurements I
> can feed them into one of those CAD Geometric Constraint solvers
> and get all the point locations out.
"As long as you can get hold of..." yes that is exactly the problem!
If you have a several mile system in front of you and you want to
load up some interesting part into some bit of software trick modeling
software
being able to find some logical 'chunk' of data is a very useful
operation.
Since another thread has suggested a tag for text, we can summarize as:
<text name=xxxx, date=yyyy, author=zzzz language=aaaaa>
let's build on that and run with another strawman construction.
What if we just had one way to group things, with a nice set of
attributes.
<ChunkOCaveData name=aaaaa, type=bbbb date=ccccc ...>
....
</ChunkOCaveData>
Okay pick a different name! <Group>?
Nest them all you want, as can be allowed in XML.
Questions:
What other hierarchical groupings are required to process data that
can not be integrated into this simple grouping technique? Is a survey
(a set of survey shots with the same name) any different than a
any other simple grouping.
For example, couldn't any discussion of default units, surveyors,
instruments,
etc. apply to the data lines/points etc. that are in the remaining
ChunkOData (ignoring any additional sub nestings).
In other words, prove to me some set of tags are actually semantically
important
otherwise and until then I'll keep thinking of just one hierarchy with
arbitrary
names and types. For example, someones example <subsurvey> tag seems
like a
tag that could easily be done with something more generic.
The above scheme would allow anyone to group anything they wanted:
survey, cave, system, room, underwater shots, surface survey, historic
survey. Literally you name, I don't care? Do I?
Does anyone need anything other than the ability to find all points
in a particular grouping?
I'd bet that there were important groupings which don't fit this scheme,
but I'd like to start from this 'typed and name group' idea and then
add only those tags that are imporant for proper
identification/processing
of the data and those that don't only provide a few searchable tags
to a logical group of data.
-Paul
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:54 CET