These all sound like good points to include in the communique and announcement
for the summit theme
(01)
DEBORAH MACPHERSON, CSI CCS, AIA
Specifications and Research
(02)
Cannon Design
1100 Wilson Boulevard, Suite 2900
Arlington, Virginia 22209
(03)
Direct Line 703 907 2353
4 Digit Dial 2353
(04)
dmacpherson@xxxxxxxxxxxxxxxx
cannondesign.com
(05)
Please consider the environment before printing this email.
(06)
-----Original Message-----
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Tuesday, December 14, 2010 6:53 PM
To: ontology-summit@xxxxxxxxxxxxxxxx
Subject: [BULK] Re: [ontology-summit] Invitation to a brainstorming call for
the 2011 Ontology Summit
Importance: Low
(07)
Deborah, Matthew, Ahsan, Steve, Ali, Nicola, and Jack,
(08)
DMcP:
> In your view is it even possible for model-driven exchange
> environments to succeed without including ontologies?
(09)
MW:
> I would argue that databases are willy nilly ontologies, since they
> make statements about the sorts of things there are, and some rules
> that govern them. Perhaps more importantly a database can be a very
> suitable implementation environment for an ontology, depending on what
> your purposes are.
(010)
I agree with Matthew. In the 1970s, DB designers were discussing very similar
issues about ontology that we are talking about here.
(011)
Type hierarchies, E-R diagrams, and Petri nets were used in the 1960s, they
were adopted by the DB community, and they are part of the UML collection. In
fact, UML diagrams are probably the most widely used notation for ontologies on
planet earth. UML plus OCL (the object- constraint language) provides a
*superset* of OWL, but in a much more readable notation.
(012)
The programming community is already familiar with UML diagrams, which provide
representations for type hierarchies, for the type constraints and cardinality
constraints on relations, for time dependencies in activity diagrams, etc. If
more expressive power is needed, UML also includes OCL as a general-purpose
notation for FOL.
(013)
That is far more expressive power in a far more readable format than OWL. You
can translate any OWL ontology to UML, but not vice-versa.
(014)
AM:
> What do you think about SKOS-XL instead OWL for building ontology?
(015)
I have no objection to anybody using whatever tools they find useful.
But it shows that OWL is a very difficult language to learn and use
effectively. Much simpler languages supplemented with diagrams would be very
attractive to many users.
(016)
SW:
> Would that I had a nickel for every time I've seen someone
> misinterpret a "controlled English" sentence.
(017)
I'd be delighted to take that bet, provided that you give me a penny for every
time I've seen somebody misinterpret a statement in some formal language
(logic, programming language, etc.).
(018)
Please note that COBOL is a rather poor example of what can be done with
English-like syntax, but it was the most widely used programming language
during the second half of the 20th century.
(019)
SW:
> My conclusion, then, is that end users are likely to understand the
> benefits of ontologies well before programmers.
(020)
Programmers and database administrators understood the need for ontologies
since the 1970s. But they called them conceptual schemas, structured analysis
and design, etc.
(021)
SW:
> The model in question is IDEF1-X. Information exchange is based on
> database replication...
(022)
That's ontology! Note Matthew's comment and my response.
(023)
AH:
> The argument I've used (with limited, but notable success) with the
> programmers around me, is that an ontology can also serve as a
> contract between the software development team and each module.
(024)
I agree. And the people who were designing software development tools in the
1970s used very similar arguments. The only missing jargon was the word
'ontology'. Instead, they used terms like 'specification' or 'conceptual
schema' or even 'IDEF1X'.
(025)
AH:
> Fleshing out these different roles would be instrumental in helping
> focus and identifying the different types of supporting arguments.
(026)
MB:
> Another way of framing this is that every application has an ontology
> anyway. The question is how it is framed, if at all. Are the meanings
> of terms resident only in the head of the developer, or in some
> logical model with written term definitions (weak semantics) or in a
> formal language which > grounds the meanings of terms with reference
> to some logical formalism?
(027)
I agree with both of those statements. And I encourage anybody who has been
using OWL to take another look at UML. For most of what they do with OWL, they
could specify much more clearly with UML.
(028)
SW:
> It's probably better to think of every application having multiple
> views of data. The view that is presented to the user may differ
> significantly from the view that's in memory, which in turn may differ
> from the view that's persisted.
(029)
I strongly agree. And that's another argument for UML as a better ontology
language than OWL. The various diagrams give you multiple views of the
subject. But OWL is designed to enforce tunnel vision.
(030)
SW:
> The case to make is that the OWL model of information is more "natural"
> than the relational model, so the application developer spends less
> time and effort translating a business model to OWL than to SQL.
(031)
SQL happens to be a very primitive version of the relational model.
Ted Codd was not happy about the SQL version of relational semantics.
In 1979, Codd and Date made a strong case for adding a type hierarchy in the
RM/T extensions. In fact, I assumed a type hierarchy in my first published
article on conceptual graphs in 1976:
(032)
http://www.jfsowa.com/pubs/cg1976.pdf
Conceptual Graphs for a Database Interface
(033)
NG:
> Deciding how much effort to put in developing a particular ontology is
> a crucial choice, and it is very important to distinguish the cases
> where a proper ontological analysis pays off, and is indeed a crucial
> aspect of success, from those where a "lightweight" approach is sufficient.
(034)
I agree. In fact, there is a great deal of informal analysis that must be done
before it's possible to write any kind of formal specification.
(035)
JR:
> How about engaging them in a survey to estimate the cost of "IT Babel"
> in their respective enterprises? We might even mention the trillion
> dollar elephant in the room --- insecure systems.
(036)
That is indeed a serious problem. People have been talking about it since the
1970s. The only thing new is that the word 'ontology' has been thrown into the
pot. But talking has not solved the problems.
(037)
John
(038)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2011/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2011
Community Portal: http://ontolog.cim3.net/wiki/
(039)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2011/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2011
Community Portal: http://ontolog.cim3.net/wiki/ (040)
|