- From: Sebastian Samaruga <sebastian.samaruga@yahoo.com.ar>
- Date: Sat, 2 Oct 2010 00:30:36 -0700 (PDT)
- To: semantic-web@w3.org
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-1677973341-1286004636=:10454 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi,<br><br>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<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>https://xama.dev.java.net<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></table><br> --0-1677973341-1286004636=:10454--
Received on Monday, 4 October 2010 06:48:19 UTC