On Thu, Jan 8, 2015 at 12:17 PM, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote: Right, Freebase would not stick a Property called "Country" right on an instance of a Music Band. We would put Country under the Musical Group type, and give it a better definition like "The nation or territory that this item originated from". Freebase's Properties always live under a Freebase Type, like "Musical Group". Which is why on Wikidata, even seeing P17 on the U2 topic page makes me wonder what kind of schema Wikidata is trying to pull off. But it appears that someone did not really read the description page of P17, like I just did, then they would see it just is not allowed like that, but instead should have used P27, but then you can't have a date of birth for a Musical Group (band), which voids using even P27 on an instance of band. I understand, there are many holes in Wikidata's schema currently. I am one of several Freebase experts coming over that can help Wikidata identify those problematic Schema. :-) But Wikidata is not a "wiki" in the true sense, or should not be purported as one.... Because it is not Schema-less, but in fact, prescribes to a publicly editable and agreed upon Schema model. One thing I did notice is that the Wikidata Schema model is actually composed of both agreement on the 2 tabs of https://www.wikidata.org/wiki/Property_talk:P17 both the Property tab, AND the Discussions tab....combined...give the effective model of the Property...whereas in Freebase, we would just have the Property, where all rules and definitions about it are stored (Discussions about a Property were stored on our wiki and also our mailing list). I enjoy the Wikidata way a bit more compared to Freebase, the benefit being a primary place to see the defines of the Property as well as the Discussion and questions about it in the past. And that is my worry. That the Schema model is publicly editable at any time. And constraint violations are only effective against a "Well Defined Property". But what if I do not Well Define that property, or worst, I completely change the meaning of that Property. Imagine if I suddenly change the meaning of one of your MySQL table columns... like, PERSON suddenly becomes FURNITURE. That can happen with Wikidata's publicly editable Schema model....if someone maliciously changes the description of that P17 Country to something very generic like "a state".... oh really ? What kind of state ? Nations only ? Or territories considered as an organized political community under one government.? or both ? it appears that P17's Discussion clarifies this a bit, and defines it a bit more narrowly and would not allow just any territory with a political community. We have the same problem in Freebase, where if by public agreement, we change the meaning of a Property so much that it might cause erroneous data statements, then we deprecate that Property and create a new one, splitting off the various statements into their proper form and letting the Community know, and also performing the data tasks to subscribe the old data to the new Schema. The pollution of data would happen if by agreement P17's Discussion page drastically changed the intended meaning of it, then all the data that used P17 would need to be cleaned up. How does Wikidata intend to deal with those kinds of changes to Property meanings in the future ? and the data cleanup involved ?

Hi Marcus! Yes, you and I are on the same page. Yes, I know about the Property-first view of WIkidata. No quibbles. But there is still an issue with Assumptions for "Country" P17 being used for an instance of Band...so let's clarify this... So, I guess things are fuzzy, because I do not jump to assumptions beyond the meaning of P17 as it states on its Property or Discussion page. And the difference is that you are mentally performing a few assumptions. It is hard to train a computer to read your mind and answer a question for you however. :) Its better to write those assumptions (meanings) down somewhere. Even for Freebase, we found that Properties had to be described very well for all to understand their meaning with minimal ambiguity, and I was a big proponent on Freebase to Google for better descriptions. So, question.... since you understand the meaning of "Country" on the U2 page as you state... Can you please tell me that meaning...and then let's see if we can transfer your knowledge to better improve P17 Property and its description.

Markus, Devils in the details. =) You used the English word "associated". That's great. Then I would propose to expand the definition of P17 just a bit to add that. P17 Country - sovereign state of this item ... to ... sovereign state ASSOCIATED with this item Then you save the world. =) Thoughts ? Agreement ? Secondly, the Description: (Description :colon: on the Discussion page https://www.wikidata.org/wiki/Property_talk:P17) is defining a Country... not the description of the Country __Property__..which is the line just above it. How is the Description :colon: line supposed to work or be really used for ? Seems like the Description :colon: line is basically describing the Represents :colon: line.... lol. Very confusing. Thad +ThadGuidry <https://www.google.com/+ThadGuidry>

