W3C home > Mailing lists > Public > public-vocabs@w3.org > April 2014

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

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Mon, 14 Apr 2014 12:34:43 +0200
To: "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>
Cc: "Dan Brickley" <danbri@google.com>, "W3C Web Schemas Task Force" <public-vocabs@w3.org>
Message-ID: <op.xeayb518y3oazb@chaals.local>
On Sun, 13 Apr 2014 14:16:25 +0200, martin.hepp@ebusiness-unibw.org  
<martin.hepp@ebusiness-unibw.org> wrote:

> 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

Yes.

> and are semantically useless - who needs, conceptually, creatorOf at the  
> level of Person or Organization if there is hasCreator at the level of  
> CreativeWork.

The people who can add microdata to content about them, but cannot control  
the data attached to the things they publish in someone else's playspace  
(which applies to a lot of social networks, especially those which try to  
enforce assumptions about a single identity for people).

And a web where not everything is collected by a given crawl for important  
information.

> However, this assumption holds only as long as both directions of a  
> relationship instance can be equally well written down in the relevant  
> syntaxes.

Right.

> For instance, in RDFa, you have the @rel and @rev attributes for exactly  
> that purpose, so you can easily use the same property...
> In Turtle syntax, it is also fairly easy to live with just one property
...
> 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.

Right.

> From the top of my head, the only solution is to add an itemprop
> keyword before the definition of the main entity.

You can use itemid and point around in certain circumstances, but it's
somewhat fragile for real-world use on the Web.

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

It is also the case that we have made a lot of arbitrary choices about  
property names, and it is often not veryclear except by seeing examples  
which way the relationship goes e.g. "author" means '*i* am *author* of  
*that*' or '*this page* has the *author* *somebody*'.

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

Yes.

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

I agree that one of these is a better solution than continuing to add  
specific inverses for properties (there are a random set there already).

I'm ambivalent about whether we should try to deprecate microdata, or  
improve it. In Russia in particular it is popular...

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

This is my inclination too.

cheers

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


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com
Received on Monday, 14 April 2014 10:35:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:39 UTC