Re: Knowledge base project and tools

Adam,

It's not just plain strings what I'm persisting, it's JSON documents.

The objects in this 'model' layer (maybe it should be called metamodel) are=
 persisted to a Document (NoSQL) database called CouchDB. There is a precon=
dition for running the examples that is the database instance running and t=
he databases for specific kinds of objects created (more on that on the REA=
DME file).

Then, it cames that one can store any kind of attribute or property within =
an object instance.

For this metamodel instance I regard of three kinds of objects, types, valu=
es of them and names of the values, that are aggregated according to contex=
t, occurrences and entities. Being such three arrangements declared in a pr=
ogramatic fashion.

They give the foundations of 'meanings' between object instances.

Then, Persistence handles the task of putting and getting back the document=
s in the store.

There is also a 'triple-like' view of the statements that you will find in =
Persistence.listStatements that gaves a representation of the ontology buil=
t up that should be interoperable with RDF and its triples.

The idea with persistence is that one could search or lookup using listStat=
ements, or the index, provided with the framework via Apache Solr and then =
populate objects from DB to work with.

Actually the loadXXX and persistXXX methods are just for the default fields=
 (ID, Revision &/ DocRevision, this last one used for historical records).

There left to be done to persist specific instance data, as type for a valu=
e, etc. in the database documents, and to implement the view in the databas=
e to provide the listStatements desired behavior.

I'll keep you updated if you want when I have a more realized solution. But=
, fundamentally, this specific layer has the tight-coupling you describe be=
cause is the lower one in the persistence for this framework (consider it a=
s JDBC is for ORM).

Conceptual modelling was what i was more concerned about, so maybe some inc=
ompleteness is confusing.

--- El mar 5-oct-10, adasal <adam.saltiel@gmail.com> escribió:

De: adasal <adam.saltiel@gmail.com>
Asunto: Re: Knowledge base project and tools
Para: "Sebastian Samaruga" <sebastian.samaruga@yahoo.com.ar>
Cc: semantic-web@w3.org
Fecha: martes, 5 de octubre de 2010, 9:25

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.







       




      
--0-1021283872-1286320444=:50327
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Adam,<br><br>It's not just plain strings what I'm persisting, it's JSON documents.<br><br>The objects in this 'model' layer (maybe it should be called metamodel) are persisted to a Document (NoSQL) database called CouchDB. There is a precondition for running the examples that is the database instance running and the databases for specific kinds of objects created (more on that on the README file).<br><br>Then, it cames that one can store any kind of attribute or property within an object instance.<br><br>For this metamodel instance I regard of three kinds of objects, types, values of them and names of the values, that are aggregated according to context, occurrences and entities. Being such three arrangements declared in a programatic fashion.<br><br>They give the foundations of 'meanings' between object instances.<br><br>Then, Persistence handles the task of
 putting and getting back the documents in the store.<br><br>There is also a 'triple-like' view of the statements that you will find in Persistence.listStatements that gaves a representation of the ontology built up that should be interoperable with RDF and its triples.<br><br>The idea with persistence is that one could search or lookup using listStatements, or the index, provided with the framework via Apache Solr and then populate objects from DB to work with.<br><br>Actually the loadXXX and persistXXX methods are just for the default fields (ID, Revision &amp;/ DocRevision, this last one used for historical records).<br><br>There left to be done to persist specific instance data, as type for a value, etc. in the database documents, and to implement the view in the database to provide the listStatements desired behavior.<br><br>I'll keep you updated if you want when I have a more realized solution. But, fundamentally, this specific layer has the
 tight-coupling you describe because is the lower one in the persistence for this framework (consider it as JDBC is for ORM).<br><br>Conceptual modelling was what i was more concerned about, so maybe some incompleteness is confusing.<br><br>--- El <b>mar 5-oct-10, adasal <i>&lt;adam.saltiel@gmail.com&gt;</i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>De: adasal &lt;adam.saltiel@gmail.com&gt;<br>Asunto: Re: Knowledge base project and tools<br>Para: "Sebastian Samaruga" &lt;sebastian.samaruga@yahoo.com.ar&gt;<br>Cc: semantic-web@w3.org<br>Fecha: martes, 5 de octubre de 2010, 9:25<br><br><div id="yiv1768300881">Hi,<br>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?<br><br>It seems a very tight coupling between a view and the data being
 handled?<br>
