Inverse properties, was: Re: Socialnetworks of a person or organization

Dear Charles:

I think you touch an important point regarding inverse properties, for which I would like to open a new thread:

On 12 Apr 2014, at 13:57, Charles McCathie Nevile <chaals@yandex-team.ru> wrote:

> TL;DR: schema:sameAs is a bad name because people think it is like owl:sameAs, but it is the pointer to things that can be used to identify something being described. In other words, what we want. The rest of the problem is to point to things people wrote, for which we need to resolve inverses, and then we can use the "author" property inverted.

First: In general, I am very hesitant to add inverse properties to conceptual models, because they will blow up the size of the vocabulary and are semantically useless - who needs, conceptually, creatorOf at the level of Person or Organization if there is hasCreator at the level of CreativeWork. 

However, this assumption holds only as long as both directions of a relationship instance can be equally well written down in the relevant syntaxes. For instance, in RDFa, you have the @rel and @rev attributes for exactly that purpose, so you can easily use the same property no matter whether you want to make a statement from the position of its subject or object.

In Turtle syntax, it is also fairly easy to live with just one property for the primary direction of the relationship type, as long as you do not deal with blank nodes.

In JSON-LD, we have the @reverse keyword, as defined in http://www.w3.org/TR/json-ld/#reverse-properties.

In Microdata, unfortunately, there is no direct pattern for swapping subject and object in a statement and thus using a property from the position of the object is cumbersome. From the top of my head, the only solution is to add an itemprop keyword before the definition of the main entity.

This may mean that we really need to think about providing inverse properties in schema.org if both directions occur in popular HTML content. However, because such will blow up the size of schema.org, the choice should not be made lightheartedly.

Whatever we decide, I **strongly* suggest that inverse properties will follow a consistent naming convention that will allow to derive them mechanically from the property for the primary direction. This is a bit more difficult with schema.org than with other vocabularies, since most properties do not begin with "has" nor have a "Of" at the end, so it is generally unclear wether "creator" means "isCreatorOf" or "hasCreator" etc.

Also, introducing inverse properties will mean that clients will have to use come kind of reasoning to understand both directions of a relationship.

At the moment, I think it would be way better to either enhance Microdata by a reverse property mechanism, or to advocate the use of JSON-LD or RDFa for such cases, and thus to address the problem at the level of syntax, rather than to pollute vocabularies with redundant properties. 

Solving this at the level of syntax would mean that one fix in the syntax replaces thousands of fixes in relevant vocabularies. We should apply E.F. Codd's idea of the normalization of representation data to the stack of standards for a Web of Data ;-).

Martin
---------------------------
http://www.heppnetz.de

Received on Sunday, 13 April 2014 12:16:50 UTC