W3C home > Mailing lists > Public > semantic-web@w3.org > March 2009

RE: first and rdf:rest as functional property

From: Jeremy Carroll <jeremy@topquadrant.com>
Date: Fri, 20 Mar 2009 14:50:04 -0700
To: 'Reto Bachmann-Gmür' <reto.bachmann@trialox.org>, "'Michael Schneider'" <schneid@fzi.de>
Cc: "'Semantic Web'" <semantic-web@w3.org>, "'Bijan Parsia'" <bparsia@cs.man.ac.uk>
Message-ID: <001e01c9a9a5$d3bb8670$7b329350$@com>


> -----Original Message-----
> > (3) Lists should not have more than one head, but it's possible with
> RDF
> > lists:
> >
> >       A1
> >        \
> >         v
> >          B -> rdf:nil
> >         ^
> >        /
> >       A2
> >

I disagree with this one.

If you program in Prolog or Lisp (or even C or Java) you often get such structures. You can't even tell. It's not even an insy-winsy bit problematic.

The view of a list is from its head, not from its body.


e.g. suppose I have an RDF graph, which uses some URI 
http://legacy/#JeremyCarroll
for me
and I want to replace this URI with
http://brightshinynew/#JeremyCarroll
through-out, but leave the legacy copies as well.
It might make sense to make duplicates of rdf lists in which any member being the old uri is duplicated to give the new uri.
The corresponding prolog code could be:

% replace(OldList,NewList,OldMember,NewMember)
% replace all occurrences of OldMember in OldList with NewMember to get NewList

% Either this first clause 
replace([],[],_,_).
% or this one
replace(L,L,Old,_) :- not member(Old,L), !.

replace([H|T][HH|TT],H,HH) :- !, replace(T,TT,H,HH).
replace([H|T][H|TT],OldM,NewM) :- !, replace(T,TT,OldM,NewM).


With the first version of the first clause we get copies which don't have more than one head (except at rdf:nil).
With the second, which is largely equivalent we do.

(I suspect the most efficient Prolog code would combine these approaches somehow, so that we avoid the repeated walking of the list used by the second approach, but avoid the global stack churn found in the first).

 
Jeremy
Received on Friday, 20 March 2009 21:50:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:28 GMT