On 01/07/2015 09:02 AM, Thad Guidry wrote:

The closest starting point for a Reconcile API with the current API structure that I can see is hacking a bit on this one: https://www.wikidata.org/w/api.php?action=wbgetentities&sites=enwiki&...

Btw, that closest starting point, only outputs 1 entity for "Paris" in the enwiki... where's Paris, Texas ?

Have you tried using wbsearchentities[1]?

[2] is able to find both Paris, France and Paris, Texas.

[1] https://www.wikidata.org/w/api.php?modules=wbsearchentities [2] https://www.wikidata.org/w/api.php?action=wbsearchentities&search=Paris&...

-- Legoktm

Actually, since Wikidata allows now properties on properties, one might easily create an item "Disambiguating property" and then make a claim "instance of - Disambiguating property" on the relevant property. there is no need for any extra implementation work.

On Wed Jan 07 2015 at 9:48:32 AM Thad Guidry thadguidry@gmail.com wrote:

Hi Lydia,

It's more than that. I can get labels just fine with &props=labels

Ideally there were be a Number 3.... a reconcile service, or an API that can be USED as a reconcile service.

Given a search string of "Paris", let's say...

1. Return some disambiguating properties and their labels and values. For

reconciling purposes, you don't want to deal with codes like P12345 but instead a human understandable description of the property. a. Allow the output of the information returned to be expanded or reduced by some parameter values that I mentioned as OUTPUT. b. Allow the use of a (disambiguator) parameter to output only the disambiguating properties. (disambiguating properties are those that are most important when comparing A = B and given a type). In Freebase API, we had the option of this as shown here: http://freebase-search.freebaseapps.com/?query=Texas&output=(disambiguat...

The current "disambiguator" with Wikidata is actually the "descriptions". Wikidata does not flag or mark properties like P856 (official site) as a "disambiguating property", an important property. Freebase does however. It would be nice for Wikidata to begin work on having a disambiguating property flag (boolean Y/N) like Freebase does.

The closest starting point for a Reconcile API with the current API structure that I can see is hacking a bit on this one:

https://www.wikidata.org/w/api.php?action=wbgetentities&sites=enwiki&...

Btw, that closest starting point, only outputs 1 entity for "Paris" in the enwiki... where's Paris, Texas ?

Thad +ThadGuidry https://www.google.com/+ThadGuidry

---

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

So Lydia,

Your saying that if I see https://www.wikidata.org/wiki/Q18614948 as a property on another Property... then that is similar to the Freebase "disambiguating" flag ?

In Freebase, we have just one flag.... but that is not the case here, correct ? Wikidata has (or might have) several such "disambiguating" flags via the property on Property ?

It would be nice, from an API and developer perspective, to not have to discover all those disambiguating properties....but have only a master disambiguating property to work with...a single "disambiguator" flag, just like Freebase has.... is this possible, where someone can go through an mark all of them as "disambiguating" ?

My hope is that the Wikidata query service could give me nicely formatted output for claims that only contain disambiguating property data.... just like the Freebase API example URL that I mentioned at the beginning of the thread. So hopefuly you guys are saying that is possible via the property on a Property.

Thad +ThadGuidry https://www.google.com/+ThadGuidry

||On 2015/01/09 14:50, Lydia Pintscher wrote:

On Thu, Jan 8, 2015 at 6:43 PM, Denny Vrandečić vrandecic@gmail.com wrote:

...

Actually, since Wikidata allows now properties on properties, one might easily create an item "Disambiguating property" and then make a claim "instance of - Disambiguating property" on the relevant property. there is no need for any extra implementation work.

And in fact that already exists ;-) See for example https://www.wikidata.org/wiki/Property:P345

We would want to say that https://www.wikidata.org/wiki/Q6545185 "unique identifier" is that same as http://www.w3.org/2002/07/owl#InverseFunctionalProperty. In this case a property is an instance of "unique identifier" (not sub property) so that "unique identifier" is the same class as InverseFunctionalProperty. We already have https://www.wikidata.org/wiki/Property:P1628 "equivalent property". Is there an "equivalent class"?

