Hoi,
When you consider splitting up in parts, the question becomes how do we
bring things together.. Where a person may have publications and awards and
awards are in a separate area, how do you find the person in either
environment? It is one thing to consider splitting up because they may help
Erik Paulson, 12/05/19 01:54:
It's probably less about splitting the dumps up and more about starting
to split the main wikidata namespace into more discrete areas [...]
In fact that was one of the proposals in "The future of bibliographic
data in Wikidata: 4 possible federation scenarios".
I hope that splitting the wikidata dump into smaller, more functional
chunks is something the wikidata project considers.
It's probably less about splitting the dumps up and more about starting to
split the main wikidata namespace into more discrete areas, because without
that the full wikidata
Hi all,
I would like to throw in a slightly different angle here. The
GlobalFactSync Project
https://meta.wikimedia.org/wiki/Grants:Project/DBpedia/GlobalFactSyncRE
will start in June.
As a preparation we wrote this paper describing the engine behind it:
Indeed, these collaborations in high-energy physics are not static
quantities, they change essentially every day (people getting hired and had
their contract expired, and most likely every two papers have a slightly
different author list.
Cheers
Yaroslav
On Sun, May 5, 2019 at 5:58 PM Darren
Hoi,
For your information, these huge numbers of authors are particularly
noticable when organisations like CERN are involved. Those people have all
an ORCID identifier and slowly but surely more authors are being associated
with publications. As a consequence papers are getting to be complete for
> We may also want to consider if Wikidata is actually the best store for
> all kinds of data. Let's consider example:
>
> https://www.wikidata.org/w/index.php?title=Q57009452
>
> This is an entity that is almost 2M in size, almost 3000 statements ...
A paper with 2884 authors! arxiv.org deals
So, I'm not particularly involved with the scholarly-papers work, but
with my day-job bibliographic analysis hat on...
Papers like this are a *remarkable* anomaly - hyperauthorship like
this is confined to some quite specific areas of physics, and is still
relatively uncommon even in those. I
Hoi,
Yes we could do that. What follows is that functionality of Wikidata is
killed. Completely dead.
Also, this thread is about us being ready for what we could be, not for
what we are. At that we are not as good as we could be. In your suggestions
for inclusion we could have the "concept cloud"
maybe it would be a good idea to run sparql updates directly to the
endpoint. rather than taking the de-tour via SQL blobs here.
How large is the RDF TTL of the page?
On Sat, May 4, 2019 at 7:37 PM Stas Malyshev
wrote:
> Hi!
>
> > WQS data doesn't have versions, it doesn't have to be in one
Hi!
> WQS data doesn't have versions, it doesn't have to be in one space and
> can easily be separated. The whole point of LOD is to decentralize your
> data. But I understand that Wikidata/WQS is currently designend as a
> centralized closed shop service for several reasons granted.
True, WDQS
Hi Stas,
Many thanks for writing this down! It is very useful to have a clear
statement like this from the dev team.
Given the sustainability concerns that you mention, I think the way
forward for the community could be to hold a RFC to determine a stricter
admissibility criterion for scholarly
Hoi,
Your approach is technically valid. It is equally obvious in part the wrong
approach. Where you say we have to consider if Wikidata is the best store
for all kinds of data, you may indicate the inadequacies of Wikidata in
relation to particular kinds of data we already store, want to use. The
yeah, the wikibase storage doesn't sound right here, but these are two
different issues, one with wikibase (sql) and one with the Wikidata Query
Service (blazegraph).
that 2M footprint is the sql db blob? each additional 2M edit is the
version history correct?
So the issue your are referring to
Hi!
> For the technical guys, consider our growth and plan for at least one
> year. When the impression exists that the current architecture will not
> scale beyond two years, start a project to future proof Wikidata.
We may also want to consider if Wikidata is actually the best store for
all
looks like you are ready for the weekend Gerard :-) I don't see a scale
issue at the moment for the type of wikidata use cases I come across. Even
total number of triples is plateauing at 7.6bn*. ( of course it's easy to
write "bad" queries that bring down the server). Allowing people to setup
Hoi,
Lies, damned lies and statistics. The quality of Wikidata suffers, it could
be so much better if we truly wanted Wikidata to grow. Your numbers only
show growth within the limits of what has been made possible. Traffic and
numbers could be much more.
Thanks,
GerardM
On Fri, 3 May
Gerard, I like wikidata a lot, kudos to the community for keeping it going.
But keep it real, there is no exponential growth here.
We are looking at a slow and sustainable growth at the moment with possibly
a plateauing of number of users and when it comes to total number of
wikidata items. just
> Wikidata grows like mad. This is something we all experience in the really
> bad
> response times we are suffering. It is so bad that people are asked what kind
> of
> updates they are running because it makes a difference in the lag times there
> are.
>
> Given that Wikidata is growing
Hoi,
This mail thread is NOT about the issues that I or others face at this
time. They are serious enough but that is not for this thread. People are
working hard to find a solution for now. That is cool.
What I want to know is are we technically and financially ready for a
continued exponential
Gerard mentioned the PROBLEM in the 2nd sentence. I read it clearly
>we all experience in the really bad response times we are suffering. It is
so bad that people are asked what kind of updates they are running because
it makes a difference in the lag times there are.
The response times are
I agree it is not clear what is being discussed here. It is growing, but in
(my opinion) in a positive way, i.e. being accepted as a viable knowledge
graph.
Regards,
Andra
On Fri, May 3, 2019 at 3:27 PM David Abián wrote:
> Hi!
>
> Indeed, Wikidata grows and will continue growing. But I don't
Hi!
Indeed, Wikidata grows and will continue growing. But I don't see
clearly what the purpose of this thread is. Is it to propose possible
technical and financial improvements?
Regards,
David
On 5/3/19 14:24, Gerard Meijssen wrote:
> Hoi,
> Wikidata grows like mad. This is something we all
Hoi,
Wikidata grows like mad. This is something we all experience in the really
bad response times we are suffering. It is so bad that people are asked
what kind of updates they are running because it makes a difference in the
lag times there are.
Given that Wikidata is growing like a weed, it
24 matches
Mail list logo
