Foundations for System Implementation a Centralised Intelligence ...

3 downloads 9853 Views 688KB Size Report
Intelligence Fusion Framework for Emergency Services ... intelligence fusion framework to provide data and information fusion for ..... daily business. From this ...
12th International Conference on Information Fusion Seattle, WA, USA, July 6-9, 2009

Foundations for System Implementation for a Centralised Intelligence Fusion Framework for Emergency Services Daniel Vincen Innovation Works EADS UK Newport, Wales, UK

[email protected]

Dafni Stampouli Innovation Works EADS UK Newport, Wales, UK [email protected]

Abstract - There is an identified need for software to provide centralised command and control, information sharing, and support intelligence analysis tasks. In this paper we report on ongoing development of a centralised intelligence fusion framework to provide data and information fusion for interoperability of emergency services. In particular, the design, and specification of such a complex system is particular challenging, so this paper is focusing on the issues relating to system implementation, such as requirements and system architecture concepts. This paper aims to discuss technological foundations, and review some of available technologies which are currently combined as an initial implementation attempt. By using the described technologies for definition of hard and soft data through probabilistic enhanced ontologies and enriching service interfaces with semantic attributes in a service oriented architecture the situation and thread assessment are addressed for emergency services. Keywords: Intelligence Fusion, SOA, OWL, PR-OWL, civil authorities, HUMINT, OSINT, C4ISR

1

Introduction and Motivation

Today's non-military organisations or civilian authorities like police, fire brigades and medical services operate distinct systems which allow only the corresponding owner to access to their data. Several incident and major events in the past decade indicated the need to share information among different agencies and authorities and current government initiatives are pointing to that direction. In military scenarios such topics are already under discussion and under development [1]. Even if it is not accepted openly by many military personnel, the nonmilitary organisations have similar needs in terms of intelligence fusion as the military organisations, and an ad hoc coalition as described in [1] is similar to a scenario where several blue light forces have to work together to minimize causalities during a natural disaster. Research is ongoing in the field of sensor data fusion, information fusion, data mining and knowledge management. The term intelligence fusion is used to make the process distinct from data fusion which focuses on the 978-0-9824438-0-4 ©2009 ISIF

Gavin Powell Innovation Works EADS UK Newport, Wales, UK

[email protected]

fusion of sensor data and information fusion which combines numerical values (such as measurements of features) to support specific hypotheses. In order to explain this better the following clarification is required. Data refers to sensor recordings and raw evidence that is collected, while information on the other hand is the organised sets of data. Once information is searched, analysed, understood and explained it becomes knowledge. Knowledge encapsulates the understanding of the static and dynamic relationships of the data, and the behaviour of the entities involved. Intelligence is a special selection of knowledge required to accomplish a mission. The term intelligence fusion could be described as the process of combining intelligence obtained from already processed and fused heterogeneous sensors information in order to provide what is referred to as Common Operational Picture (COP), which allows situation awareness and aids the decision making process. For data fusion the five distinguishable levels have been identified [2]. • Level 0 - Data Alignment, • Level 1 - Entity Assessment (e.g. signal/feature/object), Tracking and object detection/recognition/identification • Level 2 - Situation Assessment, • Level 3 - Impact Assessment, • Level 4 - Process Refinement (i.e. sensor management), • Level 5 - User Refinement. The focus of this work is the combination of fused sensor data (referred to as structured data coming from existing fusion engines) and unstructured data (provided by human intelligence and open source intelligence or other systems still to be included), on Level 2 and Level 3. The aim is to provide a multi fusion engine system which: • generates an accurate Situation Awareness picture for the operator or autonomous processing system, • presents information easier to interpret, should concentrate attention on high-interest findings and reduce clutter, • allows better use of expensive resources, • allows easier to interpret results, • provides more timely and effective decisions.

1401

1.1

Paper Overview

