Hoi,
There are a few problems here. Diseases are seemingly without an issue
except they often are. When Wikidata is connected to a disease resource and
as a consequence greater authority is given to what is disputed to be
disease then the next argument about funding and continuing funding is
exactly the kind of reason why such connection are problematic in the
extreme.
It is one thing to say that something like schizophrenia exists in a
disease database it is a completely different kettle of fish to acknowledge
this in Wikidata. FYI there is already some literature that speaks of the
exact opposite in Wikidata including other ways of treating this serious
problem.
Funding for an external source is NEVER an argument for whatever happens in
Wikidata. Funding for Wikidata that expects friendly relations with other
sources is problematic in the extreme.
Thanks,
GerardM
On 17 August 2016 at 20:03, Benjamin Good <ben.mcgee.good(a)gmail.com> wrote:
Perhaps it would be more productive if I give a very
specific example.
(I'd prefer a general, wikidata-wide policy but it sounds like that isn't
going to happen.)
We are working on integrating wikidata with many of the ontologies that
are part of the OBO Foundry [1]. These include, for example, the Gene
Ontology and the Disease Ontology. Bringing the concepts represented in
these ontologies in as items in wikidata makes it possible to author claims
that capture knowledge about the relationships between, for example, genes,
biological processes, diseases, and drugs. These claims are thus far
mostly drawn from associated public databases. They serve to populate
infoboxes on Wikipedias and, we hope, will also help foster the growth of
new applications that can help to capture more knowledge for re-use by the
wikidata community. Importantly, these imports also bind the wikidata
community here to the community of biomedical researchers over there.
Establishing a coherent pattern for binding the concepts in these
ontologies to the corresponding items in wikidata is important for two key
reasons:
(1) The ontologies and other linked data resources that use them have a
lot of data that is never likely to get into wikidata and vice versa.
Establishing clear mappings makes it possible to integrate that knowledge
(mostly) automatically. (AKA the whole idea of the semantic web...). The
more consistent the pattern of mapping, the more automation is possible.
(2) It is vitally important to the maintainers of these resources to be
able to track usage of their work products. The more an ontology that is
funded for the purpose of supporting research and knowledge dissemination
can show that it is being used, the better the argument to continue its
funding. When negotiating the import of knowledge products into a CC0
world, it is important that we can demonstrate that the items will
generally remain connected as well as give indications about how they are
being used. (Accepting of course that with CC0 there is no guarantee.)
Given that context, would you support the proposal of using the exact
match property to bind this specific set of biomedical wikidata items to
items defined elsewhere on the semantic web? If not, what would be the
best alternative?
-Ben
[1]
http://www.obofoundry.org
On Wed, Aug 17, 2016 at 8:05 AM, Andra Waagmeester <andra(a)micelio.be>
wrote:
On Wed, Aug 17, 2016 at 9:48 AM, Markus Kroetzsch <
markus.kroetzsch(a)tu-dresden.de> wrote:
As Gerard said, "exact" correspondence
might be difficult in most
cases, but something slightly weaker should be ok.
Something that one
should note is that, even in cases where two things are about the same
"idea", their usage in RDF is usually different if you compare Wikidata RDF
to external RDF. For example, a class in an external RDF document might
have instances assigned via rdf:type whereas a class-like item in Wikidata
has instances assigned via a chain of properties
This is exactly why the property P2888 is based on skos:exactMatch When I
proposed the "exact match" property this issue surfaced as well [1].
skos:exactMatch provides more freedom in expressing similarity between
concepts then the related owl:sameAs
possibly with further quantifiers assigned to the middle element. So you
cannot get a simple, direct correspondence on a structural level anyway.
Actually with skos:exactMatch you can.
There are also properties "equivalent
class" (P1709), "external
superproperty" (P2235), and "external subproperty" (P2236). See
https://tools.wmflabs.org/sqid/#/browse?type=properties&datatypes=5:Url
for the list of all 34 URL-type properties. Maybe you can discover
others that are relevant for you.
The reason I proposed the exact match property was with federated queries
in mind. Other resources can have a higher level of granularity on a given
topic. Being able to reach out to these resource can have benefits. In the
past we were able to federate over for example Wikdiata and Uniprot where
the URI was composed by generating the linking URI on the fly: e.g.
BIND(IRI(CONCAT("http://purl.uniprot.org/uniprot/"rot/", ?wduniprot)) as
?uniprot)
At first we experimented with the equivalent class property. But it was
pointed out by ontologists that using the property for class equality is
problematic as is partly expressed in its W3C definition: "NOTE: The use of
owl:equivalentClass does not imply class equality". [1]
Being able to store external URIs of wikidata URIs, would enable us to
really make WIkidata central in de linked data cloud, allowing representing
more granularity then currently captured in Wikidata.
Cheers,
Andra
[1]
https://www.wikidata.org/wiki/Wikidata:Property_proposal/exact_match
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
_______________________________________________
Wikidata mailing list
Wikidata(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata