Wikidata:Property proposal/Hijri Date
Hijri Date
[edit]Originally proposed at Wikidata:Property proposal/Generic
Description | Hijri Date of claim as written in the source |
---|---|
Data type | String |
Domain | All time claims may take this qualifier |
Allowed values | [\-]?[1-9][0-9]*(\-[0-1][0-9](\-[0-3][0-9])?)? |
Example 1 | Muhammad (Q9458) -> date of death (P570) -> "632-06-08" -> qualifier(Hijri date) -> "11-03-12" |
Example 2 | Avicenna (Q8011)-> date of death (P570) -> "1037" -> qualifier(Hijri date) -> "428-09" only year and month in original source |
Example 3 | Battle of Badr (Q486124) -> point in time (P585) -> "624-03-12" julian -> qualifier(Hijri date) -> "2-09-17" |
Source | w:Islamic calendar |
Planned use | All the dates that were mentioned in the sources as a Hijri date must have this qualifier |
التحفيز
[edit]There is no way to enter the Hijri date in Wikidata. Some users use refine date (P4241) qualifier and value elements are part of (P361) of Islamic calendar (Q28892), but this not the purpose of refine date (P4241) and reported as violations in Wikidata:Database reports/Constraint violations/P4241
This new property will resolve this problem.
This property will be a qualifier property for any time data claim.
The value may be only year (Y), (year and month (Y-MM)) or (year, month and day(Y-MM-DD)) no time allowed. the format of the value will be like ISO 8601 format with some differs:
- No zero year, the year before 1 is -1.
- No leading zero required for year.
Using string value make it easy to retrieve data and reformat it. --حبيشان (talk) 08:37, 10 December 2023 (UTC)
Discussion
[edit]- Support.-القلموني (talk) 11:16, 10 December 2023 (UTC)
- Strong support Indeed, a nesesry proprty for Isllamic heritage and civilzation Materials. @MartinPoulter: I think this is interesting for you :).--Michel Bakni (talk) 11:26, 10 December 2023 (UTC)
- Strong support X7md (talk) 11:43, 10 December 2023 (UTC)
- Strong oppose @حبيشان: there is a real lack but this is a very wrong solution to solve it, time should have the datatype "Point in time" not string. Cheers, VIGNERON (talk) 14:34, 10 December 2023 (UTC)
- @VIGNERON datatype "Point in time" does not support Hijri Calendar see Help:Data_type#time. Do you want us to store Hijri Dates as Gregoirian dates? حبيشان (talk) 14:56, 10 December 2023 (UTC)
- @حبيشان: this is indeed a big problem but Gregorian is still way less worse than storing time as string (plus in this proposal, Hijri Dates are still stored as Gregorian dates, which is also wrong and bad). Cheers, VIGNERON (talk) 15:01, 10 December 2023 (UTC)
- @VIGNERON the claim value will take the corresponding Gregorian Date of the Hijri date and this Gregorian Date is approximate because many of Hijri Dates relies of crescent sighting and some of them relying in calculated algorithm we have many of them (see w:Tabular_Islamic_calendar).
- Why storing Gregorian with Hijri in same claim value? because many of wikidata clients have not algorithms to view the Hijri date in understandable format so what bad of this. you may suggest to set claim value to "some-value" and the Hijri Date qualifier will give the value in Hijri Calendar.
- For storing time value in string: for current wikidata datatypes we have not better from storing Hijri Date as string, If you have better solution please inform us. also WikiData stores "point in time" in the database as string not numeric. حبيشان (talk) 15:38, 10 December 2023 (UTC)
- The better solution (and the only right one in my mind) is to add support for others calendar into the datatype. Cheers, VIGNERON (talk) 15:57, 10 December 2023 (UTC)
- @VIGNERON I am ready for Adding support of Hijri Calendar to "Point in time" datatype I have past experence in adding Hijri Calendar support to PHP Applications:
- I developed a PHP lib
- Added Hijri to phpBB forums
- Added Hijri to WordPress
- Added Hijri to PostgreSQL 12 DB by C extension (closed source)
- Added Hijri to Lua
- Just give us the approval and I will work with. Other than that we have no better solution than the above proposal. حبيشان (talk) 17:32, 10 December 2023 (UTC)
- If you have dev experience, feel free to develop it ; if it works, I guess it will probably be implemented, ping @Lydia Pintscher (WMDE): who could tell us more. You could also create or comment on phabricator task, like phab:T206973. Cheers, VIGNERON (talk) 09:46, 11 December 2023 (UTC)
- @VIGNERON I am ready for Adding support of Hijri Calendar to "Point in time" datatype I have past experence in adding Hijri Calendar support to PHP Applications:
- The better solution (and the only right one in my mind) is to add support for others calendar into the datatype. Cheers, VIGNERON (talk) 15:57, 10 December 2023 (UTC)
- @حبيشان: this is indeed a big problem but Gregorian is still way less worse than storing time as string (plus in this proposal, Hijri Dates are still stored as Gregorian dates, which is also wrong and bad). Cheers, VIGNERON (talk) 15:01, 10 December 2023 (UTC)
- @VIGNERON datatype "Point in time" does not support Hijri Calendar see Help:Data_type#time. Do you want us to store Hijri Dates as Gregoirian dates? حبيشان (talk) 14:56, 10 December 2023 (UTC)
- Oppose It should be specified which Hijri calendar will be added as a value, given the lack of a universal Hijri calendar, since it historically depended almost entirely on sighting the new moon, which was different geographically, and even from community to another. If it's a calendar based on astronomical calculations, could it not be calculated from the Gregorian calendar? In which case, a simple conversion option could be added. If not, there is risk that multiple values will be entered, and there will likely always be an uncertainty of a few days as to the exact date.--Ideophagous (talk) 21:22, 10 December 2023 (UTC)
- @Ideophagous Multiple values is not a RISK most of properties accept multiple values.
- Islamic history events that were recorded in their references exclusively in the Hijri date How do you think you can enter their date data in Wikidata, do you have a solution.
- You refuse to enter the Hijri date on the pretext that it did not indicate the type of Hijri Calendar entered, while you accept the registration of historical facts with a Gregorian date while it recorded in the references with a Hijri date without mentioning the method of converting the Hijri date to Gregorian!!
- It is safer to record the Hijri date as stated in the reference without any modification, and then leave it to the user to choose the appropriate conversion method.
- حبيشان (talk) 04:47, 11 December 2023 (UTC)
- Hello @حبيشان. Maybe the property then should be called "Sourced Hijri Date" or Hijri Date in Source" or such, and the addition of a source has to be mandatory, because I'm sure some editors will simply start converting from Gregorian to Hijri without adding a source. Ideophagous (talk) 08:01, 11 December 2023 (UTC)
- @Ideophagous: dates always have a part of uncertainty and fuzzyness, even inside one "universal" calendar. There is nothing we can do about it, it works mostly well for Julian and Gregorian calendars, I don't see why it wouldn't work for Hijri. It could be a parameter in the datatype and if not, ranks, context and qualifiers could always be used to understand the date. That point is not a problem here. Cheers, VIGNERON (talk) 09:46, 11 December 2023 (UTC)
- @Ideophagous Customize the date under (add qualifier) and include the Hijri date feature, and it is preferable for the user to include a reference to it. Mohammed Qays (talk) 11:02, 11 December 2023 (UTC)
- Hello @حبيشان. For a date, multiple values is a necessary evil, not a desirable feature. Uncertainty about an exact date may exist, but in the case of the Hijri Calendar it takes a whole new proportion. 12 Dhu Al Hijja 523 in Arabia is not necessarily 12 Dhu Al Hijja 523 in Morocco. If two events are dated to that day, but happened in different places, how can we know if they happened on the same day or not? Conversely if two events at different locations have different Hijri dates on Wikidata, how do we know they didn't happen on the same day, or how many days exactly separate them? Anyways, if you add the condition that the user will at least see a warning if they don't add a source (without exception), I will switch my vote to a weak support. Ideophagous (talk) 22:58, 11 December 2023 (UTC)
- @Ideophagous If the source mentions the day of the week (as most of hostrical sources). day of week (P2894) can be added and it will give a clear point of time and exact confersion to other calendars. Adding warnig for missing the source is good but with exception of publication date (P577) because it will circular citation. حبيشان (talk) 06:06, 16 December 2023 (UTC)
- Hello @حبيشان. Maybe the property then should be called "Sourced Hijri Date" or Hijri Date in Source" or such, and the addition of a source has to be mandatory, because I'm sure some editors will simply start converting from Gregorian to Hijri without adding a source. Ideophagous (talk) 08:01, 11 December 2023 (UTC)
- @Ideophagous Multiple values is not a RISK most of properties accept multiple values.
- Support The Hijri date is one of the important dates for Arab and Islamic societies, and there are events, births and deaths recorded in it. It is very important to us as an Arab and Muslim society. Mohammed Qays (talk) 10:32, 11 December 2023 (UTC)
- Strong support. It's a very important property for Islamic Articles. And our friend حبيشان has the technical experience to help in any technical support needed for this addition.--Dr-Taher (talk) 19:54, 11 December 2023 (UTC)
- Strong support.--RASHEEDYE (talk) 21:20, 11 December 2023 (UTC)
- Strong support عبدالعزيز علي (talk) 10:22, 12 December 2023 (UTC)
- Strong support أيمن 1974 (talk) 18:30, 14 December 2023 (UTC)
- per above Germartin1 (talk) 13:37, 18 December 2023 (UTC)
- Strong support, Hijri calender is very important. Islamic scholars and societies have written down their hisotry, events and other records by using it. Thus we can enrich wikidata by enormous knowledge if we add this property. Ahmed Naji Talk 11:21, 13 February 2024 (UTC)
- Strong oppose Storing dates as strings is not structured data. I think refine date (P4241) is the right property for this until there is proper support for more calendars. It is a common and valid use of the qualifier, the constraint violations report is wrong. If you look at the item page or Special:ConstraintReport instead, it isn't shown as a constraint violation. - Nikki (talk) 15:13, 1 March 2024 (UTC)
- @Nikki @Germartin1 @VIGNERON @Ideophagous We can change datatype to item. حبيشان (talk) 08:41, 2 March 2024 (UTC)
- Conditional support when phab:T206973 is implemented - it's clearly important data but neither string data type or point in time are currently acceptable for this. --Lewis Hulbert (talk) 18:55, 22 March 2024 (UTC)
- Not done, no consensus of proposed property at this time based on the above discussion. حبيشان, I would suggest you create a new proposal if/when phab:T206973 implemented. Regards, ZI Jony (Talk) 07:41, 27 May 2024 (UTC)