Topic on Talk:Structured Data Across Wikimedia/Flow

This thread will address two themes about the general expectations about the project and the way it will impact on users' workflows:

1. What do users expect from this project? What are the necessary actions to be addressed?
2. How do you envision this metadata being used? Can you think of ways it would aid in your workflows?

See above, the project doesn't trigger me. I can imagine support with wikilinks. On wd one gets suggestions for properties, qualifiers, values etc which is very helpful. So than I would like on wp a suggestion for e.g. birthdate and reference...From the example I do not get where you want to go. Perhaps I would like more examples. We need more data on wd and editing there could even be easier

I don’t know what I expect from this project. The description feels pretty vague to me – I don’t really have an idea what kind of metadata or structured data could be collected. The first action area, tagging sections, makes some sense, but I don’t think anything is stopping interested Wikipedias from implementing something fairly similar today, using RDFa:

== Oldest living organisms ==
<p about="wd:Q590039">
Bristlecone pines are known for attaining great ages. The oldest bristlecone pine in the White Mountains is <span property="schema:name">[[Methuselah]]</span>, which has a verified age of 4,852 years. It is located in the <span property="schema:location">[[Inyo National Forest]]</span> in Eastern California. The specific location of Methuselah is a very closely guarded secret.
</p>

(Based on Bristlecone pine, Wikipedia contributors, CC BY-SA 3.0.)

AIUI initially the metadata will simply be a list of topics associated with a section, the idea being that it's a step on the road to being able to search for and serve smaller pieces of content than a whole article

Interested wikipedias can do what you describe, indeed, but it's pretty awkward

Hi, I'm interested about the result of the work will be stored. Would it be in a separate database on a project' server, or directly somewhere in wikis?

Perhaps it may be interesting to serve the results linked in wikidata objects. Looking at the mockup image, we can imagine properties (bold items with icons) and values (q items). Thanks!

We're planning to store the topical metadata in a "slot" on the page - similar to how we store structured data for images on commons. Ultimately it'll also be injected into elasticsearch, but we haven't figured out the details of that yet

Obviously I am wanting Wikisource reproductions to be better findable, both internally and externally. Better and more easily usable.

I am hoping that the project will be able to tell me what is possible for my wishes for an integrated ability to interact and inject pertinent detail crosswki. in the easiest, most reliable, and referenced form.

...

Ultimately I am also hoping for better input/workflow tools to make things easier and better, and to stop having to add the same data at multiple places.

• Creating a commons file
• Creating the wikisource components, transcluding, then creating the WD item for the edition, then needing to create the work item for the parent
• Then having to update the Commons file to link back to the WD item
• then edit the WD item to add the IA details
• Then I head over to Wikipedia to then find the right template to re-add the data parameter by parameter, when I should either be able to just add a contextual template or use a lookup form or a template add the WD item, and just be able to have the data inhaled and added.

(all the around and around and around)

At the moment I use the WEF framework tool though while it is pretty good, it doesn't completely suit needs at creating/editing items from enWS. I would love to be able to have a customisable tool to create/edit WD from the sister wikis rather than having to go to WD and manually edit the item. Similarly FROM something like s:en:A catalogue of notable Middle Templars, with brief biographical notices/Bayley, Sir Edward Clive I want to be able to directly apply to the related main subject's item (not its own item) the data able to be pushed in and referenced.

No idea exactly how much of that is in scope, but that is what I hope we can think about, or poke somewhere as a way to interlink and overlay data between the sisters.  :-)

Wow, my first thoughts are:

1. the Wikidata vision is coming true! Structured knowledge to serve as the backbone of the Wikimedia landscape;
2. sounds like a more fine-grained https://schema.org/ for the Wikimedia ecosystem.

Besides automatic enrichment of Wikipedia infoboxes, I fully support the categorization of page sections: one clear expectation or outcome is to see rich snippets of Wikipedia articles when I run a search, ideally regardless of the engine I use.

I'm not sure how the project would cater for the Abstract Wikipedia, though, so I'd like to hear more on this.

I see that @Lucas Werkmeister actually explains how the page sections effort could also be implemented following the schema.org fashion with RDFa markup.

Unlike most files on Commons or the concepts described by Wikidata items, Wikipedia articles evolve with time and, depending on the implementation, metadata could fall out of sync with the sections. I’m sure there are ways to address this, for example by automatically identifying heavily edited sections.

How do we query the Structured Data on Wikimedia Commons?

Are there plans to provide something similar to the WDQS on Wikidata, or does the structured data eventualy also filter through to Wikidata? (if my understanding that this is actually separate datastores is correct)

BTW, I find the idea of structured data on Commons very exciting, and plan on adding more support and integration for the ICONCLASS classification system. Similar to what is already done for Wikidata.

Hello @Eposthumus, there is a plan for a separate query service for Structured Data on Commons. The plan will be announced soon™, as we the team is still reviewing some aspects. I'll be sure to ping you personally when the announcement will go live.

Personally speaking, I share your excitement and your expectations, but it seems we'll need to wait a bit longer. :)