Agreed, that was a neat read John. > * It is not just experienced template coders who want to make use of > the parser function (This comes from discussions with several > Wikipedians who want to try things but are not advanced enough for > more than the property parser function.)
How easy is it to get the property ID? Is it possible for us to make that easier to acquire? Perhaps add a button somewhere that says something like "Use this property in Wikitext" or somesuch. Using P numbers by themselves is not ideal, but I am still not convinced that there is another good way to do this and I think several people have made pretty reasonable arguments that aliases shouldn't be forced to be unique (though they often will be unique!). I wish I had an idea for a solution myself. I feel bad giving an opinion without any input on how to fix the situation. Thank you, Derric Atzrott On Mon, Jul 13, 2015 at 2:46 PM, Markus Krötzsch < [email protected]> wrote: > Thanks, John, for the explanation(s). I understand the idea. Essentially, > the meaning of wikitext would then depend on when exactly a page is stored. > The same content could have different meaning. That seems problematic to me > ... But I guess we don't have to worry since it seems clear that this won't > be implementable in MediaWiki as we know it today ;-) But thanks anyway -- > it's an interesting concept, even if purely hypothetical right now. > > Best regards, > > Markus > > > > On 13.07.2015 19:33, John Erling Blad wrote: > >> Actually I think we have a problem with all three points in the CAP >> theorem, so we should start coding for fault tolerance. Still this >> goes off-topic. I'm done with this thread. >> >> On Mon, Jul 13, 2015 at 6:29 PM, John Erling Blad <[email protected]> >> wrote: >> >>> A property function for versioned labels would look _exactly_ the same >>> as today, but the request for the actual value would use the label and >>> a timestamp. The timestamp would be the last revision of the template. >>> >>> Look up books on distributed databases, and check out how they >>> maintain consistency. In our case it is a simplified set up with a >>> single master server with multiple clients that has read access to the >>> server. In addition they have their own state that interfere with the >>> master state. >>> >>> We have a consistency problem (CAP theorem) because the clients don't >>> update their state (the templates) according to changes on the server >>> (the labels). One solution to this is to keep the last known version >>> (a timestamp) to make it possible to continue using outdated >>> information. >>> >>> Another way to say this is that a change in the label leaves an >>> invalid state at the clients, because the transaction ends prematurly. >>> That is the templates are not updated, which they must be if the >>> system lacks versioning. >>> >>> Even another way to describe this is that the process running on the >>> server and the clients lacks isolation, which again can be restored >>> with versioning. >>> >>> There are several consistency models that can be used, but I don't >>> know if anyone includes something like the proposed "alias model". >>> >>> CAP theorem is described in these two, but I havn't read them, sorry for >>> that! >>> >>> Brewer, Eric A.: Towards robust distributed systems (abstract), in: >>> Proceedings of the nineteenth annual ACM symposium on Principles of >>> distributed computing, PODC’00, ACM, New York, NY, USA, pp. 7– >>> >>> Gilbert, Seth and Lynch, Nancy: Brewer’s conjecture and the >>> feasibility of consistent, available, partition-tolerant web services. >>> SIGACT News (2002), vol. 33:pp. 51–59 >>> >>> On Mon, Jul 13, 2015 at 4:21 PM, Markus Krötzsch >>> <[email protected]> wrote: >>> >>>> On 13.07.2015 16:01, John Erling Blad wrote: >>>> >>>>> >>>>> No we should not make the aliases unique, the reason aliases are >>>>> useful is because they are _not_ unique. >>>>> Add versioning to labels, that is the only real solution. >>>>> >>>> >>>> >>>> Following this thread for a while, I still have no idea what this >>>> solution >>>> is. Could you give an example of how the #property function in Wikitext >>>> will >>>> look for this proposal? >>>> >>>> >>>>> There are books on the topic, and also some dr thesis. I don't think >>>>> we should create anything ad hoc for this. Go for a proven solution. >>>>> >>>> >>>> >>>> Citation needed ;-) >>>> >>>> Markus >>>> >>>> >>>> >>>>> On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler >>>>> <[email protected]> wrote: >>>>> >>>>>> >>>>>> Am 13.07.2015 um 13:00 schrieb Ricordisamoa: >>>>>> >>>>>>> >>>>>>> I agree too. >>>>>>> Also note that property IDs are language-neutral, unlike english >>>>>>> names >>>>>>> of >>>>>>> templates, magic words, etc. >>>>>>> >>>>>> >>>>>> >>>>>> As I said: if there is broad conseus to only use P-numbers to refer to >>>>>> properties, fine with me (note however that Lydia disagrees, and it's >>>>>> her >>>>>> decision). I like the idea of having the option of accessing >>>>>> properties >>>>>> via >>>>>> localized names, but if there is no demand for this possibility, and >>>>>> it's >>>>>> a pain >>>>>> to implement, I won't complain about dropping support for that. >>>>>> >>>>>> But *if* we allow access to properties via localized unique labels >>>>>> (as we >>>>>> currently do), then we really *should* allow the same via unique >>>>>> aliases, >>>>>> so >>>>>> property labels can be chanegd without breaking stuff. >>>>>> >>>>>> -- >>>>>> Daniel Kinzler >>>>>> Senior Software Developer >>>>>> >>>>>> Wikimedia Deutschland >>>>>> Gesellschaft zur Förderung Freien Wissens e.V. >>>>>> >>>>>> _______________________________________________ >>>>>> Wikidata mailing list >>>>>> [email protected] >>>>>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Wikidata mailing list >>>>> [email protected] >>>>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Wikidata mailing list >>>> [email protected] >>>> https://lists.wikimedia.org/mailman/listinfo/wikidata >>>> >>> >> _______________________________________________ >> Wikidata mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> >> > > _______________________________________________ > Wikidata mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata >
_______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
