W3C home > Mailing lists > Public > public-rdf-comments@w3.org > August 2012

Re: Inverse properties in Turtle

From: Dan Brickley <danbri@danbri.org>
Date: Sat, 11 Aug 2012 08:46:16 +0200
Message-ID: <CAFfrAFqtdzV++RU-FoOVGMN-XNA43De5N4tf86f4nQX7wLokeg@mail.gmail.com>
To: Dave Beckett <dave@dajobe.org>
Cc: public-rdf-comments@w3.org, Tim Berners-Lee <timbl@w3.org>
Hi Dave,

On 10 August 2012 19:25, Dave Beckett <dave@dajobe.org> wrote:
> Dear RDF Working Group

(Just a personal response here)

> I was prompted to make a comment on adding inverse properties in Turtle
> (also called 'is xxx of' in N3).

I assume we're talking about the general notion, not using the words
'is' and 'of' as syntax. I prefer something punctuation based, e.g.

> I personally think this is a bad idea at this stage of Turtle's life,
> for several reasons:

I was originally not in favour, but now I lean towards supporting the addition.

> 1. There was no *high* demand for it over the years.

Agreed. This is a niche topic, but I still now thing it is of occasional use.

In particular, as a maintainer/editor/contributor for popular RDF
vocabularies (FOAF, schema.org and others) I believe there is implicit
demand for this which is often expressed instead in terms of requests
for new inversely named properties. Whenever someone asks a vocabulary
maintainer to add 'isDirectorOf' alongside 'director', or asks what
the inverse of 'actor', or 'associatedAnatomy' or 'depicts' is, they
are talking about just this issue.

Since RDF has multiple syntaxes, it is easier to ask for a new
property than to consider RDF/XML, Turtle, N3, RDFa/XHTML, RDFa/SVG,
RDFa/HTML5 etc one by one.

Considering a particular case (from schema.org and RDFa world, not Turtle):

 * the Director of the Movie whose name is 'Blade Runner' is a Person
whose name is 'Ridley Scott'
 * IMDB publish pages about each, http://www.imdb.com/name/nm0000631/
http://www.imdb.com/title/tt0083658/ (let's set aside http-range
issues for now; they're separable)
 * the Movie page uses the schema.org 'director' link to point to the
associated person page; <a href="/name/nm0000631/"
itemprop="director">Ridley Scott</a>
 * In the Person page, we see only this: <a
href="/title/tt0083658/">Blade Runner</a></b>

Similarly, w.r.t. the 'actor' relation from a Movie to a Person, IMDB
use the weaker 'performerIn' schema.org property on Person (designed
for Events) to express something like the inverse.

Back with FOAF, we added some inverses due to (mild but real) popular
demand: primaryTopic <=> isPrimaryTopicOf;  topic <=> page; maker <=>
made ... each of these makes writing certain expressions more readable
at a syntax level, yet fragments the graph, pushing work onto
consumers. Each time we do this, it involved hunting around for a
sensible name.

FOAF has < 50 properties; schema.org currently has 466, see

Considering the IMDB case, I would like to be able to express the fact
that the link from  http://www.imdb.com/name/nm0000631/ to
http://www.imdb.com/title/tt0083658/ expresses a link from a page
about a Person to a page about a Movie to be expressible in simple
RDFa or Microdata. While RDFa has had some support for inverse
direction ('rev' instead of 'rel'), there was pushback for the HTML5
flavour from Ian Hickson previously, giving similar arguments to yours

> 2. It is confusing to users since you now have to explain why the arrows
>    can go backwards as well as forwards.

Yes, I freely agree it is confusing. In my experience, the notion of
the 'direction' of an RDF property confuses many people, even
sometimes RDF experts. Although the property naming choice
(foaf:depicts <=> foaf:depiction is a good example) is quite
arbitrary, people have strong intuition that is somehow matters
deeply. Layered on top of this, we have (especially in the RDFa case)
the hypertext graph, alongside the semantic/factual graph.

However this question can be couched for RDFa in simple enough terms:
"IMDB have a link in a director's page to a film, e.g. <a
href="/title/tt0083658/">Blade Runner</a></b>. Over in the film page,
they link back to the director using <a href="/name/nm0000631/"
itemprop="director">Ridley Scott</a> which makes clear the 'director'
relationship, ... so how can we make that relationship more explicit
in the director's profile page also?'

Complexity is a lump under the carpet here. We can keep pushing things
around, but it won't go away. We could put a bigger blob of markup in
the director page, we could invent extra properties, or we could add,
document, consume and publicise a notation that handles the reverse
direction directly. The considerations for Turtle are a little
different; I'd argue that its users are generally a bit more
advanced/skilled on these topics, than HTML authors. However I think
we should on such occasions consider the suite of RDF-based languages
as a whole (from SPARQL to RDFa, Turtle, ...), since they are designed
to reinforce and support each other, rather than compete.

Considering RDFa alone, or Turtle alone, I find such constructs less
compelling. But taken as a package I think this niche feature actually
helps people understand RDF more deeply. They shouldn't encounter it
on day 1, but it does highlight the Webby nature of the technology.
Nobody should be *forced* to think, but on balance it removes some
complexity elsewhere so I think we should allow it.

> 3. It is not in SPARQL's data syntax.
> 4. There is a high bar to add a new feature to an existing, well
>    understood and implemented language like Turtle.  This feature does not
>    fit that in my judgement.

Taking those two together, ...

I only support adding such a construct if it has a comparable notation
in SPARQL. They might not be 100% identical, but the basic concept
ought to either be in both, or in neither. Turtle and SPARQL share a
common heritage in N3; if we can make teaching them (Turtle and
SPARQL; I consider N3 something like a "Labs project") easier by
sharing structure and ideas, we ought to.

'rev=' is in http://www.w3.org/TR/2011/WD-rdfa-core-20111215/ but not
in RDFa Lite. This means that parsers understand it, even if the most
common idioms do not heavily encourage its use. That seems a
reasonable approach to me.



> So my request is that you do not add it.
> Thanks
> Dave
Received on Saturday, 11 August 2012 06:46:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:53 UTC