- Jeff

On 09.01.2015 17:25, Thad Guidry wrote:

https://www.wikidata.org/wiki/Property:P279 aka "the superclass" ... seems to have an equivalent property that refers to http://www.w3.org/2000/01/rdf-schema#subClassOf ???

Basically yes, this was the informal design intention when the community discussed these properties. However, we should be very careful when stating this as an "equivalent property" to rdfs:subClassOf, since the latter is not just some arbitrary vocabulary (like most other properties) but part of the RDFS and OWL language definitions that come with several possible semantics. Stating that our property is "equivalent" to such a language feature is not the whole story.

On a related note, it might really be preferrable to use properties "subClassOf(ExternalClass)" and "subPropertyOf(ExternalProperty)" to relate Wikidata elements to external vocabulary. Using these properties would mean that, from our viewpoint as a community, our claims are still correct if we would be using certain externally defined vocabulary elements instead of our own classes/properties.

== (Invented) Example ==

If we would have the claims

(1) Q1 P31 Q2 (2) Q2 subClassOf http://example.org/external/class/uri

then it means that we think that following claim is also meaningful:

(3) Q1 P31 http://example.org/external/class/uri

Our claim (2) tells external users that they may get instances of http://example.org/external/class/uri from our Q2 instances.

For this application, subClassOf (and similarly subPropertyOf) is enough. What you get with equivalentClass (equivalentProperty) is merely the other direction.

== Example (ctnd) ==

In the example above, if we would use

(2') Q2 equivalentClass http://example.org/external/class/uri

this would mean that we think that any instance of the class http://example.org/external/class/uri should also be in our Q2. It is a bit like an virtual import of data that we have not even seen. I doubt that we really want this.

The advantage of avoiding "equivalentProperty" in favour of "subPropertyOfExternalProperty" (and similarly for classes) is also that our definition can be more specific than the one used for the external property/class. So we can relate our data to multiple external things, which may fit our own definition more or less tightly.

Cheers,

Markus

There is a proposal to create a 'subproperty of' property but it is on hold until we can have a property as a datatype

Joe On 9 Jan 2015 16:26, "Thad Guidry" thadguidry@gmail.com wrote:

https://www.wikidata.org/wiki/Property:P279 aka "the superclass" ... seems to have an equivalent property that refers to http://www.w3.org/2000/01/rdf-schema#subClassOf ???

dunno.

Thad +ThadGuidry https://www.google.com/+ThadGuidry

---

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

On Fri, Jan 9, 2015 at 7:43 PM, Joe Filceolaire filceolaire@gmail.com wrote:

There is a proposal to create a 'subproperty of' property but it is on hold until we can have a property as a datatype

Property datatype is available and the "subproperty of" property exists: https://www.wikidata.org/wiki/Property:P1647 It is used on the following properties: https://www.wikidata.org/w/index.php?title=Special%3AWhatLinksHere&targe...

Cheers Lydia

As someone relatively new to Wikidata, I need to ask for some help understanding the following paragraph from the forwarded email:

Please note that *instance of* (P31) and *subclass of* (P279) are not valid values for *subproperty of* (P1647) claims, as described in the P1647 documentation [1]. For example, claims like "occupation *subproperty of* instance of" are invalid.

What specifically in the P1647 documentation [1] describes that *instance of* (P31) and *subclass of* (P279) are not valid values for *subproperty of* (P1647) claims?

[1]https://www.wikidata.org/wiki/Property:P1647

Thanks, James Weaver

On Sat, Jan 10, 2015, at 02:25 PM, Emw wrote:

Since it appears that the creation of *subproperty of* went unnoticed by many, I'd like to describe an important aspect of its proper use, and how that relates to classification.

Please note that *instance of* (P31) and *subclass of* (P279) are not valid values for *subproperty of* (P1647) claims, as described in the P1647 documentation [1]. For example, claims like "occupation *subproperty of* instance of" are invalid. The reasons for this are both technical and architectural.

On the technical side, *instance of, subclass of* and *subproperty of* are intended to be straightforwardly exportable as rdf:type, rdfs:subClassOf and rdfs:subPropertyOf. As described in *On the Properties of Metamodeling in OWL* [2], claims that use OWL's built-in vocabulary (e.g. rdf:type) as individuals make an ontology undecidable. If an ontology is undecidable, then queries are not guaranteed to terminate. This is a big deal. Decidability is a main goal of OWL 2 DL and a requirement in the more specialized profiles OWL 2 EL, OWL 2 RL and OWL 2 QL. Most Semantic Web ontologies aim to valid be in at least OWL 2 DL. So if Wikidata aims to be easily interoperable with the rest of the Semantic Web, we should aim to be valid in OWL 2 DL, and thus not make claims of the form "P *subproperty of* instance of (P31)" or "P *subproperty of* subclass of (P279)".

Avoiding such claims is also good design. There should be one -- and preferably only one -- obvious way to specify the type of an instance. Having a multitude of domain-specific "type" subproperties would promote an anti-pattern: using *instance of* as a catch-all property to make any statement under the sun that makes sense when connected with the phrase "is a".

Having a single "type" property for instances also fosters another best practice in Wikidata: asserted monohierarchy [3]. In other words, there should be only one explicit normal or preferred *instance of *or *subclass of* claim per item. Having an *instance of *claim and a *subclass of* claim on an item isn't necessarily bad (it's called "punning"), but having multiple *instance of* claims or multiple *subclass of* claims on an item is a bad smell. Items can typically satisfy a huge number of *instance of* claims, but should generally have only one such claim made explicitly in Wikidata.

