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

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


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.    (01)

On Wed, 20 Mar 2002, Eric Armstrong wrote:    (02)

> 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?    (03)

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.    (04)

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:    (05)

  http://www.eekim.com/ohs/papers/graphmodel/#nid077    (06)

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.    (07)

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.    (08)

> 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?    (09)

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.    (010)

> 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."    (011)

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.    (012)

-Eugene    (013)

-- 
+=== 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  ===========+    (014)