https://ontologforum.com/index.php?action=history&feed=atom&title=OntologySummit2012_Applications_Synthesis 2026-06-10T19:58:24Z Revision history for this page on the wiki MediaWiki 1.39.0 https://ontologforum.com/index.php?title=OntologySummit2012_Applications_Synthesis&diff=233&oldid=prev 2016-01-09T08:18:54Z

<p>Fix PurpleMediaWiki references</p> <p><b>New page</b></p><div>= [[OntologySummit2012|Ontology Summit 2012]]: (Track-4) &quot;Large-scale domain applications&quot; Synthesis =<br /> <br /> == Mission Statement ==<br /> <br /> '''This track will help to ground the discussions in the other tracks and bring key challenges to light by describing current large-scale systems and systems of systems that either use, or could use, ontologies in their deployment. &quot;Large-scale&quot; can mean either very large data sets, very complex data sets, federated systems, highly distributed systems, or real-time, continuous data systems. Examples of large data sets might include scientific observations and studies; complex data sets could be technical data packages for manufactured products, or electronic health records; federated systems could include information sharing to combat terrorism, highly distributed systems includes items such as the smart electrical grid (aka Smart Grid), and real-time systems include network management systems. Of course, some big systems might include all five aspects.''' <br /> <br /> see also: [[OntologySummit2012_Applications_CommunityInput]] <br /> <br /> ----<br /> <br /> == In implemented systems, ontologies are... ==<br /> <br /> * Strong for: <br /> ** Supporting change and aggregation <br /> ** Enabling community aggregation, annotation <br /> ** Automated data ingestion <br /> ** Data validation <br /> ** Ensuring consistency of terms across many data sets (Distributed systems) <br /> ** Supporting reasoning <br /> ** Self describing systems <br /> ** Systems with many complex constraints, rules, laws, with frequent changes (Dynamically changing systems) <br /> ** Data mining / semantic signature extraction <br /> ** Rapid system building <br /> * Weak for: <br /> ** Being understandable by software engineers and customers <br /> ** Query performance (compared to relational databases) <br /> <br /> == Needs ==<br /> <br /> * Need better standards for common elements: <br /> ** Datatypes <br /> ** Ontology patterns (e.g. whole/part patterns) <br /> ** Collect ontological primitives from observation data <br /> * Need repositories <br /> ** Repositories of ontological patterns could be more useful than repositories of ontologies <br /> * Need industrial strength semantic services resident in the cloud <br /> * Need better visualization tools and approaches <br /> * Need better tools to help interpret legacy systems, transform into semantic systems. <br /> * Need to establish feedback mechanisms from end users to ontology designers directly from point of use. <br /> <br /> == Recommendations ==<br /> <br /> * Look for the 80-20 rule of semantic development <br /> * Use well defined and narrow use cases to demonstrate benefits of semantic approaches <br /> * Having explicit vocabularies (classifiers) is a must in a distributed system; <br /> * Community should be included in the development and evolution of vocabularies <br /> * It is critical to capture and evolve domain knowledge in a form that the community is comfortable with <br /> * Transition from implicit domain knowledge to explicit encoding requires community consensus - and an organization to manage the consensus <br /> * Some have recommended exposing users to SKOS semantics; use more complicated constructs only on back end if necessary. <br /> <br /> == Other Observations / Lessons learned ==<br /> <br /> * UML to OWL is a common requirement for legacy systems <br /> ** Starting from scratch is rare. <br /> * Ontology patterns are very helpful, and encourage model reuse <br /> * Semantic techniques work best when not compromised by implementation tradeoffs <br /> * Semantic methods are faster to implement and easier to maintain <br /> * Semantic approaches particularly suited to systems with many complex constraints, rules, laws, with frequent changes <br /> * Incremental implementation is possible through federation of datastores <br /> * Ontologies are not always applied to enable reasoners - sometimes just as a more rigorous data modeling approach <br /> * Engineers turned ontologists often don't have the necessary background/skills <br /> * Existing infrastructure supports traditional software development far better than large-scale ontology development <br /> * There are many ontologies of dubious quality <br /> * Service-oriented architectures allow separation of code and ontology updates <br /> * Reasoner and query engine performance is highly dependent upon the exact formulation of rules and queries <br /> * No single technology/tool currently provides the best solution across all large system use cases <br /> <br /> --<br /> <br /> maintained by the Track-4 champions: [[SteveRay|Steve Ray]] &amp; [[TrishWhetzel|Trish Whetzel]] ... please do not edit <br /> <br /> [[Category:OntologySummit]] [[Category:OntologySummit2012]] [[Category:OntologyDrivenApplications]]<br /> <br /> <br /> <br /> </div>

imported>KennethBaclawski