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)