Re: [ontology-summit] Invitation to a brainstorming call for the 2011 On

[Pavithra <pavithra_kenjige@xxxxxxxxx>]

I think it is the matter of using the word " Ontology" vs "Data Modeling"  is causing confusion here.


If you read the document about "Nobel price"  that was circulated here before,  it is the description and rules that are involved in Nobel price selection.   You can develop a Ontology  model and/ or data model using that. 

There are three parts to data modeling in System's Engineering - conceptual, logical and physical data modeling.   We pick the  objects or entities that are in the description use one or the other ( relational or object oriented) modeling methods with ceratin concepts that goes with that modeling.    Here we do not have to worry about other things, since process modeling takes care of the behavior, communication etc..

But with ontology modeling, I believe we  work at the conceptual information modeling level with emphasis on semantics and behavior, relationships as well taking classification, terminology, vocabulary, etc into considerations.  RDF Graph.. Basic Formal Ontology (BFO) modeling are some are in use..   Ontology should lead to good data modeling, and semantic reasoning. 

I would like to do a presentation on this topic...

Regards.
Pavithra Kenjige





--- On Tue, 12/14/10, Obrst, Leo J. <lobrst@xxxxxxxxx> wrote:

From: Obrst, Leo J. <lobrst@xxxxxxxxx>
Subject: Re: [ontology-summit] Invitation to a brainstorming call for the 2011 Ontology Summit
To: "Ontology Summit 2011 discussion" <ontology-summit@xxxxxxxxxxxxxxxx>
Date: Tuesday, December 14, 2010, 8:50 PM

I'm sorry, but you are rewriting history if you conflate data models with ontologies, and you are misrepresenting computer science distinctions. I recall in the late 1980s, papers in the relational database community that began to address semantic data models. Even these were not ontologies. The database folks did not address only real world semantics, but included many system and database level constructs -- as data models still do.

Ontologies really were something new, in the early-mid 1990s. I know because I advocated the use of ontologies in the late 1980s (when I got to Intelligent Business Systems, a pre-Internet start-up company with a natural language interface to relational databases), coming off of projects at MCC that used Cyc. The emergence of work and KR standards from the DARPA Knowledge Sharing Initiative (KIF, Ontolingua, Generic Frame Protocol/OKBC, and KQML), now largely identified by Tom Gruber's initial publications, AND the use of ontological analysis by Nicola Guarino, along with Cyc's large-scale efforts on commonsense "semantics", in that 1993-1995 period enabled the emergence of ontological engineering, with ontologies as a distinct new content representation.

I have no problem with data models, but they are not ontologies, and to confuse the two is harmful and historically inaccurate. Some of the most advanced commercial ontological work is that performed by the HighFleet/Ontology Works folks (Bill Andersen, etc.), and they essentially have a deductive database application, with ontologies and rule-reasoning (i.e., logic programming) built on top of relational and object databases (with set-at-time operations best done by RDBs).

To me, some seminal papers in the late 1980s that allowed ontologies (as engineering product) to emerge in the 1990s (and some of the important papers) include the following selections, roughly in chronological order:

Peckham, Joan; Fred Maryanski. 1988.  Semantic Data Models. ACM Computing Surveys, Vol. 20, No. 3, September 1988.

Reiter, R.  1989.  Towards a Logical Reconstruction of Relational Database Theory., In: Mylopoulos, & Brodie, ed.  Readings in Artificial Intelligence and Databases. San Mateo, CA: Morgan Kaufman, pp. 301-326.

Brachman, Ronald; Levesque, Hector; Reiter, Raymond. 1989.  Proceedings of First International Conference on Knowledge Representation and Reasoning, Toronto, Canada, May 15-18, 1989. San Mateo, CA: Morgan Kaufman.

Gallaire, H; Minker, J.; Nicolas, J-M. 1989.  Logic and Databases: A Deductive Approach. In: Mylopoulos, & Brodie, ed.  Readings in Artificial Intelligence and Databases. San Mateo, CA: Morgan Kaufman, pp. 231-247.

