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@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@micelio.be> wrote:


On Wed, Aug 17, 2016 at 9:48 AM, Markus Kroetzsch <markus.kroetzsch@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/", ?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



_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata



_______________________________________________
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata