Re: Inverse properties in Turtle

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.

I agree the use case is real and the feature addresses the use case but 
it isn't a feature someone can simply ignore if they don't like or don't 
understand it because this is the web so it can appear in data from 
elsewhere.

Syntax matters to some people, maybe not you, maybe not me. I think that 
includes people who will be using this technology and a whole host of 
other technologies. Web developers. They can not be expected to have a 
complete recall of every feature.

It does give object-like effects (design depending) to the actual 
subjects because of syntax:

:Ridley_Scott ^:director :Blade_Runner , :A_Good_Year ;
               rdfs:seeAlso <http://www.imdb.com/name/nm0000631/> .

"Ridley Scott" ^foaf:name <http://www.imdb.com/name/nm0000631/> .

the latter does rather hint at literals-as-subjects.

	Andy

>
> If someone were of that illusion, or if they simply missed it
> lexically, or didn't know what it means.
>
> Regardless, this will make Turtle harder to teach. I don't have a
> feeling for how much harder.
>
> - Steve
>

Received on Saturday, 11 August 2012 20:12:12 UTC