From OntologPSMW

Revision as of 16:27, 18 December 2012 by PeterYim (Talk | contribs)

Jump to: navigation, search
[ ]


This is a workspace collecting suggestions on how to better organize, coordinate and facilitate OntologySummit2012 activities. While mainly intended for the use by the organizing committee, this is an open page, and contributions from other summit participants who are not on the organizing committee are welcome.     (1A)

OntologySummit2012: Ontology for Big Systems     (1B)

7th in the series of a 3-month open annual event by and for the Ontology Community. This Summit is co-organized by Ontolog, NIST, NCOR, NCBO, IAOA & NCO_NITRD     (1B1)

ref. OntologySummit     (1B2)

Ideas on How to Frame the Discourse     (1C)

From the 2011_12_08 Pre-launch Community Session prep work:     (1C1)

Systems engineering focuses on the interactions of people with their systems, so includes information technology, data and metadata, socio-technical and cultural aspects including institutional, legal, economic, and human-centered design requirements.     (1C1B)
o Software engineering     (1C1B1)
o Business rules and enterprise issues     (1C1B2)
o Socio-technical environment     (1C1B3)
o Big Data     (1C1B4)
o Ontology Quality in Context     (1C1B5)
"Big Data" to include several dimensions:     (1C1C)
o Complexity of collections     (1C1C1)
o Large quantities of data     (1C1C2)
o Heterogeneity of data (e.g. 600 different representations of patient records)     (1C1C3)
o Federation of distributed data sources     (1C1C4)
o Extracting (useful) knowledge out of big data (using ontology to UNDERSTAND data)     (1C1C5)
  • formulate recommendations for the application of ontological techniques to specific key problems we are facing in the subject area.     (1C1D)

From the 2011_12_08 community brainstorm input - items to note for action:     (1C2)

  • TimWilson: I have to leave the call soon, but I am very interested in     (1C2B)

the System Engineering aspects of Ontology as well as Ontology Acquisition, including text analytics.     (1C2C)

Systems Engineering and International Society for Systems Sciences is pursuing the development of a Unified Ontology for Systems Engineering. This effort is mostly practitioners getting ready for interaction with ontologists.     (1C2E)

(fitness for purpose, evaluation, metrics and metrics) under whichever theme.     (1C2G)

I'm suggesting is the theme-focused variant of the topic Joanne and I suggested here: A better title might be "Ontology Quality in Big System applications" or something like that. Or, "Evaluating Ontologies for Use in Big [X] Systems Applications"     (1C2I)

  • KenAllgood: I will volunteer for Ontology in electronic health     (1C2J)

record/bioinformatics     (1C2K)

Big Data and Cloud systems     (1C2M)

engineering systems, I'm happy to contribute.     (1C2O)

  • PatCassidy: I would be willing to champion a track on exploring the     (1C2Q)

use of a common foundation ontology as a translation mechanism (interlingua) among multiple databases or multiple systems - large or small. But if there are no others to make a "track" out of this, I can just present a paper with my views.     (1C2R)

the bandwidth to head this up.     (1C2T)

  • Eric Chan: + for aligning dots to tracks, I have Data, Process,     (1C2V)

Engineered, Multi-displinary,     (1C2W)

  • KenAllgood: I'd recommend "information interoperability across federated data"     (1C2Y)
  • AliHashemi: @Steve -- at the end of the last summit, there was a     (1C2Z)

consideration to alongside a Communique, explicitly commit to creating a website for the summit?     (1C2AA)

focusing down or presenting some branches/subtopics.     (1C2AD)

Ontologies in Big Systems"     (1C2AF)

track under which we bring in some folks in various domains and/or projects to describe particular cases where ontologies are being brought in to support big systems.     (1C2AH)

possibility.     (1C2AJ)

and decisions.     (1C2AL)

From JackRing / 2012.01.05     (1D)

JackRing: I suggest an System Engineering track that     (1D2)

  • a) focuses on the ontology of the human activity called system engineering, SE, and distinguishes it from the human activity called engineering of systems, EoS.     (1D3)
  • b) presumes that SE starts with an identification of the problem regardless of what sponsors, potential users and others may presume.     (1D4)
  • c) contributes to the system realization project in three key ways,     (1D5)
    • 1) specifying and demonstrating the languages and technologies that will be used in realizing the system,     (1D5A)
    • 2) imag(in)ing the intended system and 3) converging subsequent creativity to closure.     (1D5B)
  • d) notices that a system as imagined, envisioned, modeled, and realized is an evolving, situated ontology     (1D6)
  • e) acknowledges that a model of an intended system (the situated ontology) is a theory waiting to be examined for its dynamic and integrity limits (also called fallibility)     (1D7)
  • f) proposes experiments for discovering such limits, i.e., ontology quality (in the Deming/Crosby sense)     (1D8)
  • g) acknowledges that the capabilities (competencies, relationships, and capacity) of the system engineering cohort comprises a system that exhibits dynamic and integrity limits but ones that change as the cohort learns and evolves.     (1D9)
  • h) envisions techniques and tooling for knowledge exchange and choice making among the SE cohort     (1D10)
  • i) proposes metrics for     (1D11)
  • j) proposes metrics for the effectiveness of an SE cohort, e.g., quality, parsimony and beauty.     (1D12)
  • k) proposes ways of determining how much of what kind of SE, when, is best for each kind of problem.     (1D13)
  • l) does all this for each kind of system, e.g., state-determined, stochastic and non-deterministic and e.g., targeted (goal seeking), pursuit (goal-setting) and intelligent (value seeking).     (1D14)

