Cory’s point – that we live in and need to design for a federated world – where domains end up being more a point of view than a definition, is key. I would also add that the federation is simultaneous, and could be massively parallel, such that events no longer can be viewed as singular from an architectural pov. With ontologies, we can wall the gardens while federating the surrounding forrest. But, as mentioned earlier, there are some – only some – things you can say with OWL. And while we have reasoners, they may check for consistency etc, but they go off to lunch if you use inverseOf. And in designing a system (or systems of systems), chasing a live, morphing system around with no versioning and imprecise time specification is still a challenge. Process is quite missing; ontologies still prefer the static. The biggest challenge, though, may be the lack of better tools, especially visualization of the multi-dimensional worlds we can now capture. I’m not sure if these comments are in one Engineering Track or several – but I’ll add them to the list of considerations. From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Cory Casanave
Sent: Monday, January 23, 2012 9:06 AM
To: Ontology Summit 2012 discussion; 'Westerinen, Andrea R.'
Cc: 'Matthew West'
Subject: Re: [ontology-summit] Summit Engineering Tracks Andrea, I would agree with Henson here – the idea of the “system” being a deciding factor in such fundamentals as the language and upper ontologies seems mostly relevant to systems that are thought of in a vacuum. Years ago the problem was building “a system”, today most systems must federate internally and externally – that is the driving consideration. Even the concept of “domains” gets fuzzy as domains and their systems are overlapping. So a primary concern in the practice across all systems should be the usability of the information discovered and created such that it can be used for purposes outside of a particular systems design as well as the ability of a systems design to incorporate such information defined externally. While we don’t want a “one and only one” approach, this would suggest to me that the disciplines we use should be optimized for federation as well as reduction in unnecessary diversity. Where there is diversity we need to look for ways to bridge as well as common hubs. -Cory Agree with all you say, not surprisingly. Would add that while the application dictates specific ontology concepts relevant, there is a lot of commonality to engineered systems and the process on engineering them. However, I find myself in disagreement with most engineering literature on these topics and do not recommend much that I know about, based on my engineering experience. Here are a few reasons that ontological implications. The design and analysis of engineered systems increasingly involves a lot of representation of the world in which the system operates and interacts. So for example when designing a satellite system one often spends a lot of time with modeling and simulation of conceptual satellites flying around the globe. This means that one is representing, simulating, reasoning, about and otherwise doing analysis about thing real and artificial that you didn’t build and only have partial knowledge about. This is true at both the macro level of satellites, aircraft, and transportation systems, but also of something like designing a heart pacemaker. You have to have good representation, conceptual models of natural systems. A related point is that for large scale systems design almost never starts with a clean sheet of paper. For example, by the time a large scale aircraft program is officially started they may be ten years of work preceding which attempts to sort out what one wants the system to do and concepts of how that might be achieved. This fact invalidates most engineering text book discussions of starting from requirements and proceeding through design, integration etc. This engineering process has not been what has been used since the 1960s. Often people pretend that this is the process used, but that is one of the big problems in the failure of systems to be done on cost, schedule and do what they are supposed to do. From: Westerinen, Andrea R. [mailto:ANDREA.R.WESTERINEN@xxxxxxxx]
Sent: Monday, January 23, 2012 12:02 AM
To: henson graves; Ontology Summit 2011 discussion
Cc: Matthew West
Subject: RE: [ontology-summit] Summit Engineering Tracks You raise some great points and distinctions. In my opinion, the application/system dictates the goals, objectives, requirements, ... which are to be accomplished (all of this was the subject of quite a few other emails over the last two days). Then, the ontology captures the relevant concepts, relations, individuals, rules, ... of the application/system. Lastly, you choose the language in which you express that ontology (and it does not only have to be one language, as long as you deal with interchanging data/results). The language and its supporting infrastructure have to support the demands of the ontology and the application/system. For example, one consideration is the need for reasoning and inference which is available with RDF and OWL. Not all systems require this capability. Another consideration might be the need to do mathematical reasoning (x > y), where RDF and OWL clearly fail. On your point of OWL being insufficient to express necessary engineering concepts, I wholeheartedly agree. It is a language with logic, but is not a commonsense knowledge base. There are many piece parts that currently exist (RDF/OWL/FOL, reasoners, SUMO or Cyc, WordNet, etc.). Each plays a valuable and different role in the ultimate solution. Any one of these, alone, is insufficient.
From: henson graves [mailto:henson.graves@xxxxxxxxxxx]
Sent: Sat 1/21/2012 2:52 AM
To: Westerinen, Andrea R.; 'Ontology Summit 2011 discussion'
Cc: 'Matthew West'
Subject: RE: [ontology-summit] Summit Engineering Tracks Andrea, Your note is exactly the kind of dialog I was hoping to get started. It brings up what I believe is an important distinction for applied ontology. In this case to engineered systems and to engineering of systems (meta-engineering). The distinction is between the application, the language used to talk about the application, and the specific knowledge (ontology) represented within the language. OWL2 is a perfect place to discuss some issues. OWL2 is not only an ontology language, but a formal ontology language, and has the virtue that it has good reasoners. Starting from this about 4 years ago I started looking at and attempting to use OWL2 for representing product requirements and product designs. This starts in a series of papers with among others Ian Horrocks, and David Leal. It clearly is very promising. However, I have found that it is insufficient to represent the semantics needed for concepts such as part-whole relations. Certainly, one can introduce binary properties and call them part properties. But the language without extensions is unable to do a good job of representing a lot of engineering concepts. I am sure the ontologists would concur. So for me it is not a question of throwing OWL out, it is what semantic concepts are needed, how to express their semantics, and extensions to OWL are needed. Also, by the way, as an engineer I have been very much involved with using SysML to describe large scale systems and their interaction with the world. I view SysML as an ontology language, albeit one without a formal semantics. I also have been very much concerned with retrofitting SysML with a formal semantics and adding OWL class and role constructions. All to be able to build suitable ontologies for engineered products and more recently biomedical systems such as the human heart. - Henson I have recently written a paragraph summarizing "why (OWL) ontologies?" for a customer. It tries to address some of the points that Henson raises below. Here it is with the identifying text removed: Xxx requires the analysis, communication, comparison and [alignment] of [concepts] within and across authoritative tiers, addressing broad (high-level) to specific (low-level) enterprise environments. These requirements necessitate the creation of formal, semantically enabled models [of the concepts], and their identifying and supporting properties, relationships and individuals. Providing both a formal encoding and semantic richness allows normalization of the definitions (intent) and provides the ability to aggregate, compare, and reason over the [concepts]. These tasks and requirements are well-aligned to the goals and capabilities of an ontology-based approach. Ontologies, defined using W3C's OWL, can be created, stored and reasoned over using COTS tooling. In addition, many complementary supporting ontologies can be immediately imported, aligned and reused (such as the provenance and time/event ontologies from W3C, an ISO-3166 country ontology at downlode.org, and specific domain ontologies such as Xxx). Even if existing data is not in an ontological format, but is perhaps stored as a relational database, there is existing tooling to convert this data to an RDF encoding. (Taking this approach removes the need to use complex staging tables to mediate database information.) Using an OWL ontology as the basis for the Xxx Model allows the formalization of not only the core concepts (...) but also puts strong focus on the relationships between these concepts and the definition of formal-logic-based restrictions, facts/axioms, and rules. Using COTS OWL reasoners, logical analyses of the consistency, completeness and minimal set definitions are straightforward, along with the ability to align concepts and infer new data based on logical expressions and if/then (Horn) rules. Communication of a standardized, ontological, machine-understandable format [to environment-specific] translation agents will produce consistent, traceable and auditable definitions for specific end-point implementations.
From: henson graves [mailto:henson.graves@xxxxxxxxxxx]
Sent: Fri 1/20/2012 9:00 AM
To: 'Ontology Summit 2011 discussion'
Cc: 'Matthew West'
Subject: [ontology-summit] Summit Engineering Tracks The track co-champions are soliciting input, participation, and references
for the two tracks on engineering of large systems and the resulting
engineered systems.
My interest for the engineering tracks is to establish dialog in the Summit
not only to identify engineering problems for which ontology can offer
solutions. But to go beyond that to dialog on what ontology results and
methodology can be applied and look at use cases for its application. Many
people in the industry of developing and using engineered systems are aware
that ontology may provide value to many of their problems and issues. But
the industry position is what ontology technology can help, how do we use
it, what are the benefits, and what will it cost. At least this has always
been the management response when I have taken proposals regarding ontology
forward in industry.
If this did not go to the general interest list, someone give me a pointer
to the right one.
- Henson Graves |
_________________________________________________________________
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/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
Community Portal: http://ontolog.cim3.net/wiki/ (01)
|