Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore how to write query results into a Wikibase #1144

Open
Daniel-Mietchen opened this issue May 31, 2020 · 3 comments
Open

Explore how to write query results into a Wikibase #1144

Daniel-Mietchen opened this issue May 31, 2020 · 3 comments

Comments

@Daniel-Mietchen
Copy link
Collaborator

@Daniel-Mietchen Daniel-Mietchen commented May 31, 2020

This is one of the topics for which I thought we had a ticket already and wanted to re-read it, but I could not find one right now, so opening this one.

The basic idea has several components, e.g.:

  • writing down query (or even subquery) results (from Scholia panels or more generally) can help in various ways, e.g. with caching, addressing performance issues with complex queries/ trees/ popular properties, assisting with evaluating usage (e.g. by property, Scholia panel, or over time)
  • writing them down in a Wikibase allows for annotation (e.g. with timestamp or query ID) and querying
  • exploring this means we would need to think about
    • data models, e.g.
      • do we need that Wikibase to accept CSV, TSV or other WDQS result formats as data types?
      • do we want to model tabular data simply by row and column, with series ordinal, or in some other way?
      • what about non-tabular data - shall we always store it in its native format (perhaps with some screenshot or other representation) or as a table and then re-render?
        • what about media files from Commons that were part of the query results in an image grid?
    • licensing of that Wikibase/ individual results pages
      • CC0 makes the most sense, but this would limit doing things capturing image grids
    • automation, e.g.
      • tooling to edit that Wikibase
        • think QuickStatements or Wikidata Integrator or SPARQL CONSTRUCT queries
    • performance
      • in terms of parameters like
        • lag
        • bandwidth
        • size limits of query results
        • timeout settings of that Wikibase's SPARQL endpoint
        • whether and how to limit the user pool
          • a pragmatic approach here could be to make one of those Scholia-only
    • customization possibilities, e.g.
      • before rendering a Scholia profile, we could run a quick query on that Wikibase that checks whether all the panels relevant for the profile do render, and only shows those that do or that the user had specified (e.g. via URL parameters, as in #1114 )
      • checking for cases where a particular Scholia panel did not render at a given point in time would just be a SPARQL query over that Wikibase
    • privacy issues
      • if the query/ subquery results contain personally identifiable information
    • user contributions to query refinements could be tracked the usual wiki way
@Daniel-Mietchen
Copy link
Collaborator Author

@Daniel-Mietchen Daniel-Mietchen commented May 31, 2020

Found an earlier thread on this in #67 (comment) .

@Daniel-Mietchen
Copy link
Collaborator Author

@Daniel-Mietchen Daniel-Mietchen commented Jun 4, 2020

@Daniel-Mietchen
Copy link
Collaborator Author

@Daniel-Mietchen Daniel-Mietchen commented Jul 20, 2020

Thought a bit more about this, and think we should definitely be exploring SPARQL CONSTRUCT queries. Brief intro here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Robustifying Scholia
  
Awaiting triage
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.