Re: [Mak-developer] Call for Requests- Knowledge Association Layers

[Frank V. C. <fr...@co...>]

Ok, maybe I'm confused. I was under the impression that the toolset was
to model knowledge.

The ideas of "dimensions" are really just views based on some subjective
criteria that may or may not be relevant across the graph, in my mind
anyway.

For the nodes to represent knowledge means that there is some
ontological information (metamodel) which describes the relationships
(arcs) between nodes. 

Generic knowledge engineering involves the minimal concepts of
subsumption, where parent and child are implicit in the structure. The
relationships that are created within this structure are based on the
domain being modeled.

Another term from the generic world is roles. Roles capture the
relationship semantics (attributes) and there are rules which govern
those. For example:

(where A and C are implicitly subsumed by "Thing" or "Root")

concept C

concept D subsumed by C

concept A
	role SomeRole C

concept B subsumed by A
	SomeRole D

which shows that A defines the attribute SomeRole and is restricted to C
or that which C subsumes, making the filled (or assignment if you will)
statement of SomeRole D semantically valid because C subsumes D.

Roles can have cardinality restrictions [0, infinity], which can be
further specialized down the subsumption path. So:

concept C

concept D subsumed by C

concept E subsumed by C

concept A
	role SomeRole C

concept B subsumed by A
	SomeRole [0,2] {D,E} | {} | {D}

which specializes the cardinality to allow at most 2, but also the null
set and/or 1 filler.

Jared Rhine wrote:
> 
> [Citation date: Thu, 21 Dec 2000 07:28:20 -0500]
> 
> >>>>> Frank == Frank V Castellucci <fr...@co...>
> 
>     Frank> Is the "dimensional" view aspect akin to an orthogonal view
>     Frank> based on the "attribute" space?
> 
> Hmmm, somewhat, except that (to my knowledge in current
> implementations) dimensions are not automatically constructed, so
> any "attribute space" would need to be constructed manually, and
> there's no requirement that the results be structured in the same
> manner as would a slice through attribute space.
> 
>     Frank> concept Foo
>     Frank>      attribute A string; attribute B string;
> 
>     Frank> I can view it in terms of 'A' or 'B'?
> 
> You could construct dimensions which model this.  You could also have
> a dimension 'C' which matches none of the real attributes.
> 
>     Frank> or is it more
> 
>     Frank> concept Foo;
> 
>     Frank> concept Bar
>     Frank>      attribute HasFoo Foo;
> 
>     Frank> and view it in terms of HasFoo?
> 
> This latter structure is closer to the "tag/keyword" structure that I
> outlined as an another alternative to hierarchical structure.  I find
> this structure easier to implement and use than full-on dimensions.
> 
> -- ja...@wo...
> 
> "To live is to war with trolls." -- Ibsen
> 
> _______________________________________________
> Mak-developer mailing list
> Mak...@li...
> http://lists.sourceforge.net/mailman/listinfo/mak-developer

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package