Difference between revisions of "FactGrid talk:Directory of Properties"

From FactGrid
Jump to: navigation, search
(New Property: Collegiate church)
m (New Property: Collegiate church)
Line 63: Line 63:
 
As collegiate churches do not belong to the property monastery it would be useful to have this property for all organisations that are non-monastic communites of clergy, organised as a self-governing corporate body, which may be presided over by a dean or provost.
 
As collegiate churches do not belong to the property monastery it would be useful to have this property for all organisations that are non-monastic communites of clergy, organised as a self-governing corporate body, which may be presided over by a dean or provost.
 
[[User:Barbara Kröger|Barbara Kröger]] ([[User talk:Barbara Kröger|talk]]) 17:04, 11 May 2020 (CEST)
 
[[User:Barbara Kröger|Barbara Kröger]] ([[User talk:Barbara Kröger|talk]]) 17:04, 11 May 2020 (CEST)
-- monastery is not a property but an item (Q141472. You can create a new item for a non-monastic community of clergy, with a statement P3 (subclass of) and Q141464 (religious organization) --[[User:Bruno Belhoste|Bruno Belhoste]] ([[User talk:Bruno Belhoste|talk]]) 18:32, 11 May 2020 (CEST)
+
 
 +
-- monastery is not a property but an item (Q141472). You can create a new item for a non-monastic community of clergy, with a statement P3 (subclass of) and Q141464 (religious organization) --[[User:Bruno Belhoste|Bruno Belhoste]] ([[User talk:Bruno Belhoste|talk]]) 18:32, 11 May 2020 (CEST)

Revision as of 18:33, 11 May 2020

Welcome on the page for Property proposals and debates

New Properties should be discussed and made public on this page. We have to make sure that they are well connected (with P8 statements as given in brackets in the FactGrid:Directory of Properties), so that others will begin to use them as well. As a general guideline FactGrid should welcome experiments. We are a platform for research and we should encourage new questions and new solutions to problems (which will not save us from the dilemma that we will always be able to make a statement in more than one way - and in the bad case without being able to run interesting searches on this statement in the end). --Olaf Simons (talk) 13:52, 17 December 2019 (CET)

Nobilitierung

Olaf, wo Du gerade bei Martens warst, mE fehlt wohl die persönliche "Auszeichnung" durch "Nobiltierung", die in der Konsequenz oft eine mit Datum festzumachende "Namensänderung" beinhaltet, wobei die Verleihung wie "Reichsadel" oder "frz." bzw "dän." vllt gleich berücksichtigt werden sollte. Hinzu kämen perspektivisch, wenn auch nicht für Martens die upgrades --> Freiherr oder --> Graf. Sollte aber mE flach und einfach gehalten werden...--Martin Gollasch (talk) 11:36, 27 December 2019 (CET)

Ist eigentlich alles da, nur von uns noch nicht konsistenter genutzt Die Properties zu Namen und Titeln. Wir sollten wohl noch eine Property einrichten für den, der den Titel verleiht, und dann eine Musterperson machen, bei den wir mit Qualifikatoren die Details nennen.
Dieselbe Abfrage auf Deutsch. P26.
Und eine für den Qualifier, wer den Titel verlieh, habe ich aufgemacht.
Mir fehlt irgendwie das "Ereignis" der Nobilitierung als Auszeichnung und Namensänderung wie Ordensverleihung (ging ja manchmal hand in hand...)--Martin Gollasch (talk) 15:00, 27 December 2019 (CET)
Hm, das ist natürlich die edelste Option: Ein Ereignis aufmachen, weil man es dann dokumentieren kann, es datieren kann, es mit Personen ausstatten kann. Wie finden solche Ereignisse statt? Wenn man einfach nur den Adelsbrief zugestellt erhält, dann ist es besser (verlorene) Dokumente aufzumachen (mit Sender, Empfänger...). Wenn es aber echte Ereignisse sind, bei denen Leute an Orten aufeinander treffen, dann sollten wir das machen. (Die Frage ist immer: auf welche Suche soll man das finden? Welche Frage möchtest Du an die Datenbank stellen, bei der das dann in einer Tabelle oder auf einem Zeitstrahl auftaucht? --Olaf Simons (talk) 17:25, 27 December 2019 (CET)
Eine Datenbank, bei der man die Fragen vorher kennen muss, ist langweilig... Wir wissen nicht, welche Fragen sich in Zukunft stellen. Und wenn es irgendwo eines Tages klemmt, muss ein Bot die Daten später so umgliedern, das es für die neue Frage passt. Derzeit sind wir ganz am Anfang. Da muss doch Property:Nobilitierung mit Item:Reichsadel und Datum:Jahr erstmal genügen.--Martin Gollasch (talk) 17:44, 27 December 2019 (CET)
Also für die Nobilitierung würde ich in diesem Fall das P26 statement nehemen (<--P26 bezieht sich auf ererbte Titel (dafür kann kein Betroffener etwas, das ist so, per Geburt), hier geht es um die Auszeichnung als Verdienst der Person...). Du baust dazu den Titel, der verliehen wird und setzt mit P49 den Startzeitpunkt und mit der neuen P393 den Verleiher. Eine Reichsnobilitierung als Q-Nummer ist ok. Bei der Ordensverleihung wüürdest Du doch wohl auch nur eine P-Nummer für alle möglichen Orden aufmachen und dann für jeden denkbare Orden ein Q. --Olaf Simons (talk) 18:21, 27 December 2019 (CET)
Du verstehst mich gerade nicht:Bei einfach "von" haben wir keinen Titel, es ist eine Nobiltierung: einfach "von". Also kann ich auch keinen Titel wie Baron, Freiherr, Graf etc dazu zusetzen...--Martin Gollasch (talk) 19:55, 27 December 2019 (CET)

Hm. Dann lass uns trotzdem nochmal gründlich über das beste Modell nachdenken.

  • Mir hat bereits jetzt nie sonderlich gut gefallen, dass wir so etwas wie "von Goethe" als Namen führen. "Goethe" wäre für das Alphabet besser und könnten wir dann eingehender mit einer zu bauenden Property die Namnspräfixe sowie mit suffix to family name (P74) die Namenssuffixe nennen und erklären - etwa ob ein "von" ein Adelsprädikat ist, ob es erblich war, oder ob es nur einen Ortsbezug herstellte - all das könnten wir mit Qualifikatoren zu den Namensinformationen hinzugeben. Dann hätten wir die Namen besser auseinandergenommen.
  • Wenn es um die Ehrung der Noblitierung geht, bin ich geneigt public awards and titles (P171) dahingehend zu öffnen, dass ich verschiedene Qs der Noblitierung zulassen kann. Persönliche im Reich, erbliche und so fort. Da kann man dann auch Qs bauen wie Erhebung in den Fürstenstand und so fort.
  • Vielleicht auch sollten wir die Adelsnamen mit dem von belassen, aber ich stelle automatisch die von-Titel nach, so dass die Alphabete stimmen.

Wenn ich eine Property Nobilitierung aufmache, weiß ich noch immer nicht, was dann die Qs dazu sein sollen. --Olaf Simons (talk) 21:39, 27 December 2019 (CET)

Erstmal nur Datum (im Zweifel Jahr) ggfls mit Quelle und Lit.--Martin Gollasch (talk) 22:21, 27 December 2019 (CET)

Nur mal so gedacht Johann Wolfgang von Goethe (Q409) - es scheint mir logischer als eine Datums-P aufzumachen. Habe aber auch nichts dagegen, wenn Du sagst dass das besser wäre... --Olaf Simons (talk) 23:41, 27 December 2019 (CET)

Property für das Datum der Nobilitierung date of ennoblement (P394)

Bin gespannt wie sich die Property verbreitet und neugierig. --Olaf Simons (talk) 09:29, 28 December 2019 (CET)

örtliche Zuständigkeit (P450)

Ich möchte die Eigenschaft "gehört zum Zuständigkeitsbereich" vorschlagen. Hier finden Sie dieselbe Wikidata-Eigenschaft. Ich möchte zum Beispiel solche Sätze erstellen:

Das Statistische Bundesamt gehört zum Zuständigkeitsbereich Deutschland

Aber ich darf momentan keine geographischen oder politischen Entitäten als Objekt wählen.

--Francesco Gelati (talk) 12:14, 4 March 2020 (CET)

Juristen unterscheiden in sachliche und örtliche Zuständigkeit. Insofern würde ich eine präzisere Anlehnung an das Gesetz mit Angabe der Zuständigkeitsnorm bevorzugen. Bei zeitlichen --Martin Gollasch (talk) 13:04, 4 March 2020 (CET)

Danke für die hilfreiche Nachricht! Gerne können wir die zwei Eigenschaften 1) sachliche und 2) örtliche Zuständigkeit erstellen. Der Zeitraum der Zuständigkeit kann dann als "qualifier" ausgedrückt werden. --Francesco Gelati (talk) 13:23, 4 March 2020 (CET)

