[foaf-dev] RDF triple assertions live forever?

[Phillip Rhodes]

Julian Bond wrote:
> Publish something on a web page, allow it to be spidered, and even if =

> your domain goes off line forever, that page will still exist in places =

> around the web. Provide an RSS feed and the words will get stored =

> somewhere. Post to Usenet or a mailing list run by the majors and your =

> post will stick around. With pretty much anything on the intarwebs it's =

> almost impossible to delete it completely.

Ok, that I understand and agree with.  What I thought was being
suggested earlier was that there was something intrinsic in working
with RDF / Semantic Web technologies that implies the need for
triple assertions to remain valid forever.

> As it is with html, RSS and nntp, so it is with rdf. Except that the =

> granularity is smaller. An individual triple can start in one place, be =

> smushed repeatedly and end up in places you really weren't expecting. =

> Once you let them out of the box, triples take on a life of their own.

Yes, exactly.  In the context of how I picture using FOAF however, I =

don't see that as being a big problem.

> So. Once upon a time it seemed like a good idea to have wildcard DNS on =

> a domain with some FOAF. The FOAF got spidered on multiple domains, =

> laptop.domain.com, w.domain.com, www.domain.com, foo.domain.com. The =

> apparent assertions multiplied and were republished. No matter that most =

> of that returns 404 now, the assertions won't go away.

Bummer.

> Take the recent Tribes.net debacle. They produce no FOAF now. Any =

> triples that came from Tribes.net are now obsolete. How long do you =

> think it will be before references to them disappear?


Yesh, if you treat FOAF as a static resource to be indexed, spidered
and mirrored, then all of this makes sense.  I've never pictured it that
way (correctly or incorrectly).  Most of the use cases I have envisioned =

are more along the lines of:

Domain A -  "generate some FOAF on demand as a result of accessing
some URL, based on A. the parameters of the request, and B. the context
of the domain receiving the request"

Domain B - receive the FOAF from domain A, process it as needed to =

handle the current request then throw it away (except for a short-term =

cache as a performance optimization maybe)"

I'm also operating on the assumption that for any given request, the =

FOAF that is returned might not contain everything it could (this goes
back to all of the earlier talk about privacy, access control, etc., of =

course).



TTYL,


-- =

Phillip Rhodes
Chief Architect - OpenQabal
https://openqabal.dev.java.net
LinkedIn: http://www.linkedin.com/in/philliprhodes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mindcrime.vcf
Type: text/x-vcard
Size: 224 bytes
Desc: not available
Url : http://lists.usefulinc.com/pipermail/foaf-dev/attachments/20080328/c3=
e0aa91/mindcrime.vcf