(1) Statement- and property-level watching for changes
problematic changes should come before disallowing them)
This might be harder to do as it's not really possible - internally - to
edit just one statement. It looks like editing one statement, but the
data for the whole entity is stored together, so you are actually always
edit the whole entity. Which means additional code is needed to filter
the watches. Though if the number of watches is small it may be fine.
Additional question is what exactly is "statement"? We do not have any
user-exposed identity for statement, and internal identity can change
with each edit. So if you edit the statement - for how long it is the
same statement as before? (Ship of Theseus problem :)
(2) Statement- and property-level history (it's
currently really hard to
find out who last changed a property, e.g., to contact the person or to
look at their other edits)
Again, due to the above two it may be a bit hard to construct - though
we do have diffs, relating diffs to specific statement may be tricky.
Property, though, probably is much easier since they have clear identity.
It should be possible at least to have some code allowing to answer
questions like "which edit was the last one to touch this property" and
"which edits changed this property's statements" though it is not
trivial and I don't think it exists now.
(3) Statement- and property-level protection (for the
hard cases, mostly
temporarily, same policies as for page-level protection)
(4) Statement-level patrolling (can I approve a more recent change to
P31 without approving an older change to P580?)
This may be possible but I'm not sure it's necessary. The watch approach
below may be more effective and more consistent with the project spirit,
(5) Query-based watching: if you want to watch all
property changes for
a large set of articles, you need better tools
I think a tool that takes a query and creates a list, and allows to:
1. See how the list changes over time
2. Mark some items on the list as "ok" and some as "not ok"
3. Alert people on changes in the list
would make watching for such changes much easier.
(6) More work on edit filters (preventing some edits
based on content,
e.g., the use of shortened URLs as a homepage)
(7) Better UIs to prevent accidental edits (e.g., I can see a lot of
cases where people have entered qualifier information as new statement
That's a good case for watching too - we have properties that are
predominantly used in qualifiers, and even marked so. It should not be
hard to make auto-lists with violations and have people to look at it.
(8) Further work on easy-to-customise quality analysis
and display of
related results (the constraint service is great, but hard to use in a
targeted way to find errors in a specific area). While data-vandalism
can have far-reaching consequences, it also is much harder to hide if
the community has the right tools at hand.
(9) Better data importing infrastructures (some problems mentioned in
this thread seem to be caused by a multi-stage data import approach that
only works if nothing changes in the meantime; I am sure one could get
this fixed without relying on user-editable data).