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

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

From: Dan Brickley <danbri@google.com>
Date: Mon, 14 Apr 2014 13:12:10 +0100
Message-ID: <CAK-qy=7Cg4xk8BVExq7Z7UwJLOQdDiGqLvq=EK0cFTvqJLsgHA@mail.gmail.com>
To: Charles McCathie Nevile <chaals@yandex-team.ru>
Cc: "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>, W3C Web Schemas Task Force <public-vocabs@w3.org>
On 14 April 2014 11:34, Charles McCathie Nevile <chaals@yandex-team.ru> wrote:
> On Sun, 13 Apr 2014 14:16:25 +0200, martin.hepp@ebusiness-unibw.org
>> 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.

The 1997-1999 RDF spec established RDF conventions for this - from
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ -

"5. Formal Model for RDF

We can view a set of statements (members of Statements) as a directed
labeled graph: each resource and literal is a vertex; a triple {p, s,
o} is an arc from s to o, labeled by p. This is illustrated in figure
Figure 11: Simple statement graph template
This can be read either
o is the value of p for s
or (left to right)
s has a property p with a value o
or even
the p of s is o
For example, the sentence
Ora Lassila is the creator of the resource http://www.w3.org/Home/Lassila"

Admittedly we somewhat undermined this by using the names
'subClassOf', 'subPropertyOf' instead of saying 'superClass',

Article -superClass-> CreativeWork gives"CreativeWork is a superClass
of Article."

In general this works well for most RDF vocabularies, except when the
property name uses 'of'; i.e. people seem to act as if 'x foo y' is
shorthand for 'x hasFoo y'.

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

reasoning or normalization or programming, sure.

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

Deprecate is a strong word. I'd like to see everyone parsing RDFa 1.1
alongside it, at least.

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

That's the case Ive been making on the WHATWG list 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 12:12:39 UTC

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