And all values must be strings?<br><br>Maybe I have misunderstood? Please put me straight where I have.<br><br>But why not enhance the objects instances of the domain with definitions along the lines you give, e.g. use RDF to do this?<br>
<br>Adam<br><br><br><div class="yiv1768300881gmail_quote">On 2 October 2010 08:30, Sebastian Samaruga <span dir="ltr">&lt;<a rel="nofollow" ymailto="mailto:sebastian.samaruga@yahoo.com.ar" target="_blank" href="/mc/compose?to=sebastian.samaruga@yahoo.com..ar">sebastian.samaruga@yahoo.com.ar</a>&gt;</span> wrote:<br><blockquote class="yiv1768300881gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<table border="0" cellpadding="0" cellspacing="0"><tbody><tr><td style="font-family: inherit; font-style: inherit; font-variant: inherit; font-weight: inherit; font-size: inherit; line-height: inherit; font-size-adjust: inherit; font-stretch: inherit; -x-system-font: none;" valign="top">Hi,<br><br>This posting is regarding to a project I've posted at <a rel="nofollow" target="_blank" href="http://dev.java.net">dev.java.net</a> (<a rel="nofollow" target="_blank" href="https://xama.dev.java.net">https://xama.dev.java.net</a>) that is concerned about development of<br>
a Java infraestructure for Knowledge base/representation for use<br>in real world applications. Following is the project description as<br>stated in the readme file. Please take a look at:<br><br><a rel="nofollow" target="_blank" href="https://xama.dev.java.net">https://xama.dev.java.net</a><br>
<br>And check the docs available at the SVN repo.<br><br>Thanks!<br><br>---<br><br>This project aims to be the foundation for a functional approach to<br>'Semantic' or 'Semiotic' data representation and storage by a basic<br>
'model' package that offers a persistence facility that is to be<br>leveraged by the other 'business' package in the intention of modeling <br>the domain of affairs of an application. Then, there is the 'agent'<br>
package intending to provide an interaction stage for what
 should be<br>a kind of view of the available behavior into the business domain and<br>views/representation onto the underlying model data.<br><br>This is a very early stage of development. Functional concepts on<br>what should be regarded as identity and inmutable values are given<br>
and the mechanism to represent them as such is also available, given<br>that the values conform to 'relations', called 'contexts' that provide<br>known inter/relationships betwen values of different kinds, in order to<br>
represent their meanings.<br><br>Given such a context, the values representing their instances are of<br>the types conforming the context, that are in functional relationship<br>between each other, according to it's meaning.<br>
<br>This could be regarded as a Context being an aggregation of Types, that<br>could be called 'Units' (in the measurement sense), and the Values, or<br>instances of that 'Units' being anonymous 'Quantities'. Then, when a
 Name<br>references them, the anonymous 'Quantity' starts to belong to an Entity that<br>is only the identity of an Occurrence (three functionaly linked values) that<br>also refers to the other Value(s).<br><br>In other words, a Context (unit to measure) could be a Travel, its members<br>
(its Types) being: Distance, Speed, Time, having functional relationships between<br>them (ie.: Time: Speed/Distance). And given three values corresponding to that<br>functional mapping, an Occurrence, there could be a named instance, or an Entity,<br>
that refers to that particular Travel. Composition could occur also, given that the<br>value (data) of a Value could be, for example, the Name of another Occurrence from<br>other Context.<br><br>The idea is that, given appropiate mapping definitions, the 'model' package could<br>
feed the 'business' package in populating domain entities and in providing inferred<br>state and context behavior, following certain patterns that
 could occur in the<br>underlying model data.<br><br>Then an 'agent' layer could provide the *view* over that and facilitate the construction<br>of interfaces over the domain and data, being them visual user interfaces or, for example,<br>
exposition of endpoints like a REST interface for the interactions and the comsumption/feed<br>of representational data.<br><br></td></tr></tbody></table><br>




      &nbsp;</blockquote></div><br>
</div></blockquote></td></tr></table><br>




      &nbsp;
--0-1021283872-1286320444=:50327--

Received on Wednesday, 6 October 2010 16:13:15 UTC