|
Difference between
version 16
and
version 15:
| Line 22 was replaced by line 22 |
| - We note that in the simplest form as stated above, the {{search}} operation requires access to all annotations to determine matching resources. |
| + We note that in general, the {{search}} operation requires access to all semantic annotations to determine matching resources (e.g., in the case of search expressions containing conjunctive formulas). As the number of semantic annotations increases, this operation could become expensive. |
| Line 24 was replaced by line 24 |
| - We can remove this implementation requirement with the following additional aggregation services: |
| + We can reduce the cost by indexing semantic annotations for search. In particular, we can define an index of the form: {{ontoSearchIndex ( ResourceID, ResourceType, SemanticType )}} that can in particular, provide the functions: |
| Line 27 was replaced by lines 27-35 |
| - ... what are these ... ? |
| + AnnotationEngine: ConceptExpression getSemanticType( OntoSearchIndex, ResourceID ) |
| + AnnotationEngine: Set<ResourceID> getResourceIDs( OntoSearchIndex ) |
| + AnnotationEngine: ResourceType getResourceType( OntoSearchIndex, ResourceID ) |
| + |
| + ... |
| + This needs some work: what we want to do is, e.g., ask S1 it's resources (e.g., R1, R2, and R3) and then "ship" the expressions (C1 and C2)/R1, (C1 and C2)/R2, and (C1 and C2)/R3 only to S1, which would return R1/match, R2/C1, R3/C2, and then we would want to do something similar with S2: ask it what resources it has, then ship (C1 and C2)/RX to S2 except if X=2 or X=3, in which case we would ship (R2/C2) and (R3/C1), and so on |
| + ... |
| + Need to define what ops these require |
| + ... |
| At line 28 added 2 lines. |
| + |
| + Here a semantic type is a concept expression generated from a semantic annotation. Providing and index over a resource's |
Back to SMS Service Interfaces,
or to the Page History.
|