Section 2 of this paper describes the data and information collected from the various sources in order to be fused. Section 3 describes the design of a system that allows such a level of intelligence fusion, including system requirements, relevant technologies and initial ideas about a common analysis framework structure. Finally we present our conclusions and next steps for future work in Section 4.

2

Data acquisition

The emergency services (police, fire brigade and ambulance services) and civil authorities have independent not interoperable systems to hold the data they need for their daily operations. The content of those systems is usually produced by them and kept confidentially, if this is not regulated by law. When information needs to be communicated between organisations, a lengthy bureaucratic procedure is required, in which a request is emailed to the organisation possessing the information of interest which in turn might take weeks to respond. Furthermore the quality of the information sent depends on the operator processing the request. Therefore there is a great lack of interoperability and effective communication between systems from the different emergency services, and in some cases even within one organisation such as the Police . The information provided by the sources into the fusion engine is of various types: • video from surveillance cameras or in the near future from portable devices carried by the officers attending the event, • information from existing operational systems such as the automatic number plate recognition system (ANPR) that the Police uses, • image data obtained by police aerial platforms (Unmanned Arial Vehicles, aeroplanes, helicopters) providing surveillance an area of interest, • police reports coming from human sensors, obtained during investigation, or observation, (human intelligence), • reports from the public (both victims and witnesses), • individual informers, • national databases and liaison with other civilian agencies, organisations and authorities such as Children and Violent Adults, (CAVA) and the Violent and Sex Offenders register (VISOR), • information openly accessible on the internet (open source intelligence, e.g. Youtube, Facebook, Etc.). We are currently also working on fusion of soft sensor data such as HUMINT and OSINT. The proposed system shall be able to fuse information coming from different sources which provide structured information, like the systems and fusion engines which exist at the moment. Nevertheless additional information is needed, coming from sources like

Open source Intelligence (OSINT) and Human Intelligence (HUMINT). Therefore the system shall be able to handle unstructured (intelligence) information. HUMINT, which is defined by NATO [3] as “… a category of intelligence derived from information collected and provided by human sources”, tends to be far more subjective than traditional sensor reports. Sensors produce sensor data which is in the first instance a JDL level 1 feed, but HUMINT can be relevant for all levels of the JDL fusion model. One important aspect of the system is to be able to deal with delays in the incoming data, especially HUMINT and OSINT. Therefore the system should be able to process sensor data as they come and then update the situation picture when non-real time data arrives from human reports. This is important, since traditional sensors usually have low data latency, while the latency of HUMINT can be much longer (e.g. hours for news reports, days for a counterintelligence reports). According to [4] OSINT is defined as “… intelligence produced from publicly available information and is collected, exploited, and disseminated in a timely manner to an appropriate audience for the purpose of addressing a specific intelligence requirement.” The US Committee of Homeland Security classified Open source information in [5] as: • information that is widely available to anyone • commercial data • the expertise of individual experts • “grey” literature, consisting of written information produced by the private sector, government sources, and academia that is available on only a limited basis. So-called grey literature is typically limited because few copies are produced, the existence of the material is largely unknown, or access to information is not readily available via the Internet. Within these categories, open source information can include: • Media sources such as newspapers, magazines, radio, television, and the Internet; • Public data such as government reports, budgets, demographics, hearing materials, legislative history, press conferences, and speeches; • Information derived from professional and academic sources such as conferences, symposia, professional associations, academic papers, dissertations and theses, and experts • Commercial data such as commercial imagery • So-called “grey literature” such as working papers, discussion papers, unofficial government documents, proceedings, research reports, studies, and market surveys. However there is a need to quantify the reliability and uncertainty of HUMINT data, and incorporate this into the fusion model. In [24] we address this issue and incorporated in the development of a Centralised Intelligence Fusion Framework for Emergency Services.

1402

3

System Engineering

