Re: Higher-arity to RDF binary

David Booth <[email protected]>
Newsgroups gmane.org.w3c.semantic-web,gmane.comp.web.rdf
Message-ID <1274146436.13763.938.camel@dbooth-laptop>
On Tue, 2010-05-18 at 09:04 +1000, Peter Ansell wrote:
> On 18 May 2010 06:58, David Booth <[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.