The approach of this work is based on a comparative analysis of several tools used for the management of linked open data. To do this, diferent sections are shown, initially an introduction to the topic is presented, identifying the importance of open data for people, and showing how the results generated through them can benefit. In addition, special emphasis is placed on the need for tools that facilitate both their interaction and manipulation. A section is also shown with related works on this topic, identifying previous studies that evaluated similar tools. The objective is the presentation of a comparative analysis of tools on the study of a proposed data model, which is used to perform tests with five selected tools: 1) API, 2) SPARQL in Wikidata Query Service (WDQS), 3 ) Pywikibot and 4) OpenRefine with the Wikidata plugin. The main task is to identify, for each tool, the evaluation in terms of its ability to integrate and manage Linked Open Data, its ease of use, and its performance in executing specific tasks. Finally, the results obtained in the performance of the analyzed tools are shown, allowing us to know the strengths and weaknesses of each one concerning the proposed data model. On the other hand, the ifndings of the study are presented that suggest recommendations for the selection of the most appropriate tool according to the specific requirements needed in aspects of data integration in a project.
Linked data represents a set of good practices approved by the World Wide Web Consortium [
One of the points worth mentioning as an important focus is that “LOD is often considered as a
virtual data cloud where anyone can access any data they are authorized to see and can also add data
without altering the original data source. This provides an open environment where data can be created,
connected, and consumed at Internet scale” [
The World Wide Web Consortium [
On the other hand, there are diferent linked open data repositories, one of the best known is
Wikidata [
As a last point to comment on, Wikidata has a wide thematic coverage that allows the integration
of multiple data sources, this allows for generating a great benefit between the semantic connections
that could be made and also enriches the interoperability between diferent data sets [
In recent years, various solutions and tools have been developed for the integration of linked open data. These tools have similar and diferent characteristics, for example: the use of APIs, consultation services, and plugins, among others. Although notable progress has been made, challenges remain, including data heterogeneity, quality of integration, and usability of tools. Previous research has explored diferent aspects of these solutions, providing a basis for understanding the current strengths and limitations in this field.
It is worth mentioning that several repositories and projects are important in the LOD context, such
as DBpedia works with the extraction of structured data from Wikipedia and converts it into a set of
Linked Open Data. DBpedia is used for applications that require general information and is one of the
ifrst initiatives in LOD. Although there are several investigations [
Another repository is GeoNames, there are several works [
Another notable repository is LinkedGeoData, which features a project that converts OpenStreetMap
data into LOD, allowing geospatial information to be queried and used alongside other linked data.
Several works indicate that with indicated redesigns it is possible to consult these data sets in English,
German, French, Italian, and Spanish, among others [
Although significant progress has been made in the availability of Linked Open Data, the integration
and management of this data remain considerable challenges. The large amount and diversity of data
available can cause problems such as format incompatibilities, variations in data quality, and dificulties
in synchronizing information between diferent sources [
The objective of this work is to analyze various tools used for the integration of Linked Open Data. The study seeks to evaluate the performance of these tools in diferent aspects, for this, a data model proposed by the authors was designed. Basically, four specific tools that present great potential in aspects of interaction with Wikidata will be analyzed: 1) the Wikidata API; 2) the SPARQL in the Wikidata Query Service (WDQS); 3) Pywikibot; and 4) OpenRefine with its Wikidata plugin. Also, this work will identify the strengths and weaknesses of each tool in terms of its ability to integrate and manage linked data, as well as its ease of use and performance on specific tasks. Through this tool evaluation, the authors provide good practice recommendations for selecting the most appropriate tool, which presents specific data integration requirements in future projects.
To carry out the analysis of the indicated tools, a work methodology is presented that includes the selection of the tools, with the explanation of the most relevant characteristics of each one. On the other hand, the definition of the evaluation metrics that will be considered for this study is presented. Below is a comparison of each of these allowing an analysis of their most relevant functionalities, as well as their limitations.
Wikidata is considered one of the most important sources of structured data on the web. It was developed in order to promote adequate access and manipulation of this type of data. For this technology, the use of APIs that allow interaction with direct queries for this linked data structure stands out. In addition, SPARQL query services are incorporated, such as Wikidata Query Service (WDQS), and automation tools such as Pywikibot. These types of technologies are specialized, such as Wikidata Toolkit (WDTK), because they ofer eficient solutions for the management of large volumes of data, while applications such as OpenRefine, with its Wikidata complement, allow data processing, along with analysis techniques. data cleaning. For the latter, a great advantage is that they can be very accessible to users without programming experience.
This research will analyze four tools that correspond to the context of Wikidata: 1) the Wikidata API; 2) the SPARQL in the Wikidata Query Service; 3) Pywikibot; and 4) OpenRefine with its Wikidata plugin. These have been selected for their relevance and applicability in the integration of Linked Open Data (LOD), in addition to their ease of use and their ability to eficiently handle data manipulation tasks in contexts where large volumes of data are not required. Regarding the selection of the SPARQL API and the query service, they were considered since they are fundamental for the extraction and manipulation of data in Wikidata. On the other hand, Pywikibot was considered because it stands out in the automation of repetitive tasks, and finally OpenRefine, for being a powerful platform in aspects of data cleaning and transformation, thus guaranteeing the quality and consistency of the information linked.
Finally, for this study, it was decided to eliminate Wikidata Toolkit (WDTK) because, although it is a powerful tool for executing complex SPARQL queries and handling large volumes of data, this study focuses on solutions that are targeted to contexts for a data model proposed simple, so the data volume is not that significant. Additionally, WDTK is designed to manage and process large amounts of RDF data, which exceeds the needs of our analysis, which focuses on integrating and manipulating data at a more manageable scale. By opting for tool styles such as the Wikidata API, SPARQL in Wikidata Query Service, Pywikibot, and OpenRefine with its Wikidata plugin, the study seeks to ofer a more practical and common application-oriented perspective on Linked Open Data integration, without the additional complexity that these more advanced tools would handle.
This section indicates a study of some of the most relevant works on the technical aspects of each of the tools used.
Wikidata API: Allows access to Wikidata data through HTTP requests, obtaining data in diferent
formats such as JSON or XML. Wikidata uses the Stories Services API to generate multimedia stories
related to people, organizations, and periodicals [
SPARQL Query: Query service that allows you to access and manipulate data stored in RDF (Resource
Description Framework) format through the use of SPARQL, a query language standardized by the
W3C. Some works present how Wikidata is integrated into the Linked Data Web and how the SPARQL
Query Service facilitates consultation and access to linked data. Other studies show how Wikidata
provides a SPARQL access point, allowing users to perform complex queries on an open data set. This
not only improves Wikidata’s interoperability with other linked datasets on the semantic web, but
also allows researchers and developers to exploit Wikidata information [
Pywikibot: Bots and automation tool for interacting with Wikidata and other Wikimedia projects.
There are research papers that delve into topics such as wiki projects, voluntary contributions, notable
Python contributions, an overview of PAWS (Python Data Science Environment for Jupyter) and
PyWikiBot [
OpenRefine with Wikidata plugin: Data cleansing and reconciliation tool with the ability to link
local data to Wikidata. Data in OpenRefine can be easily transformed into Wikidata declarations by
creating a dedicated export schema that maps each column to respective elements and properties. Some
works show several preparation techniques for processing directly with QuickStatements, allowing
editing and creating Wikidata elements directly from OpenRefine [
As mentioned in other sections, there are many notable features of each of the tools mentioned, these relate to the Wikidata API allowing developers to interact with Wikidata, and providing access to read, write and query data. In addition, it facilitates the management of Wikidata elements, properties and descriptors, integrating tasks such as the creation and modification of elements, data search, and retrieval of structured information in formats such as JSON and XML. On the other hand, SPARQL Query Service presents a service that allows complex queries to be performed on RDF data using the SPARQL language. Additionally, it ofers the ability to search for specific patterns, filter results, and combine information from multiple linked data sources. This service allows the use of data in formats that are compatible with diferent applications and also allows data reading and modification operations, which allows adequate interoperability. Pywikibot works with Python, it was designed to automate interactions with MediaWiki, including Wikidata. It also allows the creation of scripts to perform repetitive tasks, update elements, and manage data, making it easier to maintain Wikidata content. Finally, OpenRefine with Wikidata Plugin is a data cleansing and transformation tool, which can be used with Wikidata data. This plugin facilitates the identification of various objects, adds characteristics to them and updates the data referring to them.
This section presents the evaluation metrics that were considered to analyze and compare the diferent selected tools. Criteria have been selected for an evaluation that includes technical aspects and also its ease of use in aspects of extraction and processing of linked data. In addition, measurements are made in aspects of data access speed, response times, and eficiency in information retrieval. Another important point that is considered is interoperability, which examines the ability of tools to interact and be compatible with other software. The scalability of each tool is also studied, considering the growing volume of data and users who use it. Finally, it is analyzed what support each tool provides in technical aspects in terms of help resources and its activity in the Community of users and programmers.
Figure 1 shows the data model proposed by the authors, it shows the relationship between the diferent objects related to educational and geographical aspects using the ontology and properties of Wikidata. The hierarchical and spatial relationship of universities such as the “Universidad Privada del Valle” and the “UADE” (Argentine Business University) with their respective countries, Bolivia and Argentina, is highlighted, using the country property (P17). Furthermore, the entity of Buenos Aires is represented as the capital of Argentina through capital ownership (P1376) and as an instance of an Argentine city. It also illustrated how Argentina and Bolivia are part of a larger entity, “Latin America,” using the ownership of part of (P361). This model not only connects educational institutions to their administrative and political locations but also places these locations in a broader regional context, thus demonstrating the ability to link data across diferent levels of geographic and thematic granularity.
This proposal, as an example, is a data model that not only allows for a clear and structured understanding of the relationships between diferent educational and geographic entities but also facilitates data interoperability in a broader context. By leveraging the ontologies and properties of Wikidata, a coherent and linked representation of information is achieved, which can be used in various applications, from academic research to the development of geographic information systems (GIS).
With the proposed linked open data model and the tools selected for study analysis, the testing procedure to be carried out will be carried out. That is, the methodology used to evaluate and validate the tools and technologies considered in this study consisted of a series of steps that allow simulating real-use scenarios with the proposed data model, allowing performance to be measured and compared using the metrics previously established in the previous section. Initially, test environments were set up, ensuring that all tools were correctly installed and updated. Data extraction and access tests were then carried out using standard data sets, measuring ease of use and response speed. Execution times were recorded and the tool’s ability to handle output conversions to diferent formats was observed. Subsequently, the interoperability of the tools concerning other software was analyzed, as well as scalability aspects through diferent tests. Finally, studies were obtained on the technical support provided on public websites, which would allow finding solutions to possible problems; some of the sites analyzed were Internet forums.
This section analyzes the main results obtained during the evaluation of the tools studied. This analysis presents the main benefits and limitations of each tool. Below are detailed: a) comparison of tools; and b) comparative analysis.
For the wiki data API, some techniques were used that provided advantages when using it. The Wikidata
REST API [
[Documentation] Clarity and Complexity: The documentation is well structured and clear for experienced users but can be overwhelming for beginners. RDF and JSON-LD are not suficiently explained to users. Examples of use: The examples shown are useful, but they are very simple. Additionally, there is a lack of guidance on query optimization. Finally, the documentation is not located in one place but is spread across multiple sources.
[Ease of use for data extraction] Learning curve: The API is intuitive for programmers dealing with RESTful APIs but is very complex for users without prior experience in Wikidata or RDF. Another point to keep in mind is that there are no graphical interfaces that facilitate its use. Ease of access to complex data: API allows access to complex data. Tool compatibility: It is compatible with data analysis tools such as Python, but its integration is not simple.
[Data access speed] Average Latency: The Wikidata API ofers fast response times for simple queries. Performance under load: API can exhibit poor performance when performing very complex queries. There aren’t many options to optimize the speed of these queries, which can be a problem in applications that require real time access.
[Ease of output conversion] Available Formats: The API allows you to obtain data in JSON, RDF, and XML formats, which provides greater flexibility in the use of diferent applications. Ease of transformation: JSON is one of the most compatible formats with other applications, but converting from RDF may require specialized knowledge, as RDF can be complicated to handle.
[Interoperability] Compatibility with Standards: The API uses standards such as RDF and JSON-LD, making it easy to integrate with other Linked Open Data (LOD) systems. Integration API: Supports other LOD APIs and services, allowing you to combine data from multiple sources for more complete analysis.
[Escalabilidad] Request Limits: The API has limits on the number of requests per second to prevent overloading, which can be an issue in large-scale applications. Scalability management: The API is suitable for small and medium-sized applications. Support for large volumes of data: It can handle large volumes of data, but with performance that decreases under high concurrent demands.
[Support and community] Technical Support Availability: Wikidata has adequate technical support, but the majority of support comes from the user community. Community Resources: There are active forums, mailing lists, and community resources that are valuable for resolving common questions and problems. Documentation Updates: Documentation and resources are not updated regularly, and support can be slow and highly dependent on community participation.
[License and terms of use] License Type: The Wikidata API operates under the Creative Commons CC0 1.0 license, allowing unrestricted use of the data. Use Restrictions: There are no significant restrictions, allowing free redistribution and modification of the data, which is ideal for open projects. Rights and Obligations: Users are required to follow the rules of the CC0 license but are free to use the data in commercial or noncommercial applications without the need for attribution.
A small prototype was developed that is prepared to interact with the proposed data model, in addition, it is designed to interact with Wikidata through its REST API. Defines lists of subject identifiers and relevant predicates (such as universities and countries) for performing RDF queries. Use the requests library to make API requests and rdflib to handle the resulting RDF data. In the Figure 2 shows how an RDF graph is developed and manipulated using Python and the rdflib library. The code begins by importing the necessary libraries (requests, time, and rdflib), which are essential for making HTTP requests and handling RDF data. Below are identifiers (subject_ids) corresponding to specific entities in Wikidata, such as “University” (Q3918), “Universidad Privada del Valle” (Q9091606), “Bolivia” (Q750), “UADE” (Q3028249), “Argentina” (Q414), “Buenos Aires” (Q1486), “City of Argentina” (Q5770918) and “Latin America” (Q12585). These entities represent nodes in the RDF graph that models the relationships between universities and their geographic and political locations. The model shows how the relationships between these entities are structured using Wikidata properties, such as: “Country” (P17), “Part of” (P361), “Capital of” (P1376) and “Instance of” (P31). In this context, the source code allows the creation and use, through a graph, of data connections, access to queries, and analysis of these. This approach is valuable for organizing and linking information about educational entities, and their geographic and political context in a structured and easy-to-use way.
For SPARQL in Wikidata Query Service (WDQS), various techniques were used that ofer specific
advantages depending on their application [
[Documentation] Clarity and Complexity: The SPARQL query service documentation on Wikidata is comprehensive and explains in detail how to use SPARQL to perform complex queries. It includes an introduction to SPARQL, but due to the inherent complexity of this query language, it can be intimidating for novices. Usage Examples: The documentation provides numerous query examples covering a wide range of use cases, which is very helpful in understanding how to structure specicfi queries. Coverage: The documentation covers almost all aspects of using SPARQL, from basic to more advanced queries, including how to optimize queries to improve performance. However, some specific use cases, such as manipulating complex results, are not fully detailed.
[Ease of use for data extraction] Learning Curve: SPARQL is a powerful language but has a steep learning curve. Understanding both SPARQL and the structure of data in Wikidata is necessary to perform efective queries. Ease of access to complex data: WDQS is efective in accessing complex and interrelated data. That is, it allows complex queries that combine multiple entities and properties. Tool Support: SPARQL query results can be exported in various formats (such as JSON, XML, CSV), making it easy to integrate with data analysis and visualization tools. However, building and maintaining complex queries may require additional optimization and visualization tools.
[Data access speed] Average Latency: Response time is fast for simple queries. However, latency can increase significantly with complex queries. Performance under load: WDQS has some performance issues when performing very complex queries. Sometimes the service imposes limits on the queries that can be performed to avoid system overload. Optimization mechanisms: The documentation includes suggestions for optimizing queries, but optimization requires a deep understanding of both SPARQL and the structure of the data in Wikidata.
[Ease of output conversion] Available Formats: Various formats can be used, JSON, CSV, XML among others. This facilitates its use in diferent applications and analyses. Ease of transformation: JSON and CSV are easy to handle and transform, making it easy to integrate into other analysis tools. However, transforming complex SPARQL data queries into simpler structures can be a challenge. Compatibility: The formats are compatible with standard data analysis tools. Handling more complex formats, such as RDF, may require specialized knowledge.
[Interoperability] Standards Compatibility: SPARQL is an accepted standard for queries on RDF data, ensuring its compatibility with other Linked Open Data (LOD) systems and services. Integration API: WDQS can be easily integrated with other services and APIs that support RDF and SPARQL, making it easy to exchange data between diferent platforms. Interoperability Protocols: WDQS supports standard interoperability protocols.
[Scalability] Request Limits: The service has limits on the size and complexity of queries to avoid overloading, which can be a drawback in projects that require complex queries. Scalability management: WDQS is suitable for small and medium-scale queries. Support for large volumes of data: Although it is possible to handle large volumes of data, performance can be significantly afected.
[Support and community] Technical Support Availability: Wikidata provides adequate technical support through its user community, but direct support is limited. Community Resources: There is an active community with forums and mailing lists where users can share solutions and advice, which is very valuable in solving common problems. Documentation Updates: Documentation and community resources are updated periodically.
[License and terms of use] License Type: Data obtained through SPARQL queries in WDQS are subject to the Creative Commons CC0 1.0 license, allowing unrestricted use. Restrictions on Use: There are no significant restrictions, allowing free redistribution and modification of the data. Rights and Obligations: Users are required to follow the rules of the CC0 license but are free to use the data in commercial or noncommercial applications without the need for attribution.
Figure 3 shows the source code shows how to perform a SPARQL query through the SPARQLWrapper library to extract data from Wikidata. The query result is presented as a list of triples, where each triple contains a subject, a predicate, and an object, represented by their identifiers in Wikidata (such as ’Q414’ for Argentina or ’P17’ for "country"). These triples describe relationships between entities in Wikidata, allowing us to understand how they are connected. The code also sets up a custom User-Agent header to avoid being blocked by the Wikidata query service.
Some sources are used as a study to carry out the test with a developed prototype [
[Documentation] Clarity: Pywikibot’s documentation is detailed and well structured, although it can be confusing for beginners due to the number of MediaWiki and Wikidata commands/functions. Complexity: The documentation is primarily intended for experienced developers. It’s not as friendly for users just starting with Python or Wikidata. Coverage: It is broad and covers most of the functions that Pywikibot ofers, from editing pages to manipulating data in Wikidata. However, it can be dificult to find specific documentation on optimizing scripts or handling large volumes of data.
[Ease of use for data extraction] Learning Curve: Learning is complex, especially for those who are not familiar with Python or Wikidata. Access to complex data: Pywikibot allows access to complex data from Wikidata but requires advanced knowledge to create eficient scripts. Compatibility: Pywikibot supports Python and can integrate with other tools. However, it is often necessary to transform the data to adapt it to these tools.
[Data access speed] Latency: The speed of data access may vary depending on the complexity of the operations performed by Pywikibot. For simple tasks, latency is low. Performance: Pywikibot may
Figure 4 shows the development carried out by the authors of this work, which shows the fragment of a small prototype with the Pywikibot library to interact with Wikidata and perform queries that return RDF triples, which are made up of a subject, a predicate and an object. Pywikibot is a collection of Python tools that makes it easy to automate tasks on MediaWiki-based wikis, such as Wikidata. In this code, queries are run to get and display specific relationships between Wikidata entities, represented by their unique identifiers (such as ’Q9091606’ and ’P31’). These relationships are printed to the console, showing the connections between diferent entities in the format of triples. The code is useful for performing automated tasks in Wikidata, such as extracting and analyzing structured data for specific research or applications.
[License and terms of use] License: Pywikibot is available under the MIT license, allowing flexible and free use of the code. Restrictions: There are no significant restrictions on the use of Pywikibot. Developers are free to modify and redistribute the code. Obligations: Users must comply with the terms of the MIT license but are free to use Pywikibot in commercial and noncommercial projects.
To carry out an analysis of OpenRefine with the Wikidata plugin based on the points you mentioned,
some sources were worked with [
[Documentation] Clarity and Complexity: The OpenRefine documentation with the Wikidata plugin is quite accessible and designed for users of diferent experience levels. Tutorials and examples are provided to allow beginners to quickly familiarize themselves with the functionalities. Coverage: The documentation covers a wide range of functionality, from installing the plugin to running SPARQL queries. However, it may lack advanced details for users who wish to perform complex data transformations. Examples of Use: There are practical examples that cover basic cases and some more complex ones, but examples for more specialized scenarios may be lacking.
[Ease of use for data extraction] Learning Curve: OpenRefine is intuitive, especially for users who already have experience in data cleaning and transformation. The Wikidata plugin makes it easy to integrate data without requiring advanced SPARQL knowledge. Ease of Access to Complex Data: Although the use of the tool allows us to simplify data extraction, performing advanced queries is more complex. Tool compatibility: It is compatible with multiple data analysis tools and its integration with Wikidata allows easy access to large volumes of structured data.
[Data access speed] Average Latency: Data access speed is good for simple queries. Performance Under Load: There may be slowdowns when performing multiple complex operations or when working with large volumes of data. Optimization Mechanisms: OpenRefine allows some optimizations to be performed on queries, but most of the performance depends on the complexity of the SPARQL query.
[Ease of output conversion] Available Formats: Extracted data can be exported in various formats, including CSV, Excel, JSON, and others, making it easy to use in various applications. Ease of Transformation: Data transformation is one of the strengths of OpenRefine, allowing personalized adjustments according to the user’s needs. Compatibility: The export formats are widely compatible with other analysis and visualization tools.
[Interoperability] Standards Support: OpenRefine follows open standards and is compatible with a wide range of Linked Open Data (LOD) tools, especially the Wikidata plugin. Integration APIs: Integrates well with open data APIs, making it easy to combine data from multiple sources. Interoperability Protocols: Compatible with standard protocols, allowing its use in environments that require interoperability with other open data systems.
[Scalability] Request Limits: OpenRefine itself does not impose significant limits, but the load on the Wikidata API can be a limiting factor, especially if many requests are made simultaneously. Scalability Management: It is suitable for small and medium-sized projects but may not scale well without careful optimization for large volumes of data. Support for Large Data Volumes: Handles large data sets well, but performance may decrease under very high loads.
Figure 5 shows the OpenRefine interface, with the result of a data connection operation with Wikidata. You see a table with 8 rows, detailing diferent entities such as universities, countries, and cities, along with their properties (for example, "instance of" or "country") and corresponding values in Wikidata. On the left, you can see the filtering and facet options, where entity judgment facets and the best candidate score have been applied.
[Support and community] Technical Support Availability: OpenRefine has an active community, and support for the Wikidata plugin is primarily provided by users and developers in the community. Community Resources: There are a good number of resources, including forums, mailing lists, and guides created by the community. Documentation Updates: Documentation is updated regularly, although it may depend on community participation to stay up to date.
[License and terms of use] License Type: OpenRefine is open source, allowing its use and modiifcation without significant restrictions. The Wikidata plugin is also under a permissive license. Use Restrictions: There are no significant restrictions on its use. Rights and Obligations: Users can use and modify the software under the Open Source license, with the obligation to follow the terms of the corresponding license (generally GPL or similar).
This work presented the analysis of four tools for the use of open data linked through a proposed data model.
The analysis of these tools was based on: a) Wikidata API, b) the SPARQL query service using Wikidata Query Service (WDQS), c) Pywikibot, and d) OpenRefine with its Wikidata plugin. From the Wikidata API point of view, this is an interesting option for integrating simple data queries, as it ofers an easy-to-use RESTful interface for programmers with experience in this type of API. However, you may be limited when performing more complex queries. On the other hand, it was observed that SPARQL, through the Wikidata Query Service, is a very useful tool for performing complex queries on interrelated data in Wikidata. Although its use requires a good knowledge of RDF and the Wikidata data structure, this tool allows you to analyze data with a very good level of precision in its results. The next tool analyzed is Pywikibot, it works with Python that ofers great flexibility to automate tasks in Wikidata. It is ideal for handling large volumes of data. However, its use requires a high level of knowledge in programming and Wikidata structure. Finally, OpenRefine with the Wikidata plugin is presented as a tool that presents great advantages in data cleaning techniques, integrating data sets linked with Wikidata. This tool is especially useful for those looking to improve the quality of their data before incorporating it into deeper analysis. However, its learning curve can be steep.
In terms of documentation and ease of use, all four tools feature extensive documentation, although some stand out more than others. The Wikidata API and SPARQL are well documented, but their level is complex for inexperienced users. Pywikibot, although it presents documentation, requires advanced programming knowledge. OpenRefine, with its graphical interface, is more accessible for data cleaning tasks, but its Wikidata plugin may require additional learning.
The learning curve of these tools is very varied. The Wikidata API is relatively easy to use for those with experience in RESTful APIs, while SPARQL requires in-depth knowledge of its programming syntax, and in dealing with the data structure in Wikidata. On the other hand, Pywikibot features a complex level of programming, and OpenRefine, while generally accessible and friendly, can be complex to use when used in conjunction with the Wikidata plugin for advanced tasks. In terms of performance, the Wikidata API and SPARQL ofer fast responses for simple queries, although they may face limitations on complex queries. Furthermore, Pywikibot has problems in operational performance aspects, since its eficiency depends on the optimization of the source code. OpenRefine is very eficient for data cleaning, but its performance may decrease with large volumes of data.
In terms of interoperability and flexibility, SPARQL and Pywikibot stand out for their high compatibility with other Linked Open Data (LOD) systems and standards. The Wikidata API easily integrates with other tools using RESTful calls, and OpenRefine, through its Wikidata plugin, provides a robust way to link external data with entries in Wikidata. Community support for these tools is robust, facilitating problem-solving and knowledge sharing. However, for users who require quick or specialized technical support, relying exclusively on community support can be a challenge, especially in the case of SPARQL, Pywikibot, and the OpenRefine plugin, where the technical complexity is greater. All tools operate under the Creative Commons CC0 1.0 license, allowing free use of data for academic and commercial projects. However, such a permissive license could raise ethical dilemmas related to data attribution.
As for a quantitative analysis, estimates and measurements were made with the tools worked on. Figure 6 shows a comparative graph of the graph creation times and development times for the diferent tools. For the graph on the left, the graph creation times are shown in milliseconds, where OpenRefine is estimated at an average of 4000 ms, being faster than Pywikibot (4665.79 ms) but slower than SPARQL (632.03 ms). The Wikidata API (6747.69 ms) is also located at an average time, which places it as a slower option, close to OpenRefine, but still slower than SPARQL. For the graph on the right, development times are shown in hours, with OpenRefine estimated at 3 hours and the Wikidata API at 2 hours. Based on the previous analysis, the OpenRefine tool is presented as an intermediate option between the API and SPARQL (7 hours), and the Wikidata API as a more eficient option in aspects of software development, being similar to the time of the standard API. This graph visualizes how the tools compare in terms of performance and software development time, which can help you decide which is the best tool to implement based on the needs at hand.
This analysis presents the importance of selecting an appropriate tool for the management of linked open data, considering the capabilities and limitations of each of these, depending on the objectives and available resources. As another option, it could be considered that the combination of the use of these tools could benefit projects that involve the manipulation and analysis of data in Wikidata. Regarding recommendations, the choice of the appropriate tool should be based on the specific needs of the project and the level of technical experience of the work team that uses them. This study has demonstrated significant diferences in performance and programming development time in terms of the use of the tools. One of the points that was considered was the creation of graphs using linked open data, in which SPARQL is the most eficient tool to create these graphs, although this presents a longer design time. On the other hand, OpenRefine and the Wikidata API ofer an interesting combination in terms of development speed and execution eficiency, making them eficient tools for projects with limited resources. This work shows a detailed comparative analysis, to facilitate decision-making for the best possible tool for the use of linked open data.
As for future lines of research, it would be valuable to work on optimizing development time in SPARQL to make it more accessible to users with less technical experience. In addition, the integration of artificial intelligence could be investigated in order to improve aspects of the quality and treatment of data linked to metadata.