Regarding the question of how to classify properties and how to relate them to items:

* "same as" (in the sense of owl:sameAs) is not the right concept here. In fact, it has often been discouraged to use this on the Web, since it has very strong implications: it means that in all uses of the one identifier, one could just as well use the other identifier, and that it is indistinguishable if something has been said about the one or the other. That seems too strong here, at least for most cases.

* In the world of OWL DL, sameAs specifically refers to individuals, not to classes or properties. Saying "P sameAs Q" does not imply that P and Q have the same extension as properties. For the latter, OWL has the relationship owl:equivalentProperties. This distinction of instance level and schema level is similar to the distinction we have between "instance of" and "subclass of".

* Therefore, I would suggest to use a property called "subproperty of" as one way of relating properties (analogously to "subclass of"). It has to be checked if this actually occurs in Wikidata (do we have any properties that would be in this relation, or do we make it a modelling principle to have only the most specific properties in Wikidata?).

* The relationship from properties to items could be modelled with the existing property "subject of" (P805).

* It might be useful to also have a taxonomic classification of properties. For example, we already group properties into properties for "people", "organisations", etc. Such information could also be added with a specific property (this would be a bit more like a "category" system on property pages). On the other hand, some of this might coincide with constraint information that could be expressed as claims. For instance, person properties might be those with "Type" (i.e., "rdfs:domain") constraint human. By the way, our constraint system could use some systematisation -- there are many overlaps in what you can do with one constraint or another.



On 28/05/14 12:14, David Cuenca wrote:
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,

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 ;)


On Wed, May 28, 2014 at 11:39 AM, Markus Krötzsch
<mar...@semantic-mediawiki.org <mailto:mar...@semantic-mediawiki.org>>

    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,


    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
        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
        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

        But semantically I see no difference between:
        cement (Q45190) <emissivity (P1295)> 0.54
        cement (Q45190) <emissivity (Q899670)> 0.54

        Am I missing something here? Are properties really needed or are we
        adding unnecessary artificial constraints?


        Wikidata-l mailing list

    Wikidata-l mailing list
    Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org>

Etiamsi omnes, ego non

Wikidata-l mailing list

Wikidata-l mailing list

Reply via email to