This section describes the issues arising concerning the development of a centralised fusion framework and the technologies and concepts that could be used to address such issues. Figure 1 displays the general role of fusion, in this special case Intelligence Fusion in an information processing system. The role of Intelligence fusion is the process of combining information/intelligence to estimate or predict the state of the environment based on collected evidence from observable data. Observe

Orient

Sensor Sources

Intelligence Fusion User Interface

Environment

Response Systems

Resource Management

Act

Decide

Figure 1 Intelligence Fusion in Information Processing Systems (adapted from [6]) This generic role, represented by the node "Intelligence Fusion" in Figure 1 is further defined in Figure 2, which shows a generic data fusion model which focuses on situation and threat assessment as the main use cases which shall be supported the centralised intelligence fusion framework. The diagram presents the processes and issues involved in data fusion process such as planning, data collection, data association, situation assessment and threat assessment [24].

Figure 2 Generic data fusion model for situation and threat assessment.

3.1

System Requirements

The requirements for a system which shall be able to handle hard and soft data are reviewed in this section. Hard data is defined as the electronic sensor data from traditional sensors, while soft data is the data from non-traditional sensors, such as humans. The system should be flexible enough to deal with different kind of information. Each type of data produces different requirements for example, different storing and handling of data formats, different

ways to access the data and the input sources. For the centralised intelligence fusion framework we are planning to use existing hard fusion engines, such as FURET II and Fusion++. Fusion ++ [7] is an object oriented development suite for data fusion. It manages various issues in the data fusion development like design, implementation, and simulation. It allows the realisation of high sophisticated data fusion systems as applied in numerous civil and defence areas, like air traffic or satellite orbit control, coastal surveillance, air defence systems or more generally combat or battle management systems. FURET II [8] is an operational demonstrator for datafusion intended to merge information gathered by a wide variety of sensors and used principally for tactical intelligence at military applications. Its main functions are: Multi-source data collection, data storage, cartographic display of data, visualisation and filtering of data to be displayed, fusion of data into target tracks, manual identification of target along with automated suggestions by the system, situation and target reporting and generation of work picture that is communicated across different levels of command and control. The system also supports sensor and expert tasking requests. Further development is focusing on extraction of knowledge from soft data like HUMINT and OSINT. HUMINT and OSINT should not be treated as sensors like traditional ones, which typically produce highly structured outputs, HUMINT and OSINT tend to be mainly unstructured. In order to fuse them with traditional multisource data, HUMINT and OSINT data must first be pre-processed with the aim of extracting knowledge from them. This includes extraction of object attributes (i.e., name, location, time) along with other relevant attributes (e.g., language, action, etc.). An enhancement of classical sensor data with HUMINT and OSINT findings has a big impact on the system design which adds following objectives as based from [9]: • handle high amounts of raw data, especially from OSINT, • quickly research complex networks to obtain key information, • readily integrate new components and other systems i.e. upgradeable without major architectural change, • include learning components for parameter optimization, • aim for real time performance for transmission, • include semi-automatic components to assist the HUMINT members in their functional tasks which might include the automated correlation of relational activities and the automated aggregation of events by time, location, structure, activity, modus operandi, characteristics and demography, • include information storage, information display and communication, • include information processing such as data and information fusion components,

1403



arbitrate the competing/complementary interests of various military/civilian agencies requiring access to the same HUMINT information for different goals.

The connection of multiple fusion engines and sources can only be done through a network, which can be of an ad-hoc or a fixed infrastructure model. Both system models should be able to handle dynamic changes of the environment, either by automatic reconfiguration or manual configuration. This is necessary to support different mission styles, e.g. fixed infrastructure where defined fusion engines and sources are configured to work together to fulfil a specific ongoing task like surveillance of an area or the investigation of an incident like a burglary. An ad-hoc mission would be the temporary connection of the fusion engines and sources in case of a disaster or a major attack by terrorist. Each system which shall be able to fuse a large variety of information types should be able to make use of existing fusion engines which are specialised on specific information types. Therefore the architecture should be kept open to existing or future fusion engines. An open architecture using multiple fusion engines, some of them maybe unknown at the moment, needs to solve general questions about these fusion engines: • How is the fusion engine to be found in the system • How is the interface of the fusion engine to be defined, incl. operations and data • How are quality of services for fusion engines defined

