"cid" is exactly what I wanted to ask about as well. What I've learned is that some wikis use an optional "cid" parameter <https://it.wikipedia.org/wiki/Template:Cita#Parametro_cid_diverso_dal_cognome_autore>, for example Italian Wikipedia's Template:Cita, that gives the rendered contents a known HTML id anchor. +1 if I understand correctly. This approach builds on web standards and even links elements beyond Cite refs. By "merge or split" CIDs what I imagine is simply that: * the CID is optional, * giving no CID results in an automatic anchor which should not be reusable from wikitext), and * there is one CID per main ref, so merging is done by relinking one main ref's subrefs over to the other main ref.
When you talk about a global CID namespace, I would be sure to avoid a global uniqueness requirement at the moment, it's enough that a CID is unique on its page and when transcluded. +1 that this should become possible in a later phase of the larger WikiCite <https://wikicite.org/> project which builds on the current steps. -Adam On Fri, Aug 23, 2024 at 3:06 AM Samuel Klein <[email protected]> wrote: > My preference, now that subreferencing exists, would be to converge on a > future where we have some FRBR-style clustering of sources (similar to what > fatcat.wiki does for the range of different URLs / content hashes that > refer to the same source, but compounded with the range of different ways > it can be cited), which assigns CIDs, and lets curators explicitly > merge/split CIDs where needed. Then we end up with one CID for each > cluster of substantively identical sources. > > This matches what any meta-analysis of citation usage, citation affect, > source reliability, retraction, &c would want to make bidirectional source > analyses useful. It's a bit of extra structural work up front, and would > result in a CID namespace of O(100M) cited sources, but would be a clear > and new public good useful immediately to our editors and to reuse and > analysis beyond our projects. > > I'm not sure what that means in the *immediate* future, but just as > fatcat did when choosing its battles, a recognition that we will start > using a CID namespace that supports future merges would let us start small > and potentially refactor initial uses via merges into any slightly > different future implementations. > > On Thu, Aug 22, 2024 at 3:41 PM Strainu <[email protected]> wrote: > >> I hit the same problem recently. My solution was very similar to what >> Adam proposed: build the same ref again (completely) and calculate the >> hash. Since in rowiki all interaction with Wikidata is through modules, it >> was trivial to extract the reference code and invoke it directly or from a >> template. >> >> One nasty problem that I couldn't really solve nicely was that the CS1 >> module would add a templatestyle which on subst would be expanded to a >> different strip marker for each instance, causing "reference with same name >> and different content" errors. This meant I could use a template, but not >> substitute it. If I understand your use case correctly, you won't have this >> problem. >> >> When this feature becomes available, you could simply adapt the template >> to generate the <ref extends> tag. >> >> Hth, >> Strainu >> >> Pe miercuri, 21 august 2024, Adam Wight <[email protected]> a >> scris: >> > Hi, I'm one of the developers working on this project. >> > Thanks for the question! Currently, the state of our thinking around >> reusing refs from a template is that it's problematic, but the simplest and >> safest existing workaround is to produce another ref in exactly the same >> way as the first. So if the CS1 family of templates is used (eg. Cite book >> / Literatur) then you can use the same or a similar template to generate >> the second ref, and if the parameters to CS1 match then your final refs >> will be identical and the footnote markers will be merged together into one >> symbol and one reflist item. >> > The second possibility would require a feature change which has some >> questionable implications: that any two refs with identical content could >> be merged in reading mode, regardless of the "name" attribute. However, >> since the reference content can only be guaranteed to be identical if the >> same template is used, I believe the first solution (use the same >> underlying template and let it produce a name) is the best workaround for >> the moment. >> > Please do suggest any better ideas you might have... so far, it's been >> hard to imagine what a more "stable link" might look like, maybe it's an >> explicit "cid" or HTML id, we're really not sure yet. >> > Regards, >> > [[mw:User:Adamw]] >> > >> > On Tue, Aug 20, 2024 at 10:47 AM Bináris <[email protected]> wrote: >> >> >> >> I have just experienced a related problem recently. I am not sure if >> it is in the scope of your project, so I just mention it here. >> >> Original problem: a reference is given in Wikidata as source of death, >> for example. It appears automatically in infobox. >> >> Later in the article I need that for another purpose, and it will >> appear on tha pege twice. >> >> Question: can we make it appear once? >> >> Answer in huwiki: the link of Wikidata contains a hash, which can be >> used as <ref name="this-hash"/>. >> >> New problem: whenever the source is edited in Wikidata, the hash >> regenerates, and the article will silently be spoiled. We can discover the >> error in ref name only accidentlly, and it is a head ache to guess the >> original. >> >> Relation to this project: can we safely reuse the references >> originating from Wikidata? Can it offer a stable link? >> >> Or should I write this to Wikidata mailing list? >> >> _______________________________________________ >> >> Wikitech-l mailing list -- [email protected] >> >> To unsubscribe send an email to [email protected] >> >> >> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ >> > >> > -- >> > Adam Wight - Developer - Wikimedia Deutschland e.V. - >> https://wikimedia.de >> > _______________________________________________ >> Wikitech-l mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ > > > > -- > Samuel Klein @metasj w:user:sj +1 617 529 4266 > _______________________________________________ > Wikitech-l mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ -- Adam Wight - Developer - Wikimedia Deutschland e.V. - https://wikimedia.de
_______________________________________________ Wikitech-l mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
