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

Reply via email to