3.2.1

A Service Oriented Architecture (SOA) is such an open architecture. SOA has become the leading approach for accessing and using distributed services and resources, which have been developed by independent organisations. Such services and resources have their own vocabularies and semantics behind them. The way to describe services in a SOA is the Web Service Description Language (WSDL, [12]) which provides for that an XML structure. WSDL allows the definition of message types, interfaces, bindings, and services. • • • •

message types are the kinds of messages that the service will send and receive. interface describes what functionality the web service provides binding describes how to access the service. service describes where to access the service.

A service whose interface is described using WSDL can be used per definition by any other service which has access to the WSDL file. The usual procedure to get such a WSDL file is through request to an XML-based registry called Universal Description, Discovery and Integration (UDDI) which enables to publish service listings, discover other services and define how the services or software applications interact over the Internet or network [13]. UDDI UDDI

These questions/problems are not new if a fusion engine is seen as some kind of service. The demanding need for Enterprise Application Integration [10] which is defined as the use of software and computer systems architectural principles to integrate a set of enterprise computer applications, in our case has led to Service Oriented Architecture [11] which is in the moment mostly implemented through webservices.

3.2

Service Oriented Architecture

Service Broker (Registry)

find

WSDL WSDL

Service Requester

Technologies

As previously discussed, different fusion engines have been developed to fuse multi-source data, e.g. images, synthetic aperture radar data, ELINT, etc, to produce structured representation of the environment. The technologies shown here shall allow the combination of that structured information with data from unstructured or less structured sources such as national databases and GIS in order to provide a more complete situation awareness and aid the threat and impact identification process. This section shows the different technologies which have been taken into account for the design of centralised intelligence fusion framework which shall improve intelligence fusion by allowing the (re-)use of other specialised fusion engines for specific data types such as sensor tracking, object recognition, etc.

publish

WSDL WSDL

SOAP SOAP

Service Provider

Figure 3 Webservice triangle A new extension for SOA has been the evolution towards a central bus to connect the participating services. Therefore is now the core component of this architecture an Enterprise Service Bus (ESB) which allows the loosely coupled connection of services in a system [14]. Services for intelligence fusion systems provide data from sensors, databases, etc. and fused information through the connection to other fusion engines. These existing fusion engines (FURET II and FUSION++) will do the low-level fusion tasks, such as tracking a target, while the higher level fusion shall be done by another fusion engine, which is under development.

1404

3.2.2

Semantic and Ontologies

OWL-S

As WSDL does not take into account any semantic behind an interface description for a service other ways are needed to describe: • what the service does, • how to access it and • how it works. A couple of standards have been developed to address these issues: OWL-S (Semantic Markup for Web Services) [15], SWSL [16], SAWSDL [17] and WSDL-S [18] (both now combined in WSDL 2.0) and WSMO [19]. OWL-S is widely seen as the most promising, "OWL-S is an ontology, within the OWL-based framework of the Semantic Web, for describing Semantic Web Services. It will enable users and software agents to automatically discover, invoke, compose, and monitor Web resources offering services, under specified constraints" ([15]). To allow the definition of the service a service ontology as displayed in Figure 4 was defined. Service

describedby (how it works)

presents (what it does) ServiceModel

supports (how to access it) ServiceProfile ServiceGrounding

