35
U
Property:Has future work
This is a property of type Text.
Pages using the property "Has future work"
Showing 10 pages using this property.
R | |
|---|---|
| Relational.OWL - A Data and Schema Representation Format Based on OWL + | A further extension for Relational.OWL could be a corresponding protocol extending the possibilities of Relational.OWL to particularly support data exchanges or replications. There we could employ the advantages of our knowledge representation technique for recurring problems occurring within such a data exchange process, e.g. identifying the same data items on remote databases. Although autonomously communicating databases in a metadata exchange are still more vision than reality, our model takes us one step further. + |
S | |
| SERIMI – Resource Description Similarity, RDF Instance Matching and Interlinking + | As future work, we intend to investigate how our model can be adjusted to consider partial string matching in the similarity function that we proposed, and to accommodate different score distribution metrics as the threshold for the parameter Also, we intend to evaluate this approach in different collections that may provide a more accurate reference alignment than the ones that we used in this work. + |
| SLINT: A Schema-Independent Linked Data Interlinking System + | Although SLINT has good result on tested datasets, it is not sufficient to evaluate the scalability of our system, which we consider as the current limiting point because of the used of weighted co-occurrence matrix. We will investigate about a solution for this issue in our next work. Besides, we also interested in automatic configuration for every threshold used in SLINT and improving SLINT into a novel cross-domain interlinking system. + |
| SPLENDID: SPARQL Endpoint Federation Exploiting VOID Descriptions + | As next steps, we plan to investigate whether VOID descriptions can easily be extended with more detailed statistics in order to allow for more accurate cardinality estimates and, thus, better query execution plans. On the other hand, the actual query execution has not yet been optimized in SPLENDID. Therefore, we plan to integrate optimization techniques as used in FedX. Moreover, the adoption of the SPARQL 1.1 federation extension will also allow for more efficient query execution. + |
T | |
| Towards a Knowledge Graph Representing Research Findings by Semantifying Survey Articles + | Integrating our methodology with the procedure of publishing survey articles can help to create a paradigm shift. We plan to further extend the ontology to cover other research methodologies and fields. For a more robust implementation of the proposed approach, we are planning to use and significantly expand the OpenResearch.org platform and a user-friendly SPARQL auto-generation services for accessing metadata analysis for non-expert users. More comprehensive evaluation of the services will be done after the implementation of the curation, exploration and discovery services. In addition, our intention is to develop and foster a living community around OpenResearch.org and SemSur, to extend the ontology and to ingest metadata to cover other research fields. + |
| Towards a Knowledge Graph for Science + | The work presented here delineates our initial steps towards a knowledge graph for science. By testing existing and developing new components, we have so far focused on some core technical aspects of the infrastructure. Naturally, there are a number of research problems and implementation issues as well as a range of socio-technical aspects that need to be addressed in order to realize the vision. Dimensions of open challenges are, among others: • the low-threshold integration of researchers through methods of crowd-sourcing, human-machine interaction, and social networks; • automated analysis, quality assessment, and completion of the knowledge graph as well as interlinking with external sources; • support for representing fuzzy information, scientific discourse and the evolution of knowledge; • development of new methods of exploration, retrieval, and visualization of knowledge graph information. + |
U | |
| Unveiling the hidden bride: deep annotation for mapping and migrating legacy data to the Semantic Web + | For the future, there is a long list of open issues concerning deep annotation—from the more mundane, though important, ones (top) to far-reaching ones (bottom): (1) Granularity: So far we have only considered atomic database fields. For instance, one may find a string “Proceedings of the Eleventh International World Wide Web Conference, WWW2002, Honolulu, Hawaii, USA, 7–11 May 2002.” as the title of a book whereas one might rather be interested in separating this field into title, location, and date. (2) Automatic derivation of server-side Web page markup: A content management system like Zope could provide the means for automatically deriving server-side Web page markup for deep annotation. Thus, the database provider could be freed from any workload, while allowing for participation in the Semantic Web. Some steps in this direction are currently being pursued in the KAON CMS, which is based on Zope. (3) Other information structures: For now, we have built our deep annotation process on SQL and relational databases. Future schemes could exploit Xquery or an ontology-based query language. (4) Interlinkage: In the future deep annotations may even link to each other, creating a dynamic interconnected Semantic Web that allows translation between different servers. (5) Opening the possibility to directly query the database, certainly creates problems such as new possibilities for denial of service attacks. In fact, queries, e.g. ones that involve too many joins over large tables, may prove hazardous. Nevertheless, we see this rather as a challenge to be solved by clever schemes for CPU processing time (with the possibility that queries are not answered because the time allotted for one query to one user is up) than for a complete “no go.” We believe that these options make deep annotation a rather intriguing scheme on which a considerable part of the Semantic Web might be built. + |
| Updating Relational Data via SPARQL/Update + | Future work is planned for various aspects of OntoAccess. Further research needs to be done on bridging the conceptual gap between RDBs and the Semantic Web. Ontology- based write access to the relational data creates completely new challenges on this topic with respect to read-only approaches. The presence of schema constraints in the database can lead to the rejection of update requests that would otherwise be accepted by a native triple store. A feedback protocol that provides semantically rich information about the cause of a rejection and possible directions for improvement plays a major role in bridging the gap. Other database constraints such as assertions have to be evaluated as well to see if they can reasonably be supported in the mapping. Also, a more formal definition of the mapping language will be provided. Furthermore, we will extend our prototype implementation to support the SPARQL/Update MODIFY operation, SPARQL queries, and the just mentioned feedback protocol. + |
| Use of OWL and SWRL for Semantic Relational Database Translation + | Currently, URIs returned by SBRD are unique but generally not resolvable. We intend to address this issue in future versions by generating resolvable URIs and incorporating the best practices of the Linking Open Data initiative. To the best of our knowledge, we believe that our rules and their usage are consistent with the design goals of the DL Safe SWRL Rules task force4. Decidability is a critical aspect of our architecture and is therefore focused on features such as the use of Horn rules with unary and binary predicates. We will continue to monitor the task force’s progress and incorporate necessary modifications. The advantages of SWRL built-ins have also proven essential. It is our hope that they are addressed in the DL Safe task force and will be comparable to the built-ins provided by SWRL. + |
Z | |
| Zhishi.links Results for OAEI 2011 + | We look forwards to build an instance matching system with better performance and higher stability in the future. + |
Facts about "Has future work"
| Has type "Has type" is a predefined property that describes the datatype of a property and is provided by Semantic MediaWiki. | Text + |
