Bill
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.
Sean Barker
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
*** 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.
Sean:
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.
Bill
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of sean
barker
Sent: Sunday, October 25, 2009 3:04 AM
To:
ontolog-forum@xxxxxxxxxxxxxxxx
Subject: [ontolog-forum] Wish list
for the sematic web
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).
********************************************************************
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.
********************************************************************