>"One should also point out to the authorities maintaining these IDs that
they should spend some effort on producing a workable solution for this. It
seems they should be the first to provide a resolver service (or maybe it
would be an "ID search engine" if it is so complicated).
With the qualifie
> "For instance: in the following contexts expand the CURIE to the chembl
webpage, in these other contexts, expand to the (sometimes unresolvable)
HTTP URI, in these other contexts, expand to the wikidata page for the
entity. "
This context-specific expansion is of course not to preclude the use o
I suggest considering w3id
Julie
On Wednesday, June 1, 2016, Dario Taraborelli
wrote:
>
>
> On Wed, Jun 1, 2016 at 2:00 PM, Federico Leva (Nemo) > wrote:
>
>> Dario Taraborelli, 01/06/2016 10:33:
>>
>>> I don't, it probably depends on what shorteners are most used for spam
>>> purposes across
Hi there, may I ask what link shorteners provide you that w3id does not?
Eg baked in metrics or 10char urls? Just curious why you would want to
reimplement.
Julie
On Wednesday, June 1, 2016, Stas Malyshev wrote:
> Hi!
>
> > that makes sense. It sounds like in the short term (and until we
>
While I agree the primary aim isn't shortening, the result is usually much
shorter by virtue of cutting out everything non essential to
identification. I say this as a non stakeholder in w3id, just a fan.
Nevertheless I take your point that it isn't automated. I would like to
understand the use ca
Makes perfect sense now, thanks for explaining.
Julie
On Thu, Jun 2, 2016 at 12:51 AM, Tom Morris wrote:
> On Thu, Jun 2, 2016 at 12:22 AM, Julie McMurry
> wrote:
>
>> While I agree the primary aim isn't shortening, the result is usually
>> much shorter by virtue of
How big a problem is fact vandalism? It may be less likely to be
detected/fixed in languages for which there are fewer editors. Only if a
big problem, I'd suggest that specific text (not whole articles) be
protected, but not locked. Eg implementing a requirement for confirmation
by multiple editors
I concur both with Markus K and with Ben. What sets Wikipedia apart is its
democratic approach. Exerting too much control, especially if in the hands
of a "trusted few", is at cross-purposes with the Wiki way and moreover not
scaleable.
The question regarding edit drift and notifications raises an
It is great that WikiData provides a way for data to be curated in a
crowd-sourced way.
It would be even better if changes (especially corrections) could be
communicated back to the original source so that all could benefit.
Has this been discussed previously? Considered?
Julie
__
Thanks Sandra for introducing ResourceSync. The web page and it appears up
to date, but according to the video footer, the original presentation was
from 2014. I would like to know who if anyone has implemented it so far and
how it is going? Has anyone on this listserve heard of it before?
My coll
Chris Mungall & co were just awarded a grant to develop tooling for mere
mortals to create ontologies.
Copying him in here to comment.
On Wed, Oct 12, 2016 at 4:40 PM, Denny Vrandečić
wrote:
> I don't know if Jakob Voss is on this list, but he had a recent paper on
> using Wikidata (not Wikibase
I didn't know that about wikidata logo, but love it all the more for it
thanks.
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
12 matches
Mail list logo