The ServiceProfile is used to advertise the service. This information is primary meant for human reading, and includes the service name and description, limitations on applicability and quality of service, publisher and contact information The ServiceGrounding provides the necessary details about transport protocols that a client needs to interact with the service, as communication protocols, message formats, port numbers, etc. The ServiceModel describe the ‘process model’ of the service, e.g. how a client can interact with the service. This description includes the sets of inputs, outputs, preconditions and results of the service execution. A service defined in OWL-S needs a real service in the background, which fulfils the operations described in the OWL-S definition. Such an implementation can be realized (grounded) through a service defined in WSDL.

DL-based Types

Atomic Process

Inputs / Outputs

Operation

Message

Binding to SOAP, HTTP, etc WSDL Figure 5 Mapping between OWL-S and WSDL (from [15]) The grounding can be seen as the mapping from an abstract (OWL-S) to a concrete specification (WSDL) of those service description elements that are needed for interacting with the service. This mapping between OWL-S and WSDL is displayed in Figure 5. As WSDL is extensible, it allows the description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. By using this extensibility of WSDL, services described in OWL-S can ground webservice processes. For using OWL-S as a semantic description for the common tasking in our multi fusion engine system we will have to include the respective OWL-S structures in the WSDL files which shall define the service provided by the available fusion engines.

3.3

Figure 4 Top level of the service ontology (from [15])

Process Model

System design

The different technologies which are needed to provide the necessary environment for the intelligence fusion have a big impact on the design of the complete system. Figure 6 shows the technical architecture resulting from a SOA approach. The existing fusion engines (FURET II, FUSION++) will be addressed via a common tasking interface and will exchange data in a common analysis structure. For the definition of the interface WSDL shall be used, an extended with OWL-S. The Common Analysis Structure is described in chapter 3.4.

1405

A Centralised Intelligence Fusion Framework which will be able to handle the large variety of structured and unstructured information has to have several components (as shown in Figure 7) which are dedicated to a different task: • • •

An Intel-Broker, which keeps track of all external sources (structured, unstructured) and their provided functionality An Inter-Information Management System which provides available internal background information An Intelligence Fusion Processor, which is responsible for the JDL Level 2 and Level 3 fusion

For the interaction with the user the dedicated component Intelligence Integration Client is needed.

Figure 6 Technical Architecture

Figure 7 Internal Architecture

3.4

semantics. OWL has three increasingly-expressive sublanguages: OWL Lite, OWL DL, and OWL Full. • OWL Lite has a low formal complexity for those users which primarily need a classification hierarchy and simple constraints. OWL Lite provides a quick migration path for thesauri and other taxonomies. • OWL DL supports those users who want the maximum expressiveness while retaining computational completeness and decidability OWL DL includes all OWL language constructs, but they can be used only under specific restrictions (see ref [20] for details). OWL DL is named due to its

Common Analysis Structure

The exchange of information between the different fusion systems shall be done using a single description of the intelligence information through a Common Analysis Structure (CAS). To ensure consistency for all connected/available fusion engines an ontology shall be defined for the data to be exchanged. The de facto standard for describing ontologies is OWL [20]. OWL is based on XML, RDF, and RDF Schema (RDF-S) and provides additional vocabulary together with a formal

1406



correspondence with description logics, a field that forms the formal foundation of OWL. OWL Full has the highest formal complexity for users who want maximum expressiveness and the syntactic freedom of RDF with no computational guarantees. OWL Full allows an ontology to augment the meaning of the pre-defined (RDF or OWL) vocabulary. It is unlikely that any reasoning software will be able to support complete reasoning for every feature of OWL Full.

assign values to more than one options improving the representation of the beliefs and reducing the biases.

4

Conclusions and Next Steps

