Re: Inverses of RDF and RDFS predicates

Thanks, David.

Regards,
Dave




On Apr 30, 2012, at 10:40, David Booth wrote:

> Sure.  The main driver I have run into is when I want to be able to
> express a particular set of information about a particular thing as
> subject.  This means that I need to be able write my triples with that
> thing in the *subject* position of the triple -- not the object
> position.
> 
> As a concrete example, I want to be able to talk about the members
> of a particular class :C.  If I only have rdf:type then I must write:
> 
>  :x rdf:type :C .
>  :y rdf:type :C .
>  :z rdf:type :C .
> 
> and the subjects of those statements are :x, :y and :z -- not :C.  If I
> could instead write:
> 
>  :C rdf:isTypeOf :x .
>  :C rdf:isTypeOf :y .
>  :C rdf:isTypeOf :z .
> 
> then the *subject* of those statements is :C, which is what I want.
> 
> There are a couple of reasons for wanting to do this:
> 
> 1. It allows one to conveniently distinguish those statements from other
> statements in which :C appears in the object position of the triple.
> This is what is done in computing the Concise Bounded Description:
> http://www.w3.org/Submission/CBD/
> It is a common approach taken for DESCRIBE queries in SPARQL.
> One could reasonably argue that instead you should put those statements
> in a separate graph if you wish to distinguish them from statements in
> which :C appears as in the object position of the triple.  Indeed, one
> could, but that adds complexity.  And the fact is, it is convenient to
> be able to do it this way.
> 
> 2. It allows one to use certain optimizations that are asymmetric.  In
> particular, if I represent my RDF triples using a hash table for each
> subject, then I can very quickly and easily lookup the members of
> class :C by using rdf:isTypeOf as the hash table index.  
> 
> For example, in Perl if $s is a hash table reference for triples in
> which class :C is the subject, and $p is property rdf:isTypeOf, then I
> can easily lookup all members of class :C with the following generic
> statement:
> 
>  @values = $s->{$p};
> 
> I.e., @values would then be a list containing :x, :y and :z.  Note that
> this simple line of code works for obtaining the values of multi-valued
> properties for triples of *any* subject $s and property $p -- not merely
> the :C example.  In contrast, if I could only put :C in the *object*
> position of the triple, then I would have to special-case my code to
> store the members of a class differently than all other multiple-valued
> statements are stored.  To avoid that, I instead made up my own inverse
> for rdf:type, which is unfortunate, because its semantics are so
> fundamental.
> 
> In essence, the ability to use the inverse property gives the author
> more flexibility in writing RDF.  This can be helpful both as a
> convenience for the author and to simplify downstream code that
> processes that RDF.
> 
> Let me know if further clarification would help.
> 
> Thanks!
> David
> 
> On Mon, 2012-04-30 at 08:20 -0400, David Wood wrote:
>> Hi David,
>> 
>> Can you please articulate one or more use cases to accompany this
>> feature request?  Thanks.
>> 
>> Regards,
>> Dave
>> 
>> 
>> 
>> 
>> On Apr 29, 2012, at 19:43, David Booth wrote:
>> 
>>> If this has already been considered and rejected by the WG then please
>>> ignore, but . . . 
>>> 
>>> It would be helpful if the RDF and RDFS specs defined inverses for the
>>> properties that they define.  For example, if
>>> 
>>> :x  rdf:type  :C .
>>> 
>>> then one might write:
>>> 
>>> :C rdf:isTypeOf :x .
>>> 
>>> and similarly for other properties.
>>> 
>>> I have resorted to defining my own inverse properties for some of these,
>>> but it seems silly to do so, rather than standardizing them, especially
>>> since it wouldn't add anything significant to the semantics.
>>> 
>>> 
>>> -- 
>>> David Booth, Ph.D.
>>> http://dbooth.org/
>>> 
>>> Opinions expressed herein are those of the author and do not necessarily
>>> reflect those of his employer.
>>> 
>>> 
>> 
>> 
>> 
> 
> -- 
> David Booth, Ph.D.
> http://dbooth.org/
> 
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of his employer.
>

Received on Monday, 30 April 2012 15:24:18 UTC