[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-ohs-talk] new version of graph model paper posted


Lee Iverson wrote:
>What is the query language though?    (01)

Won't NODAL have to have two separate layers of expression for a
query language as the node content and metadata nodes are separate?
Or am I being dim?    (02)

And, thinking aloud, if the NODAL nodes (= the metadata nodeset)
are a graph (not a tree) then isn't there a possible issue with
decidability in node
retrieval if a bifurcation (or n-furcation) has multiple endpoints of
the
same value wrt the query parameters?
Or has some genius out there already covered that one?    (03)

--
Peter    (04)

----- Original Message -----
From: "Lee Iverson" <leei@ece.ubc.ca>
To: "OHS Talk" <ba-ohs-talk@bootstrap.org>
Sent: Tuesday, April 16, 2002 11:01 PM
Subject: Re: [ba-ohs-talk] new version of graph model paper posted    (05)


> On Thu, 2002-04-11 at 00:02, Eugene Eric Kim wrote:
> >
> > The term that I settled on was "hyperdocument."  (Boy, that one was
just
> > staring at me in the face. :-)  I think the flaw with Groves and
NODAL as
> > a candidate data model for the OHS is that they are too
document-centric
> > -- NODAL less so than Groves.  They express a data model for a
document,
> > but depend on something external to relate data between documents.
> >
> > The point I try to get across in my paper is that there is no need
for
> > such a distinction, and in fact, there is much to gain by not
separating
> > the two.  A hyperdocument, as I express it, expresses data and their
> > relationships with each other.  Documents are simply two-dimensional
views
> > of a hyperdocument.
>
> Well, I'm kind of with Murray on this one.  I'm glad you've had your
> insight and seen the light on documents as views into the underlying
> data representation, but for me (and clearly some others), this is not
> a new insight.  NODAL is somewhat document-centric in that the type
> system is built around document schemas, but the actual data
repository
> is only really loosely connected to the documents involved.  There is
a
> "natural" and perhaps assumed mapping between a set of nodes and their
> "home" document, but these nodes can be arbitrarily reused in other
> documents and mixed and matched with other "compatible" types.
>
> The real difficulty in managing the relationship between a granular,
> reusable data repository and a set of encoded documents is expressing
> the subset of nodes that will form the document.  If there is some
> sort of DAG or tree descended from a root node, then this is easy and
> implicit.  It is the natural thought from someone with a passing
> familiarity with the DOM and even with the NODAL as defined in the
> White Paper, but it is certainly not the only possibility.  Ideally,
> we would be able to specify a nodeset as the result of some query and
> then use some document encoder to translate that result into a new
> document.  This would be how Doug's views would be expressed in NODAL.
> What is the query language though?  How do the encoders get expressed?
> There's some definite machinery to get from here to there.  But the
> the thoughts are relatively familiar.
>
> --
> ----------------------------------------------------------------------
---------
> Lee Iverson
> leei@ece.ubc.ca                Dept of ECE, 2356 Main Mall
> http://www.ai.sri.com/~leei/   Vancouver BC Canada V6T 1Z4
> Office: (604) 822-3381
>
>    (06)