Just curious: do you know where the code is hosted? I don't really need the tool, just wondering if I can be able to fix it.

I'm not sure if I'm having the same problem. My script is using Wikibase Integrator and was working a few weeks ago. This is my error message:

ping @Chicocvenancio

Not sure if this is the way to ping the Toolforge admins.

@TBurmeister still interested? Check the board and reach me for any question here or at any other medium.

We validated a very cheap server can be procured with second hand enterprise hardware and refurbished and very selected enterprise quality hard drives, using ZFS, the data preservation first file system in Linux.

Project results:

We couldn't find the time to start the exploration of how to model a body of knowledge for GLAM.

As reported at https://phabricator.wikimedia.org/T391815#11305743, we have a first full implementation of CIDOC-CRM 7.1.3 for Wikibase: https://gitlab.wikimedia.org/olea/crm4wb

Now working here https://github.com/olea/wikibase-release-pipeline/tree/deploy%405.0.1-olea

Has been impossible to find time or collaborators to try this. Maybe in the future we could try it again.

In T391815#11297487, @Olea wrote:

For the record:

In T391815#11140879, @Olea wrote:

For the record: this is the draft proposal for WikidataCon.

For the record, seems the full workflow works and ttl2wb.py is able to upload the bootstrap set into a clean WB (example). You can try it by yourself if you wish.

For the record, new repo with importer scripts: https://gitlab.wikimedia.org/olea/wikibase-bootstrap

The new draft:

In T391815#11209394, @DL2204 wrote:

In this last table, I see two issues:

For the record, here is where wbstack implements the feature «Import base entities» from Wikidata into a new wb.c instance: https://github.com/wbstack/ui/blob/main/src/backend/api.js#L101

I suppose the one question I have is what is the intent of this Turtle file?

I'm creating a first draft of the OWL spec for the bootstrap set:

I strongly suggest to include the local entity id into the recommendation. The main reason is practical. The OpenRefine Reconciliation Service for Wikibase, particularly it's docker image, expects P1 and P2 as rdf:type and rdfs:subClassOf. It can be interpreted as an arbitrary implementation decision but, my reasoning:

In T396468#11173879, @Olea wrote:

This means the bulk importer feature is abandoned? Just asking.

This means the bulk importer feature is abandoned? Just asking.

I'm not familiar with VUE applications but, after a small Internet checking, seems the approximation to i18n'd (internationalize) the code is using Vue I18n.

@Addshore let me a question, how could be implemented this set for the WikibaseManifest?

For the record: this is the draft proposal for WikidataCon.

@adee_wmde could you please list the reviewed tools?

@adee_wmde: About the ID generation, could be possible to keep ID's exported from a legacy WB instance when importing into a new one? I feel this can be helpful, at least with properties.

For the record; WikidataCon CFP ends 1st of September.

Happy to say the most of the OS dependencies for multimedia Mediawiki extensions would be soon included in WBS Deploy (see).

! In T396559#10903879, @Deepesha_WMDE wrote:
The same links will be available, just how they are presented will change.

Do you mean the information Mediawiki offers in a fresh WBS installation? Because I like it.

Just for the record: this task is a work in progress.

@DL2204: added schema:isPartOf and «formatter URI for RDF».

We want kartographer too: T297062.

Open question: should we add a «formatter URI for RDF» property? This is the practice @DL2204 suggests (example).

In T356626#10204102, @Ivan_Hernandez_Cazorla wrote:

About themes, have you any requirement?

The recommended revisions look like an interesting information source, example: Recommended revisions/1.43.

Related pull-request: https://github.com/wmde/wikibase-release-pipeline/pull/867

Perhaps we need a centeralized tool to enable other tools to easily interact with other Wikibases that are not all connected via the same auth system?

Companion software:

• Tool:InteGraality, a tool generating dashboards of property coverage for a given part of Wikidata.
• Listeria, generates lists on Wikipedias, based on Wikidata queries. <- do we really need this in Wikibase?
• WikibaseMigrator/Beam-me-up Tool, a tool to migrate wikibase entities from one wikibase instance to another.

@Superraptor123 what do you think?

Related tasks:

• T391815 Wikibase Request for Comment: essential minimalist ontology
• T391821 Wikibase Request for Comment: an inventory of Wikibase related artifacts
• T391826 Wikibase Request for Comment: Wikibase Suite full multimedia proof of concept configuration
• T391828 Wikibase Request for Comment: a method for portable wikibase gadgets

@daniel thanks!

Consider these standards:

@Superraptor123 would this mapping be correct?

@TuukkaH would you dare to format the proposal in a SSSOM tsv file?

So, we didn't could set up a «multimedia pilot» but now we have at the said google spreadsheet a more detailed list of related extensions and we found Wikibase Suite is including so many available but not activated. Now have a more clear escenario to the next step.

The last revision in table format:

Relevant maintenance tasks made by bots in Wikidata:

Relevant templates existing in Wikidata

@Superraptor123 what name should we use for these selection? WB bootstrap property set? Something better?

Citing Deepesha Burse:

I can't attend to the event but wanted to share this tool https://github.com/dlindem/zotwb a friend maintains and uses to import bibliography from Zotero to a Wikibase instance, like this case: https://tinyurl.com/22alvzsh

@Superraptor123 nothing to be sorry :)

In T294892#10780090, @Addshore wrote:

(but perhaps somehting we could also look at at the hackathon)

Related: T234943, bootstrap Wikibase installation with basic ontology.

In T294892#10779938, @Addshore wrote:

In T391815#10767805, @TuukkaH wrote:

One thing to keep in mind wrt. the property IDs: I think there's been a nice convention to make your P1 mean "sameAs on Wikidata" (or "Wikidata mapping")

1 - A way of modeling that data on wikibase.world via properties

For the record: https://phabricator.wikimedia.org/T294892#10779801.

For the record: https://phabricator.wikimedia.org/T294892#10779801.

In T294892#10779801, @Addshore wrote:

In T360206#10779344, @Addshore wrote:

Thanks for the comment @Olea, and some additional thoughts from me here...

Just want to point out at least two other features approaches established from the Wikidata experience:

• gadgets, some of then adds a lot of productivity for the day to day work

The flexibility that gadgets allow for wiki users to make their own custom scripts to hack the software is great, and it's agreat proving ground for functionality.
Some examples on wikidata would be the labels lister that allows actually seeing all lables on an item or property (which the UI doesnt / didnt out of the box), and allows editing them all, or the merge gadget, that actually exposes a way to merge items from the item page itself.
Really though, once proven, IMO there things should not live on as gadgets, they should be included within the software for every to take advantage of in a consistent and expected way supported by a wikibase team.

In T294892#10779177, @Addshore wrote:

In T294892#7501886, @JeanFred wrote:

@Addshore From a product perspective, would it make sense to ship integraality with wikibase / make it easy to add it to the setup (probably along the lines of a Docker image to add to the docker-compose setup) − is that smth that would be beneficial to users?

@Superraptor123, uff, it's a lot of stuff to fully understand :-|

@lojo_wmde thanks for your interest.