[Wikidata-bugs] [Maniphest] [Commented On] T198233: Create musical notation datatype(s), with rendering and maybe playback

[Jc86035]

Jc86035 added a comment.
@Ebe123:

We do have the most recent stable version of LilyPond; they haven't had such a release in 5 years...

Oh, I actually didn't realize that when I was writing up the wishlist proposal. Sorry about that. I thought it had been updated at some point, possibly because it had been a while since I had downloaded and used LilyPond as an application, and it was updated during the time that I used it.

indisputably inferior

Yes, this is quite unfair in retrospect. I did have to remove some things attributable to incorrect memory from the wishlist proposal after I'd posted it, because I had essentially put everything I could think of in there to make it sort of actually have a chance to be worked on by Community Tech (although I'm not sure if that would actually have helped in the end). I think part of the problem was that I was comparing the LilyPond features available in Extension:Score directly to both the MuseScore desktop application and the MuseScore closed-source online player.

It's also because I was frustrated with trying to add snippets into articles; on w:en:Double bass, I think it took me about an hour to figure out that the paper size had to be changed to resize the image, and I had to set the instrument to something else because the audio was coming out as piano.

I still think it should be possible, at some point, to be able to link to full scores in their original source format; it would be nice to at least support hosting .mscz/x and/or .ly files on Commons. (Is it common for full scores to be written with LilyPond? I must admit I wasn't actually aware that people would transcribe orchestral scores in LilyPond.)TASK DETAILhttps://phabricator.wikimedia.org/T198233EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc86035Cc: tstarling, Ebe123, Lydia_Pintscher, Liuxinyu970226, Aklapper, ChristianKl, ArthurPSmith, Jc86035, Mahir256, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T198233: Create musical notation datatype(s), with rendering and maybe playback

[Ebe123]

Ebe123 added a comment.
Sorry, I was not aware of this task until I got pinged.

Few corrections:
@Jc86035: We do have the most recent stable version of LilyPond; they haven't had such a release in 5 years... I do not think you are being fair to the progress that is being done in the extension, especially that your comment was made when I was beginning to become more active in this extension. We are working on fixing the issues that you pointed out, with these tasks for the points you bring up: T49578: Score should output SVG, T143500: Add all instruments to Extension:Score (please provide an example if its still broken), and T49528: Create a VisualEditor plugin tool to add/edit musical scores. Check the work-board to see what we have planned :)

I understand the frustration of not having a proper GUI for writing LilyPond, and the task is daunting. I am inclined to agree for the case to render MusicXML (of which the ability to do so is tracked with T183642: Support MusicXML to Lilypond Conversion). I am not in favour of having a whole new extension based on MuseScore, which does have its share of format (.mscx/z) problems. That format is very fragile, and does not feature the scope of what is possible through LilyPond, which has broad support for all kinds of notation that MuseScore struggles with. Your assessment that LilyPond is "indisputably inferior" is false.

Other remedies included OMR (not natively available in MuseScore BTW), which is good; however, there is no open-source (or probably even closed-source) application that does it well enough to be useful in my view. MIDI is very hairy because it is not really a representation of sheet music; it can just be converted (somewhat) into that form.

For use in Wikidata, to get around this size limitation, we can use the extension in the way it is mostly used on Wikipedia: display notable snippets/motifs of a piece. My counter-proposal is rather than storing something like the whole score of //The Planets//, we can store the motifs (and it's not limited to one:

\relative c { \clef bass \time 5/4 \key c \major \tempo "Allegro" \tuplet 3/2 { g8_\markup { \dynamic p \italic "col ligno" } g g } g4 g g8 g g4 \bar ":|]" }

The parallels drawn between \TeX and LilyPond are quite accurate, and @Mahir256's proposal seems to be echoing my sentiment. I apologise for the lack of updates, but we're waiting for the next release of LilyPond for SVG output (had to make changes upstream; it was not as simple as an extra flag sadly) and the extension does need quite a lot done, though time is not available. :)TASK DETAILhttps://phabricator.wikimedia.org/T198233EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ebe123Cc: tstarling, Ebe123, Lydia_Pintscher, Liuxinyu970226, Aklapper, ChristianKl, ArthurPSmith, Jc86035, Mahir256, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T198233: Create musical notation datatype(s), with rendering and maybe playback

