WO2015149114A1 - Ontology mapping method and apparatus - Google Patents

Ontology mapping method and apparatus Download PDF

Info

Publication number
WO2015149114A1
WO2015149114A1 PCT/AU2015/000195 AU2015000195W WO2015149114A1 WO 2015149114 A1 WO2015149114 A1 WO 2015149114A1 AU 2015000195 W AU2015000195 W AU 2015000195W WO 2015149114 A1 WO2015149114 A1 WO 2015149114A1
Authority
WO
WIPO (PCT)
Prior art keywords
ontology
terms
ontologies
data
processing device
Prior art date
Application number
PCT/AU2015/000195
Other languages
English (en)
French (fr)
Inventor
Albert Donald Tonkin
Robert Naughton CONNELL
Michael Anthony CAVANAGH
Kamalraj JAIRAM
Qingyan Wang
Dung Xuan Thi LE
Original Assignee
Semantic Technologies Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Semantic Technologies Pty Ltd filed Critical Semantic Technologies Pty Ltd
Priority to CA2952549A priority Critical patent/CA2952549A1/en
Priority to EP15774345.1A priority patent/EP3127020A1/en
Priority to JP2016559652A priority patent/JP2017513134A/ja
Priority to KR1020167030643A priority patent/KR20170021227A/ko
Priority to CN201580029320.2A priority patent/CN106663101A/zh
Priority to US15/301,357 priority patent/US11921769B2/en
Priority to SG11201607828RA priority patent/SG11201607828RA/en
Priority to AU2015240418A priority patent/AU2015240418A1/en
Publication of WO2015149114A1 publication Critical patent/WO2015149114A1/en
Priority to IL248022A priority patent/IL248022A0/en
Priority to US18/394,830 priority patent/US20240152542A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
    • G06F16/367—Ontology
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/31—Indexing; Data structures therefor; Storage structures
    • G06F16/316—Indexing structures
    • G06F16/328—Management therefor