The technological foundation of a centralised framework, for data fusion, that is applicable to the emergency services has been discussed. A diverse set of data types will need to be supported by the system to enable intelligence fusion to be performed. This gives rise to various requirements when designing the system architecture. This will provide a more complete and accurate ‘situation awareness’, and therefore a better ‘decision support’ to the human command and control operators. The technologies include current development approaches for system integration like Service Oriented Architecture and ongoing research on the semantic enhancement of the provided services. Additionally technologies which are based on ontologies to provide a dictionary for participating fusion engines for a common analysis structure are utilised. The new intelligence gained from the fusion of traditional structured hard sensor data with unstructured soft data, like HUMINT and OSINT, needs a proper representation of the implied uncertainty. This uncertainty can be modelled through PR-OWL, an extension of the OWL which incorporates MEBN together with Description Logic. Theses technologies shall not eliminate the human operators/commanders, but should instead compliment them. Information will be delivered to them in a meaningful and timely manner which will reduce the workload, prevent information overload and enhance the process of human assessment. As next steps we will define, together with civil authorities, the exact types of data they need for their daily business. From this information we will derive a common analysis structure which will describe the relevant hard and soft data for the exchange between different fusion engines. Part of a common definition will be a ‘fusion engine interface description’ which will allow for a common tasking. For the fusion process the foundations shown shall provide the framework, which allows different fusion technologies to be verified and combined in the most suitable way.

OWL as other ontology describing formalisms (Common Logic, Cyc, IDEF5, etc.) is based on classical logic and provide no consistent support for uncertainty representation or reasoning. Therefore an extension to OWL is needed to capture this lack. Costa describes in his PhD thesis PR-OWL as a Bayesian extension to the OWL Ontology Language [21]. PR-OWL which is a formal knowledge representation that expresses knowledge about a domain which includes (adapted from [21]): • Types of entities that are relevant in the domain • Properties of those entities • Relationship between those entities • Processes that happen with those entities • Statistical regularities in that domain • Inconclusive, ambiguous, incomplete, unreliable, and dissonant knowledge related to entities of the domain • Uncertainty about all the above forms of knowledge. PR-OWL enables the representation of Bayesian probabilistic models, in OWL. The Bayesian probabilistic models in PR-OWL are Multi Entity Bayesian Networks (MEBN) which integrate first order logic with Bayesian probability (for more details about MEBN see [22]). Probabilities for HUMINT reports have been introduced in the way the police are grading information to decide how to record, evaluate and disseminate given information. The UK police forces use the National Intelligence Model (NIM) produced on behalf of the Association of Chief Police Officers in the UK [23]. The NIM model is used to provide guidance on characterising the information based on the nature of the information, the way it was obtained, or the circumstances of the person providing the information, which indicates whether the information should be treated in confidence or in a sensitive manner. hawse have incorporated the suggested model to grade each piece of information according to certain attributes as discussed in [24] Rather that simply stating the source as reliable or not, a percentage rating is given at the values of the attribute that are considered most appropriate. Therefore during the input of the information the operator can

References [1] T. Pham, G.H. Cirincione, D. Verma and G. Pearson, “Intelligence, Surveillance, and Reconnaissance Fusion for Coalition Operations” 11th International Conference on, Information Fusion, Cologne and June 30 2008-July 3 2008 [2] J. Llinas, C. Bowman, G. Rogova, A. Steinberg, E. Waltz, F White. “Revisiting the JDL Data Fusion Model II.” In Proceedings of 7th Int. Conf. on Information Fusion. 2004. [3] NATO Allied Publication. 2004. “NATO GLOSSARY OF TERMS AND DEFINITIONS

1407

