Hi, On 16/09/12 15:33, Jeroen De Dauw wrote: Yes, I wondered about this too. I will make that change soon. As explained in the text, the aliases are not distinguished from other property values in the data model right now. This was the status of the discussion when we last talked about this, but we can also re-introduce aliases as a special field (I see why this would be useful). Daniel had an argument against this, saying that many other property values could also work as aliases in certain domains (e.g. binomial names of biological species). So the special status of the alias in the data model was questioned. But the current aliases are still special in various ways (no references, no statement ranks, special UI handling, maybe special constraints [if two items have the same description, can one of them use an alias that is the title of the other?]). Discuss. ;-) Yes, this DataValue is certainly in early draft stage. I will change the name as suggested by Katie. For the content, should we have optional altitude and optional planet identifier (what is the format of this? is there an IRI for Mars?)? This is also based on a preliminary decision made a while back: the idea was that properties, while not having Wikipedia articles, will still need unique string identifiers that can be used in wikitext (e.g. queries) where one does not want to address properties by ID or by "label+description" pairs. Denny mentioned that there was some discussion to use the label for this (requiring it to be globally unique for a property), so that the TitleRecord is not needed. Will this work well? After all, the label is in languages, while the TitleRecord refers to sites (which is the place where you want to refer to properties by title). Using label instead will require a more complicated site-to-language(s) mapping somehow (example: if I write a query about an Item on en.wikipedia.org, it is clear that I refer to the title of that Item in en.wikipedia.org; if I write about a Property and properties only have labels, then it is not clear if I refer to the label in en-uk, en-us, en-ca, etc.). Same answer as above. I see now that detailed explanations do not help, since nobody reads them :-p Yes, this is easy to change. When the data model was initially discussed, there was no use case for having statements (= ranked claims with references) in properties. It seems that a property could at best have a list of PropertyValueSnaks (no auxiliary Snaks, no references, no statement rank). Markus

On 17/09/12 12:54, Jeroen De Dauw wrote: Ok, I agree with that. I will change the model to have explicit aliases somewhere. Yes, this is what I mean. But PageName is just a string, and does not need to refer to an actual page (or be displayed as a link). It can still be used as a "string key" to refer to the property on a certain site. Well, the above. It allows you to assign a human-readable key to each property that you can use instead of p12345 and that is still unique for each site. Moreover, this can be done with code that is similar to what we already have for site links in Items (but without linking and thus also without auto completion). Because it is easier. First of all, "label description" is not enough: you need to say which language you talk about to make it a key (this can be guessed from the site, but this is still not a unique selection). Second, you do not need to mention the GlobalSiteId if you are on a site and want to use its own ID. So one addressing method requires one strong key (PageName), the other requires three string keys (language, label, description). The former seems easier. What you are saying ("equivalence across sites") only is another way to say that "GlobalSiteId PageName" is a key for entities on Wikidata. Such keys can always be used to define equivalence classes (of keys that refer to the same thing); how is that a problem? Do you think you need auxiliary Snaks there? The step from "list of snaks" to "list of snaks with auxiliary snaks (i.e., claims)" is not hard to make (even later), but I would not make it without a cause. In general, what is the motivation of allowing arbitrary Snaks for properties? Really general annotations (users define properties, e.g., to organise other properties) or merely technical information (some properties need extra information about things like units of measurement)? Markus

Re: keys for properties For now the following solution seems to be the simplest: * make labels for properties be unique for a given language In that case they can be used as keys. Every wiki has one (and exactly one) site language. If the label is unique, a property can be addressed by languagecode + label,and the languagecode could be used per default inside a wiki. No extra keys per site would be needed, which would have otherwise been provided by the sitelink data (which would be more appropriately named sitekey instead of sitelinks in that case). The description is not used to identify properties by the machine. This means that two different properties cannot have the same name in one language. We will need to figure out if this is a problem during usage, and if it is, change it later. I hope this makes sense, Denny 2012/9/17 Markus Krötzsch <markus(a)semantic-mediawiki.org>rg>: -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

Which means that property labels will need disambiguation additions to differentiate. I think this is correct and intuitive in a Wikimedia context. User interface memo: There will be a need both for specific properties and generic. When accessing a property by a broad = not disambiguated name, the userinterface should automatically show its subproperties (property/subproperty hierarchy), micking essentially a disambiguation page. I think this would nicely and intuitively fall into place with Wikipedia practices. Gregor