[Ebe123]

Ebe123 added a project: MediaWiki-extensions-Score.Ebe123 updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...There is already an Extension:Score (#mediawiki-extensions-score) for LilyPond, which does rendering and some audio output, ~~but it doesn't seem to have an updated version of LilyPond~~. Scores using this LilyPond datatype would also probably be limited to four hundred characters. Longer scores in the public domain would have to use some other solution, although this may be desired. [[ https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat=702741862#Proposal_for_a_musical_notation_datatype_for_properties | Quoting ]] @Mahir256:...TASK DETAILhttps://phabricator.wikimedia.org/T198233EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ebe123Cc: tstarling, Ebe123, Lydia_Pintscher, Liuxinyu970226, Aklapper, ChristianKl, ArthurPSmith, Jc86035, Mahir256, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T144103: Create .nt (NTriples) dumps for wikidata data

[Smalyshev]

Smalyshev added a project: User-Smalyshev.
TASK DETAILhttps://phabricator.wikimedia.org/T144103EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Lydia_Pintscher, thalhamm, Hydriz, Lokal_Profil, Sylvain_WMFr, ArielGlenn, Jonas, hoo, aude, daniel, -jem-, Aklapper, Smalyshev, Lahi, Gq86, Darkminds3113, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, merbst, LawExplorer, Avner, Gehel, FloNight, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, Tobias1984, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T198233: Create musical notation datatype(s), with rendering and maybe playback

[Mahir256]

Mahir256 added subscribers: Ebe123, tstarling.Mahir256 added a comment.
@Lydia_Pintscher (See the larger of the excerpts from my proposal on Wikidata:Project chat that Jc86035 included in the task description.) We initially stored population data as individual values on an item, but later began storing it as links to Commons tabular data (properties 1082 and 4179 respectively). We also store isolated mathematical expressions, not full derivations or proofs, as LaTeX snippets, and it would not surprise me if someone came around and proposed a property for links to derivations and proofs hosted on Commons (whether as raw LaTeX or otherwise). It would therefore make sense to initially store as statements musical snippets that fit in the 400-character limit for strings, and then later once a MuseScore extension for MediaWiki comes to fruition (or if Extension:Score is significantly revamped) link to full sheet music on Commons. The specific examples on the property proposal that Jc86035 created should not cause copyright problems, and I personally would not have a problem if we need to restrict such a property's use on items for copyrighted music.

@Jc86035 Regarding the points in your excerpt from the survey back in November/December:


There is at least one graphical editor of LilyPond music; I am not certain whether this can or should be made into an extension.
The extension has not been updated in a while, but at least @Ebe123 is around if we have more questions about it.
SVG output is certainly possible with LilyPond; it requires an extra flag but I am not entirely sure what else may be needed for proper rendering.
SVG output might solve the resizing and alignment issues, though I am also not entirely sure what else may be needed for this as well.
Wouldn't the problem of unplayable instruments come down to a need for better soundfonts (either for Fluidsynth or TiMidity++)? It would certainly help to know what soundfonts are used at present.


Also @tstarling who may be able to answer more of the concerns presented in this task.TASK DETAILhttps://phabricator.wikimedia.org/T198233EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Mahir256Cc: tstarling, Ebe123, Lydia_Pintscher, Liuxinyu970226, Aklapper, ChristianKl, ArthurPSmith, Jc86035, Mahir256, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] On traceability and reliability of data we publish [was Re: [Wikimedia-l] Solve legal uncertainty of Wikidata]

[Gerard Meijssen]

Hoi,
Bolderdash and Wikipedia think. When you think Wikipedia has quality, and
it has, it does not have absolute quality. I have added a lot of
information from Wikipedia to Wikidata and there is a lot that is plain
wrong from a data perspective, there are the errors and there is a lot that
is just missing. This is particularly true when the subject is not really
what people are interested in. Things like the Polk award, subdistricts of
Botswana the list is long. I am adding much of the information by hand, add
missing parts and the main use for the missing data is in the relations.

As I have said so often, quality of data is in having the same data in
multiple sources. It follows that the data that can safely be added to
Wikidata is the data where multiple sources agree on the represented facts.
This is done easiest by bots and indeed there algorithms are defined in
their code. When new data is included based on a multitude of sources, what
is the source? Particularly when data is inconsistent as multiple sources
cannot agree on specific data, sources become relevant but it is also where
you go into real research.

Arguably, when data sources differ, you easily get into disputed facts and
fake facts. This is where sourcing the facts becomes relevant. It is also
where you get into real research and where as a consequence the license of
the information becomes irrelevant.

In my opinion, we have grown up thinking in serial sourcing and
particularly when you apply this approach on data stores like Wikidata your
algorithms and thinking fails reality.
Thanks,
  GerardM

On 7 July 2018 at 19:55, Stas Malyshev  wrote:

> Hi!
>
> > I agree this is misconception that a copyright license make any direct
> > change to data reliability. But attribution requirement does somewhat
> > indirectly have an impact on it, as it legally enforce traceability.
>
> While true, I don't think it's of much practical use if traceability is
> what you are seriously interested in. Imagine Wikidata were CC-BY, so
> each piece of data you use from Wikidata now has to be marked as "coming
> from Wikidata.Org". What have you gained? Wikidata is huge, and this
> mark doesn't even tell you which item it is from, while being completely
> satisfactory legally. Even more useless it is for actually ensuring the
> data is correct or tracing its provenance to primary sources - you'd
> still have to find the item and check the references manually (or
> automatically, maybe) as you could do for CC0. CC-BY license would not
> have added very much on Wikidata side.
> All this is while, of course, even with CC0 nothing prevents you from
> importing Wikidata data in such a way that each piece of data still
> carries the mark "coming from Wikidata". While it is not a legal
> requirement with CC0, nothing in CC0 prevents that from happening. If
> your provenance needs are matched by this, there's nothing preventing
> you from doing this, and legal requirements of CC-BY do not improve it
> for you in any way - they just would force people that *do not* need to
> do it still do it.
>
> > That is I strongly disagree with the following assertion: "a license
> > that requires BY sucks so hard for data [because] attribution
> > requirements grow very quickly". To my mind it is equivalent to say that
>
> I think this assertion (that attribution requirements grow) is factually
> true. Each data piece from CC-BY data set needs to carry attribution. If
> your data needs require to combine several data sets, each of them needs
> to carry attribution. This attribution should be carried through all
> data processing pipelines. You may be OK with this growth, but as I just
> explained above, these requirements, while being onerous for people that
> don't need tracing each piece of data, are still unsatisfactory in many
> cases for those that do. So having CC-BY would be both onerous and useless.
>
> > we will throw away traceability because it is subjectively judged too
> > large a burden, without providing any start of evidence that it indeed
> > can't be managed, at least with Wikimedia current ressources.
>
> It's not Wikimedia that will be shouldering the burden, it's every user
> of Wikimedia data sets.
>
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] On traceability and reliability of data we publish [was Re: [Wikimedia-l] Solve legal uncertainty of Wikidata]

