- From: Stuart Naylor <indtec@eircom.net>
- Date: Tue, 17 Apr 2001 08:27:27 +0100
- To: <www-rdf-interest@w3.org>
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. I will introduce '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.
Received on Tuesday, 17 April 2001 01:34:07 UTC