https://www.wikidata.org/w/index.php?title=Q24238356&oldid=1184963876 seems to me like a very strange edit.
User talk:Hannolans
About this board
Welcome to Wikidata, Hannolans!
Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!
Need some help getting started? Here are some pages you can familiarize yourself with:
- Introduction – An introduction to the project.
- Wikidata tours – Interactive tutorials to show you how Wikidata works.
- Community portal – The portal for community members.
- Contents – The main help page for editing and using the site.
- Project chat – Discussions about the project.
- Tools – A collection of user-developed JavaScript tools to allow for easier completion of some tasks.
If you have any questions, please ask me on my talk page. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.
Best regards! Liuxinyu970226 (talk) 04:51, 6 July 2016 (UTC)
Previous discussion was archived at User talk:Hannolans/Archive 1 on 2016-09-27.
Hi, since I don't found Issuksiuvit Lake (Q90818514) in the Banque de noms de lieux du Québec (Q27675378). I posted a e-mail to the Commission de toponymie du Québec (Q2986528). Maybe they will add it (with the coordinates). ;)
Hello, I noticed in this item a date of birth (P569) of "10 February 7"; Not only does this seem inaccurate (this person seems to be a living human, likely born in 1989), but I cannot even understand where the claim came from (I don't see it in the reference). Do you have any thoughts about this?
I think that was a date-conversion issue in open refine. In the source 1989 was stated, Added additional reference to his website.
Thanks! I'm seeing a few more of these as well: Wirrpanda Maymuru (Q86742565), Ngalawurr Munungurr (Q86742535), Marrnyula Mununggurr (Q86742529). Also, while reasonable-looking dates were copied into Property:P1810 in the references, the links to NMVW are not working for me, which is one reason I haven't just fixed these.
It was a batch upload with the database of the mentioned museum. Not all identifiers seems to be available with an online page. I will investigate how many persons are affected.
I have checked persons, it were five persons, the date was provided as a negative number '-1951'
You are tagging this as applying "worldwide", but US copyright law is not based upon the date of death of the creator. US copyright depends upon the date of publication.
Hi, yes publication date is in every country important. The copyright status of a creator states if the oeuvre published during the lifetime of a creator is still copyrighted or in the public domain. It is not valid for unpublished and or postumous works (where specialised rules apply, see for example the discussions around the diary of Anne Frank). I changed the description of the property to make that more clear.
In the US every work published before 1925 is in the public domain (https://commons.wikimedia.org/wiki/Template:PD-US-expired), so the oeuvre of a creator that died before that date is public domain in the US.
No, it isn't. If a posthumous work is published in the United States, then the date of publication is the first year of copyright protection. This includes edited texts and translations. It does not matter when the original author died for U.S. copyright.
Yes, for posthumous and unpublished works this is not valid, the scope is as I said published works during the lifetime of the author.
Example: The author Johan Huizinga died in 1975, and his 1919 book Herfsttij der Middeleeuwen is in public domain in the EU. The 1924 English translation of his book The Waning of the Middle Ages is in public domain in the U.S., but the more recent 1996 English translation "The Autumn of the Middle Ages" is still under copyright in the U.S.
But Q276280 has only a copyright status for the jurisdiction Q59542795 that is without a status for the US. For the US it is very difficult to add a copyright status for authors died between 1925 and now. That is the reason we don't write a copyright status for the US.
But the same principle also applies to authors who died more than 100 years ago. There are multiple translations of Virgil's Aeneid that are still under copyright in the United States, even though Virgil died centuries ago.
I see what you mean. Yes, it is only valid for the original works of the original author.
There are editions of plays by Menander that are still under copyright in the United States because the texts were discovered in the 20th century. These editions, even though they are in Greek, are under copyright because the editor has put in work to transcribe and annotate them. In short, the date of death of the author is not an indicator of the copyright status of a work. Posting a blanket statement about the copyright status of an author's body of work is meaningless.
Yes, for posthumous works other rules apply. In Wikimedia Commons we even use PD-assumed for old masters paintings as sometimes we even are not sure if old paintings are public domain or not, we simply assume they are.
For classical and ancient authors we do not have their "original works". We have only copies of copies, and those copies have been edited. No one has a copy of the Aeneid written during the lifetime of Virgil. No one has a copy of Homer's Iliad written during Homer's lifetime. All classical works have undergone copying and editing. There are no "original works" by these authors to point to and talk about. All copies are more recent editions.
In that case we should consider that work in Wikidata a posthumous work with another publication date and the original work as lost.
So we have Q60220 and we have editions like Q19537661 and Q21205467. All editions have an publication date, an editor as well as the original author. To calculate the copyright status of that edition we should take into account all that data.
That would apply to every single classical work and most early mediaeval literature as well.
Yes, this is interesting, we started this property for artwoks like paintings, sculptures and photographs for works in collections where the original work still exists in museums etc. But we are now talking about creators without any known work in original state. But we are currently only writing the properties to persons who have 'works in collection' in a museum, so with original works. We planned to have a session about this property during the Creative Commons Summit and are now looking for an online meetup. This would be interesting to ake into account during that session. Would you like to join?
Have you talked to Wikiproject:Books about this?
No, as said we are using this for persons with works in collection Property:P6379 but would be interesting to see how it fits with mediaeval literature editions/works etc
Since this impacts Wikiproject:Books, it would be polite to include them in the process.
Yes, that would definitely be very interesting. I can also include the Dutch national library to discuss this modelling structure of copyright of literature in Wikidata.
In the future we could have bots that can add a copyright status to individual works like songs and books based on translators, publication date and copyright status of the authors etc. But for that we need a sense of completeness of the data needed to do a calculation.
Not to works: to the editions. It is versions / editions that have that kind of data.
Yes most importantly for editions. I modelled this for the diary of Anne Frank in that way.
Iemand in de Telegram-groep van Wikidata vroeg of iemand begrijpt wat het item Post Card (Q87667915) representeert. Ik heb er even naar gekeken, en het lijkt me een fout in de brondatabase. Weet jij er misschien meer over? Ik zie dat jij het item hebt aangemaakt.
Het hoort een vervaardiger te zijn. Het is wel een dubieuze naam en lijkt inderdaad op een foutje.
Ik zal even nagaan daar wat het is, mogelijk kan het weg.
Hallo Hannolans,
Ik zie dat je deze bewerking hebt gedaan, waarbij je bij Romeyn de Hooghe dat zijn land van nationaliteit d:Q29999 zou zijn. Het Koninkrijk bestond echter niet in zijn dagen, hij was veeleer inwoner van d:Q170072. Het zou fijn zijn als je bij mensen die voor de oprichting van het Koninkrijk zijn overleden niet Q29999 gebruikt, maar verwijst naar de toen geldende rechtsvoorganger.
Alvast bedankt, RonnieV (talk) 01:10, 12 February 2020 (UTC)
We zouden er wellicht een tabelletje of tijdlijn voor moeten maken, hoewel ik me besef (nu ik dat schrijf) dat dat ook nog eens heel erg plaatsafhankelijk is. Dan is het eventueel ook mogelijk een check-script te maken die de gevallen op een lijstje zet die verkeerd op die tijdlijn staan.
@Edoderoo, daar heb je gelijk in. Op Talk:Q29999#History staat een ruw overzichtje, maar dat dekt niet alle veranderingen in de grenzen. Op nl-Wikipedia staan overzichten van mensen die ten onrechte aan Nederland dan wel België gekoppeld zijn. Het terugschroeven van de rank van deze vermeldingen naar deprecated verbergt deze fouten, maar draagt nog niet bij tot een oplossing. Toch maar handmatig langslopen? En ondertussen hopen dat er geen nieuwe toevoegingen plaatsvinden. En ja, ik zou deze lijstjes ook kunnen toevoegen aan Wikidata. Met vriendelijke groet, RonnieV (talk) 10:29, 12 February 2020 (UTC)
Bij imports via openrefine en andere tools wordt geen rekening gehouden met historiciteit van een land. Ik zou ook niet weten hoe een erfgoedinstelling dit goed zou kunnen doen. Zij hanteren zelf deze methodiek niet maar schrijven 'Dutch'. We zouden ook in wikidata 'Nederlander' kunnen gebruiken met een nieuw property 'nationaliteit', maar ik vrees dat het dan nog ingewikkelder wordt en ik zie dan ook overlap met 'etnische groep'. Soms ook is de geboorte- en sterfdatum niet bekend bij de import, dus is het niet correct weg te schrijven. En hoe moet worden omgegaan qua historiciteit met 'Suriname' , 'Indonesie' en 'Nederlands-Indie'? Een manier lijkt mij om botjes in te zetten die voorkeursrangen instelt afhankelijk van de tijdsperiode. Wat betreft Nederlands-Indie, ik denk dat die dan niet bij land van nationaliteit kan staan, maar vervangen moet worden door werklocatie/woonlocatie = Nederlands-Indie en nationaliteit Koninkrijk der Nederlanden. ("volgens het Nederlandse Burgerlijk Wetboek van 1838 was iedereen die in Nederland of in de koloniën was geboren Nederlander. Dit betekende dat vrijwel de gehele bevolking van Nederland én van de koloniën de Nederlandse nationaliteit bezat") https://nl.wikipedia.org/wiki/Indische_Nederlanders
ai, het is zelfs nog ingewikkelder 'De term Nederlands onderdaan was ruimer dan de term Nederlander: inlanders (Indonesiërs) waren wel Nederlands onderdaan, maar geen Nederlandse staatsburger. Na de onafhankelijkheid konden achterblijvende Nederlanders tot december 1951 kiezen om Nederlander te blijven of om Indonesiër te worden. Inlanders werden automatisch Indonesiër.' Wat vullen we dan in bij Indonesiers als 'land van nationaliteit'? Iedereen die na 1951 overleden is 'Indonesier' resp Koninkrijk der Nederlanden (afhankelijk of ze bleven of vertrokken?), maar Nederlands-Indiers die voor 1951 overleden zijn?
Eens met Hanno en Edoderoo, het is effectiever om een bot hier (correctie)werk uit te laten voeren (dan aan individuele gebruikers een enkele bewerking voor te leggen met het verzoek deze aan te passen). We zouden ervoor kunnen zorgen 1) dat de gevallen waar de invoer aantoonbaar onjuist is (bv sterfdatum ligt voor begin van het gebruikte 'land van nationaliteit') worden gemarkeerd met de welbekende omcirkelde uitroepteken van constraint/beperking en 2) dergelijke probleemgevallen met het botscript worden nagelopen en gecorrigeerd. Zo zijn er veel personen die al een gemarkeerd verkeerd land van nationaliteit hebben (bv 'Netherlands'): deze zouden al aangepakt kunnen worden toch? Het voordeel van het inzetten van een dergelijk precies botscript is dat ook de input van culturele erfgoedinstellingen of wetenschappelijke organisaties (die begrijpelijkerwijs nooit volgens "onze" regels zal zijn) gecorrigeerd of überhaupt ingevuld kan worden. Op die manier voorkomen we dat dergelijke foutieve en onvolledige data een lang leven gegeven is op Wikidata.
Daarbij zou er ook beter overlegd kunnen worden over wanneer we iemand een bepaald land van nationaliteit meegeven. Wat als - zoals Hanno bv aangeeft - geboorte- en of sterfdatum niet bekend is/zijn, maar alleen 'floruit'? Geven we (dan) de nationaliteit van het land waarin de persoon het langst heeft geleefd (en beschouwen we de eerste 10 of laatste 10 jaar als 'deprecated' landen van nationaliteit)?
Het hele gebruik van de eigenschap 'etnische groep' is behoorlijk vaag en meervormig (met andere woorden: iedereen gebruikt het op de eigen manier, doet maar wat of helemaal niet). Want naast Suriname en Nederlands-Indië hebben we (wat het Koninkrijk der Nederlanden betreft) ook nog de voormalige Nederlandse Antillen. Ook die bewoners hebben allen (ook nu nog) de Nederlandse nationaliteit en ik vraag me af of etniciteit nu de beste wijze is om het onderscheid tussen de bewoners van de landen Curaçao, Aruba, Sint-Maarten of de openbare lichamen Bonaire, St. Eustatius en Saba aan te geven. Wat is jullie idee daarover?
Dit is een terugkerend niet opgelost probleem op Wikidata: Hoe koppel je een historisch persoon aan een hedendaags land? (Allemaal de schuld van nationalisme!). Bijvoorbeeld:
- Rembrandt (Q5598) -> Netherlands (Q55) / Kingdom of the Netherlands (Q29999)
- Peter Paul Rubens (Q5599) -> Belgium (Q31)
- Leonardo da Vinci (Q762) -> Italy (Q38)
Er zijn ook wel varianten van het probleem te bedenken zoals hierboven al wordt genoemd. Stel dat we hier nu een nieuwe property voor zouden maken, hoe zouden we die dan noemen? "Hedendaags land dat historisch persoon als inwoner ziet"? Iets in die richting?
Ha Multichill, interessante denkrichting. Je zou in dat geval dus bij een historische persoon zowel (bv) land van nationaliteit als deze nieuwe property invullen? Ik ga er eens over nadenken.
Ha Hannolans en Edo, Een botmatig lijstje met afwijkende waarden kan een idee zijn om dit te signaleren, maar is hooguit een klein stapje op weg naar een oplossing. Onjuiste waarden worden in Wikidata al gesignaleerd op het betreffende item, maar dat vereist nog altijd een handmatige actie van iemand.
Het is jammer dat degenen die gegevens aanleveren niet verder komen dan 'Dutch' en dat QuickStatements niet in staat is om op basis van dat gegeven en de jaartallen (indien bekend) met een beter voorstel te komen dan Q29999 (of de hiervoor helemaal 'verboden' waarde Q55). Ik hoopte dat het iets makkelijker zou zijn met QS om (bijvoorbeeld) voor iedereen van voor 1795 automagisch Q170072 te gebruiken. Zou dat nog kunnen door er twee batches van te maken, waarbij de nieuwere personen Q29999 krijgen en de oudere Q170072? Zijn er geen jaartallen bekend, dan kan de software ook niets betekenen. Helaas zie ik ook bij RKD en andere bronnen de aanduidingen 'Nederlands' en 'Belgisch' staan voor mensen uit lang vervlogen tijden.
Een bot laten lopen die alle ongeldige waarden deprecated maakt klinkt leuk, maar betekent vooral dat het probleem wordt weggemoffeld, niet dat het wordt opgelost. Dit zou nog iets kunnen doen voor iemand uit (zeg) de 17e eeuw die aan Q29999 en Q170072 gekoppeld is, maar voor iemand die alleen aan Q29999 (of Q55) gekoppeld is, is dat geen oplossing. Deprecated waarden verdwijnen veelal uit beeld, maar leiden niet tot het wel beschikbaar zijn van een juiste waarde.
Ha Multichill, een dergelijk extra veld zou in ieder geval de drang van sommigen kunnen wegnemen om hedendaagse landen als 'land van nationaliteit' toe te kennen aan historische personen. Maar dit leidt ertoe dat er nog een extra variabele moet worden ingevuld. En vervolgens valt het volgende land uit elkaar en moeten al die waarden weer bepaald worden en verwerkt. Met de kans dat mensen door meerdere (vele) landen 'geclaimd' worden, zeker als de betrokkene niet heel erg honkvast was.
Blijft natuurlijk staan dat Leonardo da Vinci niets met Q38 van doen heeft, behalve een geografische overeenkomst. Dat de Italianen hem graag als landgenoot zien, begrijp ik. Maar dat maakt nog niet dat hij ooit een burger van de huidige Italiaanse staat is geweest.
Het goed ingevuld nationaliteitsveld heeft (denk ik) meer waarde dan een veld waarin huidige staten mensen kunnen 'claimen'. En ja, sommige landnamen worden alsnog vertaald naar hedendaagse aanduidingen (bijvoorbeeld alle historische Poolse republieken of de snel wisselende aanduidingen voor Duitsland).
Vriendelijke groet, RonnieV (talk) 19:19, 14 February 2020 (UTC)
We zijn een referentiedatabase dus zouden eigenlijk moeten overnemen hoe de erfgoedinstellingen een persoon beschrijven. Nu is het eigenlijk een door ons berekend veld, want in onze databases komt dit onderscheid vaak niet voor of wordt anders gehanteerd. Als een instelling een andere waarde gebruiken dan wij zouden we die waarde kunnen toevoegen en daaruit onze 'staat' kunnen extraheren.
Quickstatements an ook OpenRefine zijn slechts tools waar 'uitkomt' wat je erin stopt: die tools 'denken niet zelf'. @RonnieV: Je vraag ''Ik hoopte dat het iets makkelijker zou zijn met QS om (bijvoorbeeld) voor iedereen van voor 1795 automagisch Q170072 te gebruiken. Zou dat nog kunnen door er twee batches van te maken, waarbij de nieuwere personen Q29999 krijgen en de oudere Q170072?'' begrijp ik dan ook niet. Twee batches ervan maken maakt geen verschil, maar misschien begrijp ik je opmerking niet goed genoeg? Het probleem is dat de gegevens aangeleverd worden met bv nationaliteit:Nederlands en dat degene die de data modelleert, opschoont en aanpast en vervolgens uploadt met QS or OR zelf zou moeten aangeven wat 'Nederlandse nationaliteit' in ieder specifiek geval zou moeten inhouden. Die tools kunnen niet zelf bepalen, zeg maar. Hoe zie jij dat specifiek?
Er wordt toch ook door niemand voorgesteld om de verkeerde landen van nationaliteit tot deprecated te maken? Ik zie dat in je eigen reactie terugkomen ''Het terugschroeven van de rank van deze vermeldingen naar deprecated verbergt deze fouten, maar draagt nog niet bij tot een oplossing.'' maar niet bij de anderen. (Ik gebruik het op een andere manier bij de discussie over hoe streng we zijn in het toekennen van meerdere landen van nationaliteit) Ik zou juist denken dat een bot, in tegenstelling tot tools als OR en GS wel in staat is bv aan de hand van de beperkingen/constraints die al gegenereerd (kunnen) worden de juiste landen van nationaliteit kunnen toevoegen. Zo is er een bot die de constraints naloopt die kunnen ontstaan na het toevoegen van de Leidse Hoogleraren ID zonder dat de employer:Universiteit Leiden is ingevuld. Deze dagelijkse bot vult dat 's avonds aan. Zoiets is toch ook best mogelijk voor landen van nationaliteit? Die constraints kunnen we zelf eenmalig instellen en dan kan de bot aan de hand daarvan de problematische gevallen al achterhalen (zonder dat steeds de complete database doorgelopen hoeft te worden) en aan de hand van een vooraf vastgesteld model het correcte land van nationaliteit toevoegen (en de verkeerde verwijderen, niet deprecated maken). En het klopt natuurlijk dat als wij over tien jaar worden overgenomen door Frankrijk tot 'La nouvelle Republique de la France' we inderdaad ons datamodel weer aanmaken passen zodat iedereen geboren na 2030 direct ook LNRF als land van nationaliteit heeft.
Misschien is het instellen van die constraints na consensus van het onderliggende datamodel en vervolgens het bouwen van een bot iets voor (een van ons) de hackathon in Tirana? Nou ja ons... tel mij niet mee hoor. Ik ben van de mooie praatjes en de werkeloze, incapabele (Ecritures)bot. Groet, ~~~~
@Ecritures, Je kent vast het spreekwoord over klokken en klepels.
Met twee batches in QS (of OR) kan, als dat handmatig moet, de bewerker er zelf voor kiezen om een passend land te kiezen. Q29999 voor de recentere personen, formeel vanaf 16 mrt 1815 (of 1839...), tussen 1795 en 1839 kwamen nog wat andere staten voorbij, zie Talk:Q29999#History. Daarvoor moet met enige voorzichtigheid gekeken worden of Q170072 wel de juiste aanduiding is. De grenzen lopen niet helemaal gelijk met die van het huidige Nederland. Maar dat heeft recenter ook gespeeld, zie bijvoorbeeld nl:Nederlandse_annexatie_van_Duits_grondgebied_na_de_Tweede_Wereldoorlog#Uiteindelijke_toewijzing en de daarop volgende paragraaf. Maar voor de jaren (eeuwen) ervoor zal het vooral handmatig uitzoeken worden, in ieder geval goed kijken naar de informatie over de betreffende persoon. Het werk dat Wikidata bewerken leuk, maar ook intensief maakt.
In zijn eerste bewerking schreef Hannolans Een manier lijkt mij om botjes in te zetten die voorkeursrangen instelt afhankelijk van de tijdsperiode. We kennen drie rangen: voorkeur, normaal en afgekeurd. Veel toepassingen gebruiken de waarden die de eerste twee rangen hebben en negeren de waarden die afgekeurd zijn. Afhankelijk van de toepassing wordt alleen met de voorkeurswaarden iets gedaan (als die bestaa[t|n]), of met de voorkeurs- en de normale waarden. Het opstellen van de regels om te bepalen aan welk land (welke landen?) je welke waarde moet toekennen, is niet eenvoudig. Je hebt niet alleen te maken met een simpele keuze tussen (zeg) Q170072 en Q29999 louter op basis van de levensperiode van een persoon. Duidelijk is dat iemand die voor 1815 is overleden in ieder geval nooit de nationaliteit van Q29999 gehad kan hebben. En iemand die na 1795 geboren is, niet die van Q170072. Er zijn personen die van beide landen de nationaliteit, misschien wel een paspoort (wanneer kwamen die dingen?) hebben gehad. Er zijn ook mensen van wie het relevante deel van hun leven zich in een van beide heeft afgespeeld. Maar dat kan van veel zaken afhankelijk zijn. Welk deel van het leven acht je relevant? De gemiddelde voetballer is op zijn veertigste wel uitgespeeld; kan daarna een belangrijke trainer worden of ergens aan de lopende band staan en niets meer doen dat hem/haar E maakt. Sommige presidenten en pauzen hadden al de pensioengerechtigde leeftijd bereikt voordat ze tot deze grootste functie in hun leven kwamen. En wat denk je van België, dat onder het Verenigd koninkrijk viel, onder de Zuidelijke Nederlanden, onder de Hasburgse Nederlanden? Waar een Graafschap Vlaanderen tussendoor fietste, en vast nog wat andere eenheden. En de 'Nederlanden' zijn dan weer een ander verhaal. Wat maakte trouwens in die tijd dat je een bepaalde nationaliteit kreeg? Je geboorte? In de negentiende en twintigste eeuw maakte het mensen in Indonesië tot onderdaan (maar niet tot staatsburger). Sommige kunstenaars uit het huidige Nederland en België brachten een groot deel van hun leven in Italië door, nl:Vincent van Gogh zat meer in het buitenland dan in Nederland. En ja, ook in deze tijd zijn er mensen die de nationaliteit van een ander land aannemen, of krijgen door bijvoorbeeld een wijziging in grenzen of structuur.
Ik denk daarom dat een bot misschien gebruikt kan worden om evident onjuiste waarden af te keuren maar dat het toekennen van andere waarden en het beoordelen van meerdere waarden mensen werk is en voorlopig zal blijven. Dat geeft niet dat dat moet gebeuren, maar het zou fijn zijn als er geen onjuiste waarden bijkomen.
En nee, als de LNRF Nederland zou overnemen, zou dat niets moeten uitmaken voor het datamodel. Dat model moet zodanig staan, dat het al dat soort wijzigingen aankan (daarvoor zijn er al te veel van dat soort wijzigingen geweest in het verleden. Wel zal een deel van de data aangepast/aangevuld moeten worden en zullen nieuwe toevoegingen beter beoordeeld moeten worden, met ook dan de vraag wat je doet met personen die al een (flink) deel van hun leven erop hebben zitten. De glorietijd van Van Agt, van Kok en van prinses Beatrix liggen dan toch echt achter ons, die van prinses Amalia moet nog komen (of nee, die moet opeens een andere toekomst gaan bedenken als het koningshuis zou worden afgeschaft...). RonnieV (talk) 00:23, 15 February 2020 (UTC)
Hoi RonnieV.
ad 'klokken en klepels', ik ga er voor mijn humeur even vanuit dat je daarmee verwijst naar je eigen schrijfsels en niet naar mijn bijdrage.
Ik begrijp nog steeds niet welk verschil twee verschillende batches in OR of QS zouden moeten bewerkstelligen in jouw ogen. Niets in ieder geval dat niet in 1 batch kan. Maar handmatig per item in het databestand ingesteld zou moeten gebeuren door erfgoedinstelling en die gaan dat niet doen. Dergelijke bestanden tellen makkelijk meerdere duizenden bestanden, soms tienduizend(en). Een reguliere erfgoedinstelling gaat dat echt niet 1 voor 1 uitzoeken welke nationaliteiten Wikidata gebruikt.
Uit je tweede paragraaf maak ik op dat je zelf ook inziet hoe gecompliceerd en ineffectief het is om zoiets handmatig per item door te lopen. Werklocatie speelt zeker ook mee (al kunnen die door Multichills bot uit de RKD database gehaald worden).
Ik drukte me waarschijnlijk niet duidelijk genoeg uit bij het gebruik van het woord datamodel. Ik doelde hiermee op het aanbrengen van een 'model van verschillende constraints en het actualiseren daarvan'. Dus als we bv instellen: iemand met een sterfdatum voor 1815 kan niet als nationaliteit 'Koninkrijk der Nederlanden hebben' zullen we in 2030 dat specifieke model moet actualiseren en aanbrengen 'iemand met een geboortedatum van na 2030 kan niet de nationaliteit Koninkrijk der Nederlanden bezitten'. Excuses voor de verwarring.
Ik denk persoonlijk dat er genoeg hele duidelijke gevallen zijn waar een bot wel het land van nationaliteit: Koninkrijk der Nederlanden kan vervangen door iets als Republiek der Nederlanden (of LNRF :)). Sluit wel aan bij mijn hierboven gestelde vraag: ''Daarbij zou er ook beter overlegd kunnen worden over wanneer we iemand een bepaald land van nationaliteit meegeven. Wat als - zoals Hanno bv aangeeft - geboorte- en of sterfdatum niet bekend is/zijn, maar alleen 'floruit'? Geven we (dan) de nationaliteit van het land waarin de persoon het langst heeft geleefd (en beschouwen we de eerste 10 of laatste 10 jaar als 'deprecated' landen van nationaliteit)?''
Aanvulling: misschien is het interessant de discussie verder voort te zetten in de kroeg zodat meer geïnteresseerden mee kunnen lezen? Of als @Hannolans er geen bezwaar tegen heeft: anderen te attenderen op de discussie hier?
Ecritures, Multichill en RonnieV, mijn voorstel zou dan zijn om twee properties te hebben wat volgens mij in lijn is met Multichills idee: een property 'nationaliteit' waarbij we schrijven hoe de erfgoedinstellingen het noemen 'Nederlander/Nederlands', maar ook 'Vlaams/Vlaming', 'Antilliaan' etc, afhankelijk van hoe bronnen zoals de kunstenaar, media of de erfgoedinstelling diegene neerzet, as is. Dit doet recht aan het concept van hoe in de kunst over verschillende nationale scholen gesproken wordt, maar ook als er gesproken wordt in de Tweede Wereldoorlog over nationale oorlogsslachtoffers (Anne Frank wordt gezien als Nederlands oorlogsslachtoffer, maar qua officiele nationaliteit valt zij er niet onder, en ook het hele concept 'Pools' versus 'nazi-Duits', versus 'Duits' kunnen we dan beter aan).
Daarnaast een 'land van nationaliteit' waarin wij via bots een analyse uitvoeren onder welke erkende staat iemand valt als staatsburger, afgaande op de in die tijd bestaande staten. Net zoals een auteursrechtelijke berekening in feite. Voor veel staten geldt bijvoorbeeld dat je als je in een land geboren bent, je die nationaliteit krijgt. Ook zijn er vaak officiele regelingen geweest qua overgang zoals voor Indonesiers. Die wetgeving kunnen we ook aanmaken in WIkidata en daarnaar verwijzen, of verwijzen naar bevolkingsregisters. Ik ben het eens met Ecritures dat dit met bots te doen moet zijn. Volgens mij doen mensen dat momenteel impliciet, wij maken het daardoor expliciet.
I just found another person with possibly 2 QID's: Q1269535 and Q75042280. Do you know if these are the same person?
yes! thanks
Hi there! I just noticed a lot of musical artists started throwing constraint violations for the copyright collectives representing them, did you mean to make that change? I started to correct it, but figured I'd ask in case there was a plan behind it. To sum it up, I use "copyright representative" to link songwriters/composers to copyright collectives like BMI, ASCAP, SGAE, SACEM, STEMRA, etc. and I need to know if this is not considered correct.
Great! That should be the correct use. I changed some of the constraint settings because of constraint violations of the visual artists. Do you have examples of constraint violations?
I added back Q1047437 under value type constraint and the violations disappeared. I realize that juridical person should suffice, but I find that value type constraints aren't always happy with deep subclass nesting?
Anyways, as long as we have the same understanding of what the property should be used for I'm happy 👍 Feel free to alter the constraint to something better, if I see violations pop up again I'll let you know.
Have an excellent Sunday!
ah, yes, constraints seem to overlook subclasses sometimes. Is there an identifier to link to music collective copyright organisations? For musical works we have {{P|P4894}}, {{P|P4860}} and {{P|P1827}}
for works not in ascap/BMI I have tried to "standardize" using Property:P972 "catalog", as in this example: Lo mejor de tu vida
I've established a few of them:
Q50808010 (SGAE), Q51796663 (SACEM), Q52354815 (SADAIC), Q64029229 (SIAE), etc.
...also Q54959446 (GEMA), Q64686643 (BUMA/STEMRA), Q64362152 (SESAC) and probably a few more that I can't remember at the moment
if in the future we get external identfiers for them, converting shouldn't be too hard.
great! would be interesting when one of them are accessible to connect with an external identifier.
Yeah, I would nominate GEMA as a first test-case, the Germans are super organized (surprise, surprise) with really well documented identifiers and clearly defined IPI roles. BUMA/STEMRA on the other end of the spectrum, have no (visible) identifiers and won't even display ISWC. SACEM and SIAE are somewhere in the middle. SGAE is also pretty good,
SACEM seems one that gives us the possibility to give a direct link, this for example is a link to a composition called 'Holiday': https://repertoire.sacem.fr/detail-oeuvre/gBdJ3CQCp1YPqmYHK5Eye02Z3X_A7qM9CEc7cb8YkPY=/HOLIDAY?query=&filters=titles#searchBtn and also with English labels, for example 'Yesterday died'. Too bad I can't remove 'YESTERDAY DIED' from the url.... https://repertoire.sacem.fr/en/work-detail/uoNgnBEHIvAwlRtfystAmu-F_kXtifvMh4RCgTgFLCQ=/YESTERDAY%20DIED?query=&filters=parties#searchBtn GEMA would be perfect if we are able to create links but they use Ajax.
Ah, YESTERDAY DIED is not required, only a random letter is required: https://repertoire.sacem.fr/en/work-detail/uoNgnBEHIvAwlRtfystAmu-F_kXtifvMh4RCgTgFLCQ=/Z?query=&filters=parties#searchBtn that mean we can use uoNgnBEHIvAwlRtfystAmu-F_kXtifvMh4RCgTgFLCQ as an identifier for a work in SACEM. But better if we can create identifiers for artists.
nice discovery! I tried the same some time ago (removing title) and when it didn't work I concluded that only the combo was a valid id. This opens up some possibilities, very cool.
I think the Argentinean one (Q52354815) can be direct-linked/scraped by playing around with the iframe. And maybe Q56576443 (SACEM, mexico) also? It's been a while since I fiddled with it
the holy grail is direct-linking http://iswcnet.cisac.org/ though, I friggin hate that stupid session-timeout stuff they have going on...
both SIAE and SGAE use captcha, so I guess those are a no-go?
Scraping is always possible. But identifiers without sessions are needed to use it as an external idproperty.
are you on Telegram? It's a bit late in the evening now, but maybe we could continue this conversation over there? Would be cool if we could develop this into something more concrete, I'm always game for improving music on WD and copyright collectives are absolute key to that work.
not very active, but you should find me under my name.
SADAIC is available with identifiers:
by SADAIC-identifier: https://www.sadaic.org.ar/obras.query.php?titulo=&autor=&tipo=abierta&iswc=&nro_obra=418152
by ISWC-code: https://www.sadaic.org.ar/obras.query.php?titulo=&autor=&tipo=abierta&iswc=T0373391811&nro_obra=
SADAIC-code seems to give the copyright partition https://www.sadaic.org.ar/obras.repartos.php?nro_obra=418152
And they have identifiers and links to authors! https://www.sadaic.org.ar/obras.autor.php?codigo=9803
pretty sweet :-) We could maybe make a concerted effort to update WD composition items with publishers also, that's hardly being done by anyone. I've done a few but it's kinda of a pain since 99.99% of the music publishing companies aren't in WD and have to be created.
Hi! I reverted your change to Otto Frank (Q7336) because you seemed to be using copyright representative (P6275) to record information about copyright status, which might be better represented using copyright status (P6216). I see you have done the same elsewhere. Cheers!
I have undone the batch.
What are you doing? Why without any discussion?
Why cheers?
Hi! Thanks for responding. Your opportunity to discuss was in the three days since I started this thread, to which you did not respond until just now. My reasons are as explained above.
discussion? you just said 'cheers', no question at all. we can't use P6216 that is for works and was discussed in that proposal.
You may be right that heat treating (P6212) is inappropriate, but unfortunately that doesn't make copyright representative (P6275) appropriate.
I don't understand what heat treating has to do with copyright representation. For many artists it is very helpful to know that they are represented by someone or that their rights are expired. Probably we should have a new property for that?
Oops, that should have been copyright status (P6216) not heat treating (P6212). My bad.
That does sound like useful information to provide. We could propose a new property, or propose an extension of P6212. I note that there is some discussion in the proposal for P6212 of the difficulty of handling the variance between different jurisdictions, which also seems likely to be a concern with applying it to people.
We will have a group of artists whose oeuvre is public domain worldwide (>100 pma, or floruit>200 years) and a group of artists that is certainly protected (<50 years pma or floruit < 50 years ago). In between we can apply the qualifier 'jurisdiction'. I will propose a new property.
OK. Feel free to ping me when the property proposal is ready for discussion.
@Bovlb I have added a proposal: Wikidata:Property proposal/Copyright status of author