Re: Higher-arity to RDF binary

On Tue, 2010-05-18 at 09:04 +1000, Peter Ansell wrote:
> On 18 May 2010 06:58, David Booth <david@dbooth.org> wrote:
> > Right, but it is unfortunate that we do not have an established
> > *standard* way to represent higher-arity relations.  Instead we have
> > *multiple* ways to do it, and different people do it different ways,
> > which means that software cannot automatically recognize them as
> > higher-arity relations.
> >
> > For example, if we had a standard "marker" property like this:
> >
> >  :higherArityRelation a rdfs:Property ;
> >     rdf:comment """A higher-arity relation (i.e., not restricted
> >                    to binary relations) between the subject and the
> >                    items in the object list.  The object must be a
> >                    list; each element of the list participates as
> >                    one of the participants in the relation.  Thus,
> >                    a tertiary relation uses a list of two items.""" .
> >
> > then for the diagnosis use case in
> > http://www.w3.org/TR/swbp-n-aryRelations/#useCase1
> > we could write something like the following:
> >
> >  foo:has_diagnosis a :higherArityRelation .
> >
> >  foo:christine foo:has_diagnosis ( foo:Breast_Tumor foo:HIGH ) .

Sorry, I meant to write:

  foo:has_diagnosis rdfs:subPropertyOf :higherArityRelation .

  foo:christine foo:has_diagnosis ( foo:Breast_Tumor foo:HIGH ) .

> >
> > and software could recognize this as a tertiary relation, perhaps
> > optimizing or rendering it differently.
> 
> The main question then is what optimisations are going to be
> performed, and what level of difference in human visual rendering is
> needed? If the application is designed specifically for the scenario
> then it won't need to know that the relation is higherArity because
> that knowledge will have been programmed into the system as part of
> arranging for the application to interpret different parts of the list
> as it requires.
> 
> The only optimisations or rendering differences would then be with
> generic browsing software from what I can tell. It would need to be
> different to a non-higherArity list display or treatment, whatever
> that is currently.

Right, that's what I meant: generic software could recognize them.  For
example, the Cyc engine already has ways to deal with higher-arity
relations in its native code, but it doesn't have any way to know that
certain patterns it sees in RDF are really meant to represent
higher-arity relations.



-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Received on Tuesday, 18 May 2010 01:34:32 UTC