OntologySummit2012: Suggestions (31AO)
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. (31AP)
OntologySummit2012: Ontology for Big Systems (31AQ)
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 (31BG)
ref. OntologySummit (31AR)
- [ ontology-summit-org ] message archives - http://interop.cim3.net/forum//ontology-summit-org/ (organizing committee members only) (31AS)
- [ ontology-summit ] message archives - http://ontolog.cim3.net/forum/ontology-summit/ (open - for all summit participants) (31AT)
Ideas on How to Frame the Discourse (31AU)
From the 2011_12_08 Pre-launch Community Session prep work: (31AV)
ref. http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2011_12_08#nid30GJ (31AW)
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. (31AX)
"Big Data" to include several dimensions: (31B3)
- formulate recommendations for the application of ontological techniques to specific key problems we are facing in the subject area. (31B9)
- Potential supporting tracks: (31BA)
From the 2011_12_08 community brainstorm input - items to note for action: (31BH)
ref. under: http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2011_12_08#nid3085 (31BI)
- TimWilson: I have to leave the call soon, but I am very interested in the System Engineering aspects of Ontology as well as Ontology Acquisition, including text analytics. (31BJ)
- JackRing: A joint Working Group of the International Council on 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. (31BK)
- AmandaVizedom: I will volunteer for a Quality in Context Track
(fitness for purpose, evaluation, metrics and metrics) under whichever
theme. (31BL)
- JackRing: @Amanda, are you including the quality of an ontology? (31BM)
- AmandaVizedom: Yes, that's what I mean, thanks for asking. The track I'm suggesting is the theme-focused variant of the topic Joanne and I suggested here:http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit/Suggestions#nid30E4. 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" (31BN)
- KenAllgood: I will volunteer for Ontology in electronic health record/bioinformatics (31BO)
- MichaelRiben: idea for track- NoSQL infrastructure and Ontology for Big Data and Cloud systems (31BP)
- MatthewWest: If there is interest in a thread on ontology of big
engineering systems, I'm happy to contribute. (31BQ)
- ToddSchneider: How about 'Ontological Analysis in Systems Engineering'? (31BR)
- MatthewWest: @Todd That sounds close to what I was suggesting. Happy to merge. (31BS)
- ToddSchneider: Matthew, sound good to merge. (31BT)
- PatCassidy: I would be willing to champion a track on exploring the 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. (31BU)
- MikeBennett: I'd like to suggest ontology sharing etc. but don't have the bandwidth to head this up. (31BV)
- Eric Chan: + for aligning dots to tracks, I have Data, Process, Engineered, Multi-displinary, (31BY)
- MichaelRiben: tract title: Enhancing Big Data Analytics with Ontologies (31BZ)
- KenAllgood: I'd recommend "information interoperability across federated data" (31C0)
- AliHashemi: @Steve -- at the end of the last summit, there was a
consideration to alongside a Communique, explicitly commit to creating
a website for the summit? (31C1)
- AliHashemi: I can volunteer, but I definitely won't be able to do it alone. (31C2)
- KenAllgood: I could assist Ali in the website (31C3)
- AmandaVizedom: I'd like to see a track refining "Big Systems," either
focusing down or presenting some branches/subtopics. (31C4)
- AmandaVizedom: Track proposal: Use cases / examples? "Use Cases for Ontologies in Big Systems" (31C5)
- AmandaVizedom: For that use cases suggestion, I'd imagine that as a 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. (31C6)
- JackRing: @Peter, I hope the outcome will be an ontology!! (31C7)
- ToddSchneider: Jack, Excellent thought, but an ontology of what? (31C8)
- MatthewWest: @Todd - an ontology of systems (broad sense) might be a possibility. (31C9)
- JackRing: @Todd, An ontology of benefits of ontology-based systems and decisions. (31CA)
- ToddSchneider: Jack, Brilliant! (31CB)
From JackRing / 2012.01.05 (31D8)
ref. http://interop.cim3.net/forum/ontology-summit-org/2012-01/msg00016.html (31D9)
JackRing: I suggest a System Engineering (SE) track that (31DA)
- 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. (31DB)
- b) presumes that SE starts with an identification of the problem regardless of what sponsors, potential users and others may presume. (31DC)
- c) contributes to the system realization project in three key ways, (31DD)
- d) notices that a system as imagined, envisioned, modeled, and realized is an evolving, situated ontology (31DG)
- 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) (31DH)
- f) proposes experiments for discovering such limits, i.e., ontology quality (in the Deming / Crosby sense) (31DI)
- 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. (31DJ)
- h) envisions techniques and tooling for knowledge exchange and choice making among the SE cohort (31DK)
- i) proposes metrics for (31DL)
- j) proposes metrics for the effectiveness of an SE cohort, e.g., quality, parsimony and beauty. (31DQ)
- k) proposes ways of determining how much of what kind of SE, when, is best for each kind of problem. (31DR)
- 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). (31DS)
From EricChan / 2012.01.05 (31CJ)
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. (31CK)
From HensonGraves / 2012.01.02~05 (31CC)
HensonGraves: Tracks should be designed to produce usable work products for the engineering and well as the ontology community (31CD)
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. (31CE)
- 1. Develop an ontology for metadata for engineering applications. This would 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. (31CF)
- 2. Develop engineering models (or axiom sets) for the human heart. Two 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. (31CG)
- 3. Develop use cases for reasoning based on engineering models (axiom sets 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.] (31CH)
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). (31CI)
From: NancyWiegand / 2011.12.17 (31CN)
NancyWiegand is the PI for the NSF funded SOCoP_INTEROP Project (31CO)
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. http://www.nsf.gov/geo/earthcube/) workshop? (31CP)
[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. http://www.nsf.gov/geo/earthcube/) 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. (31CQ)
Recap: AmandaVizedom and JoanneLuciano / 2011.12.06 (31CL)
An Objective Metrics for Understanding Ontology Quality in Context - Towards Objective Metrics for Understanding Ontology Quality in Context (AmandaVizedom and JoanneLuciano) Picking up threads from several prior Summits, armed with the progress made in distinguishing families of ontology application use cases (see, e.g., the Application Cases and Usage Framework Syntheses from OntologySummit2011, at http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2011_ApplicationCases_Synthesis and http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2011_ApplicationFramework_Synthesis, respectively), we are now in a position to push beyond the agreement to disagree that has characterized discussions of ontology quality to date. Specifically, we can work as a community to identify ontology quality characteristics relevant to (families of) ontology applications. We take this suggestion to be compatible with LeoObrst's suggestion at http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit/Suggestions#nid2YXA, FabianNeuhaus's suggestion at http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit/Suggestions#nid2YXC, MichaelUschold's suggestion at http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit/Suggestions#nid2YXE, the quality and requirements aspects of OntologySummit2010, and other suggestions made at various times in the Ontolog community. We believe that our suggested topic focuses these energies on a circumscribed and yet broadly-applicable step in making progress toward ontology quality across domains and lifecycle stages (e.g. development, evaluation, reuse, and ontologist training). (See also Slideshare presentation by Joanne Luciano http://www.slideshare.net/joanneluciano/luciano-pr-08849ontologyevaluationmethodsmetrics-8294436 T (31CM)
Recap: CoryCasanave / 2011.10.27 (31CR)
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 T (31CT)
ref. also http://ontolog.cim3.net/forum/ontolog-forum/2011-12/msg00089.html (31CS)