Apologies for cross-posting
Dear all,
We are proud to announce DBpedia Archivo (https://archivo.dbpedia.org)
an augmented ontology archive and interface to implement FAIRer
ontologies. Each ontology is rated with 4 stars measuring basic FAIR
features. We discovered 890 ontologies reaching on average 1.95 out of 4
stars. Many of them have no or unclear licenses and have issues w.r.t.
retrieval and parsing.
# Community action on individual ontologies
We would like to call on all ontology maintainers and consumers to help
us increase the average star rating of the web of ontologies by fixing
and improving its ontologies. You can easily check an ontology at
https://archivo.dbpedia.org/info. If you are an ontology maintainer just
release a patched version - archivo will automatically pick it up 8
hours later. If you are a user of an ontology and want your consumed
data to become FAIRer, please inform the ontology maintainer about the
issues found with Archivo.
The star rating is very basic and only requires fixing small things.
However, theimpact on technical and legal usability can be immense.
# Community action on all ontologies (quality, FAIRness, conformity)
Archivo is extensible and allows contributions to give consumers a
central place to encode their requirements. We envision fostering
adherence to standards and strengthening incentives for publishers to
build a better (FAIRer) web of ontologies.
1.
SHACL (https://www.w3.org/TR/shacl/, co-edited by DBpedia’s CTO D.
Kontokostas) enables easy testing of ontologies. Archivo offers free
SHACL continuous integration testing for ontologies. Anyone can
implement their SHACL tests and add them to the SHACL library on
Github. We believe that there are many synergies, i.e. SHACL tests
for your ontology are helpful for others as well.
2.
We are looking for ontology experts to join DBpedia and discuss
further validation (e.g. stars) to increase FAIRness and quality of
ontologies. We are forming a steering committee and also a PC for
the upcoming Vocarnival at SEMANTiCS 2021. Please message
hellmann(a)informatik.uni-leipzig.de
<mailto:hellmann@informatik.uni-leipzig.de>if you would like to
join. We would like to extend the Archivo platform with relevant
visualisations, tests, editing aides, mapping management tools and
quality checks.
# How does Archivo work?
Each week Archivo runs several discovery algorithms to scan for new
ontologies. Once discovered Archivo checks them every 8 hours. When
changes are detected, Archivo downloads and rates and archives the
latest snapshot persistently on the DBpedia Databus.
# Archivo's mission
Archivo's mission is to improve FAIRness (findability, accessibility,
interoperability, and reusability) of all available ontologies on the
Semantic Web. Archivo is not a guideline, it is fully automated,
machine-readable and enforces interoperability with its star rating.
- Ontology developers can implement against Archivo until they reach
more stars. The stars and tests are designed to guarantee the
interoperability and fitness of the ontology.
- Ontology users can better find, access and re-use ontologies.
Snapshots are persisted in case the original is not reachable anymore
adding a layer of reliability to the decentral web of ontologies.
Let’s all join together to make the web of ontologies more reliable and
stable,
Johannes Frey, Denis Streitmatter, Fabian Götz, Sebastian Hellmann and
Natanael Arndt
Paper: https://svn.aksw.org/papers/2020/semantics_archivo/public.pdf
Dear all,
I am trying to understand the performance impact of adding new
ResourceLoader modules. I am currently stuck in the code review of
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/638094
as I am not convinced that it is a good idea to bundle an OOUI widget
module and a special page js snippet into one module. One thing is a
general-purpose control that is planned to be used in other contexts
whereas the other is a very specific js code only executed on one
particular special page. However, since this seems to be the critical
point in the code review, I would like to better understand the impact
of the additional resource module call.
I was looking at
https://www.mediawiki.org/wiki/File:ResourceLoader_Client_lifecycle_2020.png
and according to that overview, an additional module is just one entry
in the module registry. I was hoping that minifying and caching is
something the ResourceLoader would take care of.
Any help would be appreciated.
Thank you
physikerwelt
This is the weekly TechCom board review. If there are additional topics for
TechCom to review, please let us know by replying to this email. However,
please keep discussion about individual RFCs to the Phabricator tickets.
This week, the meeting is async, so we'll be replying to the email as
well, *feel
free to join in*!
Activity since Wednesday 2020-11-25 on the following boards:
https://phabricator.wikimedia.org/tag/techcom/https://phabricator.wikimedia.org/tag/techcom-rfc/
Committee inbox:
- Automatically index extensions in Codesearch
<https://phabricator.wikimedia.org/T268328> is still in the inbox, no
activity since last week's discussion
- Create WikiTeq group on Gerrit
<https://phabricator.wikimedia.org/T267213> is now more clear (see note
from Daniel <https://phabricator.wikimedia.org/T267213#6653536> to
discuss, which we should do here)
Committee board activity:
- General ParserCache service class for large "current" page-derived data
<https://phabricator.wikimedia.org/T227776> was declined by Daniel, see
his reasoning there
New RFCs: (none)
Phase progression: (none)
IRC meeting request: (none)
Other RFC activity:
- RFC: Re-evaluate librsvg as SVG renderer for WMF wikis
<https://phabricator.wikimedia.org/T40010:> saw more conversation
- RFC: Discourage use of MySQL's ENUM type
<https://phabricator.wikimedia.org/T119173> Amir points out the need to
overhaul all db documentation (I agree, could we have a doc sprint about
this?) including policies
- RFC: Amendment to the Stable interface policy, November 2020
<https://phabricator.wikimedia.org/T268326> has a suggestion/question
about clarifying default status and deprecation procedure
- RFC: Store WikibaseQualityConstraint check data in persistent storage
<https://phabricator.wikimedia.org/T214362> WMDE calls for help from
TechCom and the Platform team to collaborate here. See Adam Shorland's
comment about putting it through the new Technical Decision Making Process
- RFC: Expand API title generator to support other generated data
<https://phabricator.wikimedia.org/T263841> Carly Bogen is asking for
clarity on the need for a steward. Timo's comment
<https://phabricator.wikimedia.org/T263841#6617970> on the task indeed
seem to contradict his note from last week's grooming email. Timo, would
you please clarify.
https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-12-02
== Callouts ==
Pinging Parsoid client teams (Editing, Language, Platform Infrastructure,
Growth) onhttps://phabricator.wikimedia.org/T266143 again. Where necessary,
this week, we will start submiting patches against your codebases. In that
case, we would appreciate prompt reviews and followups as necessary.
* …
No updates: TechCom, Anti-Harassment Tools , Growth, Product
Infrastructure, Language, OKAPI, Analytics, Machine Learning Platform,
Research, Security, WMDE, Wikidata, German Technical Wish List
== Product ==
=== Community Tech ===
* Blocked by:
* Blocking:
* Updates:
* We are still reviewing wishlist proposals. We have until December 7th
before the voting phase starts
* Watchlist Expiry has been enabled in all production wikis since last
night (https://meta.wikimedia.org/wiki/Community_Tech/Watchlist_Expiry)
=== Editing ===
* Blocked by:
* Blocking:
* Updates:
[ reply ] link deployed by default to three wikis (cs, ar, hu) and beta
feature on ~250 other Wikipedias. Received support on en.wiki during an
RfC; next step is an A/B test on ~30 medium-larges wikis. Can also be
enabled globally via user script (ask us how if interested).
=== iOS native app ===
* Blocked by:
* Blocking:
* Updates:
** Released 6.7.3 into the App Store last week. Turning on Article as a
Living Document experiment (in 6.7.3) today.
** In exploratory stage for 6.8
https://phabricator.wikimedia.org/project/view/4862/
*** Chinese variant fixes
*** Initial push notifications
*** Article inspection mode experiment
=== Android native app ===
* Blocked by:
* Blocking:
* Updates:
** Latest release rolled out to public 2 days ago.
** Working on designs for bringing watchlist into the app.
=== Web ===
* Blocked by:
** RelEng?: Members of Readers Web aren't contributors to the
@wikimedia/wvui package on NPM
*** No task as of yet
*** james f will help
* Blocking:
* Updates:
** Continuing to work on WVUI integration with Vector
*** https://phabricator.wikimedia.org/T264355
*** https://phabricator.wikimedia.org/T268363
*** https://phabricator.wikimedia.org/T257698
** IE11 support for WVUI: https://phabricator.wikimedia.org/T268703
*** Thanks to James F for the note about the es6-promise polyfill
** https://phabricator.wikimedia.org/T252774 – mediawiki.toc.styles RL
module merged into ResourceLoaderSkinModule
=== Structured Data ===
* Blocked by: -
* Blocking: -
* Updates:
** Team offsite this week
=== Abstract Wikipedia ===
* Updates:
** Continuing work on using ZType data to enforce structure when editing
ZObjects.
** Excited to welcome Genoveva (Geno) Galarza Heredero, our new software
engineer, to the team.
=== Parsing ===
* Blocked by:
** Pinging Parsoid client teams (Editing, Language, Platform
Infrastructure, Growth) on https://phabricator.wikimedia.org/T266143 again.
Where necessary, this week, we will start submiting patches against your
codebases. In that case, we would appreciate prompt reviews and followups
as necessary.
* Blocking:
* Updates:
=== Inuka ===
* Blocked by:
* Blocking:
* Updates:
** More bug fixes and UX improvements to the KaiOS app
=== Library ===
* Blocked by:
* Blocking:
* Updates:
** A bug that denied eligible users access to the Wikipedia Library Card
Bundle is now fixed
** Working on making Wikilinks more stable is still in progress
== Technology ==
=== Cloud Services ===
* Blocked by:
* Blocking:
** releng train-dev blocked waiting for nested VM support
([[phab:T267433]]) <!--https://phabricator.wikimedia.org/T267443 -->
* Updates:
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** The deluge of donations is here! Yesterday was our second-best day ever,
and that was without sending any emails out (just banners).
** Lots of discussion on best way forward for dockerized dev environment -
discussion of multipurpose image vs app-specific images ongoing at
https://phabricator.wikimedia.org/T268685 . Advice welcome from long-term
docker users!
** Fixing little bugs as they crop up in the logs
** Updating text for different specialized thank you emails
** Tweaking timing of CiviCRM queue consumers so we can keep up with the
generosity of our donors and send them timely acknowledgement.
** Trying to reduce log spam on main CRM box
=== Platform ===
* Blocked by:
* Blocking:
* Updates:
** Bug fixes for the API portal
** Parsoid cache in MediaWiki
** Sockpuppet API productionising
** Shellbox for MediaWiki on Kubernetes
=== Engineering Productivity ======= Performance ====
* Blocked by:
* Blocking:
* Updates:
** For 1000+ websites Microsoft now redirects IE users to Edge
automatically when they have Edge installed:
https://twitter.com/MonsieurPerf/status/1333740793253793796 Currently
trying to get in touch with Microsoft to find out if getting Wikimedia
sites added to the list would be a possibility. If they confirm that it can
be done, we can decide whether we want to be on the list or not.
==== Quality and Test Engineering ====
* Blocked by:
* Blocking:
* Updates:
** Blog posts at team blog:
** Outreachy, September-November 2020 (by Željko Filipin)
https://phabricator.wikimedia.org/phame/post/view/220
** Exempla Docent - testing UI for Suggested edits module, Part 2 (by Elena
Tonkovidova) https://phabricator.wikimedia.org/phame/post/view/222
** To dream a dream. My Outreachy Journey (by Harriet Ayugi)
https://phabricator.wikimedia.org/phame/post/view/223
==== Release Engineering ====
* Blocked by:
** WMCS: train-dev blocked waiting for nested VM support ([[phab:T267433]])
<!--https://phabricator.wikimedia.org/T267443 -->
** SRE ServiceOps: deploy scap 3.16.0-1 [[phab:T268634]]<!--
https://phabricator.wikimedia.org/T268634 -->
* Blocking:
* Updates:
** Train Health
*** Last week: No Train
*** This week: 1.36.0-wmf.20 [[phab:T263186]] <!--
https://phabricator.wikimedia.org/T263186 -->
*** Next week: 1.36.0-wmf.21 [[phab:T263187]] <!--
https://phabricator.wikimedia.org/T263187 -->
*** Rest of the year:
https://wikitech.wikimedia.org/wiki/Deployments#Upcoming_Release_Train_disr…
** PHP 8.0 CI support is coming as an experimental job for MW-land code;
already voting for some libraries. Work to do.
=== Search Platform ===
* Blocked by:
* Updates:
** Restart cirrus elasticsearch servers for java upgrade -
https://phabricator.wikimedia.org/T268770
** Update BAG & BRT SPARQL endpoint in the WDQS whitelist -
https://phabricator.wikimedia.org/T264659
=== Site Reliability Engineering ===
* Blocked by:
* Blocking:
releng: deploy scap 3.16.0-1 [[phab:T268634]]<!--
https://phabricator.wikimedia.org/T268634 -->
* Updates:
** Kunal is joining SRE Service Operations!
** Kubernetes infrastructure(s) upgrade policy doc posted at
https://wikitech.wikimedia.org/wiki/Kubernetes/Kubernetes_Infrastructure_up…
** Effie and Giuseppe will be presenting in SRECon. See
https://www.usenix.org/conference/srecon20americas/presentation/mouzeli
** MCR schema change finished https://phabricator.wikimedia.org/T238966
** https://techblog.wikimedia.org/2020/11/25/wikimedias-cdn-the-road-to-ats/
2nd ATS blog post is out
Hi all!
In August, I wrote to this list to discuss the when and how breaking changes can
be made without deprecation
<https://lists.wikimedia.org/pipermail/wikitech-l/2020-August/093761.html>. The
proposal I made at the time was admittedly rather radical, but it lead of a good
discussion and flushed out a number of pain points and interesting ideas. Based
on this discussion and other feedback, I have drafted an update to the Stable
Interface Policy. You can find it here:
User:DKinzler_(WMF)/Stable_interface_policy
<https://www.mediawiki.org/wiki/User:DKinzler_(WMF)/Stable_interface_policy>
(diff
<https://www.mediawiki.org/w/index.php?title=User:DKinzler_(WMF)/Stable_inte…>)
The draft has entered the RFC process
<https://phabricator.wikimedia.org/T268326>, and I intended to move it through
swiftly, so it can be adopted soon. If you have any thoughts or feedback, please
reply to this email, or put it on the phab task.
I would like to highlight a few of the changes that I am proposing:
* Define the idea of a MediaWiki "ecosystem", and state that extensions in
this ecosystem should receive support in dealing with upcoming breaking
changes. The ecosystem includes actively maintained extensions hosted by
Wikimedia or listed by the MediaWiki Stakeholder Group.
* Clarify that removal without deprecation is only ok for code that has never
been used elsewhere.
* Allow "hard deprecation by announcement" when it is not possible to emit
deprecation warnings. This was previously stated as an exception from the
deprecation policy, rather than a mode of deprecation.
* Clarify that individuals or teams who deprecate code commit to removing
usages of that code asap at least in code maintained by Wikimedia, and
should support 3rd parties in this removal from code in the ecosystem.
* Remove the recommendation that hard-deprecated code should be kept for two
releases. This is replaced by a requirement to keep it for one release, and
three months on master.
* Clarify that deprecation and removal of deprecated code should not be
backported to release candidates, and should ideally happen right after a
release, rather than shortly before a release.
The intent is to streamline the deprecation process, ensuring that deprecated
code becomes unused quickly, without causing too much of a disturbance.
Besides this, the proposal contains a number of other additions and
clarifications, as described on the phab ticket and visible in the diff.
I'm looking forward to hearing your thoughts and ideas!
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
After the recent abuse of DMCA provisions to attack popular free
software projects, the Software Freedom Conservancy has initiated a
discussion on a pledge text whose adoption may reduce such issues.
Some people here may be interested.
https://sfconservancy.org/blog/2020/nov/30/dmca-pledge/https://sfconservancy.org/blog/2020/nov/13/widevine-dmca-takedown/
----
DMCA Cooperation Pledge, Version NO-RELEASE-YET
===============================================
We pledge that, regarding any and all alleged copyright infringement and/or
alleged promulgation of circumvention techniques, by any software project
that is licensed in good faith under an OSI-Approved License, that we will
give notice to the project, and take no action of copyright enforcement or
other legal action (including but not limited to DMCA takedown due to
copyright infringement or DMCA §1201 violations), for at least 30 days from
the date of notice of our concerns made to the project.
----
Federico
-------- Messaggio inoltrato --------
Oggetto: Public Drafting Process for the DMCA Cooperation Pledge
Data: Mon, 30 Nov 2020 14:23:00 -0500
Mittente: (Bradley M. Kuhn)
Public Drafting Process for the DMCA Cooperation Pledge
Today, we created a Git repository
<https://k.sfconservancy.org/dmca-pledge> and a mailing list
<https://lists.sfconservancy.org/mailman/listinfo/dmca-pledge> to
discuss drafting of a DMCA Cooperation Pledge — based on my proposal two
weeks ago </blog/2020/nov/13/widevine-dmca-takedown/>.
Hi everyone,
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds
office hours the first Wednesday of each month. Come talk to us about
anything related to Wikimedia search, Wikidata Query Service, Wikimedia
Commons Query Service, etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, December 2nd, 2020
Time: 16:00-17:00 GMT / 08:00-09:00 PST / 11:00-12:00 EST / 17:00-18:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vyc-jvgq-dww
Join by phone in the US: +1 786-701-6904 PIN: 262 122 849#
Hope to talk to you in a week!
—Trey
Trey Jones
Sr. Computational Linguist, Search Platform
Wikimedia Foundation
UTC-5 / EST