For example, Coco Chanel (Q45661) can be said to be "*instance of* French person", "*instance of* fashion designer", "*instance of* female", etc. Instead of such catch-all use of *instance of*, Wikidata moves that knowledge into properties like *country of citizenship* (P27), *occupation* (P106) and *sex or gender* (P21). Coco Chanel has one explicit *instance of* value: human (Q5) -- a class that encapsulates essential features of the subject.

Most of Wikidata follows these general principles of classification. But a few domains of knowledge remain either somewhat of a mess, or organized but idiosyncratic. Items like the one for the German municipality of Aalen [4], with 7 *instance of* values -- several of them redundant -- exemplify the mess. With the deletion of domain-specific "type" properties like *type of administrative territorial entity* (P132) [5], we are on the right track. The solution is not to make such things subproperties of *instance of*, but rather to delete them and use *instance of* for one preferred class and put other values in other properties (note -- this may require new properties!).

The same applies for *subclass of*.

I encourage anyone interested in stuff like *subproperty of* to join the discussions ongoing at https://www.wikidata.org/wiki/Wikidata:Property_proposal/Property_metadata. The Wikidata community is currently discussing how we want to handle things like *domain* and *range* properties (e.g. should we use rdfs:domain or schema:DomainIncludes?) and whether we want to have an *inverse of* property (or delete all inverse properties). The outcome of these discussions will shape the interface between Wikidata and the rest of the Semantic Web.

Thanks, Eric

https://www.wikidata.org/wiki/User:Emw

1.https://www.wikidata.org/wiki/Property:P1647 2.Boris Motik (2007). On the Properties of Metamodeling in OWL.**https://www.cs.ox.ac.uk/boris.motik/pubs/motik07metamodeling-journal.pdf** *3. *Barry Smith, Werner Ceusters (2011). Ontological realism: A methodology for coordinated evolution of scientific ontologies. Section 1.8: Asserted monohierarchies. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3104413/#S9** 4.Aalen on Wikidata as of 2015-01-10. https://www.wikidata.org/w/index.php?title=Q3951&oldid=184247296#P31 5.https://www.wikidata.org/wiki/Wikidata:Requests_for_deletions/Archive/2014/P... _________________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l