Re: how to know that something was DELETEd

hell richard.

a few clarifications, just to make sure we don't do too much NIH work.

On 2013-03-27 15:32 , "Richard Cyganiak" <richard@cyganiak.de> wrote:
>Atom is about trees, LDP needs to be about graphs.

nothing in atom is about trees. atom is about collections and entries.
that's the data model. the tree part conveniently comes in for very
selective things such as the ability to have a sorted list (part of XML's
sorted trees) and the data model for authors (which is not the greatest
part of atom. just because something is using XML doesn't mean the domain
model is a tree.

> Atom only has collections and members (a single relationship type),
>while LDP needs to be able to deal with arbitrary relationship types.

LDP has containers and members as well. adding an alias mechanism isn't
really such a big difference.

> Atom imposes its own model of collections, members, feeds and entries,
>while LDP has to work with existing domain-specific models (where some
>parts of these models *may* have the semantics of collections, entries,
>etc.).

it provides a foundation, or you could say platform. when you look at the
existing applications, you'll see how many domain models have been used on
top of it.

> Atom is centered around the concept of an "Atom entry document" which
>forces a metadata schema designed for news syndication upon all users;
>LDP has to be agnostic regarding metadata schemas.

that's just a claim. LDP can easily the same metadata mix, but defining
some fields, and allowing users to add whatever they like (which is
exactly what atom does). only if we design some fields can we support
common service semantics (such as "order by updated"). that has turned out
to be useful, afaict.

> Atom comes with terminological baggage from its roots in web content
>syndication; LDP already has to deal with the terminological baggage of
>both the RDF and the REST communities and the last thing needed is talk
>about Feeds and Entries.

i understanding that using these terms doesn't make everybody happy.
that's fine. we don't have to use them. that still doesn't mean we have to
reinvent the wheel. we can learn from the wheels that have been spinning
for a while, build one that's even better, and call it differently. i
still don't see any fundamental difference between the scenarios we have
in our use cases, and the ones that have been deployed on the web at scale
for a long time already.

cheers,

dret.

Received on Wednesday, 27 March 2013 22:47:18 UTC