| Line 14 was replaced by line 14 |
| - searchCompatible( ResourceID, Port, StructTypeFlag, RemoteFlag ) :: Set<ResourceID> |
| + searchCompatible( ResourceID, Port, StructTypeFlag, RemoteFlag ) :: Set<ResourceID> |
| At line 18 added 4 lines. |
| + |
| + |
| + semanticType( ResourceID, String, RemoteFlag ) :: ConceptExpression // summarizing annotations |
| + |
| Line 27 was replaced by line 31 |
| - {{{search( ConceptExpression, Set<ResourceType>, RemoteSearchFlag ) :: Set<ResourceID>}}} |
| + {{{search( ConceptExpression, Set<ResourceType>, RemoteFlag ) :: Set<ResourceID>}}} |
| At line 32 added 1 line. |
| + |
| Line 46 was replaced by line 51 |
| - The first operation returns the resource type of a given resource identifier (an LSID). The second operation returns the set of semantic annotations known to the kepler object manager (including annotations stored on remote repositories depending on the value of the search flag). The last operation returns the ontology for a given ontology identifier (also a resource id). |
| + The first operation returns the resource type of a given resource identifier (an LSID). The second operation returns the set of semantic annotations known to the kepler object manager (including annotations stored on remote repositories depending on the value of the remote flag). The last operation returns the ontology for a given ontology identifier (also a resource id). |
| Line 50 was replaced by line 55 |
| - In general, the {{search}} operation requires access to all semantic annotations to find matching resources. For example, consider a search expression {{A and B}}, i.e., a resource must contribute to both concept {{A}} and concept {{B}}. To find appropriate matches for this search term, the algorithm must look for annotations that explicitly state {{A and B}} as well as those that state only {{A}} and only {{B}} (which taken together make {{A and B}}). Note that an annotation that states only {{A}} may be in one repository, while an annotation that states only {{B}} may be in another. Thus, for remote searches, the {{search}} algorithm must gather and consider all remote annotations to find matching resources. The {{search}} operation is inherently centralized because of this situation. |
| + In general, the {{search}} operation requires access to all semantic annotations to find matching resources. For example, consider a search expression {{A and B}}, i.e., a resource must contribute to both concept {{A}} and concept {{B}}. To find appropriate matches for this search term, the algorithm must look for annotations that explicitly state {{A and B}} as well as those that state only {{A}} and only {{B}} (which taken together make {{A and B}}). Note that an annotation that states only {{A}} may be in one repository, while an annotation that states only {{B}} may be in another. Thus, for remote searches, the {{search}} algorithm must obtain and consider all remote annotations to find matching resources, making the {{search}} operation inherently centralized. |
| Line 62 was replaced by line 67 |
| - Using these operations, the {{search}} algorithm would procede as follows, assuming that the remote search flag has been selected. With the {{getRepositories}} service, the algorithm first obtains the available repositories from the local kepler object manager. The algorithm selects the first returned repository and with the {{getRepositories}} service, obtains the relevant resources in the respository. For each resource in the repository, the {{partialSearch}} service is used, which returns the parts of the concept expression that the resource matches (e.g., just the concept {{A}}). The algorithm then moves to the next repository, performing the same steps. However, for those resources already having partial matches (from the previous step), the algorithm reformulates the search term given to {{partialSearch}} to include only the additional required parts of the concept expression (e.g., just the concept {{B}}). Once a complete match is found, the resource is considered a match and is not further checked. Finally, the algorithm repeats the process until all repositories have been examined. |
| + Using these operations, the {{search}} algorithm would procede as follows, assuming that the remote flag has been selected. With the {{getRepositories}} service, the algorithm first obtains the available repositories from the local kepler object manager. The algorithm selects the first returned repository and with the {{getRepositories}} service, obtains the relevant resources in the respository. For each resource in the repository, the {{partialSearch}} service is used, which returns the parts of the concept expression that the resource matches (e.g., just the concept {{A}}). The algorithm then moves to the next repository, performing the same steps. However, for those resources already having partial matches (from the previous step), the algorithm reformulates the search term given to {{partialSearch}} to include only the additional required parts of the concept expression (e.g., just the concept {{B}}). Once a complete match is found, the resource is considered a match and is not further checked. Finally, the algorithm repeats the process until all repositories have been examined. |
| Line 68 was replaced by lines 73-109 |
| - query( QueryExpression, RemoteSearchFlag ) :: Set<QueryResult> |
| + query( QueryExpression, RemoteFlag ) :: Set<QueryResult> |
| + }}} |
| + |
| + |
| + |
| + !! {{Compatible}}: Checking Semantically Well-Formed Connections |
| + |
| + {{{ |
| + compatible( ResourceID, Connection, ResourceID, StructTypeFlag, RemoteFlag ) :: Boolean |
| + }}} |
| + |
| + |
| + |
| + !! {{SearchCompatible}}: Searching for Semantically Well-Formed Connections |
| + |
| + {{{ |
| + searchCompatible( ResourceID, Port, StructTypeFlag, RemoteFlag ) :: Set<ResourceID> |
| + }}} |
| + |
| + |
| + !! {{Compose}}: Suggesting Well-Structured Actor Connections |
| + |
| + {{{ |
| + compose( ResourceID, Connection, ResourceID, RemoteFlag ) :: Set<StructMapping> |
| + }}} |
| + |
| + !! {{Merge}}: Suggesting Simple Merging of Heterogeneous Datasets |
| + |
| + {{{ |
| + merge( ResourceID, Connection, ResourceID, RemoteFlag ) :: Set<StructMapping> |
| + }}} |
| + |
| + |
| + !! {{SemanticType}}: Summarizing Semantic Annotations |
| + |
| + {{{ |
| + semanticType( ResourceID, String, RemoteFlag ) :: ConceptExpression |
