Tpt added a comment.
+1 to @Tacsipacsi. It's probably the best way to go. Would someone have time
to do it? Help would very much welcomed
TASK DETAIL
https://phabricator.wikimedia.org/T352603
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Tpt added a comment.
I have written an implementation draft:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/793867
It follows @Ltrlg approach (thank you!) with a slight tweak to avoid having
to guess the item kind (work vs edition).
The code looks first
Tpt updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T289760
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: Jerven, AndySeaborne, BenAtOlive, Justin0x2004, Izno, Gehel, Thadguidry,
Tpt, So9q, Aklapper, Invadibot
Tpt added a comment.
@Thadguidry @BenAtOlive It's a great idea to move the conversation somewhere
else. Oxigraph has a discussion space
<https://github.com/oxigraph/oxigraph/discussions> and a Gitter channel
<https://gitter.im/oxigraph/community>.
TASK DE
Tpt added a comment.
@BenAtOlive If I understand correctly, you are asking if Oxigraph can be used
to build a distributed SPARQL database with reader nodes and writer nodes? Its
definitely possible to reuse Oxigraph components for that. For example I am
currently moving the SPARQL parser
Tpt added a comment.
It's a great idea! I just believe P2860
<https://phabricator.wikimedia.org/P2860> (cites work) should be removed from
the list. It's definitely not a classifying property.
TASK DETAIL
https://phabricator.wikimedia.org/T295275
EMAIL PREFERENCES
Tpt added a comment.
@Thadguidry Great! Thank you!
@So9q Sadly it's not possible with Sled. But Sled and Oxigraph should both
work fairly well with multiple parallel thread so updating data while serving
query should work ok. I have started to run some benchmarks around it. I still
Tpt added a comment.
@Thadguidry Hi! It's a great idea to improve the roadmap. Thank you for
pushing me to do that! I have updated the GitHub issues and milestones
<https://github.com/oxigraph/oxigraph/milestones?direction=desc=completeness=open>
and added a link to them in the
Tpt added a comment.
Thank you @So9q for opening this task!
Some comments:
- Oxigraph is dual licensed under Apache2 or MIT, not under GPLv2.
- Oxigraph plans to drop the RocksDB backend in the next release and focus on
Sled. It will make the development easier.
Some other
Tpt added a comment.
> As far as I’m aware, the real URL in RDF is more like
http://commons.wikimedia.org/wiki/Special:FilePath/Leon%20Cogniet%20-%20Jean-Francois%20Champollion.jpg
– the query service UI rewrites it to the file description URL (/wiki/File:)
on display.
> I also
Tpt updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T258776
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: Librarian_lena, Lucas_Werkmeister_WMDE, Jheald, Aklapper, Tpt, CBogen,
Akuckartz, darthmon_wmde, Nandana
Tpt updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T258776
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: Librarian_lena, Lucas_Werkmeister_WMDE, Jheald, Aklapper, Tpt, CBogen,
Akuckartz, darthmon_wmde, Nandana
Tpt added a comment.
Sorry for this problem.
What is exactly the error that your parser is returning?
"PT111.89260770975S" seems valid to me according to the grammar provided by
the XML schema specification <https://www.w3.org/TR/xmlschema11-2/#duration>.
It's ma
Tpt created this task.
Tpt added projects: Wikidata, Wikidata-Query-Service, StructuredDataOnCommons.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
Currently, there is no easy way to fetch the Structured Data on Commons
(SDOC) M-ID for e.g. the value of the "
Tpt added subscribers: DVrandecic, Tpt.
Tpt added a comment.
I guess that Wikidata concept URIs are using http:// because it is what is
usually done by RDF datasets (DBpedia...), mostly for backward compatibility
reasons.
I would be slightly in favor of using http:// URI for Commons
Tpt added a comment.
@Lucas_Werkmeister_WMDE @Addshore Thank you very much for having handled this
error and sorry for having introduced it. You are amazing!
TASK DETAIL
https://phabricator.wikimedia.org/T258184
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Tpt closed this task as "Resolved".
Tpt claimed this task.
TASK DETAIL
https://phabricator.wikimedia.org/T256570
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: Michael, Aklapper, Tpt, Akuckartz, Iflorez, darthmon_wmde, alaa_wmde
Tpt created this task.
Tpt added projects: Wikidata, MediaWiki-extensions-WikibaseClient.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
Wikibase have now a hook named `WikibaseClientSiteLinksForItem` that have
been introduced to solve T128173 <ht
Tpt added a comment.
In T128173#6214099 <https://phabricator.wikimedia.org/T128173#6214099>,
@Addshore wrote:
> Does that mean we should resolve this task? Or is the "other editions" bit
also within this task? :)
I believe the "other editions" bit
Tpt added a comment.
Since yesterday, if a Wikisource page is connected to a Wikidata item that
states that it is an edition of the work using P629
<https://www.wikidata.org/wiki/Property:P629>, the sitelinks of the work item
are displayed on the page in the "In other languag
Tpt closed subtask T239546: Adds a hook to Wikibase allowing to add new
sitelink easily from Wikibase content as Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T128173
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: Addshore, Uzume
Tpt closed this task as "Resolved".
Tpt claimed this task.
Tpt added a comment.
The changes have been merged last week
TASK DETAIL
https://phabricator.wikimedia.org/T239546
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: Akl
Tpt added a comment.
I have made an attempt to have one hook for sitelinks and other project
sidebar here:
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/ProofreadPage/+/574224/
A review would be welcome!
TASK DETAIL
https://phabricator.wikimedia.org/T239546
EMAIL
Tpt closed this task as "Resolved".
Tpt claimed this task.
Tpt added a comment.
Deployed on all Wikisources \o/.
Example in enwikisource:
https://en.wikisource.org/wiki/The_Wind_in_the_Willows_(1913)
TASK DETAIL
https://phabricator.wikimedia.org/T180303
EMAIL PREFERENC
Tpt created this task.
Tpt added projects: Wikidata, Wikisource.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
To implement T128173 <https://phabricator.wikimedia.org/T128173> properly,
the Wikisource extension needs to give to the Wikibase extensions new sit
Tpt added a comment.
I believe I'm the closest of what we could call a "maintainer" of the current
version. Marco made a project to rewrite the tool, the backend seems to be more
or less finished but the frontend as not moved much.
TASK DETAIL
https://phabricator.wikimedia.o
Tpt added a comment.
> @Tpt I can't remember if we ever added the magicword for overwriting and/or
removing it on a specific page.
No, we have not created one yet at my knowledge.
TASK DETAIL
https://phabricator.wikimedia.org/T219392
EMAIL PREFERENCES
ht
Tpt added a comment.
@Lydia_Pintscher Improving JSON-LD structure like I proposed requires a
strong refactoring of Purtle. I would not commit to do it anytime soon and I
believe no one else would. So, I don't think it's a good idea to block JSON-LD
deployment for that.
TASK DETAIL
https
Tpt created this task.
Tpt added projects: Shape Expressions, Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
It would be nice to be able to get entity schemas in scribunto modules to be
able to build templates (e.g. infoboxes) based on them.
Having an API
Tpt added a comment.
Option B seems the most usable to me and the most consistent. Prefixes like
"c-wd" has the disadvantage of still having "wikidata" in it, and it's imho
quite confusing.
TASK DETAIL
https://phabricator.wikimedia.org/T222995
EMAIL
Tpt added a comment.
@alaa_wmde Thanks! It's fine for me
TASK DETAIL
https://phabricator.wikimedia.org/T216842
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: alaa_wmde, Tpt, Ladsgroup, gerritbot, Lydia_Pintscher, daniel, Denny
Tpt added a comment.
The deployment have been done.
There is a small bug that may affect some modules: calls
`mw.wikibase.entity:formatStatements().value` using Lua may need to be passed
to frame:preprocess to be properly display the table. I have already
fixed Module:Databox
Tpt closed this task as "Resolved".
Tpt added a comment.
Done
TASK DETAIL
https://phabricator.wikimedia.org/T217442
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: gerritbot, hoo, Aklapper, Lydia_Pintscher, Tpt, alaa_wmde
Tpt closed subtask T217442: Deploy maplink for geocoordinate statements on
production as Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T210926
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: Lea_Lacroix_WMDE, Lydia_Pintscher
Tpt added a comment.
@Lydia_Pintscher Great! I have schedule a SWAT for this evening.
TASK DETAIL
https://phabricator.wikimedia.org/T217442
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: gerritbot, hoo, Aklapper, Lydia_Pintscher, Tpt
Tpt added a comment.
@Lydia_Pintscher I have created a change that enables on production
servers. Is it fine for you if I ask for scheduling the deployment of this
change during a SWAT window next week? Do you prefer to enable it on labs wiki
first?
TASK DETAIL
https
Tpt renamed this task from "Deploy mapframe for geocoordinate statements on
production" to "Deploy maplink for geocoordinate statements on production".
TASK DETAIL
https://phabricator.wikimedia.org/T217442
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/pa
Tpt updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T217442
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tpt
Cc: hoo, Aklapper, Lydia_Pintscher, Tpt, Nandana, Lahi, Gq86,
GoranSMilovanovic, QZanden, LawExplorer
Tpt created this task.
Tpt added projects: MediaWiki-extensions-WikibaseClient, Wikidata.
TASK DESCRIPTION
The configuration variable useKartographerMaplinkInWikitext should be enabled
on production server to roll out T210926
<https://phabricator.wikimedia.org/T210926>.
TASK DETAIL
Tpt added a comment.
I have just made an attempt to map what I understood of MediaInfo data model
to RDF:
https://www.mediawiki.org/wiki/User:Tpt/WikibaseMediaInfo_RDF_Dump_Format
TASK DETAIL
https://phabricator.wikimedia.org/T215341
EMAIL PREFERENCES
https://phabricator.wikimedia.org
Tpt added a project: Wikidata-Query-Service.Restricted Application added a project: Wikidata.
TASK DETAILhttps://phabricator.wikimedia.org/T216271EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Aklapper, Tpt, Nandana, Lahi, Gq86, Lucas_Werkmeister_WMDE
Tpt added a comment.
The feature is behind a configuration variable disabled by default. This change uses instead of so the output is still a textual display of the coordinates, but now with a link that opens a Kartographer map. So, nothing should break except if some modules parses the output
Tpt added a comment.
Nice!
We should maybe use https://schema.org/caption instead of https://schema.org/name that is more expressive and introduce a distinction between items and media info just like we did for LexemesTASK DETAILhttps://phabricator.wikimedia.org/T215341EMAIL PREFERENCEShttps
Tpt updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...It is required if weone want to provide a SPARQL query service for these entitiesTASK DETAILhttps://phabricator.wikimedia.org/T215341EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Tpt created this task.Tpt added projects: WikibaseMediaInfo, StructuredDataOnCommons, Wikidata-Query-Service.Restricted Application added a subscriber: Aklapper.Restricted Application added a project: Wikidata.
TASK DESCRIPTIONIt would be nice if MediaInfo entities had a RDF representation
Tpt added a subscriber: Lydia_Pintscher.Tpt added a comment.
@Lydia_Pintscher Do you think we could close this task? All basic features seems done and deployed on wdqs.TASK DETAILhttps://phabricator.wikimedia.org/T160259EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Tpt updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...{F28001743}
The same problem seemsTASK DETAILhttps://phabricator.wikimedia.org/T214465EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Aklapper, Tpt, Nandana, Lahi, Gq86
Tpt created this task.Tpt added projects: Wikidata, MediaWiki-extensions-WikibaseView.Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTIONWith Firefox 64 and the Adwaita Dark GTK+ skin the term box editing fields are white text on white background (see screenshot).
This is caused
Tpt merged a task: T180304: Uses P629 (edition of) to improve language links between Wikisources.
TASK DETAILhttps://phabricator.wikimedia.org/T128173EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Tpt, PokestarFan, Hsarrazin, srishakatux, Bodhisattwa
Tpt closed this task as a duplicate of T128173: Represent editions as interwiki links on Wikisource.Restricted Application removed a subscriber: Liuxinyu970226.
TASK DETAILhttps://phabricator.wikimedia.org/T180304EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Tpt reopened subtask T128173: Represent editions as interwiki links on Wikisource as "Open".
TASK DETAILhttps://phabricator.wikimedia.org/T109579EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: PokestarFan, Superchilum, Micru, intracer,
Tpt reopened this task as "Open".Tpt added a comment.
I should close the other task, sorryTASK DETAILhttps://phabricator.wikimedia.org/T128173EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Tpt, PokestarFan, Hsarrazin, srishakatux, B
Tpt added subscribers: Micru, PokestarFan, srishakatux, Bodhisattwa, Billinghurst, MF-Warburg, Purodha, Ankry, Gymel, StudiesWorld.Tpt merged a task: T128173: Represent editions as interwiki links on Wikisource.
TASK DETAILhttps://phabricator.wikimedia.org/T180304EMAIL PREFERENCEShttps
Tpt closed this task as a duplicate of T180304: Uses P629 (edition of) to improve language links between Wikisources.Restricted Application removed a subscriber: Liuxinyu970226.
TASK DETAILhttps://phabricator.wikimedia.org/T128173EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Tpt created this task.Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTIONIt is probably not something we want possible on CommonsTASK DETAILhttps://phabricator.wikimedia.org/T213485EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc
Tpt added a project: StructuredDataOnCommons.
TASK DETAILhttps://phabricator.wikimedia.org/T149410EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: matthiasmullie, Aklapper, Ladsgroup, aude, Lydia_Pintscher, thiemowmde, daniel, hoo, Nandana, JKSTNK, Lahi
Tpt added a comment.
@Lydia_Pintscher Maybe review https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/408365 and try to push the security review of the Wikisource extension to get it deployed on beta then production cluster.TASK DETAILhttps://phabricator.wikimedia.org/T180303EMAIL
Tpt added a comment.
For this task to be done, the extension should be deployed on Wikisource: T210174TASK DETAILhttps://phabricator.wikimedia.org/T180303EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Samwilson, Candalua, gerritbot, hoo, Hsarrazin
Tpt added a comment.
I just had a quick review of the current GraphQL structure for Wikibase entities. It looks great! Thank you!
I would switch the Entity type to an interface and have Item, Property, Lexeme... implementations
type, datatype and snaktype fields values should probably
Tpt added a comment.
So you're not really asking for a change in the JSON-LD, you're asking for wikidata to only emit a single entity on the /entity/* endpoint -- and that would/could apply to all the different representations using the purtle backend. That's not a JSON-LD specific request
Tpt added a comment.
@daniel We could do something similar for stubs. with structures like:
{
"property": {
"@id": "wd:Q64",
"label": { "@value": "Foo", "@language": "en"}
...
}
instead of
{
"
Tpt added a comment.
Not a problem but a cosmetic proposal: Instead of having the structure:
{
"@graph": [
{
"@id": "wdata:Q64",
"@type": "schema:Dataset",
"about": "wd:Q64&q
Tpt added a project: Wikisource.
TASK DETAILhttps://phabricator.wikimedia.org/T207142EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Amire80, Aklapper, Nandana, JKSTNK, Lahi, PDrouin-WMF, Gq86, E1presidente, Ramsey-WMF, Cparle, Anooprao, SandraF_WMF
Tpt added a comment.
It seems to me that the only thing missing in the implementation compared to https://www.mediawiki.org/wiki/Extension:WikibaseLexeme/RDF_mapping is the addition of schema:inLanguage for Lexemes. But it is derived data so it should not block the deployment
Tpt closed this task as "Resolved".Tpt claimed this task.Tpt added a comment.
YesTASK DETAILhttps://phabricator.wikimedia.org/T200901EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Smalyshev, gerritbot, Lydia_Pintscher, Tpt, Mringgaard
Tpt closed subtask T200901: [Task] Implement RDF serialization for senses as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T160259EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Smalyshev, Lucas_Werkmeister_WMDE, Aklapper,
Tpt added a comment.
Thank you @Pintoch for raising this idea. For my fixing constraints violations project, I can mine violations from history offline so I do not really need this feature.
About the vandalism detection (and maybe diffs) use case, what we could do and seems quite reasonable to me
Tpt added a comment.
@Jonas Thank you for your feedback.
is it necessary for your tool to run the constraint checks in parallel?
No, I am going to switch to a sequential processing. Thanks for the idea!
Using WDQS instead would be a good idea, because then only your tool would get throttled
Tpt added a comment.
Sorry everyone for the troubles. I was experimenting with a tool that tries to find corrections for constraint violations.
I have modified it to send a proper User-Agent for all its requests to the Wikidata API but not restarted it.
@Wikidata team: what would be an ok request
Tpt added a comment.
I would wait for addition of proper statement serialization that is tracked by T195043.TASK DETAILhttps://phabricator.wikimedia.org/T200901EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: gerritbot, Lydia_Pintscher, Tpt, Mringgaard
Tpt added a comment.
With that.. I think it would be best if we moved your code to a new "graphql" repo, host the GraphQL server on a Cloud VPS, and then rewrite it in _javascript_ (node.js) so it's as fast as it can be. If it gets enough usage we can talk about moving it onto productio
Tpt added a comment.
In T173214#4511651, @dbarratt wrote:
In T173214#4457079, @Tpt wrote:
For statement filtering by qualifier a good solution is maybe to add an extra parameter "hasStatement" to the statements field and give to it a value of type SnakInput (a GraphQL input type
Tpt added a comment.
@dbarratt Thank you for planning to work on Wikibase+GraphQL.
The performance problem we face seems very standard, I believe it is the N+1 problem.
The standard way to solve it is to use the DataLoader utility. The original Facebook implementation is here: https://github.com
Tpt added a comment.
Also, I understand it's still disabled on both wikidata and test.wikidata.
It seems to be enabled now : https://www.wikidata.org/entity/L42.ntTASK DETAILhttps://phabricator.wikimedia.org/T195043EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Tpt added a comment.
There is still one feature missing: outputting statements on form and senses when the RDF representation of a lexeme is required (e.g. on Special:EntityData/L12.nt).TASK DETAILhttps://phabricator.wikimedia.org/T195043EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings
Tpt added a comment.
Is https://gerrit.wikimedia.org/r/449718 covering this?
Yes, I put the wrong task id in the commit message.TASK DETAILhttps://phabricator.wikimedia.org/T200901EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: gerritbot
Tpt added a parent task: T160259: [Story] RDF for Lexemes, Forms and Senses.
TASK DETAILhttps://phabricator.wikimedia.org/T200901EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Tpt, Mringgaard, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer
Tpt added a subtask: T200901: [Task] Implement RDF serialization for senses.
TASK DETAILhttps://phabricator.wikimedia.org/T160259EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Smalyshev, Lucas_Werkmeister_WMDE, Aklapper, Ladsgroup, Mringgaard, Lahi
Tpt created this task.Tpt added projects: Wikidata, Lexicographical data.
TASK DESCRIPTIONRDF serialization of senses should be implemented as specified in https://www.mediawiki.org/wiki/Extension:WikibaseLexeme/RDF_mapping#SenseTASK DETAILhttps://phabricator.wikimedia.org/T200901EMAIL
Tpt added a comment.
Indeed the set of property and their datatypes is very static and cachable so we could use them as keys of a StatementByProperty object and then have StringStatement, StringSnak... types. The object would just be huge and maybe raise some performance problems of the various
Tpt added a comment.
Thank you!
Is there any reason this can't be used where it is for now? (I mean ideally it would be in production somewhere).
It could definitely be used now but without any stability guaranties. The GraphQL query resolution is a bit heavy because it makes a lot of requests
Tpt added a comment.
@Tpt so it looks like right now you can't get a datavalue or recursively call item from a statement. I added a sample query to the task description.
It's actually possible:
Example with the string data type: https://tools.wmflabs.org/tptools/wdql.html?query=%7B%0A%20
Tpt added a comment.
There is still to implement output of forms statements when the RDF representation of a lexeme is requested (i.e. Special:EntityData/L42.ttl) and the schema:inLanguage relation for lexemes.TASK DETAILhttps://phabricator.wikimedia.org/T195043EMAIL PREFERENCEShttps
Tpt added a comment.
I have updated the draft of RDF implementation change: https://gerrit.wikimedia.org/r/c/433953
It uses the existing namespace for Lexemes specific terms but provides a new ontology file which URI is http://wikiba.se/lexeme/ontology# (but it could be easily changed)TASK
Tpt added a comment.
Not sure if you are proposing prefix as http://wikiba.se/lexeme/ontology/ or as http://wikiba.se/lexeme/ontology#.
Sorry, I was also thinking of http://wikiba.se/lexeme/ontology# but forgot the #.
Well, since wikiba.se site is not related to any specific Wikidata install
Tpt added a comment.
The full list of terms we have to define is:
Classes:
wikibase:Lexeme
wikibase:Form
wikibase:Sense
These 3 classes are direct mapping of the entity types so they should not cause name clash with other Wikibase extensions.
Properties:
wikibase:lexicalCategory
Tpt added a project: Wikidata-Query-Service.Tpt added a comment.Herald added a project: Discovery.
why not just http://wikiba.se/ontology# ?
If we do that it raises multiple concerns:
It does not solve the name clash problem you mentioned earlier if two extensions want to create the same class
Tpt created this task.Tpt added projects: Wikidata, Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added a project: Discovery.
TASK DESCRIPTIONNow that the Wikibase ontology is stable we should drop the "-beta" component inside of the URIs. The vocabulary prefix shoul
Tpt added a comment.
Ok for the file. For the canonical namespace URI should we use something like "http://wikiba.se/ontology-lexeme#" to have something similar to "http://wikiba.se/ontology-beta#"? Or maybe "http://wikiba.se/lexeme/ontology#"? Should we also use
Tpt added a subscriber: daniel.Tpt added a comment.
@daniel Do you think that the ontology terms specific to lexemes should live in the same namespace and ontology definition file as the other Wikibase terms or should we create a new namespace?TASK DETAILhttps://phabricator.wikimedia.org
Tpt created this task.Tpt added a project: MediaWiki-extensions-WikibaseClient.Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONIf Kartographer is available Wikibase Client should use the tag to do globe coordinates rendering if the globe is earth.TASK
Tpt created this task.Tpt added a project: Lexicographical data.Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONCalls to Special:EntityData are failing when called with form id. See e.g. https://wikidata-lexeme.wmflabs.org/index.php/Special:EntityData/L15-F1
Tpt added a comment.
I have made some prototypes here:
GlobeCoordinate: https://test2.wikipedia.org/wiki/Module:GlobeCoordinate
Time: https://test2.wikipedia.org/wiki/Module:Time
TASK DETAILhttps://phabricator.wikimedia.org/T195070EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Tpt created this task.Tpt added projects: DataValues, Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONManipulating Wikidata complex values (GlobeCoordinates, Times, Quantities...) in Lua modules is painful. It would be nice to provide a good Lua library making easy to parse
Tpt added a subtask: T195043: [Task] Implement RDF serialization for lexemes.
TASK DETAILhttps://phabricator.wikimedia.org/T160259EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Lucas_Werkmeister_WMDE, Aklapper, Ladsgroup, Lahi, Gq86, GoranSMilovanovic
Tpt renamed this task from "[Task] Implement RDF serialization for lexemes" to "[Task] Implement RDF serialization for lexemes and forms".
TASK DETAILhttps://phabricator.wikimedia.org/T195043EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
Tpt added a parent task: T160259: [Story] RDF for Lexemes, Forms and Senses.
TASK DETAILhttps://phabricator.wikimedia.org/T195043EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TptCc: Aklapper, Tpt, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer
Tpt created this task.Tpt added a project: Lexicographical data.Herald added a subscriber: Aklapper.Herald added a project: Wikidata.
TASK DESCRIPTIONRDF serialization should be implemented in WikibaseLexeme in LexemeRdfBuilderTASK DETAILhttps://phabricator.wikimedia.org/T195043EMAIL
Tpt added a comment.
I have started a draft of mapping of the Lexeme DataModel to RDF: https://www.mediawiki.org/wiki/Extension:WikibaseLexeme/RDF_mapping
I have left some comments for different possible mappings of each element of the data model. I have focused on matching when relevant
Tpt added a comment.
I have made a change for the Wikisource extension (the CI is currently broken because the dependency on Wikibase is not setup yet). Having this feature there has two advantages:
Do not require a configuration parameter to enable/disable this feature. We probably want it only
1 - 100 of 135 matches
Mail list logo
