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

Re: Inverse properties in Turtle

From: Steve Harris <steve.harris@garlik.com>
Date: Mon, 13 Aug 2012 19:13:37 +0100
Message-Id: <97662BE9-03D6-40B5-96B8-72326DDD936F@garlik.com>
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, Pat Hayes <phayes@ihmc.us>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
To: Gregg Kellogg <gregg@greggkellogg.net>
On 13 Aug 2012, at 18:15, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> On Aug 13, 2012, at 2:20 AM, Steve Harris <steve.harris@garlik.com> wrote:
> 
>> On 2012-08-12, at 02:26, Gregg Kellogg wrote:
>> 
>>> On Aug 11, 2012, at 1:11 PM, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
>>> 
>>>> 
>>>> 
>>>> On 11/08/12 19:40, Steve Harris wrote:
>>>>> On 11 Aug 2012, at 18:02, Pat Hayes wrote:
>>>>> 
>>>>>> 
>>>>>> On Aug 11, 2012, at 5:22 AM, Andy Seaborne wrote:
>>>>>> 
>>>>>>> Hi Dan,
>>>>>>> 
>>>>>>> On 11/08/12 07:46, Dan Brickley wrote:
>>>>>>>> Hi Dave,
>>>>>>>> 
>>>>>>>> On 10 August 2012 19:25, Dave Beckett <dave@dajobe.org> wrote:
>>>>>>>>> Dear RDF Working Group
>>>>>>>> 
>>>>>>>> (Just a personal response here)
>>>>>>> 
>>>>>>> Ditto.
>>>>>>> 
>>>>>>>> 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.
>>>>>>> 
>>>>>>> For those people, do you think "^" will read acceptable to those
>>>>>>> people?  (Your point about "isXof" not always being the best
>>>>>>> choice of name is also interesting.)
>>>>>>> 
>>>>>>>>> 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.
>>>>>>> 
>>>>>>> A difference between "^:directory" (or the "is...of" syntax) and
>>>>>>> a property :isDirectorOf is that the "^" solution immediately
>>>>>>> does the reversing of the written subject and written object.
>>>>>>> 
>>>>>>> :Ridley_Scott ^:director :Blade_Runner
>>>>>>> 
>>>>>>> leading to a possible unexpected situation later:
>>>>>> 
>>>>>> POSSIBLY unexpected. If someone were under the illusion that the
>>>>>> caret syntax created a new property, they would be surprised or
>>>>>> disappointed at this point. The answer, surely, is to take pains,
>>>>>> in writing the documentatio, to explain carefully that it does not
>>>>>> do this. Your example would be a good one to use is such a
>>>>>> tutorial, for example. But the fact that a feature MIGHT be
>>>>>> surprising to someone who DIDNT read the tutiorials and does not
>>>>>> understand it, it surely not a good argument for not including it.
>>>> 
>>>> I'm undecided about this feature; I haven't seen a complete proposal 
>>>> yet.  There is not absolute argument one way or the other that I've seen 
>>>> and it seems to come down to a value judgement.
>>>> 
>>>> What does not work for me in this case is the argument like
>>>> 
>>>> Use Case -> feature solves Use Case -> include feature.
>>> 
>>> Case #1
>>> 
>>> For one thing, it would mean that a Turtle serialization of a SPARQL DESCRIBE (at least one using a Concise Bounded Description) could be generated with a single "subject". For a describe of :gregg in the graph
>>> 
>>> :gregg foaf:knows :andy .
>>> : andy foaf:knows :gregg .
>>> 
>>> could be serialized as
>>> 
>>> :gregg foaf:knows : andy; ^foaf:knows :danbri .
>> 
>> Not really relevant to your point but a CBD doesn't include statements where the described URI is the object. http://www.w3.org/Submission/CBD/#definition
> 
> No, not for IRIs, but step 2 does this for BNodes, including the subjects which reference them as objects. So, yes, my example doesn't strictly adhere to this, but a BNode variant would
> 
> :gregg foaf:knows _:someone; ^foaf:knows _:someone .

Not by my reading of step 2, it says where the bNodes is the subject of the triple. Anyway, it's somewhat irrelevant!

- Steve

> That said, even though I've brought forth some potential use cases, I don't feel strongly about including inverse properties myself. I'm probably a +0.5.
> 
> Gregg
> 
>> It's a good example of how this type of thing can be used to reduce the number of bytes needed to write a chunk of RDF though.
>> 
>>> Case #2
>>> 
>>> The second scenario I've seen is where several resources need to be declared as having the same type.
>>> 
>>> foaf:Person ^a :gregg, : andy .
>>> 
>>> Personally, I prefer is..of, and suggest that we include that as syntactic suggar:
>>> 
>>> foaf:Person is rdf:type of :gregg, :andy
>>> 
>>> Reads much better. (Not so much in the first use case).
>> 
>> Ditto.
>> 
>> - Steve
>> 
>> -- 
>> Steve Harris, CTO
>> Garlik, a part of Experian
>> +44 7854 417 874  http://www.garlik.com/
>> Registered in England and Wales 653331 VAT # 887 1335 93
>> Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ
>> 
> 
Received on Monday, 13 August 2012 18:14:10 UTC

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