- From: Dan Brickley <danbri@danbri.org>
- Date: Sat, 11 Aug 2012 08:46:16 +0200
- 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 http://schema.org/docs/schema_org_rdfa.html 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 here. > 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. cheers, Dan > So my request is that you do not add it. > > Thanks > > Dave >
Received on Saturday, 11 August 2012 06:46:51 UTC