Smalyshev added a comment.
I think as it concerns Blazegraph and RDF, everything that needed to be done is
done. We support XSD 1.1 now. So I am removing the Wikidata Query parts from it.
TASK DETAIL
https://phabricator.wikimedia.org/T94064
EMAIL PREFERENCES
Jc3s5h added a comment.
In https://phabricator.wikimedia.org/T94064#1296543, @daniel wrote:
@mkroetzsch precise dates for prehistoric times may be useful for
astronomical events. These could/should use a different calendar model
though, such as https://en.wikipedia.org/wiki/Julian_day
daniel added a comment.
@mkroetzsch precise dates for prehistoric times may be useful for astronomical
events. Thouthe could/should use a different calendar model though, such as
https://en.wikipedia.org/wiki/Julian_day (Q14267)
TASK DETAIL
https://phabricator.wikimedia.org/T94064
EMAIL
mkroetzsch added a comment.
@Jc3s5h You are right that date conversion only makes sense in a certain range.
I think the software should disallow day-precision dates in prehistoric eras
(certainly everything before -1). There are no records that could possibly
justify this precision, and
mkroetzsch added a comment.
@Smalyshev You comment on my Item 1 by referring to BlazeGraph and Virtuoso.
However, my Item 1 is about reading Wikidata, not about exporting to RDF. Your
concerns about BlazeGraph compatibility are addressed by my item 2. I hope this
clarifies this part.
As for
Smalyshev added a comment.
Dates without years should not be allowed by the time datatype
That's fine but they are already there, so I'm not sure how we can say should
not be allowed there. We have to do something when we encounter them. What is
something?
The additional proposal to revert
mkroetzsch added a comment.
@Smalyshev
Re halting the work on the query engine/produce code now: The WDTK RDF
exports are generated based on the original specification. There is no
technical issue with this and it does not block development to do just this.
The reason we are in a blocker
Lydia_Pintscher added a comment.
Is there any issue with for now just not including those dates in the RDF
export? That'd allow @smalyseh to continue working on queries while we figure
out the rest. It also shouldn't block us in whichever way we go forward later.
And I agree that using year 0
mkroetzsch added a comment.
@mkroetzsch I already listed a few of the tools that implement XSD 1.0 style
BCE years and I read your answer as to say that you know of no tools that
implement XSD 1.1 style BCE years.
Then you misread my answer. Almost all tools that exist today use the 2000
JanZerebecki added a comment.
@mkroetzsch I already listed a few of the tools that implement XSD 1.0 style
BCE years and I read your answer as to say that you know of no tools that
implement XSD 1.1 style BCE years.
TASK DETAIL
https://phabricator.wikimedia.org/T94064
REPLY HANDLER ACTIONS
Lydia_Pintscher added a comment.
It is the only way I see forward right now that will let you continue working
on queries quickly. (Anything else needs considerably more
discussion/investigation as this ticket shows) And I consider it acceptable in
this case. How many cases are we talking
Smalyshev added a comment.
The WDTK RDF exports are generated based on the original specification. There
is no technical issue with this and it does not block development to do just
this.
If by original specification you mean assumption all data is proleptic
Gregorian, then it does not
Smalyshev added a comment.
@Lydia_Pintscher this means for the dump there will be no difference between
has property value with date containing year 0 and has no property valye.
I'm not sure it is a good idea. Having no property value is meaningful (e.g.
having position start/end date, having
Lydia_Pintscher added a comment.
Yes I am proposing to drop dates that have year set to 0 for now from the RDF
export. We can communicate that and need to do this anyway as it is really bad
practice.
TASK DETAIL
https://phabricator.wikimedia.org/T94064
REPLY HANDLER ACTIONS
Reply to
Smalyshev added a comment.
I'm not sure why it is the only way. Certainly using Somevalue or string or any
other placeholder value are ways too. They can be worse ways if you see
arguments against them but why they are not ways at all? Why these ways can not
be considered? Also, we're not
mkroetzsch added a comment.
@Smalyshev We really want the same thing: move on with minimal disturbance as
quickly as possible. As you rightly say, the data we generate right now is not
meant for production use but for testing. We must make sure that our production
environment will understand
Smalyshev added a comment.
Item 1 will ensure that we can work with the dates as they will most likely
be when we enter production.
I'm not sure what is the basis of this assertion? I didn't see any plans for
BlazeGraph to move to new standard in the near term, and the same for Virtuoso.
I
mkroetzsch added a comment.
@Smalyshev P.S. Your finding of years in our Virtuoso instance is quite
peculiar given that this endpoint is based on RDF 1.0 dumps as they are
currently generated in WDTK using this code:
Smalyshev added a comment.
Virtuoso seems to be pretty odd. E.g. this query:
PREFIX : http://www.wikidata.org/entity/
SELECT ?x ?time WHERE {
?x http://www.wikidata.org/ontology#time ?time .
FILTER (?time 0002-01-01^^xsd:date)
} LIMIT 100
returns only a handful of items with
JanZerebecki added a comment.
@mkroetzsch Do you know of some widely used software that implements XSD 1.1
handling of BCE dates?
Dates without years should not be allowed by the time datatype.
what dates in Wikidata mean
I think the best way forward is to leave the lexical 0 in the
mkroetzsch added a comment.
@Smalyshev @Lydia_Pintscher Dates without years should not be allowed by the
time datatype. They are impossible to order, almost impossible to query, and
they do not have any meaning whatsoever in combination with a preferred
calendar model. All the arguments @Denny
mkroetzsch added a comment.
@mkroetzsch Do you know of some widely used software that implements XSD 1.1
handling of BCE dates?
Many applications that process dates are based on ISO rather than on XSD.
Java's SimpleDateFormat class, for example, is based on ISO and thus interprets
year
JanZerebecki added a comment.
All the software I checked that handles XSD types implement XSD 1.0 BCE years.
Together we know of nothing that implements XSD 1.1 BCE years. I'd suggest we
produce output for the RDF tools that exist.
The calendar model used for saving the data is always the
daniel added a comment.
I agree that we should gather more data before continuing the discussion about
the interpretation of dates stored in wikidata.
In https://phabricator.wikimedia.org/T94064#1160748, @mkroetzsch wrote:
@mkroetzsch Do you know of some widely used software that implements
JanZerebecki added a comment.
About representation of years BCE: Thank you for starting that mailing list
thread. It seem that it tends towards saying that the normative thing for
SPARQL 1.1 is XSD 1.1 with the reasoning that XSD 1.1 retroactively changes
anything that refers to XSD 1.0 as
JanZerebecki added a comment.
The lexical representation where the year fraction is 0 has undefined meaning
in Wikibase, so we can not assume it is a month-day without a year. I think the
easiest way is to represent is as a date with undefined meaning as string, like
we should additionally do
Smalyshev added a comment.
The lexical representation where the year fraction is 0 has undefined meaning
in Wikibase,
True. That's the complication - it can both be used for year before 1AD and
for we don't know what year it was but it was July 4th.
As we probably will implement custom
mkroetzsch added a comment.
we don't know what year it was but it was July 4th
Ouch. Where has this been designed? Can you point to the specification of this?
@Denny, is this intended? Dates without a year are extremely hard to handle in
queries and don't work at all like the normal dates
Smalyshev added a comment.
@mkroetzsch I don't think it is specified anywhere, it's just what people do.
See https://en.wikipedia.org/wiki/Marissa_Stott and its wikidata item, and
another one above. If you just look for items with date 0 in RDF, I'm sure many
of them are exactly that. I don't
29 matches
Mail list logo
