Re: Pingback, again - Was: Re: Use-Cases and call for help to add descriptions and scenarios.

hello olivier.

On 2012-10-31 04:03 , "Olivier Berger" <olivier.berger@it-sudparis.eu>
wrote:
>In the case where containers get "external" resources added to them
>(aggregation, weak links, etc.), I think it would be quite interesting
>to consider that eventually these resources could get notified that they
>just got added to a LDP C.
>Similarly, when a resource gets deleted, the container could be notified
>about that to eventually remove it from its members.
>Does it make sense wrt the LDP scope ?

i would hesitate to do that. like i tried to point out in my original
post, links often are more "service" that they are "data", so trying to
persist them as "data" may not be such a great idea (and i think this is
what arnaud initially meant when i talked about the headaches of managing
bidirectional links). so instead of treating links as data, in loosely
coupled architectures you'd rather design services that other can ask at
runtime about reverse links.

for example, it would be a quite a headache for a big blog to be notified
every time somebody mentioned a blog post, and then having to store all
these backlinks, and maybe even testing whether they still are alive. much
better to have a service (such as google) that you can go to, whenever it
matters, that aggregates and manages the links, and at any point in time
will tell you who is linking to your blog post.

trying to persist all relationships between resources on the web, in
particular those that are not under your authority, is a scalability and
maintenance nightmare, and might be something you maybe shouldn't even
try. knowledge on the web always is partial, and that's a fact of life.
iff we wanted to tackle this, i'd much rather have the kind of "linking
service" i outlined above, rather than putting the burden of managing
incoming links on everybody's data directly. i guess RDF would be a very
good foundation for that, you would just have a service you'd ask about
triples where some of your resources are the link target, and then you'd
get a bunch of triples you could mix in with yours, but it probably would
be a very good idea to not persist those, but to treat them as a snapshot
that could change at any time.

michael hausenblas might want to pitch in here, because maybe there could
be some synergy between this idea and VoiD, which as i understand it is a
more static model of how "resource graphs" could be interlinked, but maybe
could be extended to be something more dynamic (and i am sorry, michael,
if that is an absurd misrepresentations of what VoiD is all about).

cheers,

dret.

Received on Wednesday, 31 October 2012 22:38:50 UTC