Die bestehen bereits: örtliche Zuständigkeit (P450) und sachliche Zuständigkeit (P451) --Francesco Gelati (talk) 15:33, 4 March 2020 (CET)

Nach edit-Konflikt'

Für die örtliche Zuständigkeit bestand bereits regional coverage (P429) - ich sehe aber zudem exakt das Problem das Martin sieht, wir brauchen etwas Sinnvolles für die sachliche Zuständigkeit. Ich denke dabei brauchen wir reziproke Optionen. Beides lege ich an als field of responsibility (P452) "Zuständigkeitsbereich" und under the responsibility of (P453) "im Zuständigkeitsbereich von". Martin mag gerne legale Definitionen beifügen, das geht mit definition (P423). --Olaf Simons (talk) 15:40, 4 March 2020 (CET)
Das war jetzt etwas schnell und brachte uns zwei Dubletten. Wobei meine Anlagen diejenigen sind, die in den Registern auftauchen. Lasst uns vorher kurz beraten, ob nicht schon dergleichen im System ist und ob's auch wirklich zuende gedacht ist. --Olaf Simons (talk) 15:43, 4 March 2020 (CET)

Genau, ich entschuldige mich dafür. --Francesco Gelati (talk) 17:29, 4 March 2020 (CET)

divorce

