Markus, The explanation about the implications of renaming/deleting makes most sense and just that justifies already the separation in two. It is equally true that when we create a property, we might have "cleaned" the original concept so much that it might differ (even slightly) with the understood concept that the item represents. However, even after that process, the "new" concept is still an item...
The process of imbuing a concept with permanent characteristics (adding a datatype) and the practical approach, also seems to recommend keeping items and properties separate. Thanks for showing me that reasoning :) I am still wondering about how are we going to classify properties. Maybe it will require a broader discussion, but if they are the same (or mostly the same) as items, then we can just link them as "same as", and build the classing structure just for the items. OTOH, if they are different, then we will need to mirror that classification for properties, which seems quite redundant. Plus adding a new datatype, "property". All in all, my conclusion about this is that properties are just concepts with special qualities that justify the separation in the software (even if in real life there is no separation). many thanks for your detailed answer, and sorry if I'm bringing up already discussed topics. It is just that when you stare long into wikidata, wikidata stares back into you ;) Cheers, Micru On Wed, May 28, 2014 at 11:39 AM, Markus Krötzsch < mar...@semantic-mediawiki.org> wrote: > Hi David, > > Interesting remark. Let's explore this idea a bit. I will give you two > main reasons why we have properties separate, one practical and one > conceptual. > > First the practical point. Certainly, everything that is used as a > property needs to have a datatype, since otherwise the wiki would not know > what kind of input UI to show. So you cannot use just any item as a > property straight away -- it needs to have a datatype first. So, yes, you > could abolish the namespace Property but you still would have a clear, > crisp distinction between property items (those with datatype) and normal > items (those without a datatype). Because of this, most of the other > functions would work the same as before (for example, property > autocompletion would still only show properties, not arbitrary items). > > A complication with this approach is that property datatypes cannot change > in Wikibase. This design was picked since there is no way to convert > existing data from one datatype to another in general. So changing the > datatype would create problems by making a lot of data "invalid", and > require special handling and special UI to handle this situation. With > properties living in a separate namespace, this is not a real restriction: > you can just create a new property and give it the same label (after naming > the old one differently, e.g., putting "DEPRECATED" in its name). Then you > can migrate the data in some custom fashion. But if properties would be > items, we would have a problem here: the item is already linked to many > Wikipedias and other projects, and it might be used in LUA scripts, > queries, or even external applications like Denny's Javascript translation > library. You cannot change item ids easily. Also, many items would not have > a datatype, so the first one who (accidentally?) is entered will be fixed. > So we would definitely need to rethink the whole idea of unchangeable > datatypes. > > My other important reason is conceptual. Properties are not considered > part of the (encyclopaedic) data but rather part of the schema that the > community has picked to organise that data. As in your example, > "emissivity" (Q899670) is a notion in physics as described in a Wikipedia > article. There are many things to say about this notion (for example, it > has a history: somebody must have defined this first -- although Wikipedia > does not say it in this case). As in all cases, some statements might be > disputed while others are widely acknowledged to be "true". > > For the property "emissivity" (P1295), the situation is quite different. > It was introduced as an element used to enter data, similar to a row in a > database table or an infobox template in some Wikipedia. It does probably > closely relate to the actual physical notion Q899670, but it still is a > different thing. For example, it was first introduced by User:Jakec, who is > probably not the person who introduced the physical concept ;-) Anything > that we will say about P1295 in the future refers to the property -- a > concept of our own making, that is not described in any external source > (there are no publications discussing P1295). > > This is also the reason why properties are supposed to support *claims* > not *statements*. That is, they will have property-value pairs and > qualifiers, but no references or ranks. Indeed, anything we say about > properties has the status of a definition. If we say it, it's true. There > is no other authority on Wikidata properties. You could of course still > have items and properties "share" a page and somehow define which > statements/claims refer to which concept, but this does not seem to make > things easier for users. > > These are, for me, the two main reasons why it makes sense to keep > properties apart from items on a technical level. Besides this, it is also > convenient to separate the 1000-something properties from the 15-million > something items for reasons of maintenance. > > Best regards, > > Markus > > > > On 28/05/14 09:25, David Cuenca wrote: > >> Since the very beginning I have kept myself busy with properties, >> thinking about which ones fit, which ones are missing to better describe >> reality, how integrate into the ones that we have. The thing is that the >> more I work with them, the less difference I see with normal items.... >> and if soon there will be statements allowed in property pages, the >> difference will blur even more. >> I can understand that from the software development point of view it >> might make sense to have a clear difference. Or for the community to get >> a deeper understanding of the underlying concepts represented by words. >> >> But semantically I see no difference between: >> cement (Q45190) <emissivity (P1295)> 0.54 >> and >> cement (Q45190) <emissivity (Q899670)> 0.54 >> >> Am I missing something here? Are properties really needed or are we >> adding unnecessary artificial constraints? >> >> Cheers, >> Micru >> >> >> _______________________________________________ >> Wikidata-l mailing list >> Wikidata-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikidata-l >> >> > > _______________________________________________ > Wikidata-l mailing list > Wikidata-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata-l > -- Etiamsi omnes, ego non
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
