Great stuff, thanks, also for the same post on the SE list
its good to see great minds at work :-)
It may be useful to specify further what you mean by Industry
Industry is made up of different stakeholders, but until this point in history, industry is represented by small powerful
consortia (cartels) who determine what happens in the sector/market by obliterating everything else, generally people with strong
personal financial interests decide what is on the table
Today, we can redefine industry based on the ability to give a voice to the various stakeholders in Industry, and make sure
that they dont get bullied/silenced/obliterated simply because they have a different perspective
are the customers part of the industry? the workers? the victimsof the industry adverse impact and their families?
step 1, make sure all the stakeholders are identified and have a voice in
other suggested steps
1. find people who agree/are already working on any subset below from various orgs (make sure there is some agrement on the goals
among people working togther, else split the team up)
2. possibly set up a team/taskforce around any of the points, making sure that each point connects with other points if there are shared issues
3. study what are the obstacles/challenges to achieve the stated goasl, and possibl strategies to achieve them
4. for each of the starndardization bodies concerned, find out what is their protocol/suggested procedures to get work started/off the ground
keep the loop open, and constantly readjust, do ongoin improvement, refinement
bear in mind that some peopl who monopolise where
On Sun, Oct 25, 2009 at 5:14 PM, Dave McComb <mccomb@xxxxxxxxxxxxxxxx>
This is great. How do we go about getting this organized?
I've been involved with something IBM calls their Data Governance Council, which has a similar sort of mission (except in data rather than semantics), and has worked on things such as just getting agreement on what are the problems, setting up a maturity model (a way to know whether you're making progress in governance etc). Maybe this is a model for how to progress from here.
This is a great outline of what's needed. Seems like we need some sort of road map and fellow travelers to make some progress.
Since I was asked what we need to move forward with the Semantic Enterpise, I cam up with a wish list to fill in the other 90% which is not ontology. Since it is mostly about the semantics of doing business, rather than ontology languages, feel free to ignore the post.
What do we need to get SemWeb working for Industry.
1) An examination of methods for certifying that the user semantics for terms matches the definition of the term. Data exchange experience shows that the user view of what terms means is always local to a particular business culture, which may be confined to a single department. Standard example - how many man-hours in a man year? When I talk to the pay department, there should be about 2,200; when I talk to my line manager, there should be 1,650, and to my project manager, 1,500. And, btw, there are 10 months in an EU year.
2) In particular domains, an agreed set of certification methods (following from 1) - something like an ISO 9000 audit. The rigour of any particular method will be a trade-off between audit cost and risk. In pizza sales, there is unlikely to be any audit, whereas if we were to trade aircraft parts openly, a very high level of conformance checking is needed. (I looked at certification requirements in a paper for the SIMDAT project on cloud computing and SOAs - and this topic appears to be one in which investments are being made.)
3) A standard for communicating certification conformance. There is not much point in a business investing in the Semweb to do business electronically if, before you can do business, the commercial department have to do a manual check whether the business is ISO 9000 certified. (Also considered in a SIMDAT paper).
4) A trust infrastructure to support assertions about certification. This can probably draw on work on security trust infrastructures (e.g. the TRUSTCOM project).
5) The development of methods, methodologies and criteria for constructing ontologies, and, in particular for identifying the terms in an ontology (cf Chris Partridge's work - is it the last word on the subject?). It is my view that the terms needed for a business ontology are precisely those that apply at decision points in business processes, and which parametrise the process or select between alternative processes. User domain ontologies are only relevant to the extent that businesses interoperate, and upper ontologies are therefore relevant only as guides to constructing user domain ontologies where the scope of interoperation is not known in advance. Most of what passes for a taxonomy is a set of heuristics to guide the user to find the right terms, and is not relevant to the user domain ontology (but see 6)
6) The development of heuristics to guide the users to the right terms - this is primarily a human factors study. I would expect most user domain ontologies to be supported by multiple heuristic taxonomies to match the cultural habits of particular groups of users.
7) The development of domain standards against which business can be certified. It seems likely that a user domain ontology developed without considering 1 to 5 above is likely to fail or be replaced relatively rapidly. I conventional technologies, the Oil and Gas area (ISO 15926 I think) and some areas of industrial products (ISO 10303 series) provide examples, with the CAx-IF providing a certification like function for design geometry software.
8) The development of persistence criteria for assertions, and a way of communicating them. It takes a finite time to assemble and process a set of assertions. We know that the assertions business make changes over time and therefore we need assurance that the assertions we rely on for a business transaction remain valid, at least for the length of the transaction. This could be analogous to record locking in conventional database systems, where, for example, the person buying the last ticket on an aeroplane takes a lock on the record until they pay or decline, preventing anyone else buying the ticket, and ensuring only one person can buy it. There are many more cases than simple transaction locking.
9) Methods for detecting and dealing with viral assertions - i.e. false assertions inserted into a trusted source. The problem is not simply to correct the assertions, but to propagate a warning to anyone who may have used the assertion (and may have cached the result).
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx