Re: Inverse properties in Turtle

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

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 09:21:17 UTC