Gardarin, Georges; Valduriez, Patrick.  1989.  Relational Databases and Knowledge Bases. Reading, MA: Addison-Wesley.

Ullman, Jeffrey.  1988.  Principles of Database and Knowledge-Base Systems, Volume I. Rockville, MD: Computer Science Press.

Ullman, Jeffrey.  1989.  Principles of Database and Knowledge-Base Systems, Volume II: The New Technologies. Rockville, MD: Computer Science Press.

Guha, R.V.; Lenat, Douglas.  1990. Cyc: A Mid-Term Report. Microelectronics Technology and Computer Corporation (MCC), Austin, Tx.  Technical Report ACT-CYC-134-90.

Gruber, Thomas.  1993.  A Translation Approach to Portable Ontology Specifications.  Knowledge Acquisition 5, pp. 199-220.

Gruber, Thomas.  1995.  Towards Principles for the Design of Ontologies used for Knowledge Sharing.  International Journal of Human and Computer Studies, 43(5/6), pp. 907-928.

Fox, Mark; Gruninger, M. 1994.  Ontologies for Enterprise Integration. In: Cooperative Proceedings of the 2nd Conference on Cooperative Information Systems, Toronto, Ontario.

Guarino, N, ed.  1998. Formal Ontology in Information Systems.  Amsterdam.: IOS Press. Proceedings of the First International Conference (FOIS'98), June 6-8, Trent, Italy.

Guarino N.  1994. The Ontological Level. Invited paper Presented at IV Wittgenstein Symposium, Kirchberg, Austria, 1993. In R. Casati, B. Smith and G. White (eds.), Philosophy and the Cognitive Sciences, Vienna, Hölder-Pichler-Tempsky.

Guarino, N.; Giaretta, P. 1995.  Ontologies and Knowledge Bases: Towards a Terminological Clarification.  In: N. Mars, ed.  Towards Very Large Knowledge Bases: Knowledge Building and Knowledge Sharing.  IOS Press, Amsterdam: 25-32. http://www.loa-cnr.it/Papers/KBKS95.pdf.

Gruninger, M. and Fox, M.S. 1995.  Methodology for the design and evaluation of ontologies. In: Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal.

Borgo, Stefano; Guarino, Nicola; Masolo, Claudio.  1996.  Towards an Ontological Theory of Physical Objects.  National Research Council, LADSEB-CNR, Padova, Italy. 

Uschold, Michael; Gruninger, Michael.  1996.  Ontologies: Principles, Methods, and Applications.  The Knowledge Engineering Review, 11(2), pp. 93-136.

Finally, you might also look at the early Ontolog Ontologies and Databases series, for some distinctions.

Thanks,
Leo 


-----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: Re: [ontology-summit] Invitation to a brainstorming call for the 2011 Ontology Summit

Deborah, Matthew, Ahsan, Steve, Ali, Nicola, and Jack,

DMcP:
> In your view is it even possible for model-driven exchange environments
> to succeed without including ontologies?

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.

I agree with Matthew.  In the 1970s, DB designers were discussing
very similar issues about ontology that we are talking about here.

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.

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.

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.

AM:
> What do you think about SKOS-XL instead OWL for building ontology?

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.

SW:
> Would that I had a nickel for every time I've seen someone misinterpret
> a "controlled English" sentence.

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.).

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.

SW:
> My conclusion, then, is that end users are likely to understand
> the benefits of ontologies well before programmers.

Programmers and database administrators understood the need for
ontologies since the 1970s.  But they called them conceptual schemas,
structured analysis and design, etc.

SW:
> The model in question is IDEF1-X. Information exchange is based
> on database replication...

That's ontology!  Note Matthew's comment and my response.

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.

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'.

AH:
> Fleshing out these different roles would be instrumental in helping
> focus and identifying the different types of supporting arguments.

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?

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.

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.

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.

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.

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:

    http://www.jfsowa.com/pubs/cg1976.pdf
    Conceptual Graphs for a Database Interface

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.

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.

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.

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.

John

_________________________________________________________________
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/

_________________________________________________________________
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/

_________________________________________________________________
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/     (01)