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

[<wil...@gm...>]

The idea of KAL (Knowledge Association Layers) is really just how to make
views on knowledge, but it must be compatible with the hasTo or isA
philosophy, for which it may be useful to define a Default Layer.

Some ideas about the zigzag structure:
Perhaps I'm wrong, and my point of view is just a result of ignorance (I
just read the introduction with the samples on the structure), but I think
the gzigzag approach is much too inflexible and complicated, for the
following reasons,

inflexible: you can only show two dimensions (merge two views) at a time (if
you are a very creative gui programmer, you might have three dimensions, but
I think this is really a hard work to understand as well (I had once the
experience in my course neuro-physiological-basics of the human mind))

complicated: handling dimensions is always a complicate task for the human
brain, swapping dimensions is real work. Swapping knowledge along three
dimensions, I don't want to explain it to the pointy haired manager :)

The third aspect, I'd like to give is, that it seems to be exact the same
difference between C++ and Java:
C++ has multiple roots, which are all user defined, like zigzag where you
have multiple dimensions which are all purely user defined.
Java you have a single rooted hierarchy, which starts with Object, so if
you're calling toString, or you are getting Objects from a Vector you don't
need to know nothing about them. This is comparable to the default layer
(that arose from the previous mails), where there is handled the basic two
relations, isA hasA. If you find a new knowledge-base you can assume the
semantic of the default layer, without any knowledge (about views), that the
user additionally added.

	Thank you for comments
	Richard



-----Ursprüngliche Nachricht-----
Von: mak...@li...
[mailto:mak...@li...]Im Auftrag von Frank
V. Castellucci
Gesendet: Freitag, 22. Dezember 2000 06:11
Cc: mak...@li...
Betreff: Re: [Mak-developer] Call for Requests- Knowledge Association
Layers


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

_______________________________________________
Mak-developer mailing list
Mak...@li...
http://lists.sourceforge.net/mailman/listinfo/mak-developer