(ENGLISH AND FRENCH)”, p 105, [Online] NATO Available at: http://www.dtic.mil/doctrine/jel/other_pubs/aap_6_04.pd f [Accessed 27 February 2009]. [4] Director of National Intelligence, July 11, 2006, National Open Source Enterprise, Intelligence Community Directive, Number 301 [5] Committee of Homeland Security, September 2008, “Giving a Voice to Open Source Stakeholders: A Survey of State, Local & Tribal Law Enforcement” [6] D. Hall, Llinas J, “Handbook of Multisensor Data Fusion”, Boca Raton, CRC Press 2008 [7] K. Dastner, T. Kausch, and F. Opitz, “An object oriented development suite for data fusion: Design, generation, simulation and testing” 11th International Conference on, Information Fusion, Cologne and June 30 2008-July 3 2008 [8] Janes, 10 May 2007. “FURET 2 (France), Intelligence systems - Analysis and support.” [Online] Surrey, UK Available at: http://www.janes.com/articles/Janes-C4ISystems/FURET-2-France.html [Accessed 25 February 2009]. [9] L. Pigeon; Beamish C J; Zybala M, “HUMINT Communication Information Systems for Complex Warfare”, Presented at the 7th International Command and Control Research and Technology Symposium (ICCRTS 2002) held in Quebec City, Canada on 16-20 Sep 2002. [10] J. Gable, March/April 2002 “Enterprise Application Integration”. [Online] Information Management Journal Vol. 36, No. 2, Available at: http://findarticles.com/p/articles/mi_qa3937/is_200203/a i_n9019202 [Accessed 25 February 2009]. [11] T. Erl, “Service-Oriented Architecture: Concepts, Technology, and Design”, Upper Saddle River, NJ, USA, Prentice Hall 2005 [12] World Wide Web Consortium (W3C), 26 June 2007. “Web Services Description Language (WSDL) Version 2.0 Part 0: Primer.” [Online] W3C Available at: http://www.w3.org/TR/2007/REC-wsdl20-primer20070626/ [Accessed 25 February 2009]. [13] Organization for the Advancement of Structured Information Standards (OASIS), 19 October 2004. “UDDI Version 3.0.2.” [Online] W3C Available at: http://uddi.org/pubs/uddi-v3.0.2-20041019.htm [Accessed 25 February 2009]. [14] D.A. Chappell., “Enterprise Service Bus: Theory in Practice”. Sebastopol, CA, USA, 2004. [15] World Wide Web Consortium (W3C), 22 November 2004. “OWL-S: Semantic Markup for Web Services” [Online] W3C Available at: http://www.w3.org/Submission/OWL-S/ [Accessed 25 February 2009].

[16] S Battle,. et al., 2005, “Semantic Web Services Framework (SWSF) Overview”. [Online] The DARPA Agent Markup Language, Available at: http://www.daml.org/services/swsf/1.0/overview/ [Accessed 10 March 2009] [17] World Wide Web Consortium (W3C), 28 August 2007, “Semantic Annotations for WSDL and XML Schema.” [Online] W3C Available at http://www.w3.org/TR/sawsdl/ [Accessed 10 March 2009] [18] World Wide Web Consortium (W3C), 7 November 2005, “Web Service Semantics - WSDL-S” [Online], W3C Member Submission, Available at http://www.w3.org/Submission/WSDL-S/#S42. [Accessed 11 March 2009] [19] J. Domingue; H. Lausen, and D. Fensel, (Chairs) ESSI Web Services Modelling Ontology Working Group. [Online], Available at: http://www.wsmo.org. [Accessed 10 March 2009] [20] World Wide Web Consortium (W3C), 10 February 2004, “OWL Web Ontology Language” [Online], W3C, Available at http://www.w3.org/TR/owl-features/. [Accessed 10 March 2009] [21] C. G. P. Costa, “Bayesian Semantics for the Semantic Web”. Doctoral Thesis, School of Information Technology and Engineering, George Mason University. Fairfax, VA, USA, 2005. [22] K.B Laskey, “MEBN: A Logic for Open-World Probabilistic Reasoning.”, The Volnegau School of Information Technology and Engineering, George Mason University, Fairfax, VA, USA, 2005 [23] National Criminal Intelligence Service, 2000, “The National Intelligence Model”, UK [24] D. Stampouli, D. Vincen, G, Powell, Situation Assessment for a Centralised Intelligence Fusion Framework for Emergency Services. 12th Conference on Information Fusion, Seattle US, 2009.

1408

Suggest Documents