<p>What I have come with so far is a kind of Semantic ORM for Java with a very simple embrionary REST MVC CRUD. Trying to figure out where to go from here now.</p>
<p>The universality/model granularity problem I think could be solved using model 'ResourceProviders' running in parallel into the same engine, each one listening others events and providing their views of the domain knowledge they handle and so providing their 'augmenting' resources between them.</p>
<p>Having no needs to use a universal model by means of declaring providers and their plug time configuration, ie. mappings, the common metamodel are the triples being held by each profile.</p>
<p>As an example, one such providers could augment a patient records data application with, for example, DBPedia data regarding the application form being shown (ie. Disease) using the MVC infraestructure.</p>
<p>This may be seen as a very dummy example but this is my first attempt to build knowledge applications and being able to solve this kind of features is a great achievement for myself.</p>
<p>Regards,<br>
Sebastian.</p>
<div class="gmail_quote">On Aug 28, 2012 8:07 AM, "Sebastian S." <<a href="mailto:cognescent@gmail.com">cognescent@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Think I'm going into better relationships with models, metamodels and their representations. Or so it seems so. There is another attempt commited in the repo, and counting...</p>
<p>What I'm fighting on now with is to being able to have a kind of upper level ontology with temporal semantics and expressive enough to provide means of understanding instances of, for example, a doctor as a merchant, a patient as a customer of that merchant and a diagnose as a service transaction, using consumer/provider and others as super concepts in common but not stating the correlation explicitly.</p>
<p>That could allow the integration with existing platforms as it was commented.</p>
<p>The issue of models and their representations being parts of purposeful flows is intended to be regarded as very important, implementing the ability to render an agent 'mental model' in an interaction on a given context and with model exchange via dialogs using prompts as callbacks to the user. For this search for: DCI (design pattern).</p>
<p>Regards,<br>
Sebastian.</p>
<div class="gmail_quote">On Aug 27, 2012 9:02 AM, "Paola Di Maio" <<a href="mailto:paola.dimaio@gmail.com" target="_blank">paola.dimaio@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Not sure if the 'universal plug' can be a useful metaphor<br>
<br>
many standards, and one plug design to fit them all<br>
<br>
a common device that claims to fit every electricity plug in the universe<br>
<br>
let us know what ye come up with<br>
<br>
:-)<br>
<br>
P<br>
On Mon, Aug 27, 2012 at 9:34 AM, Sebastian S. <<a href="mailto:cognescent@gmail.com" target="_blank">cognescent@gmail.com</a>> wrote:<br>
> Paola,<br>
><br>
> I've been thinking that the universality issue is not as a problem but more<br>
> much as a model of model, layers and model representation matter.<br>
><br>
> For example, representations can handle different models at different layers<br>
> and those models having many levels or specificity.<br>
><br>
> So the design now should be narrowing now into o set of representations for<br>
> leveles of models of profiles which speak in a universal way about concrete<br>
> domains, interleaving views as appropriate by interpretation of layered<br>
> representations of those models.<br>
><br>
> I'll be trying to be more concise about this while I develop this further.<br>
> Then this will became rendered into the project docs and sources.<br>
><br>
> Regards.<br>
> Sebastian.<br>
><br>
> On Aug 24, 2012 10:23 AM, "Paola Di Maio" <<a href="mailto:paola.dimaio@gmail.com" target="_blank">paola.dimaio@gmail.com</a>> wrote:<br>
>><br>
>> Sebastian<br>
>><br>
>> apologies for late reply, but was playing in other threads<br>
>><br>
>> i do agree that narrowing the focus does indeed help feasibility<br>
>> of task at hand<br>
>> however just a very quick <chime> for universality<br>
>><br>
>> I design general intelligence systems,<br>
>> universality can be achieved by autodetection of schema properties<br>
>><br>
>> (like taking a dump of a schema and generating the code for the map)<br>
>><br>
>><br>
>> any schema (detect structure of schema) to<br>
>> any other schema (configure to structure...)<br>
>><br>
>> however I design, not code so<br>
>> if you or someone interested in exploring universality from the ground<br>
>> up I think it can be done<br>
>><br>
>> cheers<br>
>><br>
>> PDM<br>
>><br>
>><br>
>> On Thu, Aug 23, 2012 at 1:56 AM, Sebastian S. <<a href="mailto:cognescent@gmail.com" target="_blank">cognescent@gmail.com</a>><br>
>> wrote:<br>
>> > [The PragmaticWeb Research List]<br>
>> > Hi,<br>
>> ><br>
>> > I've been reading all of the comments and I'm taking note of all of them<br>
>> > because they all seem very valuable to me. I'm verry thankful really.<br>
>> ><br>
>> > I agree in that there is some kind of solitaire fashion that one feels<br>
>> > like when coming to this at first. And I also think that maybe I seem a<br>
>> > little 'universal' in the needs/features I would like to implement and<br>
>> > address too. And also that it would seem very unrealistic to come 'from the<br>
>> > ground up' with a tool that addresses everything.<br>
>> ><br>
>> > So, I'm trying to narrow a little the scope and try to reflect this into<br>
>> > an updated document. It only adds a section named 'Application Model' in<br>
>> > respect to the first but if I'm making my point there, a general purpose<br>
>> > tool can be thought as a layer that is useful when someone tells it what to<br>
>> > do (quite like a traditional RDBMS or framework or programming language).<br>
>> > So, its it could be understood that there be models narrowing this<br>
>> > 'universality' but without losing the benefits of a layer of semantics for<br>
>> > future integration, merging and maybe interoperability of 'semantic<br>
>> > application instances'.<br>
>> ><br>
>> > <a href="https://cognescent.googlecode.com/files/Brochure2.pdf" target="_blank">https://cognescent.googlecode.com/files/Brochure2.pdf</a><br>
>> ><br>
>> > I also would like to implement this in Java, so I'm describing the<br>
>> > initial layout of packages and their functionalities into the Google Code<br>
>> > hosted project repository, in a document named 'packages.txt':<br>
>> ><br>
>> ><br>
>> > <a href="https://code.google.com/p/cognescent/source/browse/trunk/Cognescent/src/packages.txt" target="_blank">https://code.google.com/p/cognescent/source/browse/trunk/Cognescent/src/packages.txt</a><br>
>> ><br>
>> > It is far from being more than a draft specification of components and<br>
>> > their features. It reflects the partitioning of the proposed software model<br>
>> > and where and what could be done. My actual coding time is not much and I'm<br>
>> > doing this alone. Whenever updates become available they'll be published. It<br>
>> > would be also greatly appreciated if someone can help somehow in the<br>
>> > creation of a development team for this project.<br>
>> ><br>
>> > Thanks in advance!<br>
>> > Sebastian.<br>
>> ><br>
>> ><br>
>> > On Sun, Aug 19, 2012 at 12:08 PM, Patrick Durusau <<a href="mailto:patrick@durusau.net" target="_blank">patrick@durusau.net</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Quintin,<br>
>> >><br>
>> >><br>
>> >> On 08/19/2012 07:10 AM, Quintin Siebers wrote:<br>
>> >><br>
>> >> Hey,<br>
>> >><br>
>> >> We've been working on such a system for a few years now, and our<br>
>> >> current version is open to have a look at:<br>
>> >><br>
>> >> <a href="http://en.mssm.nl/software/kamala-in-the-cloud/" target="_blank">http://en.mssm.nl/software/kamala-in-the-cloud/</a><br>
>> >><br>
>> >><br>
>> >> Good point but Kamala requires (as any topic map application does) that<br>
>> >> you establish what subjects you want to talk about, their identifies,<br>
>> >> relationships, etc. Having said that, you can fill it with whatever content<br>
>> >> you like.<br>
>> >><br>
>> >> My objection to Sebastian's needs/features is their universal nature.<br>
>> >><br>
>> >> If I were writing a topic map for business expenses, it would be very<br>
>> >> unlikely to include the rules for receipts written in cuneiform (the<br>
>> >> earliest business document is a receipt for beer at an inn). Not that topic<br>
>> >> maps can't do that, but most clients are unlikely to be interested. For that<br>
>> >> matter, of the thousands of natural languages in existence, most clients are<br>
>> >> going to be interested in only one (1). Topic maps can do more but again,<br>
>> >> probably not a requirement.<br>
>> >><br>
>> >> You can see where this is going.<br>
>> >><br>
>> >> I think topic maps shine brightest meeting the semantic requirements of<br>
>> >> actual customers.<br>
>> >><br>
>> >> That someone, somewhere, off the Net most likely, is not best served by<br>
>> >> my topic map is quite likely.<br>
>> >><br>
>> >> But, I am not arrogant enough to presume to act in their best interest,<br>
>> >> never having asked what they want, much less their permission.<br>
>> >><br>
>> >> Is the "digital divide" (<a href="http://en.wikipedia.org/wiki/Digital_divide" target="_blank">http://en.wikipedia.org/wiki/Digital_divide</a>)<br>
>> >> the new "white man's burden?<br>
>> >> (<a href="http://en.wikipedia.org/wiki/White_Man%27s_Burden" target="_blank">http://en.wikipedia.org/wiki/White_Man%27s_Burden</a>)"<br>
>> >><br>
>> >> Hope you are having a great weekend!<br>
>> >><br>
>> >> Patrick<br>
>> >><br>
>> >><br>
>> >><br>
>> >> Quintin Siebers<br>
>> >><br>
>> >> --<br>
>> >> <a href="mailto:q.siebers@mssm.nl" target="_blank">q.siebers@mssm.nl</a><br>
>> >> (+31) (0)6 - 11 06 16 27<br>
>> >><br>
>> >><br>
>> >> Morpheus Kennistechnologie BV<br>
>> >> <URL: <a href="http://www.mssm.nl" target="_blank">http://www.mssm.nl</a> ><br>
>> >> postbus 69<br>
>> >> 3500 CD Utrecht<br>
>> >> KVK 30 26 04 30<br>
>> >><br>
>> >> On 19 aug. 2012, at 13:03, Alexander Johannesen<br>
>> >> <<a href="mailto:alexander.johannesen@gmail.com" target="_blank">alexander.johannesen@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Hola,<br>
>> >><br>
>> >> On Sun, Aug 19, 2012 at 8:52 PM, adasal <<a href="mailto:adam.saltiel@gmail.com" target="_blank">adam.saltiel@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Is what you are proposing really possible from the ground up? I wonder<br>
>> >> if<br>
>> >> even getting an architecture is possible from the ground up, i.e.<br>
>> >> without<br>
>> >> starting with real world compromises dictated by the job in hand.<br>
>> >><br>
>> >><br>
>> >> Not sure if what's proposed is possible from the ground up, but I know<br>
>> >> it's certainly possible to create an ontology-based complete system,<br>
>> >> however I doubt "from the ground up" has been defined enough at this<br>
>> >> point. I've worked on creating full-stack application and systems<br>
>> >> delivery framework based on ontologies / Topic Maps, both in terms of<br>
>> >> integration but also as a development tool, and as a way to infer<br>
>> >> capabilities of services based on their entity / resource rather than<br>
>> >> clumsy API's.<br>
>> >><br>
>> >> I'm fairly confident that it's the way of the future, but as you<br>
>> >> probably allude to as well, it's still a bit way off, mostly because<br>
>> >> whomever comes up with it first or already doing it, are doing it in<br>
>> >> solitary, much like the TM community watching the spectacle of RDF<br>
>> >> from the side-lines.<br>
>> >><br>
>> >><br>
>> >> Regards,<br>
>> >><br>
>> >> Alex<br>
>> >> --<br>
>> >> Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic<br>
>> >> Maps<br>
>> >> --- <a href="http://shelter.nu/blog/" target="_blank">http://shelter.nu/blog/</a><br>
>> >> ----------------------------------------------<br>
>> >> ------------------ <a href="http://www.google.com/profiles/alexander.johannesen" target="_blank">http://www.google.com/profiles/alexander.johannesen</a><br>
>> >> ---<br>
>> >> _______________________________________________<br>
>> >> topicmapmail mailing list<br>
>> >> <a href="mailto:topicmapmail@infoloom.com" target="_blank">topicmapmail@infoloom.com</a><br>
>> >> <a href="http://www.infoloom.com/mailman/listinfo/topicmapmail" target="_blank">http://www.infoloom.com/mailman/listinfo/topicmapmail</a><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> topicmapmail mailing list<br>
>> >> <a href="mailto:topicmapmail@infoloom.com" target="_blank">topicmapmail@infoloom.com</a><br>
>> >> <a href="http://www.infoloom.com/mailman/listinfo/topicmapmail" target="_blank">http://www.infoloom.com/mailman/listinfo/topicmapmail</a><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Patrick Durusau<br>
>> >> <a href="mailto:patrick@durusau.net" target="_blank">patrick@durusau.net</a><br>
>> >> Former Chair, V1 - US TAG to JTC 1/SC 34<br>
>> >> Convener, JTC 1/SC 34/WG 3 (Topic Maps)<br>
>> >> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300<br>
>> >> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)<br>
>> >><br>
>> >> Another Word For It (blog): <a href="http://tm.durusau.net" target="_blank">http://tm.durusau.net</a><br>
>> >> Homepage: <a href="http://www.durusau.net" target="_blank">http://www.durusau.net</a><br>
>> >> Twitter: patrickDurusau<br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > PragmaticWeb mailing list<br>
>> > <a href="mailto:PragmaticWeb@lists.spline.inf.fu-berlin.de" target="_blank">PragmaticWeb@lists.spline.inf.fu-berlin.de</a><br>
>> > <a href="https://lists.spline.inf.fu-berlin.de/mailman/listinfo/pragmaticweb" target="_blank">https://lists.spline.inf.fu-berlin.de/mailman/listinfo/pragmaticweb</a><br>
>> ><br>
</blockquote></div>
</blockquote></div>