What is the best way to give information about a divorce? A proposition would be to create a qualifier "date of divorce" to P84 (married with), but it has the inconvenient to duplicate the information contained in the qualifier P50. Does anyone have a better idea? Bruno Belhoste (talk) 11:19, 2 May 2020 (CEST)

My legal understanding ist, that a marriage ends legally by death or divorce. There are some further ways to get out especially considering church law, but theses are the two main reasons. So, the end is the end, by one or the other reason. And "divorce" is just an explanation, like cause of death... We don't mix there either...--Martin Gollasch (talk) 12:41, 2 May 2020 (CEST)
What about qualifying it with in the course of (P464) and divorce (Q153391) which I just created. If you want to refer to a specific divorce process you might also create it. --Olaf Simons (talk) 12:57, 2 May 2020 (CEST)
The thing will have to be a qualifier since it will usually happen on several marriage candidates. --Olaf Simons (talk) 13:03, 2 May 2020 (CEST)
Then you should create the Annulment under Canon Law aswell. Thats something we like to forget in the protestant North.--Martin Gollasch (talk) 13:52, 2 May 2020 (CEST)

New Property: Collegiate church

As collegiate churches do not belong to the property monastery it would be useful to have this property for all organisations that are non-monastic communites of clergy, organised as a self-governing corporate body, which may be presided over by a dean or provost. Barbara Kröger (talk) 17:04, 11 May 2020 (CEST)

-- monastery is not a property but an item (Q141472). You can create a new item for a non-monastic community of clergy, with a statement P3 (subclass of) and Q141464 (religious organization) --Bruno Belhoste (talk) 18:32, 11 May 2020 (CEST)