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

Re: [ba-ohs-talk] rough draft of graph model paper

Cool. Thanks for the clarifications.
I look forward to the next version, which will undoubtedly head off
such confusions before they arise.
:__))    (01)

Eugene Eric Kim wrote:    (02)

> Thanks to all who commented on my paper.  I plan on incorporating much of
> that feedback into the next draft.  I'll try to comment quickly on a few
> specific comments.
> On Wed, 20 Mar 2002, Eric Armstrong wrote:
> > 3C  I wasn't totally clear whether a graph-based data modeling
> >        language was another approach of the 3B variety, or
> >        something different.
> >
> > 3C  I need some background on the concept of a "graph-based"
> >        data modeling language. What makes it different from
> >        other kinds of data modeling languages? What general
> >        advantages recommend that approach?
> Two good points.  The purpose of this paper is largely to explore
> graph-based data models for various collaborative apps.  I tried to be
> generic about it as possible.
> I'm not explicitly proposing a new graph-based data modeling language, but
> I did want to make several points.  First, as I stated at:
>   http://www.eekim.com/ohs/papers/graphmodel/#nid077
> these pictures could easily be expressed as ER diagrams.  That's because
> that's really what they are.  However, the system that implements these
> diagrams have explicit constructs that correspond to each element in these
> ER diagrams.  That is not the case when implementing an ER diagram in a
> relational or an object schema.
> Second, my suspicion is that the system needs to support the notion of a
> typed link internally within the system.  Neither Groves or NODAL
> currently do this.  You could make the argument that they don't need to,
> that NODAL+RDF would give me what I want.  But what's the purpose of
> having both?  RDF alone should be just as competent at modeling documents
> as NODAL or Groves -- once you get past the ugly syntax, that is.
> > 3D8 Hmm. We're talking about knowledge containers here, but
> >         they appear to contain everything that is in Figure 1.
> >         It must be a way of slicing things up, but how?
> >         Figure 2 goes on to give a concrete example, but still
> >         doesn't tell me about knowledge containers. Maybe it
> >         is too early to introduce this concept?
> Probably too late, actually.  I used the term "knowledge container"
> loosely, and I know I shouldn't.  A document is a knowledge container, but
> a paragraph within a document is also a knowledge container.  So knowledge
> containers can contain other knowledge containers.  A node is a knowledge
> container, and a set of nodes is also a knowledge container.
> > 4B  Hmm. I really got lost, it seems. This says  RDF could
> >       be used to model knowledge containers, as described
> >       above. I felt edified by what I saw above, but somehow
> >       I never knew when we were talking about "knowledge
> >       containers."
> The point of this paragraph is that RDF can be used to model all kinds of
> data, not just machine-readable semantics.  I can use RDF to model this
> e-mail, for instance.
> -Eugene
> --
> +=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+
> |       "Writer's block is a fancy term made up by whiners so they        |
> +=====  can have an excuse to drink alcohol."  --Steve Martin  ===========+    (03)