[mathieu lovato stumpf guntz]

Le 07/07/2018 à 19:55, Stas Malyshev a écrit :


I think this assertion (that attribution requirements grow) is factually
true. Each data piece from CC-BY data set needs to carry attribution. If
your data needs require to combine several data sets, each of them needs
to carry attribution. This attribution should be carried through all
data processing pipelines. You may be OK with this growth, but as I just
explained above, these requirements, while being onerous for people that
don't need tracing each piece of data, are still unsatisfactory in many
cases for those that do. So having CC-BY would be both onerous and useless.

Hi Stas,

The attribution need to be carried only through processing pipelines 
whose results need to be published.


Can we talk about real concrete examples where attribution would 
seriously prevent any real case use? If all this stands on solid facts, 
surely it shouldn't be too hard to come with at least one example. 
Otherwise, it is certainly useless to continue this discussion.


Cheers

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] [Wikimedia-l] Solve legal uncertainty of Wikidata

[mathieu lovato stumpf guntz]

Hi Andra,


Le 04/07/2018 à 13:00, Andra Waagmeester a écrit :



No, Wikidata is not going to change the CC0. You seem to be the
only person wanting that and trying to discredit Wikidata will not
help you in your crusade. I suggest the people who are still
interested in this to go to
https://phabricator.wikimedia.org/T193728
 and make useful