There is the cultural factor here that Freebase took an approach which is very similar to the RDFS approach in that they like the idea of defining separate properties like :HumanBirthDate :HorseBirthDate :DogBirthDate You can then treat these as subproperties of :AnimalBirthDate which is in turn a subproperty of :StartDate, or something like that. Freebase has a metaschema that does this sort of aggregation https://developers.google.com/freebase/v1/search-metaschema To a system designer who puts economy and simplicity first, there is something maddening about how Freebase defines separate types for "Film Actor", "TV Actor" and "Theatre Actor", since you might think an actor is just an actor and that the property to say an actor appeared in a film is almost the same as saying actor appeared in a TV episode; look deeper of course and you find different modelling needs. For instance there is a big difference between a TV actor with a recurring role and a TV actor who appears in one episode, etc. I think Freebase approached it this way because they had the idea of it being divided into separate "bases" which can managed separately; this means you get vocabulary tuned to each domain rather than somebody figuring out the grand scheme ahead of time. On Thu, Jan 8, 2015 at 4:52 PM, Peter F. Patel-Schneider < pfpschneider(a)gmail.com&gt; wrote: -- Paul Houle Expert on Freebase, DBpedia, Hadoop and RDF (607) 539 6254 paul.houle on Skype ontology2(a)gmail.com http://legalentityidentifier.info/lei/lookup

On Fri, Jan 9, 2015 at 12:43 AM, Jason Douglas &lt;jasondouglas(a)google.com&gt; wrote: Yes that is all there is. For a usage example see https://www.wikidata.org/wiki/Property:P9 (The value is currently not linked in that statement. That will be fixed with the next deployment next week.) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

First: A band is an organisation, not a person. Second P17 is deliberately a bit ambiguous so it can be used for those cases where we don't have specific info. We also have specific properties for those cases where we have specific info. We can have an architect born in Germany who spent most of his career in Lithuania and is one of their most prominent architects. We can have an Irish band playing traditional Irish ballads who have only worked in the USA for the last 20 years and are almost unknown in Ireland. Joe On 8 Jan 2015 23:07, "Paul Houle" &lt;ontology2(a)gmail.com&gt; wrote:

On 08.01.2015 22:52, Peter F. Patel-Schneider wrote: We have to be careful not to generalise too far from the original example in this thread (bands). I think you cannot say many formal things about the country of a band, but it's different with other types of objects that may have a country. This could mean that one will need different descriptions for the meaning of P17 with embassies and bands. Seems plausible. (And it would bring in some Freebase-like type-based rationale into the system as well -- maybe a nice conclusion for this part of the discussion). In general, I don't think one can discuss such things in general ;-). Every individual domain has to be looked at by experts who know what is reasonable there and what is confusing/too vague/too specific to work. Markus

+1 to this. While property re-use is desirable in general, we need to make some basic distinctions. The realm of geographic relations (a special kind of part-whole relations) is particularly clear and specific, and it would be worthwhile to distinguish them from more vague notions of associations between objects. This issue comes up much more now that we have "subproperty of": if used with cities, "country" is a subproperty of "is in the administrative territorial entity" (P131), but when used with bands, it is not. This is a sure sign that things should be diversified here. Cheers, Markus On 12.01.2015 19:18, apohllo(a)o2.pl wrote:

