[PragmaticWeb] Business Applications

Mon Aug 27 14:02:45 CEST 2012

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 at 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 at 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 at 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 at 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 at 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 at gmail.com> wrote:
>> >>
>> >> Hola,
>> >>
>> >> On Sun, Aug 19, 2012 at 8:52 PM, adasal <adam.saltiel at 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 at infoloom.com
>> >> http://www.infoloom.com/mailman/listinfo/topicmapmail
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> topicmapmail mailing list
>> >> topicmapmail at infoloom.com
>> >> http://www.infoloom.com/mailman/listinfo/topicmapmail
>> >>
>> >>
>> >> --
>> >> Patrick Durusau
>> >> patrick at 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 at lists.spline.inf.fu-berlin.de
>> > https://lists.spline.inf.fu-berlin.de/mailman/listinfo/pragmaticweb
>> >