comments over there.

It seems all this assertions are following some erroneous assumptions. 
This ticket is not about changing Wikidata license. It aims at making 
sure what can and what can not be legally imported into a database using 
CC0, and in which juridiction it can be legally used safely or not in 
downstream projects.


It would certainly be interesting that Wikimedia infrastructure would 
allow to host projects using Wikibase with other topic/license scopes 
that are queriables within other Wikimedia projects. Surelly it would 
make a good match with the "become the essential infrastructure of the 
ecosystem of free knowledge" goal. But that's an other story, and I 
didn't found time to work on that topic so far.


It would also be great if we could avoid to imput the title of "crusader 
dedicated to discredit Wikidata" to someone that not later than this 
afternoon helped a new contributor to make its first edit on this project.


Cheers.



Maarten


___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata





___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T198233: Create musical notation datatype(s), with rendering and maybe playback

[Lydia_Pintscher]

Lydia_Pintscher added a comment.
Thanks for filing the ticket!
From my side: in general fine and if we want a new datatype for it then this could be a nice student project for example.

Open question: Do we want this to be on Wikidata as statements? Or on Commons to link to it? The drawback I can see for having it on Wikidata as statements would be length and licensing limitations that might not be great for this type of content. Thoughts?TASK DETAILhttps://phabricator.wikimedia.org/T198233EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_PintscherCc: Lydia_Pintscher, Liuxinyu970226, Aklapper, ChristianKl, ArthurPSmith, Jc86035, Mahir256, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T198233: Create musical notation datatype(s), with rendering and maybe playback

[Lydia_Pintscher]

Lydia_Pintscher added a parent task: T91505: [Epic] Adding new datatypes to Wikidata (tracking).
TASK DETAILhttps://phabricator.wikimedia.org/T198233EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_PintscherCc: Liuxinyu970226, Aklapper, ChristianKl, ArthurPSmith, Jc86035, Mahir256, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T91505: [Epic] Adding new datatypes to Wikidata (tracking)

[Lydia_Pintscher]

Lydia_Pintscher added a subtask: T198233: Create musical notation datatype(s), with rendering and maybe playback.
TASK DETAILhttps://phabricator.wikimedia.org/T91505EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_PintscherCc: Malore, PokestarFan, Swpb, ArthurPSmith, gerritbot, Smalyshev, Shrutika719, MGChecker, Sannita, Ricordisamoa, Liuxinyu970226, Rits, Physikerwelt, Lydia_Pintscher, Aklapper, Lahi, Himanshuc3, Gq86, GoranSMilovanovic, QZanden, srishakatux, LawExplorer, Pahadiahimanshu, Manrajsinghgrover, Keer25, Wikidata-bugs, aude, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T197666: OAuth extension not working in Mediawiki

[despens]

despens added a comment.
After adding wfLoadExtension( 'OAuth' ); and  $wgSecretKey = ""; to LocalSettings.php, the special page https://staging.catalog.rhizome.org/wiki/Special:OAuth/initiate returns another error:

A database query error has occurred. This may indicate a bug in the software.
 [4c8f6a094aeb89788c334f87] 2018-07-07 18:43:41: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
 Retrieved from "https://staging.catalog.rhizome.org/wiki/Special:OAuth/initiate"

It would be helpful if the extensions that are part of the docker distribution would be documented in the LocalSettings.php.templater file so when providing a custom one it would be clear what settings it needs to contain.