Referring to the NIST classification of semantic relations, general affiliation is a different relation than part-of. That's why conflating them is not the best idea. But this is a minor issue in that context. I am wondering if there is any list of "properties for beginners", that should not be treated as a real part of the knowledge base? As I wrote earlier there are two problems with ambiguous entities: 1. indicating super-properties 2. inferences drawn with such properties I don't question the usefulness of properties such as "country", i.e. searching all cities in one country or searching all bands that originated in another country. I am just concerned with the duplication and as a result coherence of the data that is in Wikidata. One of the basic principles of DB design is that data should be stored in only one place. That's why DB normal forms where developed. Even more - that's why Wikidata was extracted from individual Wikipedias in the first place! In the case of Dublin, country and Ireland. At present we have two distinct claims expressing the same fact, that one day may become incompatible. Being constructive - maybe it's the time to consider derived properties? Thus claims like "Dublin country: Ireland" would be visible in the UI, but would be computed based on the contents of the knowledge base. The same applies to age and many other properties, that are useful for 'beginners', but can be computed from the other properties and rules expressed in the ontology. Cheers, Aleksander ---- Wł. Wt, 13 sty 2015 16:51:47 +0100 Joe Filceolaire&amp;lt;filceolaire(a)gmail.com&amp;gt; napisał(a) ---- Country (p17) should be used for a general affiliation. Dublin has a general affiliation with Ireland. On the other hand City of Dublin is in the administrative territorial entity Dublin region which is in the administrative territorial entity Republic of Ireland which is on the geographical feature the Island of Ireland. If you are being specific then don't search using p17. Use p131 instead. We have both because they serve different functions. P17 is a property for beginners. We have lots of beginners so we should keep this property. Joe On 12 Jan 2015 19:32, "Markus Krötzsch" &amp;lt;markus(a)semantic-mediawiki.org&amp;gt; wrote: +1 to this. While property re-use is desirable in general, we need to make some basic distinctions. The realm of geographic relations (a special kind of part-whole relations) is particularly clear and specific, and it would be worthwhile to distinguish them from more vague notions of associations between objects. This issue comes up much more now that we have "subproperty of": if used with cities, "country" is a subproperty of "is in the administrative territorial entity" (P131), but when used with bands, it is not. This is a sure sign that things should be diversified here. Cheers, Markus On 12.01.2015 19:18, apohllo(a)o2.pl wrote: Hi, the discussion regarding the properties in Wikidata is very interesting. However I have doubts if leaving the country (P17) property as it is, is a good idea. The difference between Dublin country: Ireland, and U2 country: Ireland, is not superficial, but in both cases we have to do with two different semantic relations. When we look at the ACE relation types [1], we might conclude, that in the first case this is a part-whole relation and in the second: general-affiliation. The ACE classification scheme is very general and it was used successfully for validating many NLP systems and tasks, relation-extraction in particular. The reason I am against conflating these relations is the same as the reason I am against not disambiguating concepts like "work as an activity" and "work as an artifact". The activity/artifact distinction is semantically so basic, that it feels very natural to make this distinction. Moreover we can draw conclusions based on that distinction, e.g. that the activity might be interrupted, while the artifact not, the artifact might be destroyed, while the activity not etc. So it's also hard for me to accept such ambiguity in the case of properties. I think this will become more apparent with the adoption of subproperties, since it will be hard to identify a superproperty for the country property and even more apparent with systems that draw conclusions based on Wikidata. The semantics of properties might be broad, but should not be ambiguous. Kind regards, Aleksander Smywinski-Pohl [1] http://www.itl.nist.gov/iad/mig/tests/ace/2008/doc/ace08-evalplan.v1.2d.pdf ---- Wł. Cz, 08 sty 2015 22:29:33 +0100 *Markus Krötzsch&amp;lt;markus(a)semantic-mediawiki.org&amp;gt;* napisał(a) ---- On 08.01.2015 21:29, Thad Guidry wrote: &gt; Hi Marcus! &gt; &gt; Yes, you and I are on the same page. I do indeed get this impression ;-) &gt; Yes, I know about the &gt; Property-first view of WIkidata. No quibbles. But there is still an &gt; issue with Assumptions for "Country" P17 being used for an instance of &gt; Band...so let's clarify this... &gt; &gt; So, I guess things are fuzzy, because I do not jump to assumptions &gt; beyond the meaning of P17 as it states on its Property or Discussion &gt; page. And the difference is that you are mentally performing a few &gt; assumptions. It is hard to train a computer to read your mind and &gt; answer a question for you however. :) Its better to write those &gt; assumptions (meanings) down somewhere. &gt; &gt; Even for Freebase, we found that Properties had to be described very &gt; well for all to understand their meaning with minimal ambiguity, and I &gt; was a big proponent on Freebase to Google for better descriptions. &gt; &gt; So, question.... since you understand the meaning of "Country" on the U2 &gt; page as you state... Can you please tell me that meaning...and then &gt; let's see if we can transfer your knowledge to better improve P17 &gt; Property and its description. For me this means "the band is associated with Ireland" (culturally, personally, originally). No deeper meaning. In most cases, it will also be true that the band has had its first public performance in this country and that (all) the band members are of that nationality, but this would be jumping to conclusions. I fully agree with you that this is not very precise. My point is that it is still useful to have such broad relationships recorded, for example for browsing/filtering of data. Moreover, in this particular case I have doubts that narrower properties such as "had first public performance in" or "consists of band members that are nationals of" would be what people are looking for. Your original proposal of "country of origin" seems vague to me as well (what does this mean for a band? when does a band "originate"? do they always have an official time and place of being founded which is recorded somewhere? -- seems like we are just simulating a level of precision that does not exist in "reality"). An "Irish band" is not a mathematical term with an exact definition, but I can live with that, as long as we can find a reference that calls U2 an "Irish band" it is valid for me as data. I completely agree with you that detailed descriptions are very helpful -- you already need this to agree on what a "reference" for a claim is (and what isn't). Yet, this is different from narrowing down the use of a property to one special case. One can also allow for properties that are intentionally broad and approximate as long as this is documented clearly enough. In many cases, data with higher precision can be found anyway (for example, Wikidata should record the nationality of band members, and we could also capture the time and place of the first public appearance and the nationality of the record label of the first album etc.). Best regards, Markus &gt; &gt; &gt; &gt; _______________________________________________ &gt; Wikidata-l mailing list &gt; Wikidata-l(a)lists.wikimedia.org &lt;mailto:Wikidata-l@lists.wikimedia.org&gt; &gt; https://lists.wikimedia.org/mailman/listinfo/wikidata-l &gt; _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org &lt;mailto:Wikidata-l@lists.wikimedia.org&gt; https://lists.wikimedia.org/mailman/listinfo/wikidata-l _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Dear Thad, The second part of your email has good points in it, too. As you say, one must allow for adjustments in the intended meaning of a property in real life, and adjusting too much could be dangerous. The method you suggest (creating a new property and deprecating the old one, rather than modifying the meaning of the old one) has been used in Wikidata as well. Another thing that is very common in Wikidata are community-controlled mass edits: users offer to write conversion tools and the community decides how to use them. This can help to convert large amounts of data to a new format or to detect and cross-check errors. The constraint mechanism you see today is also a community-created way of avoiding unintended uses (be they caused by changed definitions or by other causes). Finally, some basic things that you probably know already: * Property datatypes in Wikidata cannot be changed after creation (ensuring that the data always remains structurally valid for this type). Technically speaking, this is the only "schema" we have (you mentioned SQL: things are similar there; the database schema does not include a definition of what you mean by the country column in the band table; at best it tells you that the country should be a key in the countries table). * The experience with Wikipedia has led to many mechanisms for counteracting spam and vandalism. Patrolling, (semi)protection of pages, spam fighting robots and scripts, etc. can similarly be used on Wikidata to fight against deliberate attacks on high-visibility pages such a properties. In a sense, structured data is making it much easier to detect problems with automated tools. This should be effective against most deliberate attempts to cause trouble by changing property labels etc. (but we will need to do more there I guess). Cheers, Markus On 08.01.2015 20:37, Thad Guidry wrote: ... ...