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 <[email protected]> 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 <[email protected]>
> wrote:
>
>>
>>
>> On Wed, Aug 17, 2016 at 9:48 AM, Markus Kroetzsch <
>> [email protected]> 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
>>
>> [1] https://www.wikidata.org/wiki/Wikidata:Property_proposal/exact_match
>>
>>
>> _______________________________________________
>> Wikidata mailing list
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>>
>
> _______________________________________________
> Wikidata mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
_______________________________________________
Wikidata mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata
