Coder Social home page Coder Social logo

Comments (10)

guenthermi avatar guenthermi commented on June 27, 2024

I have written a class to configure the connection to the WikibaseApi and send queries. Another class should contain methods for the use cases. So I started to implement a mehtod which read out the datatype from the property-id. The API response something like "time" for P569 or "wikibase-item" for P553. Should that be converted in one of the constants from the DatatypeIdValue interface?

from wikidata-toolkit.

mkroetzsch avatar mkroetzsch commented on June 27, 2024

Very good. Yes, the strings from the JSON should be represented by the corresponding datatype contents in our code.

Btw, I have also written some basic Web access components for the dump file downloading. These might be handy later on, especially for testing, since there are mock implementations of the interface. So you don't need to focus on the code that fetches string data from the web.

from wikidata-toolkit.

eldur avatar eldur commented on June 27, 2024

... Maybe interesting for you ;-)

from wikidata-toolkit.

mkroetzsch avatar mkroetzsch commented on June 27, 2024

This is very interesting indeed. Should we make use of (parts of) jwbf in out code? Or the other way around (e.g., we already have the Wikidata data model and we will implement the Wikidata JSON serialization)? Our goal is to publish such features as independent Maven modules, so one could pull in parts without pulling in everything. However, I don't know jwbf and its architecture enough to say what could work here.

from wikidata-toolkit.

eldur avatar eldur commented on June 27, 2024

I'll offer the same points from the referenced issue - if you interested in.

JWBF is only a minimal service layer. You'll get, in your case, shortcuts for login, token handling, encoding and a few simple utils like a APIRequestBuilder (and the offered changes for API integration tests / not wikidata specific)

from wikidata-toolkit.

fer-rum avatar fer-rum commented on June 27, 2024

Via mailing list since this might interest others too:

I did a quick review of the JWBF as it was proposed to be used with
wikidata as well.

Code quality and style is pretty high, everything looks clean and
straight forward. The documentation is very sparse, but it seems to be
worked on.

Depending on how much the MediaWiki API and the Wikidata API differ
from each other it would take some coding effort to get the bots
running with the WDTK. As it looks in the github repository the
developers already tried to play around with this [0].

So I propose the following:

  • Including Wikidata access into the JWBF would be fine
  • let the JWBF-team handle the inclusion in their code, instead of
    including the JWBF into the WDTK
  • establish communication between the projects and keep both sides
    up-to date about recent developments

Reaching the first milestone of the WDTK would be a good time for a
first handshake between the projects.

Sincerly,
Fredo Erxleben

[0]
eldur/jwbf@74970a3

Zitat von Markus Krötzsch [email protected]:

This is very interesting indeed. Should we make use of (parts of)
jwbf in out code? Or the other way around (e.g., we already have the
Wikidata data model and we will implement the Wikidata JSON
serialization)? Our goal is to publish such features as independent
Maven modules, so one could pull in parts without pulling in
everything. However, I don't know jwbf and its architecture enough
to say what could work here.


Reply to this email directly or view it on GitHub:
#11 (comment)

from wikidata-toolkit.

eldur avatar eldur commented on June 27, 2024

I tried to get the full rundtrip:

  • read a wikibase_item info from wikipedia
  • get the claim from wikidata by the given wikibase_item

but how can I map the json response to a org.wikidata.wdtk.datamodel.interfaces.Claim?

eldur/jwbf@698b478

from wikidata-toolkit.

eldur avatar eldur commented on June 27, 2024

Hi fer-rum, thanks for your comment ... now I get a JsonException at
eldur/jwbf@82acd0d

from wikidata-toolkit.

mkroetzsch avatar mkroetzsch commented on June 27, 2024

Pull request #123 introduces basic capabilities for fetching entity data via the API. It is not currently planned to add write access (JWBF would be much better suited to support the related aspects), but the code might be useful as an example on how to parse JSON data (which works well by now).

from wikidata-toolkit.

mkroetzsch avatar mkroetzsch commented on June 27, 2024

Closed by merging #123.

from wikidata-toolkit.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.