- From: Paola Di Maio <paola.dimaio@gmail.com>
- Date: Mon, 27 Aug 2012 13:02:45 +0100
- To: "Sebastian S." <cognescent@gmail.com>
- Cc: semantic-web@w3.org, pragmaticweb@lists.spline.inf.fu-berlin.de
Not sure if the 'universal plug' can be a useful metaphor many standards, and one plug design to fit them all a common device that claims to fit every electricity plug in the universe let us know what ye come up with :-) P On Mon, Aug 27, 2012 at 9:34 AM, Sebastian S. <cognescent@gmail.com> wrote: > Paola, > > I've been thinking that the universality issue is not as a problem but more > much as a model of model, layers and model representation matter. > > For example, representations can handle different models at different layers > and those models having many levels or specificity. > > So the design now should be narrowing now into o set of representations for > leveles of models of profiles which speak in a universal way about concrete > domains, interleaving views as appropriate by interpretation of layered > representations of those models. > > I'll be trying to be more concise about this while I develop this further. > Then this will became rendered into the project docs and sources. > > Regards. > Sebastian. > > On Aug 24, 2012 10:23 AM, "Paola Di Maio" <paola.dimaio@gmail.com> wrote: >> >> Sebastian >> >> apologies for late reply, but was playing in other threads >> >> i do agree that narrowing the focus does indeed help feasibility >> of task at hand >> however just a very quick <chime> for universality >> >> I design general intelligence systems, >> universality can be achieved by autodetection of schema properties >> >> (like taking a dump of a schema and generating the code for the map) >> >> >> any schema (detect structure of schema) to >> any other schema (configure to structure...) >> >> however I design, not code so >> if you or someone interested in exploring universality from the ground >> up I think it can be done >> >> cheers >> >> PDM >> >> >> On Thu, Aug 23, 2012 at 1:56 AM, Sebastian S. <cognescent@gmail.com> >> wrote: >> > [The PragmaticWeb Research List] >> > Hi, >> > >> > I've been reading all of the comments and I'm taking note of all of them >> > because they all seem very valuable to me. I'm verry thankful really. >> > >> > I agree in that there is some kind of solitaire fashion that one feels >> > like when coming to this at first. And I also think that maybe I seem a >> > little 'universal' in the needs/features I would like to implement and >> > address too. And also that it would seem very unrealistic to come 'from the >> > ground up' with a tool that addresses everything. >> > >> > So, I'm trying to narrow a little the scope and try to reflect this into >> > an updated document. It only adds a section named 'Application Model' in >> > respect to the first but if I'm making my point there, a general purpose >> > tool can be thought as a layer that is useful when someone tells it what to >> > do (quite like a traditional RDBMS or framework or programming language). >> > So, its it could be understood that there be models narrowing this >> > 'universality' but without losing the benefits of a layer of semantics for >> > future integration, merging and maybe interoperability of 'semantic >> > application instances'. >> > >> > https://cognescent.googlecode.com/files/Brochure2.pdf >> > >> > I also would like to implement this in Java, so I'm describing the >> > initial layout of packages and their functionalities into the Google Code >> > hosted project repository, in a document named 'packages.txt': >> > >> > >> > https://code.google.com/p/cognescent/source/browse/trunk/Cognescent/src/packages.txt >> > >> > It is far from being more than a draft specification of components and >> > their features. It reflects the partitioning of the proposed software model >> > and where and what could be done. My actual coding time is not much and I'm >> > doing this alone. Whenever updates become available they'll be published. It >> > would be also greatly appreciated if someone can help somehow in the >> > creation of a development team for this project. >> > >> > Thanks in advance! >> > Sebastian. >> > >> > >> > On Sun, Aug 19, 2012 at 12:08 PM, Patrick Durusau <patrick@durusau.net> >> > wrote: >> >> >> >> Quintin, >> >> >> >> >> >> On 08/19/2012 07:10 AM, Quintin Siebers wrote: >> >> >> >> Hey, >> >> >> >> We've been working on such a system for a few years now, and our >> >> current version is open to have a look at: >> >> >> >> http://en.mssm.nl/software/kamala-in-the-cloud/ >> >> >> >> >> >> Good point but Kamala requires (as any topic map application does) that >> >> you establish what subjects you want to talk about, their identifies, >> >> relationships, etc. Having said that, you can fill it with whatever content >> >> you like. >> >> >> >> My objection to Sebastian's needs/features is their universal nature. >> >> >> >> If I were writing a topic map for business expenses, it would be very >> >> unlikely to include the rules for receipts written in cuneiform (the >> >> earliest business document is a receipt for beer at an inn). Not that topic >> >> maps can't do that, but most clients are unlikely to be interested. For that >> >> matter, of the thousands of natural languages in existence, most clients are >> >> going to be interested in only one (1). Topic maps can do more but again, >> >> probably not a requirement. >> >> >> >> You can see where this is going. >> >> >> >> I think topic maps shine brightest meeting the semantic requirements of >> >> actual customers. >> >> >> >> That someone, somewhere, off the Net most likely, is not best served by >> >> my topic map is quite likely. >> >> >> >> But, I am not arrogant enough to presume to act in their best interest, >> >> never having asked what they want, much less their permission. >> >> >> >> Is the "digital divide" (http://en.wikipedia.org/wiki/Digital_divide) >> >> the new "white man's burden? >> >> (http://en.wikipedia.org/wiki/White_Man%27s_Burden)" >> >> >> >> Hope you are having a great weekend! >> >> >> >> Patrick >> >> >> >> >> >> >> >> Quintin Siebers >> >> >> >> -- >> >> q.siebers@mssm.nl >> >> (+31) (0)6 - 11 06 16 27 >> >> >> >> >> >> Morpheus Kennistechnologie BV >> >> <URL: http://www.mssm.nl > >> >> postbus 69 >> >> 3500 CD Utrecht >> >> KVK 30 26 04 30 >> >> >> >> On 19 aug. 2012, at 13:03, Alexander Johannesen >> >> <alexander.johannesen@gmail.com> wrote: >> >> >> >> Hola, >> >> >> >> On Sun, Aug 19, 2012 at 8:52 PM, adasal <adam.saltiel@gmail.com> wrote: >> >> >> >> Is what you are proposing really possible from the ground up? I wonder >> >> if >> >> even getting an architecture is possible from the ground up, i.e. >> >> without >> >> starting with real world compromises dictated by the job in hand. >> >> >> >> >> >> Not sure if what's proposed is possible from the ground up, but I know >> >> it's certainly possible to create an ontology-based complete system, >> >> however I doubt "from the ground up" has been defined enough at this >> >> point. I've worked on creating full-stack application and systems >> >> delivery framework based on ontologies / Topic Maps, both in terms of >> >> integration but also as a development tool, and as a way to infer >> >> capabilities of services based on their entity / resource rather than >> >> clumsy API's. >> >> >> >> I'm fairly confident that it's the way of the future, but as you >> >> probably allude to as well, it's still a bit way off, mostly because >> >> whomever comes up with it first or already doing it, are doing it in >> >> solitary, much like the TM community watching the spectacle of RDF >> >> from the side-lines. >> >> >> >> >> >> Regards, >> >> >> >> Alex >> >> -- >> >> Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic >> >> Maps >> >> --- http://shelter.nu/blog/ >> >> ---------------------------------------------- >> >> ------------------ http://www.google.com/profiles/alexander.johannesen >> >> --- >> >> _______________________________________________ >> >> topicmapmail mailing list >> >> topicmapmail@infoloom.com >> >> http://www.infoloom.com/mailman/listinfo/topicmapmail >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> topicmapmail mailing list >> >> topicmapmail@infoloom.com >> >> http://www.infoloom.com/mailman/listinfo/topicmapmail >> >> >> >> >> >> -- >> >> Patrick Durusau >> >> patrick@durusau.net >> >> Former Chair, V1 - US TAG to JTC 1/SC 34 >> >> Convener, JTC 1/SC 34/WG 3 (Topic Maps) >> >> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 >> >> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) >> >> >> >> Another Word For It (blog): http://tm.durusau.net >> >> Homepage: http://www.durusau.net >> >> Twitter: patrickDurusau >> > >> > >> > >> > _______________________________________________ >> > PragmaticWeb mailing list >> > PragmaticWeb@lists.spline.inf.fu-berlin.de >> > https://lists.spline.inf.fu-berlin.de/mailman/listinfo/pragmaticweb >> >
Received on Monday, 27 August 2012 12:03:17 UTC