I am at a loss what the database query issue might be. Since I did migrate the database from my legacy Wikibase install (and ran the updater script), I wonder if the updater script is incomplete.TASK DETAILhttps://phabricator.wikimedia.org/T197666EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: despensCc: Aklapper, Addshore, Tarrow, despens, Lahi, Gq86, GoranSMilovanovic, QZanden, Gstupp, LawExplorer, Abbe98, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] On traceability and reliability of data we publish [was Re: [Wikimedia-l] Solve legal uncertainty of Wikidata]

[Stas Malyshev]

Hi!

> I agree this is misconception that a copyright license make any direct
> change to data reliability. But attribution requirement does somewhat
> indirectly have an impact on it, as it legally enforce traceability.

While true, I don't think it's of much practical use if traceability is
what you are seriously interested in. Imagine Wikidata were CC-BY, so
each piece of data you use from Wikidata now has to be marked as "coming
from Wikidata.Org". What have you gained? Wikidata is huge, and this
mark doesn't even tell you which item it is from, while being completely
satisfactory legally. Even more useless it is for actually ensuring the
data is correct or tracing its provenance to primary sources - you'd
still have to find the item and check the references manually (or
automatically, maybe) as you could do for CC0. CC-BY license would not
have added very much on Wikidata side.
All this is while, of course, even with CC0 nothing prevents you from
importing Wikidata data in such a way that each piece of data still
carries the mark "coming from Wikidata". While it is not a legal
requirement with CC0, nothing in CC0 prevents that from happening. If
your provenance needs are matched by this, there's nothing preventing
you from doing this, and legal requirements of CC-BY do not improve it
for you in any way - they just would force people that *do not* need to
do it still do it.

> That is I strongly disagree with the following assertion: "a license
> that requires BY sucks so hard for data [because] attribution
> requirements grow very quickly". To my mind it is equivalent to say that

I think this assertion (that attribution requirements grow) is factually
true. Each data piece from CC-BY data set needs to carry attribution. If
your data needs require to combine several data sets, each of them needs
to carry attribution. This attribution should be carried through all
data processing pipelines. You may be OK with this growth, but as I just
explained above, these requirements, while being onerous for people that
don't need tracing each piece of data, are still unsatisfactory in many
cases for those that do. So having CC-BY would be both onerous and useless.

> we will throw away traceability because it is subjectively judged too
> large a burden, without providing any start of evidence that it indeed
> can't be managed, at least with Wikimedia current ressources.

It's not Wikimedia that will be shouldering the burden, it's every user
of Wikimedia data sets.

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata] On traceability and reliability of data we publish [was Re: [Wikimedia-l] Solve legal uncertainty of Wikidata]

[mathieu lovato stumpf guntz]

Hi Andra,

I agree this is misconception that a copyright license make any direct 
change to data reliability. But attribution requirement does somewhat 
indirectly have an impact on it, as it legally enforce traceability. 
That is I strongly disagree with the following assertion: "a license 
that requires BY sucks so hard for data [because] attribution 
requirements grow very quickly". To my mind it is equivalent to say that 
we will throw away traceability because it is subjectively judged too 
large a burden, without providing any start of evidence that it indeed 
can't be managed, at least with Wikimedia current ressources.


Now, I don't say traceability is the sole factor one should take into 
account in data reliability, but certainly it is one of them. Maybe we 
should first come with clear criteria to put in a equation that enable 
to calculate reliability of information. Since it's in the core goals of 
the Wikimedia strategy, it would certainly worth the effort to establish 
clear metrics about reliability of information the movement is spreading.


Cheers


Le 04/07/2018 à 13:00, Andra Waagmeester a écrit :
I agree with Maarten and to add to that. It is a huge misconception 
that CC0  makes data unreliable. It is only a legal statement about 
copyright, nothing more, nothing less. Statements without proper 
references and qualifiers make data unreliable, but Wikidata has a 
decent mechanism to capture that needed provenance.


On Wed, Jul 4, 2018 at 12:50 PM, Maarten Dammers > wrote:


Hi Mathieu,

On 04-07-18 11:07, mathieu stumpf guntz wrote:

Hi,

Le 19/05/2018 à 03:35, Denny Vrandečić a écrit :


