[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[VladimirAlexiev]

[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[GreenReaper]

GreenReaper added a comment.


  In T207705#8091791 , 
@Jheald wrote:
  
  > I believe an exception should be made for a pair of functions to return as 
an `xsd:dateTime` the minimum and the maximum date that a given `edtf:EDTF` 
value could represent (similar to equivalent functionality found in edtf.js 
,and I think also a number of other edtf 
implementations).  This would allow the results of a query outputting an  
`edtf:EDTF` value to be easily ORDERed, by the earliest possible date, or the 
latest possible date, or perhaps the midpoint of the two...
  
  I'd light to highlight this particular function as I also believe it to be 
useful. There was discussion in the extension itself about adding an xsd:date 
for the start and/or end of an interval, but others felt that this would not be 
correct as it is not **actually** a point in time. Still, it would be very 
useful for things like event schedules  (I am not sure that middle would be 
suitable, since it is not a time specified by the interval at all, but others 
might disagree; perhaps it could be achieved easily by adding both together and 
dividing by two).

TASK DETAIL
  https://phabricator.wikimedia.org/T207705

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: GreenReaper
Cc: ChristianKl, Jheald, Moebeus, Epidosis, SilentSpike, So9q, Lectrician1, 
GreenReaper, Spinster, mxn, Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, 
Liuxinyu970226, Pigsonthewing, Aklapper, Astuthiodit_1, karapayneWMDE, 
Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[ChristianKl]

ChristianKl added a comment.


  RE:request for feedback on #3:
  
  I would want that in the typical case the user interface shows the EDTF value 
and that it's easy to enter dates in that format. In most cases, a user should 
just be able to input dates without worrying about qualifiers. The user should 
not have to worry about Wikidata having its own time system that differs from 
the ISO-supported EDTF.
  
  As far as what happens on the backend, I can see that it might make sense 
sometimes to store two values. If we for example have dates in the Julian 
calendar storing that date both in the Julian calendar and also in Gregorian 
EDTF would make it easier to sort dates while still being able to display the 
Julian date.
  
  I believe that the longer Wikidata doesn't fix this issue the more times 
people will make errors when entering dates because they are not thinking about 
the conversion between how Wikidata's idea of time differs from the ISO 
standard.

TASK DETAIL
  https://phabricator.wikimedia.org/T207705

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ChristianKl
Cc: ChristianKl, Jheald, Moebeus, Epidosis, SilentSpike, So9q, Lectrician1, 
GreenReaper, Spinster, mxn, Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, 
Liuxinyu970226, Pigsonthewing, Aklapper, Astuthiodit_1, karapayneWMDE, 
Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[Jheald]

Jheald added a comment.


  As noted by @GreenReaper above, the Wikibase_EDTF 
 wikibase extension 
should now give a solid basis for building EDTF support on wikibase, allowing 
EDTF strings to be input, validated, and rendered by the wikibase GUI, if we 
want to add properties with an EDTF datatype to Wikibase.
  
  A separate but related issue is what adaptations could or should be made to 
WDQS to support EDTF. (And could this help with issue T159160 
 "Take account of date precision 
when displaying dates in WDQS GUI").
  Here are some possible steps towards adding EDTF awareness to WDQS:
  
  1. Extend the GUI output code to recognise objects with rdf type 
`^^http://id.loc.gov/datatypes/edtf/EDTF` (equivalent to `^^edtf:EDTF` for 
short) as representing EDTF dates, and display columns of them in the output in 
an appropriately readble way for human consumption ("humanization").   Some of 
the internationalisation developed for the Commons Other date 
 template and 
underlying Complex date 
 Lua module,  the 
Wikibase EDTF  project, 
or other EDTF implementations 
 may help with 
translations.  The standard defines different levels of EDTF compliance; it 
might be reasonable initially to support only a subset of the standard 
initially.  Functionality could be tested by building suitable strings in 
SPARQL queries, using the `strdt()` function to cast them to type `edtf:EDTF`.
  
  2. Once it is possible for the GUI to interpret and display EDTF dates, add 
triples to the SPARQL triplestore and the RDF dump with new prefixes (perhaps 
`wdtn:` and `psn:`) to give EDTF-valued dates, so `wd:Q692 wdtn:P569 
[1564-04..1564-04-26]^^edtf:EDTF`.  The ability to use these forms in queries 
should substantially address the T159160 
 problem, without affecting existing 
queries.
  
  3. The new triples should not replace the existing `wdt:` and `ps:` triples, 
nor existing `psv:` triples with their `wikibase:time`valued nodes, but exist 
alongside them.
  
The EDTF format, even if normalised through eg the edtf.js 

 javascript package used by Zotero, IMO contains too many ways to express 
more-or-less the same thing, which counts against efficient indexing or 
retrieval.  Its ability to represent complex and approximate dates does not 
lend itself to the kind of range-safe fast indexing 

 that can be used to retrieve exact dates (represented internally by Blazegraph 
as exact microseconds since a particular moment).  Similarly, if one wants to 
find dates with a year-precision or a month-precision, the existing 
`wikibase:time`valued nodes express that information directly as RDF statements 
which are all indexed, whereas to extract corresponding EDTF statements would 
require much slower assembling of the whole dataset then filtering with string 
operations and/or regexes.  Even edtf shops are trying to find good ways to 
model the format in RDF  (example ). 
Given that we already now have a quite developed model for complex dates as 
statements, IMO it would not make sense to give it up (contra @Spinster?). Also 
I suspect there are area where it achieves more nuance and exactness than the 
current version of EDTF.
  
Instead I would suggest that we keep the existing data model on wikidata as 
the primary way of representing complex dates.  I would suggest that the only 
EDTF valued-property we should would be a single `EDTF date stated as`.  Input 
should be allowed eg of the form `P571 inception = //somevalue//, qualifier: 
EDTF date stated as = ...`  Bots should then translate this into wikidata dates 
and qualifiers, moving the `EDTF date stated as = ...` qualifier to the 
reference when this is done. EDTF-valued `wdtn:` and `psn:` triples should be 
constructed from the wikidata statement and its qualifiers, to be accessible 
via SPARQL, LDF, rdf dumps, or an API request.  This would allow data to be 
edited and round-tripped back to institutions, and input to be compared with 
output, while maintaining a single preferred unified model in wikidata for 
representing complex dates.
  
  4. At the present time, with our use of Blazegraph perhaps approaching 
end-of-life, an aversion to implementing new services or functions specific to 
that platform is understandable.  However I believe an exception should be made 
for a pair of functions to return as an `xsd:dateTime` the minimum and the 
maximum date that a 

[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[Jheald]

Jheald added a project: Wikidata data quality and trust.

TASK DETAIL
  https://phabricator.wikimedia.org/T207705

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jheald
Cc: Jheald, Moebeus, Epidosis, SilentSpike, So9q, Lectrician1, GreenReaper, 
Spinster, mxn, Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, Liuxinyu970226, 
Pigsonthewing, Aklapper, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, 
ItamarWMDE, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, 
LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[GreenReaper]

GreenReaper added a comment.


  From what I can see with a cursory search, the IETF seem happy to declare 
extensions to the standard 
 
rather than seeking to replace it. Time in a general sense is not their focus; 
timestamps for Internet protocols (which do not need to express the same 
vagaries as EDTF) and methods of setting time over a network are.
  
  Regardless, the focus of this issue is to implement a //specific// format, 
which is both of interest to some institutions, and also offers features not 
available in the existing datatype.
  
  There is a reasonable concern that not everyone will be able to contribute 
fully to development - I had my own problems when filing issues - but it 
probably does not pose the same issues as, say, integrating a proprietary 
database engine.
  
  As a practical matter, I suspect those who care the most about correctness 
with respect to the more obscure parts of the standard are the most likely to 
have a copy of it, or resources to fund access to it.

TASK DETAIL
  https://phabricator.wikimedia.org/T207705

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: GreenReaper
Cc: Moebeus, Epidosis, SilentSpike, So9q, Lectrician1, GreenReaper, Spinster, 
mxn, Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, Liuxinyu970226, Pigsonthewing, 
Aklapper, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[Pigsonthewing]

Pigsonthewing added a comment.


  In T207705#7704257 , 
@Jc3s5h wrote:
  
  > 
  
  
  
  > I oppose ISO 8601
  
  Your proposed alternative is..?

TASK DETAIL
  https://phabricator.wikimedia.org/T207705

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Pigsonthewing
Cc: Moebeus, Epidosis, SilentSpike, So9q, Lectrician1, GreenReaper, Spinster, 
mxn, Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, Liuxinyu970226, Pigsonthewing, 
Aklapper, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[Epidosis]

Epidosis added a comment.


  The task above could be updated: ISO 8601-2:2019 effectively supported EDTF 
(https://en.wikipedia.org/wiki/ISO_8601).

TASK DETAIL
  https://phabricator.wikimedia.org/T207705

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Epidosis
Cc: Epidosis, SilentSpike, So9q, Lectrician1, GreenReaper, Spinster, mxn, 
Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, Liuxinyu970226, Pigsonthewing, 
Aklapper, Invadibot, maantietaja, Akuckartz, Nandana, Lahi, Gq86, 
GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, 
Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[GreenReaper]

GreenReaper added a comment.


  A largely complete PHP library  
(limitations as specified) and Wikibase data type 
 (MediaWiki extension 
), initially funded by 
the Luxembourg Ministry of Culture, is now available 
.
  
  I've been trying it out on WBStack . Alas, the spec only 
includes dates for intervals, not times; and there are issues to address (e.g. 
large ranges) - but overall it looks promising.

TASK DETAIL
  https://phabricator.wikimedia.org/T207705

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: GreenReaper
Cc: GreenReaper, Spinster, mxn, Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, 
Liuxinyu970226, Pigsonthewing, Aklapper, Invadibot, maantietaja, Akuckartz, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] T207705: Implement the Extended Date/Time Format Specification

[Spinster]

Spinster added a comment.


  I accidentally bumped upon this, wasn't aware this was proposed. Although I'm 
one of Wikidata's greatest fans, I've always found its current date/time system 
very limited, especially when it comes to modeling intervals and uncertainties 
in an easily machine-readable way. The current 'solution' with qualifiers is, 
IMO, less than ideal.
  
  This proposal looks like a really good step in the right direction. Although 
I definitely see how updating the massive amounts of date/time data already in 
Wikidata to a newer and more refined format will be a PITA, I think it's a 
better solution for the long run.

TASK DETAIL
  https://phabricator.wikimedia.org/T207705

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Spinster
Cc: Spinster, mxn, Lydia_Pintscher, Marsupium, Jc3s5h, Mvolz, Liuxinyu970226, 
Pigsonthewing, Aklapper, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, 
QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, 
Mbch331
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs