Data Portal @ linkeddatafragments.org

Matches in ScholarlyData for { ?s ?p ?o. }

• authorList hasItem item-1.
• authorList hasItem item-2.
• authorList hasItem item-3.
• authorList hasItem item-4.
• authorList hasItem item-5.
• authorList hasItem item-6.
• authorList hasLastItem item-6.
• item-1 type ListItem.
• item-1 hasContent maribel-acosta.
• item-1 next item-2.
• item-2 type ListItem.
• item-2 hasContent amrapali-zaveri.
• item-2 next item-3.
• item-2 previous item-1.
• item-3 type ListItem.
• item-3 hasContent elena-simperl.
• item-3 next item-4.
• item-3 previous item-2.
• item-4 type ListItem.
• item-4 hasContent dimitris-kontokostas.
• item-4 next item-5.
• item-4 previous item-3.
• item-5 type ListItem.
• item-5 hasContent soeren-auer.
• item-5 next item-6.
• item-5 previous item-4.
• item-6 type ListItem.
• item-6 hasContent jens-lehmann.
• item-6 previous item-5.
• paper-18 type InProceedings.
• paper-18 label "SPARQL Web-Querying Infrastructure: Ready for Action?".
• paper-18 sameAs paper-18.
• paper-18 abstract "Hundreds of public SPARQL endpoints have been deployed on the Web, forming a novel decentralised infrastructure for querying billions of structured facts from a variety of sources on a plethora of topics. But is this infrastructure mature enough to support applications? For 427 public SPARQL endpoints registered on the DataHub, we conduct various experiments to test their maturity. Regarding discoverability, we nd that only one-third of endpoints make descriptive meta-data available, making it dicult to locate or learn about their content and capabilities. Regarding interoperability, we nd patchy support for established SPARQL features like ORDER BY as well as (understandably) for new SPARQL 1.1 features. Regarding eciency, we show that the performance of endpoints for generic queries can vary by up to 34 orders of magnitude. Regarding availability, based on a 27-month long monitoring experiment, we show that only 32.2% of public endpoints can be expected to have (monthly) two-nines uptimes of 99100%.".
• paper-18 hasAuthorList authorList.
• paper-18 isPartOf proceedings-2.
• paper-18 title "SPARQL Web-Querying Infrastructure: Ready for Action?".
• authorList type List.
• authorList hasFirstItem item-1.
• authorList hasItem item-1.
• authorList hasItem item-2.
• authorList hasItem item-3.
• authorList hasItem item-4.
• authorList hasLastItem item-4.
• item-1 type ListItem.
• item-1 hasContent carlos-buil-aranda.
• item-1 next item-2.
• item-2 type ListItem.
• item-2 hasContent aidan-hogan.
• item-2 next item-3.
• item-2 previous item-1.
• item-3 type ListItem.
• item-3 hasContent juergen-umbrich.
• item-3 next item-4.
• item-3 previous item-2.
• item-4 type ListItem.
• item-4 hasContent pierre-yves-vandenbussche.
• item-4 previous item-3.
• paper-19 type InProceedings.
• paper-19 label "String Similarity Metrics for Ontology Alignment".
• paper-19 sameAs paper-19.
• paper-19 abstract "Ontology alignment is an important part of enabling the semantic web to reach its full potential. The vast ma jority of ontology alignment systems use one or more string similarity metrics, but often the choice of which metrics to use is not given much attention. In this work we evaluate a wide range of such metrics, along with string pre-processing strategies such as removing stop words and considering synonyms, on different types of ontologies. We also present a set of guidelines on when to use which metric. We furthermore show that if optimal string similarity metrics are chosen, those alone can produce alignments that are competitive with the state of the art in ontology alignment systems. Finally, we examine the improvements possible to an existing ontology alignment system using an automated string metric selection strategy based upon the characteristics of the ontologies to be aligned.".
• paper-19 hasAuthorList authorList.
• paper-19 isPartOf proceedings-2.
• paper-19 title "String Similarity Metrics for Ontology Alignment".
• authorList type List.
• authorList hasFirstItem item-1.
• authorList hasItem item-1.
• authorList hasItem item-2.
• authorList hasLastItem item-2.
• item-1 type ListItem.
• item-1 hasContent michelle-cheatham.
• item-1 next item-2.
• item-2 type ListItem.
• item-2 hasContent pascal-hitzler.
• item-2 previous item-1.
• paper-20 type InProceedings.
• paper-20 label "NoSQL Databases for RDF: An Empirical Evaluation".
• paper-20 sameAs paper-20.
• paper-20 abstract "Processing large volumes of RDF data requires sophisticated tools. In recent years, much effort was spent on optimizing native RDF stores and on repurposing relational query engines for large-scale RDF processing. Concurrently, a number of new data management systems— regrouped under the NoSQL (for “not only SQL”) umbrella—rapidly rose to prominence and represent today a popular alternative to classical databases. Though NoSQL systems are increasingly used to manage RDF data, it is still difficult to grasp their key advantages and drawbacks in this context. This work is, to the best of our knowledge, the first systematic attempt at characterizing and comparing NoSQL stores for RDF processing. In the following, we describe four different NoSQL stores and compare their key characteristics when running standard RDF benchmarks on a popular cloud infrastructure using both single-machine and distributed deployments.".
• paper-20 hasAuthorList authorList.
• paper-20 isPartOf proceedings-2.
• paper-20 title "NoSQL Databases for RDF: An Empirical Evaluation".
• authorList type List.
• authorList hasFirstItem item-1.
• authorList hasItem item-1.
• authorList hasItem item-10.
• authorList hasItem item-2.
• authorList hasItem item-3.
• authorList hasItem item-4.
• authorList hasItem item-5.
• authorList hasItem item-6.
• authorList hasItem item-7.
• authorList hasItem item-8.
• authorList hasItem item-9.
• authorList hasLastItem item-9.
• item-1 type ListItem.
• item-1 hasContent philippe-cudre-mauroux.
• item-1 next item-10.
• item-10 type ListItem.
• item-10 hasContent marcin-wylot.

• first
• previous
• next