Regarding attribution, commonly it is assumed that you
have to respect it transitively. That is one of the
reasons a license that requires BY sucks so hard for data:
unlike with text, the attribution requirements grow very
quickly. It is the same as with modified images and
collages: it is not sufficient to attribute the last
author, but all contributors have to be attributed.

If we want our data to be trustable, then we need
traceability. That is reporting this chain of sources as
extensively as possible, whatever the license require or not
as attribution. CC-0 allow to break this traceability, which
make an aweful license to whoever is concerned with obtaining
reliable data.

A license is not the way to achieve this. We have references for that.


This is why I think that whoever wants to be part of a
large federation of data on the web, should publish under CC0.

As long as one aim at making a federation of untrustable data
banks, that's perfect. ;)

So I see you started forum shopping (trying to get the Wikimedia-l
people in) and making contentious trying to be funny remarks.
That's usually a good indication a thread is going nowhere.

No, Wikidata is not going to change the CC0. You seem to be the
only person wanting that and trying to discredit Wikidata will not
help you in your crusade. I suggest the people who are still
interested in this to go to
https://phabricator.wikimedia.org/T193728
 and make useful
comments over there.

Maarten


___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata





___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata


___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Created] T199016: Count structured data uploads and edits by volunteer-built tools

[Abit]

Abit created this task.Abit added projects: Product-Analytics, Structured-Data-Commons, Multimedia.Herald added a project: Wikidata.
TASK DESCRIPTIONWe would like to know how many structured data uploads and edits come from key Commons tools.  (For this purpose let's define structured data uploads and edits as uploads and edits of media on Commons and uploads and edits to structured data fields that appear on the file page, including statements, captions, and descriptions.  Some of these statements reside in Wikidata.)

Example key Commons tools: Pattypan, Open Refine, Quick Statements, Monumental.TASK DETAILhttps://phabricator.wikimedia.org/T199016EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: mpopov, AbitCc: Ramsey-WMF, Abit, Lahi, PDrouin-WMF, Gq86, E1presidente, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden, Tramullas, Acer, V4switch, LawExplorer, Susannaanas, Wong128hk, Aschroet, Jane023, Wikidata-bugs, Base, matthiasmullie, aude, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Steinsplitter, Matanya, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] SPARQL tutorial video (2 hours)

[Nurunnaby Hasive]

Great! Thanks, Asaf!

I learn so many issues about Wikidata after watching your 3hr long Wikidata
intro video. Last few days I'm trying to learn SPARQL. Hope your this video
also help me a lot to learn more about SPARQL.

Thanks again!

Hasive

On Fri, Jul 6, 2018 at 5:40 PM Rajeeb Dutta  wrote:

> Thanks Asaf for sharing the video.
> Thanks,
> Regards,
> Rajeeb Dutta.
> Sent from my iPhone
>
> On 06-Jul-2018, at 4:18 PM, Tito Dutta  wrote:
>
> Great. Many thanks for sharing.
>
> Thanks
> Tito Dutta
> Note: If I don't reply to your email in 2 days, please feel free to remind
> me over email or phone call.
>
>
> On Fri, 6 Jul 2018 at 16:14, Asaf Bartov  wrote:
>
>> Hullo.
>>
>> I recently recorded a video of my 2-hour SPARQL tutorial.  It is better
>> than the SPARQL section in my 3-hour Intro to Wikidata video from a couple
>> of years ago, and is easier to follow, with the query screen fed directly
>> rather than through the video camera.
>>
>> It is now available here:
>>
>> https://commons.wikimedia.org/wiki/File:Querying_Wikidata_with_SPARQL_for_Absolute_Beginners.webm
>>
>>
>> Enjoy!
>>
>>A.
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>


-- 
*Nurunnaby Chowdhury (Hasive) **:: **নুরুন্নবী চৌধুরী (হাছিব)*
User: Hasive  |
GSM/WhatsApp/Viber: +8801712754752 
​
Administrator | Bengali Wikipedia 
Board Member | Wikimedia Bangladesh 
fb.com/Hasive  | @nhasive
 | www.nhasive.com
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata