Re: Knowledge base project and tools

Hi,
Looking at net.java.dev.xama.model.Persistence am I right that the
representation in the DB is a string and that loadX and persistX always use
a Javascript engine, I assume to display results?

It seems a very tight coupling between a view and the data being handled?
And all values must be strings?

Maybe I have misunderstood? Please put me straight where I have.

But why not enhance the objects instances of the domain with definitions
along the lines you give, e.g. use RDF to do this?

Adam


On 2 October 2010 08:30, Sebastian Samaruga <sebastian.samaruga@yahoo.com.ar
> wrote:

> Hi,
>
> This posting is regarding to a project I've posted at dev.java.net (
> https://xama.dev.java.net) that is concerned about development of
> a Java infraestructure for Knowledge base/representation for use
> in real world applications. Following is the project description as
> stated in the readme file. Please take a look at:
>
> https://xama.dev.java.net
>
> And check the docs available at the SVN repo.
>
> Thanks!
>
> ---
>
> This project aims to be the foundation for a functional approach to
> 'Semantic' or 'Semiotic' data representation and storage by a basic
> 'model' package that offers a persistence facility that is to be
> leveraged by the other 'business' package in the intention of modeling
> the domain of affairs of an application. Then, there is the 'agent'
> package intending to provide an interaction stage for what should be
> a kind of view of the available behavior into the business domain and
> views/representation onto the underlying model data.
>
> This is a very early stage of development. Functional concepts on
> what should be regarded as identity and inmutable values are given
> and the mechanism to represent them as such is also available, given
> that the values conform to 'relations', called 'contexts' that provide
> known inter/relationships betwen values of different kinds, in order to
> represent their meanings.
>
> Given such a context, the values representing their instances are of
> the types conforming the context, that are in functional relationship
> between each other, according to it's meaning.
>
> This could be regarded as a Context being an aggregation of Types, that
> could be called 'Units' (in the measurement sense), and the Values, or
> instances of that 'Units' being anonymous 'Quantities'. Then, when a Name
> references them, the anonymous 'Quantity' starts to belong to an Entity
> that
> is only the identity of an Occurrence (three functionaly linked values)
> that
> also refers to the other Value(s).
>
> In other words, a Context (unit to measure) could be a Travel, its members
> (its Types) being: Distance, Speed, Time, having functional relationships
> between
> them (ie.: Time: Speed/Distance). And given three values corresponding to
> that
> functional mapping, an Occurrence, there could be a named instance, or an
> Entity,
> that refers to that particular Travel. Composition could occur also, given
> that the
> value (data) of a Value could be, for example, the Name of another
> Occurrence from
> other Context.
>
> The idea is that, given appropiate mapping definitions, the 'model' package
> could
> feed the 'business' package in populating domain entities and in providing
> inferred
> state and context behavior, following certain patterns that could occur in
> the
> underlying model data.
>
> Then an 'agent' layer could provide the *view* over that and facilitate the
> construction
> of interfaces over the domain and data, being them visual user interfaces
> or, for example,
> exposition of endpoints like a REST interface for the interactions and the
> comsumption/feed
> of representational data.
>
>
>