From EricChan / 2012.01.05     (1D15)

EricChan: I have in mind about a track for "ontological information model for cloud infrastructure" with focus on "complex event processing of high-volume, high-velocity, monitoring data (Big Data)" in different layers of the infrastructure. This ontology can enable effective use of Business Activity Monitoring (BAM) tool in cloud infrastructure. ... I will be happy to support others who would like to chair this track.     (1D15A)

From HensonGraves / 2012.01.02~05     (1D16)

HensonGraves: Tracks should be designed to produce usable work products for the engineering and well as the ontology community     (1D16A)

My suggestion is that the summit develop a collection of challenge problems which different tracks work on. A track representing an interest group could take a problem and have its members propose approaches and solutions which would be critiqued by the group. A track would not have to come to a consensus solution only produce as a work product proposed solutions and critiques. Here are some examples of the kind of thing that I have in mind, based on by experience and interests. Other examples would work as well.     (1D16B)

  • 1. Develop an ontology for metadata for engineering applications. This would     (1D16C)

include artifacts such as specifications, test plans, and test results. Something like DOLCE would be a good place to start the discussion. As participants one needs people with real experience in engineering practice and ontology theory. It is not too hard to argue that an ontology is the best way to manage the volume of data encountered on large scale engineering programs. [I spent about 7 years attempting to design a metadata based information storage and retrieval system for a very large scale product development program.] I would be happy to contribute or identify others who could contribute to understanding of the data management issues of such an endeavor.     (1D16D)

  • 2. Develop engineering models (or axiom sets) for the human heart. Two     (1D16E)

approaches naturally present themselves as starting points. One is models produced in SysML and the other is Description Logic with possibly Description Graph extensions. Analysis of the difference would be of great benefit for both communities and have immediate practical applications. Along the way one needs to look at how the literature on mereology contributes or not to developing axioms.     (1D16F)

  • 3. Develop use cases for reasoning based on engineering models (axiom sets     (1D16G)

in description logic). The use cases of course have to be grounded in everyday engineering problems and have to have to be embedded in logics for which tractable reasoning is possible. [I am very much engaged with this as I have a lot of industry experience with relatively simple cases where checking consistency of axiom sets would have saved the taxpayer a few billion dollars and 4 or 5 years of product development time. The problem is that engineering models do not represent the assumptions under which they are valid. As design progresses a model gets included in a design without knowledge of the assumptions under which it is valid. The result is inconsistent designs and the inconsistency is often not detected until test and evaluation, which of course may require years of rework to fix.]     (1D16H)

If this approach with the challenge problems were to be attractive then I would be willing to participate with the proviso that I could get some folks from the ontology community to join the INCOSE Model-Based System Engineering Ontology Action Team (OAT).     (1D16I)

From: NancyWiegand / 2011.12.17     (1D17)

NancyWiegand is the PI for the NSF funded SOCoP_INTEROP Project     (1D17A)

NancyWiegand: [Part of the OntologySummit2012 focus looks] ... similar to what I was thinking about for an INTEROP workshop, maybe along with an EarthCube Cyberinfrastructure (ref. workshop?     (1D17B)

[ppy] indeed ... as all these things are quite interrelated. ... The (community's) choice of the theme: "Ontology for Big Systems" does give us enough latitude to try to reach out to other Systems communities (enterprise architecture, conceptual modeling, software engineering, etc.) and team up with them to tackle "Big Systems" -- not pilot system, but real life, complex, heterogeneous, distributed system ... and not the least, the "hot-button" issues facing those who are dealing with "Big Data." ... While the Ontology Summit would come from a vantage point of Ontology (teamed up with collaborators in Systems Sciences and Engineering,) the kind of "Big Systems" as exemplified by, say, the Earth Cube Cyberinfrastructure (ref. would obviously be a great application that can be examined. Therefore, if the timing is right, and you could put in the bandwidth to contribute to a track (and portions of a track), let's talk some more about possible collaboration and your (+your team's) involvement in the coming Ontology Summit.     (1D17C)

Recap: AmandaVizedom and JoanneLuciano / 2011.12.06     (1D18)

An Objective Metrics for Understanding Ontology Quality in Context -     (1D18A)

Recap: CoryCasanave / 2011.10.27     (1D19)

OMG-SIMF collaboration - Suggested Theme: Either "Information Federation with Ontologies" or "Solving the Data Problem". A focus on the practical application of ontological methods and tools to a problem facing every large organization - understanding and using data from independently conceived resources together. The concerns of information federation are not the same as the concerns of these other ontology use cases (such as proof) and this may result in differences in ontological approach, languages, notations, tooling and even theories. Federated data is inherently distributed, uncoordinated, messy and conflicting - yet there is value in leveraging these disparate data resources in a more unified way. It is not always clear how "neat" solutions work in this unstructured world, yet the very "scruffy" solutions seem to be insufficient. A position of the community on this question could help the application of ontologies, ontological tooling and ontological approaches to this important problem. CoryCasanave / 2011-10-27        (1D19A)