The fact that we can have this conversation,
although we have never corresponded before, is a testament to the effectiveness
of semantic standards, starting with the definition of the Volt, the way
you wire up the plug on our computers, and all the other thousand
standards that contribute to the mechanics of communication. When you buy
something on line, you rely on having common semantics for the transaction,
starting with the meaning of "$" though to the supplier telling the
postal service your zip code (and them understanding it in terms of the geography
of the USA).
The answer to your objection comes in two parts:
Firstly, there are already some established ways of checking
conformance to semantic standards. The CAx-IF regularly tests conformance of
mechanical CAD systems for their conformance to STEP (ISO 10303), both to make
sure that new versions of software can interoperate using the standard, and to
test that the vendors have the same interpretation of extensions to the
standard. I would imagine that similar testing goes on in the commercial sector,
for example, for EDIFACT messages. The objective is not to prove conformance to
the standard ab initio, but to confirm conformance to the standard, probably
after several rounds of bug-fixing.
Secondly, whether or not you require proof of conformance to a semantic
standard is a measure of how much risk you are prepared to take. You may not
require proof that the Hawaiian Pizza you are ordering actually has ham and
pineapple, but if it doesn't it will have only cost you $10 and some space in
your garbage can. A bolt on an aircraft might also cost only $10, but it might
also cost the lives of hundreds of people. The aerospace industry is rightly
very choosy about who it trusts to make bolts, and the manufacturers have to go
through a relatively expensive certification process.
Just to put this in context, as a major world supplier of defence
systems, we supply hundreds of products with millions of components to tens of
customers, each of whom also has hundreds of suppliers, as indeed do we. The
PLCS standard is being put in place to simplify the support by using a common
set of semantics. The problem is not to implement thousands of slightly
different PLCS sysstems, but have common systems with common semantics. (BTW
the standard is written as a conventional Entity-Relation schema plus a
taxonomy to specialise generic elements and rules to tie down particular
transactions - almost RDF).
The problem is not that as human beings, we cannot negotiate the
meaning of our communications, but rather, whether we can trust our computers
to do some of the work for us, without manually checking each step that they
have taken. There was a report a year or so ago that someone had developed
autonomous agents that had then gone on to develop their own language for
communicating with each other. The problem was, nobody knew what they were
saying. I do not believe this is the aim of the semantic web.
BAE SYSTEMS - Advanced Technology Centre Bristol, UK
+44(0) 117 302 8184
BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,
Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Burkett,
Sent: 26 October 2009 12:59
Subject: Re: [ontolog-forum] Wish list for the sematic web
*** WARNING ***
This message has originated outside your organisation,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
In my personal opinion, based on my personal experience, your
list starts off with a major misstep:
>1) An examination of methods for certifying that the
user semantics for terms matches the definition of the term.
I don’t believe there is any possible way to do
this. The semantics of data and the schemas that govern them are created
by people (or their software surrogates) using their native linguistic skills,
- complete with all the language foibles and inconsistencies that plague
human-to-human communication. Consider how much time and money is spent
creating legal documents and arguing court cases over what the language in a
legal document means – I think the same interpretative imprecision and
vagueness will be present in most data. Note that dictionaries do not assert
what a word means (nor do they enforce that meaning), but rather dictionaries
document the conventional usage of the term.
I think the main objective of semantic technologies needs to be
semantic adaptability: the ability to respond quickly to and correct semantic
errors – much the same way we learn the idiosyncrasies of the way each of
us speak and adapt to them.
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of sean barker
Sent: Sunday, October 25, 2009 3:04 AM
Subject: [ontolog-forum] Wish list for the sematic web
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
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
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.