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

Re: [TURTLE] Turtle Inverse Properties

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Sun, 19 Aug 2012 15:46:30 +0100
Message-ID: <5030FC46.3030604@epimorphics.com>
To: public-rdf-wg@w3.org
> Use cases
> =========
>
> Reduce otherwise verbose reuse of an object for many subjects.
> (From TimBL http://lists.w3.org/Archives/Public/public-rdf-comments/2012Jul/0007.html)
>
> Examples:
>
>      foaf:Person is a of :Alice, :Bob, :Charlie, :David, :Elisa .
>
> vs.
>
>      :Alice a foaf:Person .
>      :Bob a foaf:Person .
>      :Charlie a foaf:Person .
>      :David a foaf:Person .
>      :Elisa a foaf:Person .

I confess I don't see much data that fits that style even hand-written: 
more common is a record-like structure:

:Alice rdf:type foaf:Person ;
        foaf:name  "Alice" ;
        foaf:knows Bob, :Charlie .

:Bob rdf:type foaf:Person ;
      foaf:name  "Bob" ;
      foaf:knows :Alice, :Charlie .

> Allowing a predicate to be used in either direction
> (From TimBL http://lists.w3.org/Archives/Public/public-rdf-comments/2012Jul/0007.html)
>
>      :Alice  foaf:age 38;
>          g:child :Bob, :Charlie;
>          is  g:child of  :Edna, :Fred;
>          foaf:basedNear :London;
>          is dc:author of [ dc:title "My life"; dc:date "1999"] .
>
>
> Compatibility with N3 has not been considered as a use case.
>
> Rationale
> =========
>
> Decreases the motivation for the anti-pattern to define both property
> and inverse of the property for all properties. In other words, if you
> can write  "is child of" you don't need to define a separate "parent"
> property.

This has some merit but from a readability argument, actually having 
"child" and "parent" make some sense as well.

The inverse isn't always best expressed as "is...of".

RDFS vocabulary builds directionality in the property names:

rdfs:subClassOf
rdfs:subPropertyOf

> No emerging consensuses on the need to reduce otherwise verbose reuse
> of an object for many subjects.
>
>
> Objections
> ==========
>
> English-centric "is ... of" is English-centric.
>
> Moves Turtle away from stated goal of compatibility with SPARQL 1.1.
>
>
> Revised ^ Syntax
> ================
>
>      foaf:Person ^a :Alice, :Bob, :Charlie, :David, :Elisa .
>
>      :Alice  foaf:age 38;
>          g:child :Bob, :Charlie;
>          ^g:child :Edna, :Fred;
>          foaf:basedNear :London;
>          is dc:author of [ dc:title "My life"; dc:date "1999"] .

            ^dc:author [ dc:title "My life"; dc:date "1999"] .

> Objections to Revised Syntax
> ============================
>
> Not compatible with N3
>
> Not compatible with SPARQL Update or SPARQL CONSTRUCT
>
> No implementation experience
>
>
> Objections to both original syntax and revised syntax
> =====================================================
>
> Turtle is a reasonably settled languages, changes made by the working
> group so far have been limited to areas of existing differences in
> implementation.
>
> No demand over years of implementation experience
>
> Harder to teach Turtle
>
> No implementation experience in SERIALIZING to these inverse forms.
>
>
> Proposals
> =========
>
> 1. Add is .. of syntax to Turtle.

-1

I'd rather leave this open for a comprehensive and deployment-tested 
proposal for readably pseudo natural langauge in the future, probably 
with more words and forms to make it "readable" to a new class of user.

>      1.1. Allowing "literals" in any subject position by syntax,
> however the RDF model disallows literal as subject. (somewhat as
> SPARQL but SPARQL does not support is ... of syntax)
>
>      1.2. Attempting to limit use of "literals" in subject position to
> only is ... of predicates in grammar (Not as SPARQL)

and not in the syntax-object position.  That's going to make for a 
tricky grammar.  At this point 1.1-style is better.

> 2. Add ^ property path syntax to Turtle.

-0

the list-syntax-object UC does not click for me

the lack of evidence of what happens in practice to machine-written data 
is a concern I have

>      1.1. Allowing "literals" in any subject position by syntax,
> however the RDF model disallows literal as subject. (As SPARQL in
> query blocks, however SPARQL disallows path syntax in triple assertion
> syntax)
>
>      1.2. Attempting to limit use of "literals" in subject position to
> only ^ predicates in grammar (Not as SPARQL and SPARQL disallows path
> syntax in triple assertion syntax.)
>
>
> 3. Add both ^ property path syntax and "is ... of" syntax.

-1
One and only one.

>      1.1. Allowing "literals" in any subject position by syntax,
> however the RDF model disallows literal as subject. (As SPARQL in
> query blocks, however SPARQL disallows path syntax in triple assertion
> syntax)
>
>      1.2. Attempting to limit use of "literals" in subject position to
> only ^ predicates and is .. of predicates in grammar (Not as SPARQL
> and SPARQL disallows path syntax in triple assertion syntax and SPARQL
> does not support is ... of)
>
> 4. Do nothing.

+1
A safe choice.

	Andy
Received on Sunday, 19 August 2012 14:46:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:06 UTC