Semantic API

Semantics and RDF it's exciting stuff isn't it.

I am going to post a follow on to Zen & Chinwag as if I did get a answer
then I missed it but that wouldn't be unusual.

I am firstly going to explain the background of why I require a API based on
RDF Ontology's.

As a App developer and integrator I work across various industries.
Currently a large proportion of my time is devoted to Legal concentric
activities. The Legal arena has a representation through WWW.LegalXML.org.

The Legal industry has a large amount of Legal specifics to it's IT
requirements but like us all it has some very generic processes.

A Legal Office could be defined as.

Legal Accounts, Document Automation, Time & Billing, Document Management,
Case Management, Knowledge Management.

The vendors comprise of a cottage industry which is a blend of grey 'All in
One' and best of breed applications. The actual integration of a Legal
solution is a absolute nightmare which often results in the choice of a 'All
in One' application which often has dictates to a localisation as narrow as
'London' or 'California'.

My initial thoughts where of a Com, Corba, Dcom with standards in the vain
of MAPI. Then I started looking at the possibilities of XML.

Initially XML was very exciting until I started parsing documents and
exchanging data and was gob smacked at the actual overheads of schema
handling. I believe various industries have got a little carried away with
bloat schemas to represent common data structures. Also I have a problem
with schema because of the fact they dictate that this is a entity data
structure. Which if I look at application design for reasons of
functionality data structures are never the same even though the do exactly
the same job.

I believe the two problems above have very strong parallels across many
industries but back to my cause.

	Back to 'Chinwag' which I choose that name because as a solution it will be
the last time your will hear it.

Chinwag is an idea for application to application interoperability without
the need of formal schema.

It's reasoning comes from the way many systems work with closed sensitive
data, is that the very idea that a XML repository in it's own right will not
work. This is due to the fact that many systems know exactly what the
require and are returned the bare minimum to satisfy that requirement.
Business data will never be open as it has value and unless their is a
incentive you will not be able to receive it.

So my logic takes me back to the API which will return fragments of data on
the satisfaction of the calling parameters.

The problem with a API call is the presumption that you know what it does
and you know what it returns.

So this is where ontology's come in, business process ontology's to be
precise.
With my dislike for schema I began to wonder if a different representation
of data would be viable.
My analogy to this is that a schema is just the company handbook to data and
like a experienced worker who knows their workplace processes they don't
need the handbook (schema).

So if you had a application ontology that describes it's data elements so
that they are known and positioned by context then it is feasible that no
schema is required.

You might see where I am going but through the Semantic web a application
will define it's context through a series of referenced ontology's.

Application Data Ontology -> Application Process Ontology -> Industry
Specific Process Ontology -> Process Ontology and so on until there is
enough to provide data element comprehension and context.

I will not go into the topics of how two applications could map themselves
to a source of common context, methods of expressing API functionality...

What I have seen so far from anyone out the is still explicit declaration as
opposed to inference and selection by relevance.

So all I need is a plethora of well thought ontologies which link by there
context.

If anyone has any info on any working groups at providing self comunicating
apps or would like to get something more concrete please email me.

Also I have many further ideas on this but for the sake of brevity the above
will do for now.

Received on Tuesday, 17 April 2001 01:48:22 UTC