36
U
Property:Has Results
This is a property of type Text.
Pages using the property "Has Results"
Showing 25 pages using this property.
A | |
|---|---|
| A Probabilistic-Logical Framework for Ontology Matching + | Using stability constraints improves alignment quality with both learned and manually set weights. + |
| A Semantic Web Middleware for Virtual Data Integration on the Web + | Because ARQ is using a pipelining concept the response time is very good, even when data has to be retrieved from a remote data source. + |
| A Survey of Current Link Discovery Frameworks + | No data available now. + |
| ANAPSID: An Adaptive Query Processing Engine for SPARQL Endpoints + | We observe that SHJ and ANAPSID operators are able to produce the first tuple faster than ARQ or Hash join, even in an ideal scenario with no delays; further, ARQ performance is clearly aff_ected by data transfer distribution and its execution time can be almost two orders of magnitude greater than the time of SHJ or ANAPSID. We notice that SHJ and ANAPSID are competitive, this is because the number of intermediate results is very small, and the benefits of the RJTs cannot be exploited. This suggests that the performance of ANAPSID operators depends on the selectivity of the join operator and the data transfer delays. + |
| Accessing and Documenting Relational Databases through OWL Ontologies + | No data available now. + |
| Adaptive Integration of Distributed Semantic Web Data + | No data available now. + |
| AgreementMaker: Efficient Matching for Large Real-World Schemas and Ontologies + | Experiments have shown that our quality measure is usually effective in defining weights for the LWC matcher. + |
| Analysing Scholarly Communication Metadata of Computer Science Events + | No data available now. + |
| Avalanche: Putting the Spirit of the Web back into Semantic Web Querying + | Avalanche is able to successfully execute query plans and retrieves many up-to-date results without having any prior knowledge of the data distribution. We, furthermore, see that different objective functions have a significant influence on the outcome and should play a critical role when deployed on the Semantic Web. + |
B | |
| Bringing Relational Databases into the Semantic Web: A Survey + | No data available now. + |
C | |
| Cross: an OWL wrapper for teasoning on relational databases + | No data available now. + |
D | |
| D2RQ – Treating Non-RDF Databases as Virtual RDF Graphs + | No data available now. + |
| DataMaster – a Plug-in for Importing Schemas and Data from Relational Databases into Protégé + | No data available now. + |
| Discovering and Maintaining Links on the Web of Data + | No data available now. + |
F | |
| FedX: Optimization Techniques for Federated Query Processing on Linked Data + | With our optimization techniques, we are able to reduce the number of requests significantly, e.g., from 170,579 (DARQ) and 93,248 (AliBaba) to just 23 (FedX) for query CD3. + |
| From Relational Data to RDFS Models + | No data available now. + |
I | |
| Integration of Scholarly Communication Metadata using Knowledge Graphs + | No data available now. + |
K | |
| KnoFuss: A Comprehensive Architecture for Knowledge Fusion + | - + |
L | |
| LIMES - A Time-Efficient Approach for Large-Scale Link Discovery on the Web of Data + | LIMES outperforms SILK in all experimental settings. It is important to notice that the difference in performance grows with the (product of the) size of the source and target knowledge bases. + |
| LogMap: Logic-based and Scalable Ontology Matching + | No data available now. + |
O | |
| Optimizing SPARQL Queries over Disparate RDF Data Sources through Distributed Semi-joins + | No data available now. + |
Q | |
| Querying Distributed RDF Data Sources with SPARQL + | The experiments show that our optimizations significantly improve query evaluation performance. For query Q1 the execution times of optimized and unoptimized execution are almost the same. This is due to the fact that the query plans for both cases are the same and bind joins of all sub-queries in order of appearance is exact the right strategy. For queries Q2 and Q4 the unoptimized queries took longer than 10 min to answer and timed out, whereas the execution time of the optimized queries is quiet reasonable. The optimized execution of Q1 and Q2 takes almost the same time because Q2 is rewritten into Q1. + |
| Querying over Federated SPARQL Endpoints : A State of the Art Survey + | {{{Results}}} + |
| Querying the Web of Data with Graph Theory-based Techniques + | We divide evaluation results of GDS, FedX and DARQ into three categories. First is query performance related metrics. Limited by space, we only provide QPS in this paper7. Second is system loads including CPU usage and memory usage. Third is network overhead including uploading data and downloading data. Here we especially compare GDS with FedX, because DARQ fails providing correct results or is time out on many queries. + |
| Querying the Web of Interlinked Datasets using VOID Descriptions + | - + |
