- From: Peter Ansell <ansell.peter@gmail.com>
- Date: Tue, 18 May 2010 09:04:00 +1000
- 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. Cheers, Peter
Received on Monday, 17 May 2010 23:04:54 UTC