W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2010

Re: Higher-arity to RDF binary

From: Peter Ansell <ansell.peter@gmail.com>
Date: Tue, 18 May 2010 09:04:00 +1000
Message-ID: <AANLkTinVenEsg01GYk-Dkv1ZdTBcIcJQBsq77seXO89G@mail.gmail.com>
To: David Booth <david@dbooth.org>
Cc: Jakub Kotowski <jakubkotowski@gmx.net>, Jitao Yang <jitao.yang@gmail.com>, semantic-web@w3.org, www-rdf-interest@w3.org
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 ) .
> 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.


Received on Monday, 17 May 2010 23:04:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:45:06 UTC