Search instances of a class a la Google
export the generated application; need to package a JavaScript launcher + the RDF database.
update RDF database after user change: keep same features as :update, but do it as much as possible with rule techniques
RDF database: CRUD(maybe JRDF), queries, read-write N3
update RDF database after user change: primitive type, objects, lists
Manage downward inheritance (property type has subclasses)
Lists: Properties of cardinality>1; Add/Remove buttons; show as a table; for both ObjectProperty and DatatypeProperty.
: 1. follow object properties; 2. follow subclassOf , then rdf:type
Search instances of a class a la Google
Link a Property value to a known ("isting"ID
update RDF database after user change: keep same features as :update, but do it as much as possible with rule techniques
fill GUI from RDF database: primitive types, objects, lists
RDF database: simple queries by subject and object are not efficient
Manage upward inheritance (property type has superclasses)
java.beans.PropertyEditor for File, URL, Date (useful for EulerGUI)
Migrate to sf.net namespace, ... what else?
Simple infrastructure to record user actions; undo-redo (necessary for good servant features)
abstract GUI components: neutral convergence model covering Swing, SWT, Qt, HTML, etc (necessary for multiple back ends; need to rework the current JavaScript+Java instanciation code, maybe use Drools, as this is second order logic plus default processing)
N3 architecture to encapsulate a software component, in the spirit of "telligent modularity" generate N3 model from java source for interfaces, need to specify protocol a la UML, plus implement helpers generating glue code to plugin callers and callees; examples of encapsulated components: RDF API, GUI displaying time events
Pave the way for deployment platforms: PHP, Ajax, RCP, eclipse, firefox, GWT, Ajax, OpenOffice, Mono(.Net), etc; what more do I need to do beside :abstract_components, :language_writers and :encapsulate ?
language writers: at least need to have instanciators for languages Java, PHP, Python; possibly C#, ruby, Perl, C, C++; need to modelize notions like instanciationn, XML (for HTML and PHP) , etc
language readers: at least need to have parsers for languages Java, PHP, Python; possibly C#, ruby, Perl, C, C++.
export the generated application; need to package a JavaScript launcher + the RDF database.
input connectors for domain (business) models : RDFS, UML, XMI, Pojo; for SQL RDBToOnto can be used, but it needs to connect to the database
relational DBMS, XML DBMS, Sesame, OWLIM, eXist, ...
unlike :storage_connectors that uses a virgin data store for persistence, we want here to reproduce Hibernate features to re-use an existing relational DBMS or other storage to store data modeled by the current application's model
Atempto, WordNet, Link-Grammar, Gate, ...
using Language Natural technologies, communicate between programs (or human to machine) without prior protocol
automate feature and implementation search, and glue code generation, to facilitate connection of software components and application building
each action of the user must be recorded to deduce his intentions, and to propose suitable actions
provide extension points à la eclipse into the generated application, e.g. if one want to add action buttons in a context of a property, like the GRAPH and REMOVE buttons of EulerGUI; to achive this generate java source for interfaces from N3 model cf http://jmvanel.free.fr/computer-notes_2008.html#Challenges .
Deduction runtime: storage add non-monotonic predicates for CReate, Update, Delete, e.g. :currentModel ded:retract ( ?SUBJECT ?PREDICATE ?OBJECT ). use cases: transform object graph; replace edited class before relaunching form builder
GUI accepts drop of N3 or RDF MIME types
GUI rules for behavior: exploit model and data: functional properties, cardinalities, inheritance, owl:differentFrom, constraints (solve to infer values), propagate edits or not (money Xfer between accounts), has few values
graph view (following user past actions, lens), ZIP paradigm
offer pre-canned queries and reports, e.g. distinguish "scribed"lasses and and "clared"lasses; gather nodes up to a given depth; having a rule base , or a fact base , infer the classes and properties
offer pre-canned transforms: UML-->OWL, RDFS-->OWL, OWL --> HTML, RDF-->HTML, UML-->OWL,
generic and specific HTML report from one N3 or project
specifiy in N3 pipes between inference engines; a pipe has input and output (can be File, non-File URL, or pipe), possibly input and output models; implement the piping chain; simple use case: convert an RDFS model into OWL, and then pipe the standard Déduction GUI generator.
apply rules to the rules :) To translate N3 rules into Drools rules, an implementation in N3 will output a result in an N3 vocabulary which reproduces the Drools language accurately, then the final translation in character string will be simple. The steps will be the same to translate N3 into Java, etc, except that there it is simpler, because one considers only facts here.
JavaScript, Java (or other language) can be put in special N3 predicate to be executed. Also called action rules; much like exception rules (implemented in Drools translation). To do something meaningful, this code needs to have access to API ( like RDF CRUD API ) and data like RDF Id's passed from the logic rules.
GUI events are passed to the logic rules engines, so that callbacks can be implemented by logic rules.
""". #ENDS 56 msec