Definitions

  • the present invention relates to a method and apparatus for use in generating a mapping using ontologies.
  • Semantic Web technologies such as ontologies and new languages such as OWL (Web Ontology Language) and RDF (Resource Description Framework) enable the description of linked concepts such as health, medicine or engineering to be described in previously impossible detail and in a manner which is both human and machine understandable.
  • OWL Web Ontology Language
  • RDF Resource Description Framework
  • the particular business or research need may require concepts from multiple ontologies, possibly from disparate disciplines. In such cases an alignment between the concepts in the two ontologies may be required. These aligned ontologies may then be pruned to give a target ontology specific to the particular needs of the business or organisation.
  • This invention not only provides the alignment and pruning methods required, but also provides technical tools to perform semantic matching of concepts and broad naive indexes utilising synonyms and homonyms specific to the business context.
  • a user can access disparate data sources, map them to context specific ontologies, align the disparate ontologies and then prune the aligned ontologies to contain only the relevant information. They can then extract the data into a format of their choosing and access them via the generated application which understands the axioms and inferences of the underlying ontologies and implements them through program code against the target database.
  • a doctor could access patient records from multiple practice management systems, hospital and health systems plus diagnostic and imaging systems without being concerned about the various record layouts being accessed.
  • a medical researcher could join such data to laboratory research data such as genome analysis, drug development and testing and so forth.
  • Traffic engineers can join signal data to barometric data, CCTV feeds, twitter and event calendars. Telecommunications companies can accept 99% of new Call Data Record structures without needing to write specific code for each new phone feature created by each manufacturer for each model in their range.
  • US-7,464,099 provides a method of transferring content from a file and a database.
  • the file includes content instances, each content instance being associated with a respective field, and each field having a respective type.
  • the transfer is achieved by determining the type of each field, and then storing each content instance in a store in accordance with the determined field type of the associated field.
  • Each content instance can then be transferred to the database in accordance with the determined field type.
  • a similar procedure is provided for creating XML files based on content within the database.
  • the present invention provides an apparatus for use in generating a mapping using ontologies, the apparatus including at least one electronic processing device that: determines ontologies having respective ontology terms;
  • the mapping may be at least one of:
  • the ontologies may include:
  • the electronic processing device may generate a mapping to map a putative ontology to a formalized ontology.
  • the mapping may be used in transferring content from a source data store having a source data structure including a number of source data fields to a target data store having a target data structure including a number of target data fields, wherein the ontologies are associated with the source data structure and the target data structure and wherein the electronic processing device transfers content between the source data fields and target data fields using the mapping.
  • the ontologies may include a source ontology associated with the source data structure and a target ontology associated with the target data structure.
  • the source and target ontologies may be putative ontologies and the source and target ontologies are mapped to one or more formalized ontologies.
  • the electronic processing device may determine an ontology by:
  • the electronic processing device may select an ontology using at least one of:
  • the electronic processing device may select one of a number of existing ontologies by:
  • the electronic processing device may generate a putative ontology from a database schema by:
  • the electronic processing device may generate a putative ontology from a database schema by:
  • the electronic processing device may generate relationships between ontology terms using a table structure defined by the database schema.
  • the putative ontology may include:
  • the electronic processing device :
  • the index may include an indication of:
  • the electronic processing device may generate an index by, for each ontology term:
  • the electronic processing device generates a single index for multiple ontologies and wherein the index entry includes an indication of the ontology associated with the ontology term.
  • the electronic processing device may:
  • the electronic processing device may determine the indication of the one or more ontology terms using an index.
  • the electronic processing device may:
  • executable code when executed on a computer system, causes the computer system to display a user interface for allowing a user to interact with content stored in a data store having a data structure, the content being stored in data fields corresponding to the user selected ontology terms.
  • the executable code may cause the computer system to generate queries for interacting with data stored in a source or target data structure in accordance with a source or target ontology.
  • the executable code may cause the computer system to generate queries in accordance with at least one of data properties and relationships between the user selected ontology terms of an ontology.
  • the executable code may cause the computer system to:
  • the electronic processing device may:
  • the electronic processing device may determine an ontology term meaning by:
  • the electronic processing device may determine if a potential ontology term meaning is at least one of:
  • the electronic processing device may store an indication of the ontology term meaning in an index, the indication including at least one of:
  • the electronic processing device may determine an alignment between ontology terms by:
  • the electronic processing device may further determine the alignment based on at least one of:
  • the electronic processing device may:
  • the electronic processing device may determine alignment between one or more source ontology terms from a source ontology and one or more target ontology terms from a target ontology. [0046] Preferably, the electronic processing device may determine the group of ontology terms by:
  • the electronic processing device may determine related ontology terms by: for each selected ontology term, identifying ontology terms within a defined relationship path length for each of a number of different types of relationship; and
  • the electronic processing device may repeatedly add identified ontology terms until all the selected ontology terms are connected by relationships.
  • the electronic processing device may use a different relationship path length for different types of relationship.
  • the electronic processing device may determine a relationship path length in accordance with user input commands.
  • the apparatus may include:
  • an indexer module that generates an index indicative of ontology terms in an ontology
  • a browser module that enables browsing of ontology terms in an ontology and generates code embodying at least part of the ontology thereby allowing a user to interact with data stored in a data structure in accordance with the ontology
  • an aligner module that determines alignment between ontology terms different ontologies
  • pruner module that determines a group of ontology terms within at least one ontology at least in part using relationships between the ontology terms
  • a semantic matcher module that identifies ontology term meanings.
  • the present invention provides a method for use in generating a mapping using ontologies, the method including, in at least one electronic processing device: determining ontologies having respective ontology terms;
  • Figure 1A is a flow chart of an example of a method for use in generating a mapping using ontologies
  • Figure 1 B is a schematic diagram of examples of different mappings based on example ontology structures
  • Figure 2 is a schematic diagram of an example of a distributed computer architecture
  • Figure 3 is a schematic diagram of an example of a base station processing system
  • Figure 4 is a schematic diagram of an example of an computer system
  • Figure 5 is a flow chart of an example of a method for use in generating a mapping for transferring content between source and target data structures
  • Figure 6 is a flow chart of an example of a method of generating a putative ontology
  • Figure 7 is a flow chart of an example of a method of determining an index
  • Figure 8 is a flow chart of an example of a method of browsing an ontology
  • Figure 9 is a flow chart of an example of a method for pruning an ontology
  • Figure 10 is a flow chart of a second example of a method for aligning ontologies
  • Figure 1 1 is a flow chart of an example of a semantic matching method
  • Figures 12A and 12B are schematic diagrams of example ontologies
  • Figure 13 is a schematic diagram of the modules used for interacting with ontologies
  • Figure 14A is a schematic diagram of an example of the software stack of the ETL (Extraction Transformation Load) module of Figure 13;
  • Figure 14B is a schematic diagram of an architecture used for implementing the ETL module if Figure 13;
  • Figure 15 is a schematic diagram of an example of the functionality of the browser module of Figure 13;
  • Figure 16 is a schematic diagram of an example of the functionality of the indexer module of Figure 13;
  • Figure 17A is a schematic diagram of an example of the functionality of the pruner module of Figure 13;
  • Figures 17B to 17D are schematic diagrams of examples of a pruning process
  • Figure 18A is a schematic diagram of a first example of the functionality of the semantic matcher module of Figure 13;
  • Figure 18B is a schematic diagram of a second example of the functionality of the semantic matcher module of Figure 13;
  • Figure 18C is a schematic diagram of an example of relationships between tables
  • Figure 18D is a schematic diagram of a third example of the functionality of the semantic matcher module of Figure 13;
  • Figure 19A is a schematic diagram of an example of a "thing database"
  • Figure 19B is a schematic diagram of an example of a framework for unifying disparate sources
  • Figure 19C is a schematic diagram of an example of the functionality of the aligner module of Figure 13.
  • Figures 19D and 19E are schematic diagrams of examples of merged ontologies.
  • content is stored as one or more content instances in content fields of a data store acting as a content repository, such as database or file.
  • the content fields could be database fields of a database, with a content instance corresponding to a database record, including values stored across one or more database fields.
  • content fields could be fields defined within a file, such as an XML file, which may be used for transporting data, for example, when data is to be extracted from and/or transferred to a database, as will become apparent from the description below.
  • content fields could be fields defined within a file, such as an RDF triple store, which may be used for transporting data, for example, when data is to be extracted from and/or transferred to a RDF triple store database, as will also become apparent from the description below. It is assumed that the content is stored in accordance with a data structure, such as a database schema, XML document definition, ontology or schema, or the like.
  • source is used to refer to a data store, such as a database or file from which data is being extracted
  • target is used to refer to a data store, such as a database or file into which data is being stored.
  • content instance refers to an individual piece of content that is being extracted from a source and/or transferred to a target and is also not intended to be limiting.
  • content instance could refer to a database record having values stored in a number of different database fields, or a set of related database records, or could alternatively refer to a single value stored within a single field.
  • ontology represents knowledge as a set of concepts within a domain, using a shared vocabulary to denote the types, properties and interrelationships of those concepts. Ontologies typically include a number of components such as individuals, classes, objects, attributes or the like and the term “ontology terms” is generally used to refer to these components and optionally specific ones of these concepts.
  • meaning is intended to refer to the semantic interpretation of a particular ontology term, content field name, or the like.
  • the term meaning therefore encompasses the intended meaning of the ontology term or content field, for example to account for issues such as homonyms, synonyms, meronyms, or the like, as will be described in more detail below.
  • the electronic processing device determines ontologies having respective ontology terms.
  • This process can be performed in any appropriate manner, and can include having the electronic processing device select one or more of a number of existing ontologies, stored for example in one or more ontology databases, or could alternatively be achieved by generating putative ontologies.
  • the ontologies selected correspond to a source ontology associated with a source data structure and a target ontology associated with the target data structure, although this is not essential.
  • Selection of ontologies could be achieved on the basis of the source or target data structure, and could include comparing fields within the data structures to ontology terms until a suitable match is found. This process could also involve examining domains of a number of ontologies and selecting domains, and hence ontologies that are of relevance to a particular subject matter field of the content, the industry to which the content relates, or the like. Selection of the ontologies can be automated, for example by providing the electronic processing device with an indication of the subject matter field of the relevant content; manual, for example by having the electronic processing device display details of available ontologies allowing the user to select these, or through a combination of manual and automated processes.
  • This process can involve deriving some ontological axioms from relational referential integrity constraints, but most axioms would need to be manually added or ignored.
  • This putative ontology may then be aligned with an existing rich ontology to add metadata.
  • the electronic processing device determines a group of ontology terms from at least one of the ontologies.
  • the group of ontology terms are typically a sub-group of the respective ontology and represent a group of related ontology terms.
  • the group typically includes selected ontology terms, for example corresponding to ontology terms of interest.
  • the group of ontology terms can include selected ontology terms corresponding to the source or target data fields that are to be mapped to the target or source data fields, for example to allow content therein to be extracted and transferred to the target data store.
  • the group further typically includes ontology terms required to maintain relationships between the selected ontology terms.
  • the manner in which the group is determined will vary depending on the preferred implementation, and could include selecting one of a number of previous determined groups, for example on the basis of the content to be extracted. Alternatively however, this will involve generating the group by identifying the selected ontology terms and then examine related ontology terms progressively, until a path connecting each of the selected ontology terms is found. This process is sometimes referred to as pruning as it effectively involves pruning an ontology to a reduced number of ontology terms that can be more easily managed than the entire ontology, but which still maintains the structure and axioms of the ontology.
  • the electronic processing device determines alignment between ontology terms for at least some of the group of ontology terms, with the alignment being determined at least partially in accordance with an ontology term meaning of the ontology terms.
  • the electronic processing device examines at least the meaning of the ontology terms in one ontology and attempts to identify equivalent ontology terms in the other ontology.
  • this could include identifying source and target ontology terms that have the same meaning, but more typically will examine relationships between the source ontology terms, and also between the target ontology terms, to identify if the source and target ontology terms also have similar relationships with other source and target ontology terms.
  • the alignment need not be a one-to-one mapping, and a single ontology term in one ontology may align with multiple ontology terms in the other ontology.
  • a source ontology may define an individual's name as a single concept
  • a target ontology may define first and last names as separate concepts, in which case content will need to be merged as it is transferred from the source to the target.
  • the electronic processing device operates to generate a mapping in accordance with the alignment.
  • the mapping can represent a mapping between the ontologies themselves and/or can represent a mapping between source data fields and target data fields in respective source and target data structures, based on alignment between the target ontology terms and source ontology terms.
  • the electronic processing device can determine for the source data fields, corresponding source ontology terms, and then using the alignment, aligned target ontology terms, and hence the target data fields.
  • the mapping is then typically stored in the form of a mapping file, index, table, merged ontology, or the like, allowing it to be subsequently used in transferring data.
  • the above process allows two ontologies to be aligned, with this in turn being used to create a mapping.
  • the mapping can be used to equate ontology terms in different ontologies, allowing this in turn to be used to map source data fields to target data fields using respective ontologies.
  • This mapping can be used in transferring content between a source and target, with the use of the ontologies helping to ensure that the structure of the content is maintained even when content is being transferred between data stores having different data structures.
  • the use of ontologies can also help ensure that the integrity of content being transferred is being maintained or improved as it is being transferred, for example to ensure that the content is in the required normal form, and even providing normalisation if required.
  • using ontologies allows additional relationship restrictions to be imposed as content is being transferred from the source to the target data store, so that even if data in the source data store is not stored in third normal form, it can be converted to third normal as it is transferred.
  • source and target ontologies can be previously defined ontologies, such as official created ontologies such as the Galen ontology (generally referred to as a formalised ontology), or can alternatively be putative ontologies, generated based on the data structure itself. This allows a number of different mapping relationships to be established as will now be described with reference to Figure 1 B.
  • source and target data stores having respective source and target data structures S, T are shown.
  • Each data store can have a corresponding putative ontology 150, 160, with corresponding formalised ontologies 151 , 161 also existing. This allows a number of different mappings to be established. [0072] For example, mappings can be created directly between the putative ontologies 150, 160, allowing content to be transferred directly between the source and target S, 7.
  • a mapping could be created between a putative ontology 150, 160 and a corresponding formalised ontology 151 , 161 using the above described techniques.
  • This process allows a putative ontology 150, 160 to be created based on the source or target data structure S, 7, and then substantially automatically mapped to a formalised ontology 151 , 161 to thereby provide meaning, definitions and potentially relationships, to ontology terms in the putative ontology 150, 160.
  • This process can also be used in normalising the data stored in the respective data structures.
  • mapping the putative ontologies 150, 160 to the formalised ontologies 151 , 161 allows for content to be transferred between the source and target S, 7.
  • the formalised ontologies could also be aligned to allow for mappings therebetween to again allow transfer of content between the source and target S, 7.
  • mappings between ontologies can be used to create mappings between ontologies, with these in turn being used to establish a mapping directly between a source and target data structure.
  • This facilitates transfer of content between disparate source and targets, and allows this to be performed in accordance with formalised data structures, thereby ensuring that content is provided in a normalised form.
  • This therefore not only allows for content transfer between disparate data structures, but can also be used to overcome issues associated with data stored in a denormalised form.
  • the electronic processing device is typically adapted to perform a number of different functions to facilitate the above described process, including generating an index of ontologies, allowing users to browse and interact with ontologies, align ontologies, prune ontologies, and interpret the meaning of ontology terms, as will now be further described.
  • the mapping can be of any form.
  • this can be in the form of a merged ontology or alternatively an alignment index, as will be described in more detail below.
  • the ontologies that are involved can include putative ontologies and/or formalized ontologies depending on the preferred implementation.
  • the electronic processing device generates a mapping to map a putative ontology to a formalized ontology.
  • the mapping can be used in transferring content from a source data store having a source data structure including a number of source data fields to a target data store having a target data structure including a number of target data fields, wherein the ontologies are associated with the source data structure and the target data structure and wherein the electronic processing device transfers content between the source data fields and target data fields using the mapping.
  • the ontologies can include a source ontology associated with the source data structure and a target ontology associated with the target data structure, with the source and target ontologies being putative ontologies mapped to one or more formalized ontologies.
  • the electronic processing device can determine an ontology by generating a putative ontology or selecting one of a number of existing putative or formalised ontologies.
  • the electronic processing device typically determines a source or target ontology using either metadata associated with the source or target data structure or source and target data fields of the source or target data structure. This process could include generating a putative ontology or selecting one of a number of existing ontologies, for example from ontologies stored in a store such as an ontology database. In this latter case, the electronic processing device can compare the data structure data fields to ontology terms of a number of existing ontologies and select one of the number of existing ontologies in accordance with the results of the comparison.
  • the electronic processing device when generating an ontology, for example from a database schema, the electronic processing device typically identifies tables in the schema, creates an ontology term corresponding to each table, identifies at least one bill of material table and creates an ontology term corresponding to each entry in the bill of materials table.
  • this process operates to examine the content of any denormalised database tables and expands the contents of this table to identify additional ontology terms.
  • the electronic processing device can display an indication of the ontology term corresponding to each entry in the bill of materials table and add the ontology term to the putative ontology in response to user input commands. This allows the user to override the creation of ontology terms if required.
  • the electronic processing device can further generate relationships between ontology terms using a table structure defined by the database schema. This process allows the electronic processing device to generate a putative ontology including classes corresponding to ontology terms, data properties for at least some of the classes and object properties defining relationships between classes.
  • the electronic processing device determines an index for at least one ontology, the index including an indication of the ontology terms of the at least one ontology and uses the index to determine the group of ontology terms and alignment between ontology terms. Whilst the use of an index is not essential, it substantially reduces the amount of data that needs to be handled compared to use of an entire ontology, thereby making browsing, grouping (pruning) and alignment processes more manageable.
  • the index can be of any appropriate form but typically includes, for each ontology term, a name of the ontology term and an indication of an ontology term meaning and an ontology term type.
  • the index may also include additional information such as an address for the ontology term in the respective ontology, which could take the form of a URI (Uniform Resource Identifier) or the like.
  • the electronic processing device generates the index by, for each ontology term, identifying an ontology term name, identifying an ontology term type, identifying an ontology meaning of each ontology term using a semantic matching process and creating an index entry including an indication of the ontology term name, the ontology term type and the ontology term meaning.
  • the electronic processing device generates a single index for multiple ontologies and wherein the index entry includes an indication of the ontology associated with the ontology term, although this is not essential and alternatively a separate index can be used for each ontology that is indexed.
  • the electronic processing device is typically further adapted to display an indication of one or more ontology terms in the ontology, identify at least one ontology term in response to user input commands and display details of at least one of at least one identified ontology term and data properties associated with the at least one identified ontology term.
  • This allows the user to browse ontologies and view details of the ontology terms defined therein. This can be useful to allow users to assess whether the correct ontologies are being used, understand the scope of the ontologies, explore relationships between different ontology terms, and assess how a source or target data structure relate to the ontologies.
  • the electronic processing device typically determines the indication of the one or more ontology terms using an ontology index.
  • the index provides a rapid mechanism for the electronic processing device to display a list of ontology terms, and then subsequently explore data properties associated with selected ontology terms.
  • the electronic processing device is typically adapted to determine user selected ontology terms and corresponding user selected data properties in response to user input commands. This can be used not only to display details of the selected ontology terms and data properties, but also allows the electronic processing device to generate executable code.
  • the executable code is based on the user selected ontology terms and data properties, and when executed on a computer system, causes the computer system to display a user interface for allowing a user to interact with content stored in a data store having a data structure corresponding to the user selected ontology terms.
  • this provides a mechanism for allowing the electronic processing device to automatically generate code that can be used to display an interface allowing users to interact with and subsequently export content from or import content to respective source and/or target data structures.
  • the executable code causes the computer system to generate queries for interacting with data stored in the source or target data structure in accordance with the source or target ontology, for example by querying and retrieving the content, for example using SPARQL (SPARQL Protocol and RDF Query Language).
  • SPARQL SPARQL Protocol and RDF Query Language
  • This provides a mechanism for rapidly deploying computer software that can act as an interface to a database. Furthermore, by virtue of this being generated based on the ontologies, it can integrate relationships defined within the ontology into the structure of the code and hence resulting queries. Thus, this allows the computer system to generate queries in accordance with data properties or relationships between the ontology terms selected by the user.
  • the computer system typically displays an indication of one or more ontology terms, for example from a source or target ontology, determines selection of at least one ontology term in response to user input commands, and queries data stored in a corresponding data field.
  • the electronic processing device is typically adapted to perform semantic matching. This typically involves comparing an ontology term to a number of potential ontology term meanings, for example stored in a reference database, such as concept matching database, and selecting one of the potential ontology term meanings as the ontology term meaning in accordance with the results of the comparison.
  • the electronic processing device determines an ontology term meaning by generating a matching score for the results of each comparison and determining an ontology term meaning in accordance with matching scores. In determining the matching score, the electronic processing device determines if a potential ontology term meaning is at least one of a synonym, an antonym, a meronym, a superclass and a subclass of the ontology term under consideration.
  • an indication of this is typically stored as part of an index, the indication including at least one of an identifier indicative of a defined meaning and a list of equivalent meanings.
  • an identifier indicative of a defined meaning and a list of equivalent meanings.
  • the electronic processing device typically determines an alignment between ontology terms by comparing ontology term meanings of a number of ontology terms, generating a matching score for the results of each comparison and determining an alignment in accordance with matching scores. More typically the electronic processing device will also determines the alignment based on relationships between ontology terms or data properties of the ontology terms. Thus, this takes into account not only the absolute meaning of terms, but also the relative structures of the ontologies to determine if an alignment exists. Thus, the electronic processing device can determine relationships between the source ontology terms, determine relationships between target ontology terms, compare the relationships and determine alignment between source and target ontology terms in accordance with the results of the comparison.
  • the electronic processing device typically determines alignment between one or more source ontology terms from the source ontology and one or more target ontology terms from the target ontology, so this allows one-to-one, many-to-one and one-to-many relationships to be encompassed.
  • the electronic processing device can determine a group of ontology terms, for example by pruning an ontology so that ontology terms that are irrelevant or unused for the current application can be removed and only those relevant to the current situation remain. In one example, this is achieved by determining selected ontology terms and then determining the group of ontology terms at least partially in accordance with the selected ontology terms and relationships between the ontology terms.
  • the electronic processing device identifies ontology terms within a defined relationship path length for each of a number of different types of relationship and adds identified ontology terms to the group of source ontology terms. This process can be performed iteratively so that the electronic processing device repeatedly adds identified ontology terms until a desired end point is reached, such as when all the selected ontology terms are connected by relationships. This then establishes a group of related ontology terms that allow relationships within the ontology to be preserved and used in other processes, such as aligning ontologies, creating mappings, or the like.
  • a number of different relationships can be examined in an attempt to establish paths between all of the selected ontology terms, with the electronic processing device optionally using a different relationship path length for different types of relationship.
  • some types of relationships would be deemed more important, and hence would typically be given a longer path length when identifying relation ontology terms.
  • the path length(s) could be defined by a user, allowing manual intervention to be used in controlling the creation of the group.
  • a number of different tools can be used to assist in generating the mappings and managing the ontologies.
  • the tools are provided as part of a software suite forming an integrated package of ontology and data management tools.
  • the tools include an indexer module that generates an index indicative of ontology terms in an ontology, a browser module that enables browsing of ontology terms in an ontology and generates code embodying at least part of the ontology thereby allowing a user to interact with data stored in a data structure in accordance with the ontology, an aligner module that determines alignment between ontology terms different ontologies, a pruner module that determines a group of ontology terms within at least one ontology at least in part using relationships between the ontology terms and a semantic matcher module that identifies ontology term meanings.
  • the use of respective modules is not essential and other arrangements can be used.
  • the processes can be performed at least in part using a processing system, such as a suitably programmed computer system. This can be performed on a standalone computer, with the microprocessor executing applications software allowing the above described method to be performed. Alternatively, the process can be performed by one or more processing systems operating as part of a distributed architecture, an example of which will now be described with reference to Figure 2.
  • a processing system such as a suitably programmed computer system. This can be performed on a standalone computer, with the microprocessor executing applications software allowing the above described method to be performed.
  • the process can be performed by one or more processing systems operating as part of a distributed architecture, an example of which will now be described with reference to Figure 2.
  • two base stations 201 are coupled via a communications network, such as the Internet 202, and/or a number of local area networks (LANs) 204, to a number of computer systems 203.
  • a communications network such as the Internet 202
  • LANs local area networks
  • computer systems 203 can communicate via any appropriate mechanism, such as via wired or wireless connections, including, but not limited to mobile networks, private networks, such as an 802.11 networks, the Internet, LANs, WANs, or the like, as well as via direct or point-to-point connections, such as Bluetooth, or the like.
  • each base station 201 includes a processing system 210 coupled to a database 21 1 .
  • the base station 201 is adapted to be used in managing ontologies, for example to perform pruning or alignment, as well as generating mappings for example for use in transferring content between source and target data stores.
  • the computer systems 203 can be adapted to communicate with the base stations 201 to allow processes such as the generation of mappings to be controlled, although this is not essential, and the process can be controlled directly via the base stations 201.
  • each base station 201 is a shown as a single entity, it will be appreciated that the base station 201 can be distributed over a number of geographically separate locations, for example by using processing systems 210 and/or databases 21 1 that are provided as part of a cloud based environment. In this regard, multiple base stations 201 can be provided each of which is associated with a respective data stores or ontology, although alternatively data stores could be associated with the computer systems 203.
  • the processing system 210 includes at least one microprocessor 300, a memory 301 , an input/output device 302, such as a keyboard and/or display, and an external interface 303, interconnected via a bus 304 as shown.
  • the external interface 303 can be utilised for connecting the processing system 210 to peripheral devices, such as the communications networks 202, 204, databases 211 , other storage devices, or the like.
  • peripheral devices such as the communications networks 202, 204, databases 211 , other storage devices, or the like.
  • a single external interface 303 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.
  • the microprocessor 300 executes instructions in the form of applications software stored in the memory 301 to allow index generation, mapping and content transfer to/from the database 21 1 to be performed, as well as to communicate with the computer systems 203.
  • the applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.
  • the processing system 210 may be formed from any suitable processing system, such as a suitably programmed computer system, PC, database server executing DBMS, web server, network server, or the like.
  • the processing system 210 is a standard processing system such as a 32-bit or 64-bit Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g. hard disk) storage, although this is not essential.
  • the processing system could be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.
  • FPGA Field Programmable Gate Array
  • the computer system 203 includes at least one microprocessor 400, a memory 401 , an input/output device 402, such as a keyboard and/or display, and an external interface 403, interconnected via a bus 404 as shown.
  • the external interface 403 can be utilised for connecting the computer system 203 to peripheral devices, such as the communications networks 202, 204, databases 211 , other storage devices, or the like.
  • peripheral devices such as the communications networks 202, 204, databases 211 , other storage devices, or the like.
  • a single external interface 403 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.
  • the microprocessor 400 executes instructions in the form of applications software stored in the memory 401 to allow communication with the base station 201 , for example to allow an operator to provide control inputs.
  • the computer systems 203 may be formed from any suitable processing system, such as a suitably programmed PC, Internet terminal, lap-top, hand-held PC, smart phone, PDA, web server, or the like.
  • the processing system 100 is a standard processing system such as a 32-bit or 64-bit Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g. hard disk) storage, although this is not essential.
  • the computer systems 203 can be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.
  • FPGA Field Programmable Gate Array
  • the processing system 210 of the base station 201 hosts applications software for performing the processes, with actions performed by the processing system 210 being performed by the processor 300 in accordance with instructions stored as applications software in the memory 301 and/or input commands received from a user via the I/O device 302, or commands received from the computer system 203.
  • the processing system 210 executes applications software having a number of modules including an indexer module, a browser module, an aligner module, a pruner module, a semantic matcher module and an ETL module.
  • the use of respective modules is not essential and other arrangements can be used.
  • the base station 201 is typically a server which communicates with the computer system 203 via the particular network infrastructure available, and may for example be in the form of an enterprise server that interacts with a database 21 1 for users of one or more computer systems 203.
  • the processing system 210 identifies source and target ontologies using the source and target data structures. This can be achieved in any manner, but typically involves creating a putative ontology based on the source and target data structures for source and target data stores. For example, the names of the different source and target data fields could be equated to ontology terms, with relationships between the ontology terms being identified from the relationships in the source and target data structures.
  • a specific example of the process of generating putative ontologies will be described in more detail with reference to Figure 6.
  • the indexer module determines an index of source and target ontologies.
  • the index is typically in the form of a list including an entry indicative of each ontology term, an associated ontology term type if this is known, and also optionally an ontology term meaning.
  • the ontology term meanings are typically determined by the semantic matcher module at step 520 that compares the ontology term to a concept matching database, and uses the results of the comparison to identify a meaning for each ontology term in the index.
  • the browser module is used to browse an ontology and select source or target ontology terms. This allows a user to select those ontology terms that are of interest, typically corresponding to content to be extracted from the source data store or imported into the target data store.
  • the selected ontology terms can then be used at step 540 to allow the browser module to generate code for interacting with content stored in a data store in accordance with the respective data structure.
  • this can include code for allowing a computer system to generate a user interface which the user can use to review data fields of the data structure, select content to be extracted / imported and then generate the necessary queries to perform the extraction / importation, as will be described in more detail below.
  • the selected ontology terms are used by the pruner module to prune either the source and/or target ontology.
  • this allows the user to select only those parts of the ontology that are of interest, with the processing system 210 then selecting additional ontology terms required to maintain relationships between the selected ontology terms as will be described in more detail below.
  • the processing system 210 uses the aligner module to align the source and target ontologies. This identifies a correspondence between one or more of the source ontology terms and one or more of the target ontology terms, thereby allowing a mapping between the source and target data structures to be determined at step 570, which in turn can be used together with code generated by the browser module to transfer content from the source data store to the target data store.
  • the processing system 210 determines each table in the database, typically by extracting this information from metadata defining the database schema.
  • the processing system 210 defines a class corresponding to each table in the database.
  • the term class refers to a specific ontology term corresponding to a concept within the ontology, as will be described in more detail below.
  • the processing system 210 identifies any database tables having a BOM (Bill Of Materials) structure or a Type structure.
  • a BOM table has two "one to many" relationships and is used to list of all parts constituting an item, object or article.
  • the Type structure has one "many to one" relationship and has only one relevant attribute or column which is used to limit the range of values in the related table.
  • Such tables are often used to de- normalise data and can therefore contain many concepts or classes that should each represent a respective ontology term.
  • the processing system expands each Type table and each BOM table to define further classes corresponding to each unique entry in the table.
  • the processing system 210 optionally displays each identified class from within the Type or BOM table, allowing a user to confirm whether the class should be retained at step 650. If it is indicated that the Type or BOM class should not be retained, it is removed at step 660.
  • the processing system 210 defines relationships and attributes (also referred to as data objects and data properties) based on the database schema.
  • relationships and attributes also referred to as data objects and data properties
  • the table structure can be used to identify relationships between the identified classes, whilst data fields in the tables are used to identify attributes of the classes.
  • the relationships and attributes are in turn used to define object properties and data properties in the ontology, thereby allowing the putative ontology to be generated and saved, for example in an ontology database at step 680.
  • this allows a putative ontology to be created in a substantially automated fashion solely from an analysis of the data structure of a data store, such as a database, structured file, or the like.
  • a data store such as a database, structured file, or the like.
  • the putative ontology can be aligned with a formalised ontology, as will be described in more detail below.
  • the indexer module determines an ontology of interest. This may be determined based on user input commands, for example supplied via the browser module, or could be received from another module requiring an index. For example, an ETL module that has generated a putative ontology may require this be indexed and provide an indication of the ontology to the indexer module, or alternatively, a pruner module may request an index allowing pruning to be performed on an ontology.
  • the indexer module compares the ontology to one or more existing indexes, typically stored in an index database, and determines if an index already exists. This can be achieved by comparing metadata associated with the ontology, such as an ontology name and/or address, with corresponding information associated with the indexes, or alternatively by comparing one or more ontology terms to ontology terms in existing indexes.
  • the indexer module selects a next ontology term at step 720, and then creates an index entry including an indication of the ontology term name, an ontology term type and an ontology term address, typically indicative of a URI (Uniform Resource Identifier) or similar, at step 725.
  • the indexer module obtains a semantic meaning for the ontology term from a semantic matcher module, as will be described in more detail below, and adds this to the index entry.
  • the indexer module determines if all ontology terms have been completed and if not the process returns to step 720, allowing a next ontology term to be selected. Otherwise, at step 740, the index is stored and optionally provided to another module.
  • the browser module generates an ontology term list for a selected ontology, using an ontology index. Accordingly, as part of this process, the browser module can request the ontology index from the indexer module, for example based on the identity of a selected ontology. The ontology term list can then be displayed to a user via an appropriate GUI (graphical user interface).
  • GUI graphical user interface
  • a step 805 the user tags one or more ontology terms of interest, before selecting a next ontology term to view at step 810 allowing the browser module to display a ontology term screen including data properties for the selected ontology term at step 815.
  • the data properties correspond to attributes of the ontology term, which are defined as part of the ontology.
  • the browser module determines if a search option has been selected by the user, in which case the user enters search terms in the data fields of the data properties at step 825.
  • the browser module then generates and performs a query of data associated with the respective ontology term data properties, returning and displaying results to the user at step 830.
  • this process allows the user to review the content that would be associated with respective data properties in the corresponding source or target data store, thereby allowing the user to ascertain whether the ontology term and associated data properties are of interest.
  • the user tags one or more data properties of interest at step 835.
  • this process allows the user to review the ontology terms and associated data properties and then select ontology terms and data properties of interest by tagging them.
  • step 840 the ontology terms are reviewed to determine if all ontology terms and data properties of interest to the user have been selected. If not, the process returns to step 810 allowing further ontology terms to be reviewed.
  • the browser module selects the tagged ontology terms and associated data properties, allowing these to be used in other processes, such as to perform pruning at step 850 or to generate an application at step 855.
  • generation of an application involves uses scripts or the like to generate executable code, that when executed on a computer system allows the computer system to display a user interface for interacting with content in fields in the source or target corresponding to the selected ontology terms or data properties, as will be described in more detail below.
  • the selected ontology terms are added as seeds for the pruning process.
  • an iterative process is performed to repeatedly explore ontology terms related to the seed ontology terms until a path is identified that interconnects the seed ontology terms.
  • ontology terms can be related by different types of relationships, such as parent, child, sibling, or the like. As certain types of relationship may be more important than others, different relationship types may have different lengths. Additionally, the length of path that is explored for each type of relationship can be varied thereby ensuring that a larger number of ontology terms connected to the seed ontology terms via the more important relationships are included. Accordingly, at step 910, the user can adjust the path lengths for the different relationships, thereby allowing the pruning process to be tailored by the user, for example to control the extent and/or direction of pruning.
  • ontology terms related to the selected ontology terms are determined, by identifying those ontology terms related by relationships of the specified path length.
  • the pruner module determines if the selected seed terms are linked. In other words there is a series of interconnected ontology terms that links the seed ontology terms, and if so, the pruning process can end with the selected and related ontology terms identified being used the define the pruned ontology at step 925, which can be stored as a pruned ontology or pruned index.
  • step 930 it is determined if the iterations are complete, and if not the related ontology terms are added the selected ontology terms and the process returns to step 915, allowing further related ontology terms to be identified.
  • the number of ontology terms related to the seed ontology terms is gradually increased until the seed ontology terms are connected by a path of relationships.
  • the above described process is repeated either until the ontology is successfully pruned, at which time the seed ontology terms are interconnected via a path of related ontology terms, or until a predetermined number of iterations are completed and no path is identified, in which case the process is halted at step 940.
  • this typically suggests that the ontology terms are from different ontologies, in which case the pruning process is performed in conjunction with an alignment process, allowing the pruning process to span multiple ontologies as will be described in more detail below. Alternatively, this indicates that the ontology terms cannot be easily linked.
  • source and/or target ontology terms are selected using the index. This may involve having the user select ontology terms using the browser module, or more typically select two pruned ontologies corresponding to pruned versions of source and target ontologies that contain source and/or ontology terms of interest.
  • the matcher module is used to determine a matching score for different combinations of pairs of source and target ontology terms. These scores are used to define preliminary alignments solely based on how similar the meanings of the source and target ontologies are at step 1010.
  • the aligner module examines relationships (object properties) and attributes (data properties) of the source and target ontology terms to determine whether the preliminary alignments are correct. Thus, for example, this will examine if preliminary aligned source and target ontology terms have similar number of attributes, and also if these have similar relationships with other source or target ontology terms. This can be used to identify inexact matches, for example if each of the terms first name and last name may be preliminary matched to name, with the examination of the relationships being used to demonstrate this should be a many to one relationship.
  • this can be used to refine the alignments, allowing these to be stored to represent the alignment between the source and target ontologies at step 1025.
  • This can be in the form of a merged ontology, or alternatively an alignment index.
  • the matcher module receives ontology terms for matching. This could be based on user selection via the browser module, but more typically is by receiving terms from the indexer module or the aligner module.
  • a next pair combination is selected, either by comparing a single ontology term to a plurality of respective terms in a matching database, or by selecting a next pair of received source and target ontology terms.
  • the semantic matcher module calculates a semantic similarity using a concept matching database.
  • the score can be determined in any one of a number of manners, but typically involves applying a predetermined formula that calculates a score based on whether the meanings are in any way related, such as whether they are antonyms, synonyms, or the like. In one particular example, this involves matching ontology terms with definitions, for example using a dictionary, such as WordNet, or the like.
  • WordNet is a large lexical database of English. Nouns, verbs, adjectives and adverbs are grouped into sets of cognitive synonyms (synsets), each expressing a distinct concept and is described in Fellbaum, Christiane (2005).
  • the semantic matcher module determines whether the terms are related by subclass and superclass arrangements. This information is then combined with the similarity score to calculate a matching score at step 1120. At step 1 125, it is determined if all pairs are completed and if not the process returns to step 1 105 allowing a next pair of source and target ontologies to be selected and a matching score is calculated. Once all potential pairs of ontology terms or ontology terms and matching concepts in the database have been checked, the semantic matcher module can select the best match and then provide an indication of this at step 1 130.
  • the above described processes allow users to interact with ontologies, select ontology terms of interest and use this to generate software for interacting with content stored in a data store, such as a database or XML file, in accordance with a respective ontology.
  • the users can further investigate the ontology and then prune this using a pruner module, allowing a minimal ontology to be determined which allows the user to interact with content of interest.
  • the pruned ontology can then be aligned with another pruned ontology, so that this can be used to define a mapping therebetween, which can in turn be used to transfer data between data stores having a source and target data structure.
  • a set of Data Properties associated with each Class may have Data Properties of Name, Title, Date-of-Birth, and Gender.
  • a set of axioms providing a formulaic relationship between any of the preceding properties. For example, "if a Person has a Title of 'Mrs' then the gender must be female" or "if two objects have the same unique identifier then they are the same object”. These axioms allow further inferencing of concepts, relationships and properties.
  • An ontology can be described in a number of languages such as RDFS, XML, DAML, OIL, N3 and OWL. These languages may have different dialects such as OWL-Lite or OWL-DL. From a functionality perspective they differ in their ability to manage and describe complex relationships and axioms.
  • An ontology may contain hundreds of thousands of concepts. A user may be interested in a subset of these concepts. This subset may be from:
  • Some concepts in a target ontology may not be pre-defined, and may not exist in any of the source ontologies. In such a case the user may need to manually add the missing concepts.
  • the required subset may have both or either starting and ending concepts.
  • Figures 12A and 12B For the purpose of illustration two extremely simple example ontologies are shown in Figures 12A and 12B. It will be appreciated that these are utilised to illustrate the processes of indexing, pruning semantic matching and alignment and are not intended to be limiting.
  • Hierarchically connected classes are represented by solid ellipses, which are hierarchically connected by solid lines pointing from the superclass to the subclass. Each subclass inherits all the properties of its superclass.
  • the non-hierarchically connected set of classes, shown as broken ellipses, are connected to any class by a named Object Property line shown here as a dashed line.
  • Each class has a set of data properties some of which are shown in Table 1 for illustration.
  • the system performs the functionality shown in Figure 13, with these being implemented by respective modules.
  • the modules include:
  • ⁇ ETL Extraction-Transformation-Loading module 1300. This extracts, transforms and loads content within structured data sources. This includes two sub-components, including:
  • Processor 1301 that extracts source data either via a specified ontology, or, in the absence of an ontology, via a putative ontology which the Processor creates to describe the data.
  • the Processor can be deployed either in the Cloud or on the same machine as the data or on a machine which can access the data via messaging, ODBC, https, SOAP or any equivalent protocol. Multiple copies of the Processor can be deployed in order to obtain data from multiple sources.
  • Orchestrator 1302 that collects data from the various Processors and maps the source ontologies to the target ontology. Queries are written using the target ontology and are translated into equivalent source ontology queries, allowing data to be returned using the target ontology.
  • Ontology Browser module 1310 including a browser 131 1 , editor 1312 and generator 1313. This generates screens and the associated software and data to manage them, which enables a user to browse and edit an ontology and the data described by the ontology. These screens appear in two stages. The first stage is during the generation process. In this stage the screens are dynamically created and display additional information to enable the user to select which features are to be generated. In the second stage the screens are hard coded and only display the information specified for generation.
  • Ontology Indexer module 1320 The Indexer module creates a set of linked indexes on one or more ontologies, of all the class names, data property names and, object property names. Additionally the index includes semantically equivalent terms (synonyms and homonyms for example) which come from the source ontologies plus from a semantic equivalence function.
  • Ontology Pruner module 1330 The Pruner module takes an ontology and allows a user to specify which classes, data properties, object properties and axioms they wish to retain. Using those retained the Pruner module checks to see that the relational and axiomatic integrity defined in the ontology is maintained.
  • Ontology Aligner module 1340 takes two or more ontologies and uses a number of techniques to align the concepts in the various ontologies, either with each other or with a specified target ontology.
  • the techniques utilise the indexes created by the indexer module to find concepts which are semantically similar.
  • Each data property and concept is compared using the semantic matcher module. It refines the matching based upon the ontology structure and the data properties.
  • the matcher module compares two terms or two lists of terms to determine whether they have a mathematically defined degree of semantic equivalence within a specified context, for example medicine or engineering, or, in another instance, given a single term, will provide a list of synonyms, homonyms, etcetera based upon a specified context.
  • an ontology does not have any data instances except as examples, however an ontology can be matched to existing data in one of two ways:
  • the ontology is constructed from the existing data.
  • a relational database could be automatically converted to a 'putative' ontology by relational Entities (tables) being defined as ontological Classes, relational Relationships as ontological Object Properties, and relational Attributes (columns) as ontological Data Properties.
  • tables relational Entities
  • Relationships ontological Object Properties
  • relational Attributes relational Attributes
  • ontological axioms could be derived from relational referential integrity constraints, but most axioms would need to be manually added or ignored. This putative ontology may then be aligned with an existing rich ontology to add metadata.
  • a putative ontology can be automatically generated from the source data using methods appropriate to the source data structure and metadata (if it exists). This putative ontology may be manually updated using the ontology editor, or used as generated. In either case the putative ontology is then aligned using the aligner module with a subject area ontology (invoked by the ETL module processor) and with the target ontology (invoked by the ETL module orchestrator). [00170] The target ontology may be pruned using the pruner module, to ensure that it contains only the desired concepts plus those concepts, axioms, properties, inferences and provenance details which are required to ensure the integrity of the desired concepts.
  • the ELT module performs the functions of data extraction, transformation and loading common to all ETL tools without the use of a metadata repository. It does this by using metadata associated with the source data to determine data structure and then by mapping this metadata to an ontology. It also assigns meaning to the data and hence is able to achieve a high level of automation in mapping and transforming the data.
  • Eliminating the need for a metadata repository means that the flexibility of the processes is not constrained by the human interface required to maintain it. New data formats and technologies can be automatically accommodated.
  • the code to perform these processes is called the processor and the orchestrator. Numerous copies of the processor may be deployed to read data at any defined location.
  • the processor can be co-located on the same device as the data or it can be located in the cloud and access the data using a remote access protocol.
  • the processor extracts metadata from the source and creates a putative ontology from that metadata. It then performs some elementary data transformations and passes the data and the ontology to the orchestrator.
  • the orchestrator receives input from the various processors and aligns their ontologies. It then applies a mapping from the aligned source ontologies to the user defined target ontology. The user can now see all the data from the various source ontologies. Data can be extracted either by specifying a specific query against the target ontology or by using the ontology browser module to create the query, as will be described in more detail below.
  • FIG. 14A An example ETL module software stack including the various software components which are required to achieve this outcome are shown in Figure 14A, whilst Figure 14B shows an example deployment in which a number of processors are coupled to a single orchestrator via a network arrangement.
  • the processor is responsible for reading data from disparate data source, exposing the data as RDF and creating a putative ontology to describe the data.
  • the high level functions are as follows:
  • the orchestrator is responsible for reading target ontologies and mapping files and orchestrating the transformation of request and response.
  • the high level functions are as follows:
  • the ontology browser module operates to automatically create a set of screens to enable a user to browse an ontology, query data defined by an ontology and add instance data to data defined by an ontology.
  • the screens thus generated can then be used independently of the ontology and the creating tools, as a complete stand-alone application.
  • the ontology browser module can exist in two major forms, either as a stand-alone tool, or second as a plug-in to existing ontology tools (such as Protege). In either form it can generate an application specific to the ontology selected.
  • the generated application can be used without the ontology as a full function code-set for accessing, updating, deleting and adding records with all the data rules defined in the original ontology being enforced.
  • the ontology browser module provides a set of processes which can be implemented in a computer program which generates screens and the associated software and data to manage them which enables a user to browse and edit an ontology and the data described by the ontology. These screens appear in two stages. The first stage is during the generation process. In this stage the screens are dynamically created and display additional information to enable the user to select which features are to be generated. In the second stage the screens are hard coded and only display the information specified for generation.
  • the user will first access the 'landing
  • Each list item could include
  • screens is generated in the deployable code, as a
  • the parent/super classes of the screen or set of screens selected class-a clickable link specific to each class.
  • the child/sub classes of the be generated using a selected class-a clickable link number of templating tools utilising subclass relationships. to ensure that a particular
  • This frame is only displayed during
  • a query is performed by adding data
  • constraints can be defined by the user.
  • Generic screens are not user friendly and cannot be customised. Therefore the process allows the user to generate a complete set of screens whose look and feel can be parametrically predetermined using facilities such as cascading style sheets, Templates, icons and user supplied parameters.
  • the browser module 1310 takes a target ontology 1501 from the orchestrator 1302, or any ontology defined by the user.
  • the Browser module 1310 displays the set of screens 1502 which allowing the user to browse the ontology and to specify which components of the ontology to generate into a standalone application.
  • the browser module 1302 generates a standalone application 1503 including a set of computer screens 1504 to manage the data using the structure and rules specified in the target ontology.
  • the application can be generated in a number of modes, such as purely an ontology or data browser module, or as a full function data add, update and delete application. In this case the user now has a complete application 1503 to manage the data described by the ontology.
  • Ontologies using OWL or RDF files have enough information to generate web pages and create a corresponding database 1505 to store the information.
  • the RDF or OWL file may have been created by an ontologist based upon their detailed business knowledge.
  • the browser module 1310 creates an application 1503 for end users to query or enter transaction data.
  • the OWL or RDFS file is fed into the browser module 1310 along with application customisation files, database connection details and any other metadata required to create the application.
  • the browser module 1310 can create web pages, for example using HTML5, JSP, JSF or any similar technology. For each class in the ontology browser module 1310 creates a web page and each property associated with that class is created as a field within the page.
  • the application 1503 bridges between the generated webpages and the database 1505. It performs the processes to persist the data from the web pages to the database 1505, to extract data from the database 1505, to query data in the database 1505 and to display data on the web page.
  • the browser module 1310 then creates database scripts for creating and loading a database of the type specified in the user supplied metadata. This could be a relational database (RDBMS), a Triple Store, NOSQL, NewSQL, Graph Database or any other recognised database.
  • RDBMS relational database
  • NOSQL NOSQL
  • NewSQL NewSQL
  • Graph Database any other recognised database.
  • the user initially selects the ontology to be browsed in the 'Landing screen' described in Table 2.
  • the ontology can be selected from a file or a Web address.
  • a class list is generated using an index of the ontology. This list displays the name and description of each class.
  • search function is provided enabling the user to search by class name or part of a class description. It is also possible to search on a data property. In either case the search would return a list of classes which contain that data property.
  • the Data Property Component The name of each data property is displayed in a list format with a description box beside the field. Clicking on an information icon beside the field will display all the field attributes and any axioms related to that field. Optionally (clickable), data properties of a parent/super or related class or classes may also be shown
  • the parent/super Class Component This displays the name and description of the parent/super class of the displayed class, with a clickable link to it. Clicking on this link will cause the browser module to display a screen displaying the Parent of the current class.
  • the child/sub Class Component This displays the name and description of the subclasses of the displayed class, with a clickable link utilising subclass relationships. Clicking on one of these links will cause the browser module to display a Child/sub class or subclass of the current class.
  • the Object Property Component This displays the related Classes of the selected class, each with a clickable link using the object property. Clicking on one of these links will cause the browser module to display a class related to the current class.
  • a query is issued to return all the data instances for that class. This is displayed as a list with one row for each instance of the class. By clicking on a particular row, that row is displayed as a formatted screen similar to the ontology class screen.
  • the data returned maybe restricted by executing a query which would filter the results. The construction and use of such a query will now be described in more detail.
  • filtering the data returned to the user is achieved by capturing from the user, the user's exact requirements of the data to be returned, in the form of a filter and then generating a query based on that filter.
  • the filter is constructed by entering values or expressions into the data property fields on a class screen. For example, using the sample ontologies described above, to find out how many shares John Doe owns, the following steps would be required:
  • Naming and coding specification and standards for the application to be generated This includes style sheets, Templates, Java scripts and other display specifications.
  • Icons to be associated with classes and actions.
  • the application will be generated by the browser module 1310 and saved into the location specified in the application metadata (Step 1 ).
  • the database creation and load scripts will be created. Run these scripts to ready the application for use.
  • the above described browser module 1310 allows a user to browse and interact with ontologies, and then by selecting specific classes and data properties, generate an application 1503 that can be used to interact with data stored in a data store 1505 in accordance with the selected classes and data properties.
  • the indexer module automatically creates a set of indexes of the terms used in a collection of one or more ontologies to assist a user to browse an ontology and to expedite the querying of data defined by an ontology These indexes are used by the other modules to assist in the alignment, pruning and browsing of ontologies.
  • the indexer module indexes one or more ontologies by creating a set of linked indexes of all the class names, data property names and object property names and relationships.
  • the index includes semantically equivalent terms which come from the source ontologies plus from a semantic equivalence function.
  • the indexer module 1320 receives an ontology 1601 from the orchestrator 1302, or any ontologies defined by the user, via a set of screens 1602, or by the processor 1301 and creates indexes 1603 of all the class names, data property names and, object property names. It will be appreciated that the screens may be generated by the browser module 1310 as previously described.
  • CDO Concept-Data Property-Object Property
  • Is a Inv Obj Prop Ont 1.2 is a Inv Obj Prop Ont 2.0 is a Inv Obj Prop Ont 2.0 is a Inv Obj Prop Ont 2.1 is a Inv Obj Prop Ont 2.2 is a Inv Obj Prop Ont 2.2 is a Inv Obj Prop Ont 2.2 is a Inv Obj Prop Ont 2.4 is a Inv Obj Prop Ont 2.4
  • the source information on which the aligner module performed the preceding calculations is all available in the indexes created by the indexer.
  • the indexes are constructed in multiple formats, corresponding to sorting the above tables into different sequences.
  • the aligner module can perform many of its tasks by executing SQL queries against the indexes.
  • index structure An example of the index structure will now be described in more detail.
  • a root word or lemma is determined for each synonym set.
  • the semantic matcher module requires that the context be set in order to obtain the optimum results.
  • the context of each ontology is known, narrow and related to the other ontologies of interest.
  • the ontology is loaded into the semantic matcher module This will examine every word semantically using any definitions contained in the ontology and comparing them with those definitions already loaded into the semantic matcher module or available from public dictionaries such as WordNet.
  • the context is supplied by the ontology (e.g. Medical/Surgical or Geographical Location)
  • the semantic matcher module defines a Concept Id, a unique number corresponding to the lemma or root word for every family of synonyms.
  • the indexes are loaded into an appropriate database structure and tuned for performance. Typically this will involve creating multiple database indexes over the ontology index tables.
  • indexer module provides a service which is used by other modules, tools or components.
  • the pruner module is designed to enable a user to take a large ontology or a collection of aligned ontologies and prune them down to the classes of interest for the user's needs, without losing integrity by inadvertently deleting a component which contains data or axioms relevant to their ontology terms of interest.
  • FMA Foundational Model of Anatomy
  • the FMA is very large and highly detailed, though also very general in nature (e.g. non-application specific). It is also rigorous in its adherence to proper modelling principles. These criteria together lend the FMA to many possible applications. However, they have also rendered it cumbersome (i.e. overly large or detailed or principled) for use by any specific application.
  • Region-based i.e. the brain or the abdomen.
  • ⁇ System-based i.e. the cardiovascular system or the skeletal system.
  • Granularity-based i.e. only items visible in an x-ray or only cellular and sub-cellular components.
  • the desired ontology derivative was generally based on a subset extraction such as those above, it was then often further manipulated to better suit the needs of the application (i.e. classes added, classes removed, properties removed, properties added, etc.).
  • SNOMED-CT is a large medical ontology of medical terms used in clinical documentation. It consists of 300,000+ concepts with about 1 ,400,000 relationships between them. The concepts are divided into 9 functional areas. A researcher may only be interested in one of these areas, say mental health. Removing the other 18 areas would break many of the relationships between medical health terms and pharmaceutical terms. Obviously they may wish to retain these items. To do so manually would require many months of work with existing tools and would be prone to error.
  • a user may wish to create a new ontology from components of several existing source ontologies and then add their own additions.
  • the combined ontology would contain many irrelevant concepts which would need to be removed.
  • a parcel delivery company combining a transport ontology with a geo-location ontology to create an ontology which enables delivery routes to be determined and optimised.
  • axioms such as aeroplanes start and stop their journeys at airports, ships at ports and trains at stations, it would be possible to construct an information base covering every concept in their business model. However much of each source ontology would not be needed.
  • the pruned ontology definition may be used in place of a view over the complete ontology. This view could be used for a number of purposes such as access control, scope management etc.
  • the pruner module operates in conjunction with the browser module to perform the functions set out in Table 6 below.
  • Ontologies For example-given a geo ontology and a transport ontology construct a journey ontology which would allow analysis of the appropriate transport mechanisms between two locations.
  • the pruner module interacts with the browser module to allow a user to specify which classes, data properties, object properties and axioms of a selected ontology they wish to retain. Using those retained the pruner module checks to see that the relational and axiomatic integrity defined in the ontology is maintained.
  • the user may specify two essential concepts within a single ontology which must be retained in the pruned ontology.
  • the invention maps all the conceptual relationships between classes, tagging all classes which are required to analyse the specified concept. Additional classes, object properties and axioms are then included from the source ontology to ensure the integrity of the pruned ontology.
  • the user may specify two essential concepts from disparate ontologies which must be retained in the pruned ontology.
  • the pruner module attempts to map all the conceptual relationships between classes, tagging all classes which are required to analyse the specified concept. If no connecting paths are identified the software will recognise the potential impossibility of creating a pruned ontology which connects the two starting concepts. The user will be asked to:
  • FIG. 17A An example of the arrangement of the pruner module is shown in Figure 17A.
  • the pruner module 1330 opens ontologies 1701 defined in OWL and RDFS files, with the user then interacting with the pruner module 1330 via a set of screens 1702 as defined in Table 7 below, to thereby produce a pruned ontology 1703. It will be appreciated that the screens may be generated by the browser module 1310 as previously described. Table 7
  • the user selects the concepts that they require and the tool identifies and adds the components required for completeness and integrity.
  • the user selects a class as a starting seed point S 0 in the source ontology and tags it as K 0 for keep.
  • the computer identifies and tags as ' ⁇ - ⁇ ' all parents of classes marked K 0 ', all classes and inferences from classes and inferences tagged as K 0 . These tagged variables are called the Si-shell.
  • the user reviews the computer tagged items and retags them as Ki for Keep , Mi for Maybe and for Discard. All axioms are loaded for the tagged M, and K, components. The process is then repeated, incrementing i each time until the user has tagged all the components for the appropriate ontology.
  • a reasoner is then applied to the resulting ontology to identify potential errors and add inferred values. Any concepts, inferences or axioms thus added are tagged K n and the tagged components are exported as the pruned ontology.
  • the process is as shown in Figure 17C.
  • the user selects a class as a starting seed point S 0 in one ontology and another as ending seed point E 0 in either the same or another ontology and tags them both as K for Keep with 'K 0s ' or 'K 0e '-
  • the variables in the S and E shells are compared by the semantic matcher module described in more detail below.
  • the matcher module returns a numeric value for the match quality between variables in each shell. If the predetermined match quality is met then a path has been determined between the two shells. This should only occur of the shells overlap. If the start and end point are in the same ontology the match quality must be 1.0 or exact.
  • the data properties of a tagged data class may be pruned. This is performed by selecting the class and marking the data fields (data properties) as 'D' for Discard. Any inferences based upon the existence of the discarded field will be ignored.
  • the paths P j between S 0 and E 0 can be populated and a skeletal pruned ontology can be defined in terms of these paths. All class parents and inferred parents for tagged P j path components are also tagged as belonging to the path P j . All axioms are loaded for the tagged Pj path components thus creating an expanded ontology.
  • a reasoner is applied to the expanded ontology to identify potential errors and add inferred values. Any concepts, inferences or axioms thus added are tagged and exported as part of the pruned ontology.
  • the user selects a class as a starting seed point S 0 in one ontology and another as ending seed point E 0 in the other ontology and tags them both as K for Keep with 'K 0s ' or 'K 0e '.
  • they define a set of user defined paths which connect the ontologies, as shown by the lines 1710.
  • a reasoner is applied to the expanded ontology to identify potential errors and add inferred values. Any concepts, inferences or axioms thus added are included in the pruned ontology 1711 , which can now be exported.
  • object properties have the following attributes:
  • ⁇ The relationship has a direction. This is defined as from a 'Domain' concept to a 'Range' concept. In relational database terminology, the primary key of a Domain becomes a foreign key in a Range.
  • the relationship has a type, including:
  • the super/sub class relationship is equivalent to a special case of an object property.
  • a subclass 'inherits' all the Data Properties and all the Object Properties of its superclass.
  • the Data Property 'Type' in any concept raises a red flag as it implies the existence of an unmodelled concept, viz. 'Type of Club' in Club, Type of Member' in Member and so forth.
  • the 'Type of Club' concept could contain a list of all the valid values such as Sailing, Chess, Gymnastics etcetera.
  • the Type_of_Club concept would have an Object Property called 'Has Type' with Range of Club. This concept would be automatically included in the pruned ontology.
  • the user selects the ontology to be pruned in the browser module 'Landing screen'.
  • the ontology can be selected from any source, such as a file, Web address, or the like.
  • the Class List is generated using the index of the ontology. This list displays the name and description of each class.
  • search function is provided enabling the user to search by class name or part of a class description. It is also possible to search on a data property. In either case the search would return a list of classes which contain that data property. The user then selects a class as the starting point and tags it S 0 .
  • the user selects an end point E 0. If the user does not select an endpoint then they will need to manually control the pruning operation as described above. The user may also return to the Landing Screen and select another ontology for the end point or could alternatively add a set of bridging concepts and relationships if they are aware that the chosen ontologies are disparate. If the user does not specify bridging concepts then the process will proceed on the basis of the overlapping ontologies process described above, otherwise it will proceed as per the disparate ontologies process.
  • a number of metadata parameters can be set, including:
  • the user only specifies a starting point from which to start the pruning process. They can perform manual pruning in one of two manners, which can be used interchangeably at any time.
  • ⁇ From the Class List screen, typically displayed by the browser module 1310, they can tag classes to be retained with a 'K'. At any time they can select a 'Validate' option which will automatically tag any related classes and axioms and display the tagged classes in the class list. Additionally they can select a 'View' option which will pass the tagged classes to a graphing program to show the selected classes and relationships graphically.
  • the graphing program can be a publically available graphing packages such as OntoGraf or the like.
  • the user can open the starting class in the Class Display screen by clicking on the class in the Class List screen displayed by the browser module 1310.
  • the user can then tag all the data properties which they wish to retain, plus any sub/super classes plus any classes specified in the object properties frame. This process can be performed iteratively by clicking on the link to any related class displayed. At any time the user can return to the Class List screen to Validate or View their progress.
  • the user may decide to extend the process by changing the completion criteria in the application metadata and selecting the Resume option. If the user is satisfied with the result they would select the "Generate Ontology" option. This results in the pruned ontology being generated in the location specified in the application metadata.
  • the tags can be saved to allow easy re-editing of the pruning process.
  • the user specifies starting and end points and a set of related bridging concepts from which to run the pruning process. They may have saved tags from an earlier attempt to prune and merge the ontologies.
  • commence pruning option By selecting a commence pruning option the process will start as described in as per the disparate ontology process described above. Assuming that the application metadata parameters have been set to pause between shells the process will stop as each shell is completed.
  • the user can validate or view the automatically tagged items and may remove any tags that they recognise as irrelevant. Until a path connecting the starting and end points to one of the user defined bridging points is established the view function will display many partial ontologies, one for each user defined point and one for the starting and end points.
  • the user may decide to extend the process by changing the completion criteria in the application metadata and selecting the Resume option.
  • the semantic matcher module enables a mathematical value to be applied to the degree to which two concepts are similar when considered within a particular context.
  • the name for this process is 'semantic matching' and it is of particular importance when trying to align the concepts in two ontologies.
  • All companies are organisations but not all organisations are companies.
  • the class companies are a subset of the class organisation. For example "This organisation is a listed company but that organisation is a golf club”.
  • a social context company is not related to organisation but may be related to a set of associates. For example "John Doe keeps bad company". A club and a company are both organisations so there is some similarity. A listed company and an unlisted company are also similar and share a common parent. Are they as conceptually close as a club and a company? What about a public unlisted company (>50 shareholders) and a private unlisted company ( ⁇ 51 shareholders)? Are they closer than a listed company and an unlisted company?
  • Another common technique is to arrange the concepts in a single hierarchical tree with the concept of 'thing' as the root. Most Sameness formulae are functions of the number of concepts between those being measured and their common parent, and the distance to the root of the hierarchy.
  • the distance to the root of the hierarchy can differ significantly, depending upon the ontologist who built the ontology and whether the ontology has been pruned by the person using the ontology, the distance to the root is generally irrelevant.
  • sameness is measured by the number of edges between concepts. Other possibilities exist based upon the number of data properties. For example, a club and a company may have "5" data properties each, the balance being held in the definition of an organisation, whereas a public listed company and a public unlisted company may only have one attribute each, the balance being held in the company definition. Thus a public unlisted company is more similar to a public listed company then a company is to a club ("2" attributes instead of "10", or in other words there is less difference and difference is equivalent to distance).
  • a good semantic matcher module should be able to calculate the sameness and distance of a match using any appropriate formula.
  • the existence of fingers implies the existence of hands. Although they are not the same there is a relationship between them and the existence of one implies the existence of the other because one is a part of the other (Meronym).
  • the semantic matcher module includes a database of concepts, their meaning and relationships between them. It has tools for loading the concepts from ontologies, for manually editing the relationships between concepts and their definitions and for analysing concepts in a mathematically defined manner. These mathematically defined properties of concepts and their relationships can then be used in a variety of situations, such as aligning ontologies, as a dictionary and as a semantic concept matcher module.
  • the semantic matcher module concept finds synonyms, subsumptions (class hierarchy) and meronyms (part of) in a particular context (e.g. Medical, Business). It is initially loaded by parsing an ontology and obtaining the classes, their annotations, class structure and any 'part-of Object properties. The class name is then used in something such as WordNet or Watson to determine the meaning and possible synonyms. The meaning is parsed into triples, as are any notations. The matcher module then looks for mathematical correspondences in the triples determine synonymity.
  • the semantic matcher module is a stand-alone process which either evaluates two lists of concepts, typically from two ontologies or else evaluates a single concept, matching this against reference terms to determine a meaning for the concept.
  • matcher module will pair each item in the first list with each item in the second list. Each pair i,j is then analysed to determine the following items:
  • the matcher module takes a single concept and a context definition and produces a list of synonyms, sub and superclasses and meronyms for that concept in that context. If the context is not supplied the evaluation is performed across all contexts.
  • SemMatch SemMat(Party, Client, Business) ⁇ (1.0,0,0)
  • SemMat(Car,Wheels,Automotive) (0.1 ,0,1 )
  • SemMat(Patient,Person,Medical) (0.25,-1 ,0)
  • SemMat(Patient,Person, ) (0.25,-1 ,0)
  • SubClass Patient, Practitioner, Performer
  • the Semantic Matcher module 1350 uses a Concept Matching Database 1604 to perform its evaluations.
  • two lists of concepts 1801 , 1802, such as ontology terms A, B and X, Y are received and then compared by the semantic matcher module 1350 to generate sameness scores 1803 for each possible pairing of ontology terms.
  • a single concept such as a single ontology term 1804 is received, and the semantic matcher module 1350 compares this to the concept matching database 1604 and returns a list of synonyms 1805.
  • the concept matching database (CMD) 1604 is constructed using the indexer module 1320. Before it can be used the database must first be loaded, which is typically it would be loaded by parsing an ontology based upon the context of interest. The database can be updated by the user at any time to add new contexts.
  • the CMD 1604 contains a number of tables as defined in Table 8, with the relationships between the tables being shown in 18C.
  • WordJD An automatically generated unique computer key.
  • SourceJD The Ontology from which the word was sourced.
  • a concept name It may be more than one word.
  • Name of a context typically the name of an
  • Context ontology e.g. SNOMED CT, HL7 RIM.
  • ContextJD An automatically generated unique computer key.
  • SourceJD An automatically generated unique computer key.
  • Relation_Type_ID An automatically generated unique computer key.
  • CCW_ID_C concept key is a part i.e. Concept ID is part of
  • Relation_Type_ID IncludesJD concept key is a part i.e. IncludesJD is part of ConceptJD.
  • Word_ID_P The parent word key.
  • an overall context of the ontologies 1801 to be loaded is determined and entered into the Context table with an ID of 1. For example, if medical ontologies are loaded, the context would be identified as "medical".
  • Each of these ontologies has a source which will be loaded into the Source table thus allowing the Source 2 Context table to also be loaded.
  • Temporary tables are created relating WordJD2ContextJD with lemma and Concept, both set to null, and Class20bject-Property2Class with Word IDs for each class and ConceptJD set to null.
  • the first step is to match each word to a meaning and synonym obtained from a standard dictionary, such as the WordNet 1802. Any unmatched words are then matched against words from other contexts to identify synonyms.
  • WordNet 1802 Each word in the Word table is passed to WordNet 1802 to obtain a meaning and potentially the root word or lemma for the group of synonyms or lexeme, based upon that Word.
  • the WordNet meaning is lexically compared with the meaning derived from the annotation.
  • Wordnet Word and Meaning are loaded into the Word table with a new WordJD.
  • the new WordJD is assigned to WordJD_C and the original WordJD is assigned to WordJDJ 3 both are then loaded into the Word2Word.
  • the WordJD2ContextJD table is loaded with the WordJD assigned to the Wordnet Lemma as the WordJD and the same ContextJD as the related WordJD, which was loaded as the WordJD_P.
  • the WordJD2ContextJD table has only two columns lemma and concept. So the lemma is assigned with new WordJD_C and concept is assigned from WordJDJ 3 .
  • the Class20bject-Property2Class is loaded with the WordJD information from Wordnet 1802.
  • All words for which a Lemma was defined are then loaded into the Concept table.
  • the Word_ID2Context_ID can now be updated with known Concept ID and Lemma and used to load the Concept_Word_Context table resulting in the CWCJD being assigned to each Concept and Word used in the named Context.
  • the CWCJD can be used to identify the words in the Class20bject-Property2Class and together to populate the CWC2CWC table and the RelationJType table.
  • a second pass of the Word table examines the meanings of every word for which there is no related lemma, by syntactically comparing the meaning with the meanings of words in the other contexts.
  • the WordJD of the first meaning to match is chosen as the lemma.
  • the process then continues as for Wordnet identified lemmas.
  • a third pass simply identifies each word which is not related to a lemma as being a lemma. At the completion of these three passes every word will have been identified in every possible context in the concept table 1809.
  • An organisation is a concept which is defined as follows; "An organisation is a collection of individuals with an agreed reason for being their collection", which could be converted as shown in Table 10.
  • Table 10
  • a Member of a Club is an Individual. This could have been inferred if the Membership concept had the Object Properties more correctly defined as Member isAn Individual instead of Individual Holds Membership.
  • SPO shared predicate object
  • ontology alignment tools find classes of data that are "semantically equivalent,” for example, "Truck” and "Lorry.” The classes are not necessarily logically identical.
  • the result of an ontology alignment is a set of statements representing correspondences between the entities of different ontologies. This may be expressed in the purpose built language Expressive and Declarative Ontology Alignment Language' (EDOAL) (David, et al., 2013) or other languages (ZIMMERMANN, et al., 2006).
  • EEOAL Expressive and Declarative Ontology Alignment Language'
  • ZIMMERMANN et al., 2006
  • the first requirement is to determine if there is a semantic match between the concepts in the ontologies being aligned, which can be determined using the semantic matcher module described above.
  • the words 'company' and Organisation' in a business context do not have exactly the same meaning.
  • All companies are organisations but not all organisations are companies.
  • the class companies is a subset of the class organisation. For example "This organisation is a listed company but that organisation is a golf club”.
  • In a social context company is not related to organisation but may be related to a set of associates. For example "John Doe keeps bad company”.
  • a club and a company are both organisations so there is some similarity.
  • a listed company and an unlisted company are also similar and share a common parent viz. company. Are they as conceptually close as a club and a company? What about a public unlisted company (>50 shareholders) and a private unlisted company ( ⁇ 51 shareholders)? Are they closer than a listed company and an unlisted company?
  • a Putative Ontology is an ontology created from a structured source, typically a relational database, an xml file or a spreadsheet. Such an alignment may have some very complex mappings in which data instances in the putative ontology map to classes in the full ontology. This is a special case of alignment.
  • Figure 19A shows a "Thing Database”, which is an example of a totally de-normalised data structure as it can contain the metadata (and hence structure) as well as the data within four tables.
  • Thing Type table contains a Thing Type of 'Class'
  • every related row in the Thing table would contain the name of a class.
  • the relationship between classes would be defined in the Thing to Thing' table where the Thing Type to Thing Type' specifies the type of relationship.
  • any Type table can give rise to a set of classes.
  • a vehicle type table could have been used to ensure that only valid types of vehicles are included. For example Cars, trucks, tractors but not prams, bicycles, ships. Ontologically, we could then have a separate class for each type of vehicle specified in the Vehicle Type table. This concept can be generalised but is not always appropriate. It could result in every personnel table being split into male and female classes! Consequently the program should identify every situation in which hidden classes contained in the data can be exposed and present them to the user for validation.
  • Type table may contain many types of types.
  • Concepts, Data Properties and Properties of Data Properties such as Vehicles, trucks, Cars, engine type, weight, kilograms. This could be shown as:
  • ⁇ Car has engine type diesel
  • ⁇ Car is subclass of Vehicle
  • a common alignment technique is to arrange the concepts from each ontology into two hierarchical trees, each with the concept of 'thing' as the root.
  • the mathematical concept of 'Distance' is then introduced to give some mathematical mechanism for determining alignment.
  • Most Distance formulae are functions of the number of concepts between those being measured and their common parent, and the distance to the root of the hierarchy.
  • the ontology aligner module looks for common concepts in multiple ontologies and maps the concepts from one ontology to the other thus allowing the two ontologies to be treated as one ontology. Using the alignment it is also possible to merge the two ontologies although this is a risky process and is not generally recommended due to the potential for semantic mis-match propagation.
  • ontologies 1901 , 1902 defined in OWL and RDFS files are opened using the aligner module 1340, with the user then interacting with the ontology using a set of screens as defined below, ultimately resulting in ontologies 1903, 1904 connected by a series of alignments 1905 and potentially a merged aligned ontology 1906.
  • the process consists of a number of sub processes, including:
  • Alignment Map This map is updated every time an alignment is identified and is consulted by the program before a new alignment pair is considered for evaluation to prevent duplication of effort.
  • the Alignment Map can be displayed to the user enabling them to follow the alignment process, query and override any potential alignment and instruct the program to re-perform any process.
  • Each step i can be assigned a weighting factor Wi, with the results being combined to provide an overall alignment score. These weighting factors are applied at certain steps.
  • a possible Weight Accumulation formula is given, but there are many possible weighting schemes that could be used. This is an area where machine learning or statistical analysis and inferencing can be used to determine suitable weighting formulas.
  • MVi A ⁇ ⁇ ⁇ / Wi +( Wi - 1 )*MVi/ Wi
  • MV is the raw Match Value calculated in step i.
  • MV is the weighted match value and MV, is the match value at step i.
  • MV for each pair is based upon the score provided by the semantic matcher module and Set 1.0 for purposes of this example.
  • the alignment map records the two concepts, assigns an alignment Id, a minimal map Id, any tags associated with the alignment, any PMP Id assigned, any enrichment Id and the last processing step Id.
  • a separate table, related on the Alignment Id stores the Match Value for each step. These values can be manually overridden if desired.
  • the process continues to the next class related to the current class in the first Ontology by an Object Property.
  • Superclasses of the current class are processed first.
  • the program processes Inheritance Object Properties before other Object Properties.
  • Superclasses of the current class are processed before any subclasses are examined. The process stops as soon as an alignment with MV ⁇ MV AT . is found.
  • ⁇ 'Type' table in ERA diagrams must be identified. The user must select each row in the type table which is to be.
  • each PMP is tagged as 'PMP' and given a PMP-set-identifier PMP01 , PMP02, ... for each set of equivalent BOM tables. They are resolved later on, as will be described in more detail below. As each PMP class is identified the details may be presented to the user who may decide that that instance is not a PMP.
  • ⁇ MV is calculated as follows:
  • the Match Value MV 3 N M /N A .
  • MV 3 A MV 2 A / W 3 +( W 3 - 1 ) * MV 3 / W 3
  • N(A) is the number of Data properties in A, assuming N(A) ⁇ N(B)
  • MVi ⁇ ( ⁇ )/ ⁇ ( ⁇ ) where N(A) is the number of Data properties in A, assuming
  • MV 4 A MV 3 A / W 4 +( W 4 - 1 ) * MV/ W 4
  • Multi class mappings occur when the class in on ontology has been split into a number of subclasses in another ontology. In such cases we would expect the pair to be have already been tagged as either "Possible Siblings” or “Multi Class Mappings” and "Subset”.
  • the multiclass mapping is usually detected by analysing the number of Data Properties for the potentially related classes in the class and sub classes in each ontology. If the ontology class which does not have a subclass has the number of Data Properties approximately equal to the class in the other Ontology plus the Data Properties of the sub-class with the most Data Properties then it is probable that the sub classes of the class in the second ontology have been denormalised into the class in the first ontology.
  • the Data Properties in single class in one ontology maps to the Data Properties in a class and subclass or subclasses in the other ontology.
  • the Data Properties in a class and subclasses match to the Data Properties in a class and some subclasses in the other ontology.
  • the Data Property count is performed by considering matching the Data Properties of the first ontology class with the Data Properties of each pair composed of Class + Subclass in the second ontology.
  • Company in Ontology 1 has no children and 2 children in Ontology 2. If analysing the Data Properties of company (1 ) with Company + Listed Company (2) shows that the number of Data Properties match but not all the meanings.
  • N() is the function to produce the number of Data properties in concepts A, B and ⁇ .
  • This method can be generalised to the situation where the two classes have a different number of children. This situation can be tagged as 'Enrichment Possible' and each class involved is given a single enrichment ID.
  • PMP resolution involves identifying additional classes in putative ontologies by identifying denormalised classes stored in tables, and results in a major enrichment of the ontology from which it was derived.
  • Each PMP-set-identifier is analysed to determine its mapping to a Type structure or a BOM structure as described above. These generally map to some arrangement of the ERA diagram shown in Figure 19A, as is determined by mapping only the Object properties with the matching structural relationships in that diagram.
  • An example of extracted classes from Data Property instances is shown in Tables 14 to 17.
  • mapping is determined it is a relatively simple matter to generate the denormalised ontology captured in the BOM structure.
  • This generated ontology component can then be aligned by returning to the step of low level class matching based on the semantic meaning of the classes as previous described. In this step the Classes generated from the BOM analysis will be added to the appropriate minimal maps.
  • No MV is calculated for this step as it results in the return to the step of low level class matching and the recalculation of the MV values for the newly identified classes.
  • each enrichmentJD identified in the multi class mappings process being analysed to determine whether the subclass sets from the two ontologies match or contain siblings.
  • ontology 1 class organisation may have sub classes Club and Company.
  • Ontology 2 contains Qango, Club and Company.
  • Qango is a sibling in Ontology 2 but does not appear in ontology 1. Rather than say the Qango does not align with anything it would be better to identify it as an enrichment to Ontology 1.
  • Minimal Map Once the Minimal Map has been fully processed it is recorded along with its classes as a set of RDF triples.
  • Minimal Maps must be assembled into a single map by querying the RDF triple generated above. This will be a map of all the classes for which an alignment with acceptable threshold value was found. There may be unaligned items.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Animal Behavior & Ethology (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Machine Translation (AREA)
PCT/AU2015/000195 2014-04-02 2015-04-02 Ontology mapping method and apparatus WO2015149114A1 (en)

Priority Applications (10)

Application Number Priority Date Filing Date Title
CA2952549A CA2952549A1 (en) 2014-04-02 2015-04-02 Ontology mapping method and apparatus
EP15774345.1A EP3127020A1 (en) 2014-04-02 2015-04-02 Ontology mapping method and apparatus
JP2016559652A JP2017513134A (ja) 2014-04-02 2015-04-02 オントロジーマッピング方法及び装置
KR1020167030643A KR20170021227A (ko) 2014-04-02 2015-04-02 온톨로지 매핑 방법 및 장치
CN201580029320.2A CN106663101A (zh) 2014-04-02 2015-04-02 本体映射方法和设备
US15/301,357 US11921769B2 (en) 2014-04-02 2015-04-02 Ontology mapping method and apparatus
SG11201607828RA SG11201607828RA (en) 2014-04-02 2015-04-02 Ontology mapping method and apparatus
AU2015240418A AU2015240418A1 (en) 2014-04-02 2015-04-02 Ontology mapping method and apparatus
IL248022A IL248022A0 (en) 2014-04-02 2016-09-25 A method and device for ontological mapping
US18/394,830 US20240152542A1 (en) 2014-04-02 2023-12-22 Ontology mapping method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201461974180P 2014-04-02 2014-04-02
US61/974,180 2014-04-02

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/301,357 A-371-Of-International US11921769B2 (en) 2014-04-02 2015-04-02 Ontology mapping method and apparatus
US18/394,830 Continuation US20240152542A1 (en) 2014-04-02 2023-12-22 Ontology mapping method and apparatus

Publications (1)

Publication Number Publication Date
WO2015149114A1 true WO2015149114A1 (en) 2015-10-08

Family

ID=54239127

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2015/000195 WO2015149114A1 (en) 2014-04-02 2015-04-02 Ontology mapping method and apparatus

Country Status (10)

Country Link
US (2) US11921769B2 (zh)
EP (1) EP3127020A1 (zh)
JP (1) JP2017513134A (zh)
KR (1) KR20170021227A (zh)
CN (1) CN106663101A (zh)
AU (1) AU2015240418A1 (zh)
CA (1) CA2952549A1 (zh)
IL (1) IL248022A0 (zh)
SG (1) SG11201607828RA (zh)
WO (1) WO2015149114A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3163513A1 (en) * 2015-10-26 2017-05-03 Agfa Healthcare Method of automated notation 3 (n3) query rule creation
WO2017091120A1 (en) * 2015-11-25 2017-06-01 MiNDiGO AB A system and a method for ontology based browsing
JP2019536178A (ja) * 2016-09-22 2019-12-12 エヌフェレンス, インコーポレイテッドNference, Inc 意味的情報の可視化およびライフサイエンスエンティティ間の顕著な関連を示す時間的信号の推測のためのシステム、方法、およびコンピュータ可読媒体
US11074230B2 (en) 2018-09-04 2021-07-27 International Business Machines Corporation Data matching accuracy based on context features
US11487902B2 (en) 2019-06-21 2022-11-01 nference, inc. Systems and methods for computing with private healthcare data
US11545242B2 (en) 2019-06-21 2023-01-03 nference, inc. Systems and methods for computing with private healthcare data

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9720899B1 (en) 2011-01-07 2017-08-01 Narrative Science, Inc. Automatic generation of narratives from data using communication goals and narrative analytics
US11238090B1 (en) 2015-11-02 2022-02-01 Narrative Science Inc. Applied artificial intelligence technology for using narrative analytics to automatically generate narratives from visualization data
US11922344B2 (en) 2014-10-22 2024-03-05 Narrative Science Llc Automatic generation of narratives from data using communication goals and narrative analytics
US11288328B2 (en) 2014-10-22 2022-03-29 Narrative Science Inc. Interactive and conversational data exploration
US10152556B1 (en) * 2015-04-16 2018-12-11 Jpmorgan Chase Bank, N.A. Semantic modeling platform
US11232268B1 (en) 2015-11-02 2022-01-25 Narrative Science Inc. Applied artificial intelligence technology for using narrative analytics to automatically generate narratives from line charts
US11222184B1 (en) 2015-11-02 2022-01-11 Narrative Science Inc. Applied artificial intelligence technology for using narrative analytics to automatically generate narratives from bar charts
US11188588B1 (en) 2015-11-02 2021-11-30 Narrative Science Inc. Applied artificial intelligence technology for using narrative analytics to interactively generate narratives from visualization data
US10545955B2 (en) * 2016-01-15 2020-01-28 Seven Bridges Genomics Inc. Methods and systems for generating, by a visual query builder, a query of a genomic data store
US11238115B1 (en) 2016-07-11 2022-02-01 Wells Fargo Bank, N.A. Semantic and context search using knowledge graphs
US10878000B2 (en) * 2016-07-29 2020-12-29 Hewlett Packard Enterprise Development Lp Extracting graph topology from distributed databases
US11144838B1 (en) 2016-08-31 2021-10-12 Narrative Science Inc. Applied artificial intelligence technology for evaluating drivers of data presented in visualizations
US10067965B2 (en) 2016-09-26 2018-09-04 Twiggle Ltd. Hierarchic model and natural language analyzer
US20180089316A1 (en) * 2016-09-26 2018-03-29 Twiggle Ltd. Seamless integration of modules for search enhancement
US11100469B2 (en) * 2016-10-25 2021-08-24 International Business Machines Corporation Cross-domain collaborative data log
US9946777B1 (en) 2016-12-19 2018-04-17 Palantir Technologies Inc. Systems and methods for facilitating data transformation
US11238084B1 (en) * 2016-12-30 2022-02-01 Wells Fargo Bank, N.A. Semantic translation of data sets
US10678834B2 (en) * 2017-02-02 2020-06-09 GM Global Technology Operations LLC Methodology for generating a consistent semantic model by filtering and fusing multi-source ontologies
US11068661B1 (en) 2017-02-17 2021-07-20 Narrative Science Inc. Applied artificial intelligence technology for narrative generation based on smart attributes
US11954445B2 (en) 2017-02-17 2024-04-09 Narrative Science Llc Applied artificial intelligence technology for narrative generation based on explanation communication goals
US11568148B1 (en) 2017-02-17 2023-01-31 Narrative Science Inc. Applied artificial intelligence technology for narrative generation based on explanation communication goals
US10943069B1 (en) 2017-02-17 2021-03-09 Narrative Science Inc. Applied artificial intelligence technology for narrative generation based on a conditional outcome framework
KR102159220B1 (ko) * 2017-05-11 2020-09-23 경희대학교 산학협력단 효과적인 대화 관리를 위한 의료 시스템에서의 의도-컨텍스트 융합 방법
US20180357381A1 (en) * 2017-06-09 2018-12-13 Intelligent Medical Objects, Inc. Method and System for Generating Persistent Local Instances of Ontological Mappings
WO2019001445A1 (zh) * 2017-06-30 2019-01-03 华为技术有限公司 一种管理本体的方法以及m2m平台
CN109246660B (zh) * 2017-06-30 2020-05-08 华为技术有限公司 一种管理本体的方法以及m2m平台
US10846644B2 (en) 2017-09-15 2020-11-24 International Business Machines Corporation Cognitive process learning
US10628777B2 (en) 2017-09-15 2020-04-21 International Business Machines Corporation Cognitive process enactment
US11488029B2 (en) * 2017-09-15 2022-11-01 International Business Machines Corporation Cognitive process code generation
US11853930B2 (en) * 2017-12-15 2023-12-26 Accenture Global Solutions Limited Dynamic lead generation
CN107978341A (zh) * 2017-12-22 2018-05-01 南京昂特医信数据技术有限公司 一种基于语境的医学语义框架下的异构数据适配方法及其系统
US11042709B1 (en) 2018-01-02 2021-06-22 Narrative Science Inc. Context saliency-based deictic parser for natural language processing
US10963649B1 (en) 2018-01-17 2021-03-30 Narrative Science Inc. Applied artificial intelligence technology for narrative generation using an invocable analysis service and configuration-driven analytics
US10755046B1 (en) 2018-02-19 2020-08-25 Narrative Science Inc. Applied artificial intelligence technology for conversational inferencing
CN108710677B (zh) * 2018-05-18 2021-08-17 中国兵器工业新技术推广研究所 通过NoSQL数据库实现BOM数据多组织多视图的解决方法
US10740345B2 (en) * 2018-06-27 2020-08-11 MDClone Ltd. Data structures for storing and manipulating longitudinal data and corresponding novel computer engines and methods of use thereof
US10706236B1 (en) 2018-06-28 2020-07-07 Narrative Science Inc. Applied artificial intelligence technology for using natural language processing and concept expression templates to train a natural language generation system
JP7135641B2 (ja) * 2018-09-19 2022-09-13 日本電信電話株式会社 学習装置、抽出装置及び学習方法
CN109447267B (zh) * 2018-10-16 2021-04-06 东北石油大学 融合数据元标准的叙词本体构建方法
CN110059194B (zh) * 2019-03-01 2022-04-08 中国科学院信息工程研究所 一种融合表示学习和分治策略的大规模本体合并方法
US11935636B2 (en) 2019-04-26 2024-03-19 Merative Us L.P. Dynamic medical summary
DE112019007213B4 (de) * 2019-05-20 2023-05-04 Mitsubishi Electric Corporation Ontologieerzeugungssystem, Ontologieerzeugungsverfahren und Ontologieerzeugungsprogramm
US10909160B2 (en) * 2019-05-29 2021-02-02 TADA Cognitive Solutions, LLC Digital duplicate
US11269907B1 (en) * 2019-11-15 2022-03-08 Palantir Technologies Inc. Object-centric data analysis system and graphical user interface
CN110688433B (zh) * 2019-12-10 2020-04-21 银联数据服务有限公司 一种基于路径的特征生成方法及装置
US11734333B2 (en) * 2019-12-17 2023-08-22 Shanghai United Imaging Intelligence Co., Ltd. Systems and methods for managing medical data using relationship building
US11580326B2 (en) 2019-12-30 2023-02-14 Nec Corporation Ontology matching based on weak supervision
JP7352501B2 (ja) * 2020-03-17 2023-09-28 株式会社東芝 情報処理装置、情報処理方法、およびプログラム
US11816434B2 (en) * 2020-08-27 2023-11-14 Entigenlogic Llc Utilizing inflection to select a meaning of a word of a phrase
US11455588B2 (en) 2020-09-04 2022-09-27 TADA Cognitive Solutions, LLC Data validation and master network techniques
US20220374459A1 (en) * 2021-05-17 2022-11-24 Salesforce.Com, Inc. Systems and methods for hierarchical retrieval of semantic-based passages in deep learning
US20230033904A1 (en) * 2021-07-28 2023-02-02 Illumex Technologies, Ltd. System and method for generating business ontologies and glossaries from metadata
US11714956B1 (en) * 2022-01-27 2023-08-01 Rakuten Mobile, Inc. Ontology-based semantic rendering

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7328209B2 (en) * 2004-08-11 2008-02-05 Oracle International Corporation System for ontology-based semantic matching in a relational database system
US7567915B2 (en) * 1999-08-20 2009-07-28 6100198 Canada Inc. Ontology-driven information system
US20100281061A1 (en) * 2009-04-30 2010-11-04 International Business Machines Corporation Semantic Data Validation of Disjoint Data
US20110078205A1 (en) * 2009-09-30 2011-03-31 Robin Salkeld Method and system for finding appropriate semantic web ontology terms from words
US20110179032A1 (en) * 2002-07-12 2011-07-21 Nuance Communications, Inc. Conceptual world representation natural language understanding system and method
EP2469421A1 (en) * 2010-12-23 2012-06-27 British Telecommunications Public Limited Company Method and apparatus for processing electronic data
US20120330974A1 (en) * 2011-06-24 2012-12-27 Sonja Zillner Method of composing an ontology alignment

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006011739A (ja) * 2004-06-24 2006-01-12 Internatl Business Mach Corp <Ibm> オントロジを利用する装置、コンピュータシステムおよびデータ処理方法
US8640087B2 (en) * 2006-03-17 2014-01-28 The Mitre Corporation Semantic system for integrating software components
US7558791B2 (en) * 2006-07-31 2009-07-07 Informed Control Inc System and method for ontology-based translation between directory schemas
US20100185700A1 (en) * 2007-09-17 2010-07-22 Yan Bodain Method and system for aligning ontologies using annotation exchange
US9396283B2 (en) * 2010-10-22 2016-07-19 Daniel Paul Miranker System for accessing a relational database using semantic queries
US8856181B2 (en) * 2011-07-08 2014-10-07 First Retail, Inc. Semantic matching
US20130018827A1 (en) * 2011-07-15 2013-01-17 International Business Machines Corporation System and method for automated labeling of text documents using ontologies
EP2755148A1 (en) * 2013-01-15 2014-07-16 Fujitsu Limited Data storage system, and program and method for execution in a data storage system

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7567915B2 (en) * 1999-08-20 2009-07-28 6100198 Canada Inc. Ontology-driven information system
US20110179032A1 (en) * 2002-07-12 2011-07-21 Nuance Communications, Inc. Conceptual world representation natural language understanding system and method
US7328209B2 (en) * 2004-08-11 2008-02-05 Oracle International Corporation System for ontology-based semantic matching in a relational database system
US20100281061A1 (en) * 2009-04-30 2010-11-04 International Business Machines Corporation Semantic Data Validation of Disjoint Data
US20110078205A1 (en) * 2009-09-30 2011-03-31 Robin Salkeld Method and system for finding appropriate semantic web ontology terms from words
EP2469421A1 (en) * 2010-12-23 2012-06-27 British Telecommunications Public Limited Company Method and apparatus for processing electronic data
US20120330974A1 (en) * 2011-06-24 2012-12-27 Sonja Zillner Method of composing an ontology alignment

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3163513A1 (en) * 2015-10-26 2017-05-03 Agfa Healthcare Method of automated notation 3 (n3) query rule creation
WO2017072097A1 (en) * 2015-10-26 2017-05-04 Agfa Healthcare Method of automated notation 3 (n3) query rule creation
WO2017091120A1 (en) * 2015-11-25 2017-06-01 MiNDiGO AB A system and a method for ontology based browsing
JP2022133385A (ja) * 2016-09-22 2022-09-13 エヌフェレンス，インコーポレイテッド 意味的情報の可視化およびライフサイエンスエンティティ間の顕著な関連を示す時間的信号の推測のためのシステム、方法、およびコンピュータ可読媒体
JP7106077B2 (ja) 2016-09-22 2022-07-26 エヌフェレンス，インコーポレイテッド 意味的情報の可視化およびライフサイエンスエンティティ間の顕著な関連を示す時間的信号の推測のためのシステム、方法、およびコンピュータ可読媒体
JP2019536178A (ja) * 2016-09-22 2019-12-12 エヌフェレンス, インコーポレイテッドNference, Inc 意味的情報の可視化およびライフサイエンスエンティティ間の顕著な関連を示す時間的信号の推測のためのシステム、方法、およびコンピュータ可読媒体
JP7229495B2 (ja) 2016-09-22 2023-02-28 エヌフェレンス，インコーポレイテッド 意味的情報の可視化およびライフサイエンスエンティティ間の顕著な関連を示す時間的信号の推測のためのシステム、方法、およびコンピュータ可読媒体
US11900274B2 (en) 2016-09-22 2024-02-13 nference, inc. Systems, methods, and computer readable media for visualization of semantic information and inference of temporal signals indicating salient associations between life science entities
US11074230B2 (en) 2018-09-04 2021-07-27 International Business Machines Corporation Data matching accuracy based on context features
US11487902B2 (en) 2019-06-21 2022-11-01 nference, inc. Systems and methods for computing with private healthcare data
US11545242B2 (en) 2019-06-21 2023-01-03 nference, inc. Systems and methods for computing with private healthcare data
US11829514B2 (en) 2019-06-21 2023-11-28 nference, inc. Systems and methods for computing with private healthcare data
US11848082B2 (en) 2019-06-21 2023-12-19 nference, inc. Systems and methods for computing with private healthcare data

Also Published As

Publication number Publication date
KR20170021227A (ko) 2017-02-27
JP2017513134A (ja) 2017-05-25
CN106663101A (zh) 2017-05-10
AU2015240418A1 (en) 2016-11-17
SG11201607828RA (en) 2016-10-28
US11921769B2 (en) 2024-03-05
US20170185674A1 (en) 2017-06-29
IL248022A0 (en) 2016-11-30
EP3127020A1 (en) 2017-02-08
US20240152542A1 (en) 2024-05-09
CA2952549A1 (en) 2015-10-08

Similar Documents

Publication Publication Date Title
US20240152542A1 (en) Ontology mapping method and apparatus
US11899705B2 (en) Putative ontology generating method and apparatus
US11625424B2 (en) Ontology aligner method, semantic matching method and apparatus
US20170083547A1 (en) Putative ontology generating method and apparatus
US20170061001A1 (en) Ontology browser and grouping method and apparatus
Bakar et al. Feature extraction approaches from natural language requirements for reuse in software product lines: A systematic literature review
JP2022526242A (ja) テキストドキュメントのアノテーションのための方法、装置、およびシステム
Fu FCA based ontology development for data integration
Vavliakis et al. RDOTE–publishing relational databases into the semantic web
Ristoski Exploiting semantic web knowledge graphs in data mining
Sellami et al. Keyword-based faceted search interface for knowledge graph construction and exploration
Amarger et al. Skos sources transformations for ontology engineering: Agronomical taxonomy use case
Embley et al. Conceptual modeling foundations for a web of knowledge
Fu et al. Building SysML model graph to support the system model reuse
Pietranik et al. A method for ontology alignment based on semantics of attributes
Banouar et al. Interoperability of information systems through ontologies: State of art
Kwakye A Practical Approach to Merging Multidimensional Data Models
Wang et al. AceMap: Knowledge Discovery through Academic Graph
Mosca et al. Ontology learning from relational database: a review
Kong et al. Boosting Code Search with Structural Code Annotation
Tomingas et al. Discovering Data Lineage from Data Warehouse Procedures
Rabbani Supporting the Semi-Automatic Creation of the Target Schema in Data Integration Systems
Hartmann et al. Directing the development of constraint languages by checking constraints on rdf data
Nentwig Scalable Data Integration for Linked Data
Nguyen Semantic and structural integration of heterogeneous XML sources

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15774345

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 248022

Country of ref document: IL

ENP Entry into the national phase

Ref document number: 2016559652

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15301357

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 201691989

Country of ref document: EA

ENP Entry into the national phase

Ref document number: 20167030643

Country of ref document: KR

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2015774345

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015774345

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2015240418

Country of ref document: AU

Date of ref document: 20150402

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2952549

Country of ref document: CA