Hi Nathan,
On 12 Mar 2010, at 16:46, Nathan wrote:
Then if I delete a Primary resource, the secondary resources must
also
be deleted, true / false (?).
The web is about representations of information resources. If you add
RDF to the picture, then it's also about descriptions of arbitrary
entities.
On the web, you can create and delete representations. You can create
and delete descriptions. But you cannot create or delete resources.
I'd argue that a resource is anything that can be named (or assigned a
URI), regardless of whether it has a representation or not. Even
without
a representation a resource could still be reserved (which allows
references to be made to a concept before any realization of that
concept exists - although I've yet to confirm if 204 could be used for
this..);
I would agree with everything above. But I'd say that from the web
POV, you can't do anything useful with a resource that is reserved but
doesn't have a representation or provides some other useful response
(such as 303) when resolved.
in another use-case though a resource like /news/latest may be
nothing more than a conceptual map to another resource (served via a
3xx
code) -
Side note: I interpret 301, 302 and 307 as “try over there to get a
representation of this resource”. So if you get a representation from
the target, then I'd consider that a representation of the original
resource. This interpretation is not backed by any spec or other
authoritative document, but for me it makes the picture cleaner. 303
of course is explicit about that the representation is of a
*different* resource.
this is a resource with no representation, which can be both
created and deleted surely?
Well it can be created and deleted, but the web (by which I mean, HTTP
and URIs) provides no standard way of creating or deleting resources
that have no representation. You have to use some nonstandard
mechanism of your own invention for this (which of course can be built
on standard operations, e.g. POST). Hence my view that the creation or
deletion of the resource is a side effect of something that you invoke
that's “outside” of the web.
In another case; let's say planned to lease a /London_Office
(resource)
which I then described with a representation and 303'd to; then I
decided not to lease the /London_Office so deleted the representation
/and/ the resource because /London_Office isn't something that can be
named because it no longer exists, was never realized, and moreover I
want it removed because it was a painful loss.
Thus, can you delete resources? or another way, can you delete a
conceptual map?
I suppose you can delete them, but there is no operation for doing so
in HTTP. Hence you'll have to devise your own mechanism for this. And
wether deleting <foo> also deletes <foo#bar> is something that depends
on how you model your domain concepts as resources, representations
and descriptions. In general, the HTTP and URI specs don't constrain
this.
So, you can't really “delete” those primary and secondary
resources. But
if you delete all the representations of a primary resource, then
this
will delete the authoritative descriptions of the secondary
resources,
because those live inside the representations.
if I remove the section and the reference test.html#whatever from
test.html; have I not deleted that secondary resource? it can't be
named
any more, or referenced, or.. and so on
Good point, in this case you are right. For HTML documents,
<foo.html#whatever>, if defined at all, will be a named element within
the HTML document (see RFC 2854). It's pretty clear what it means to
delete a named element in an HTML document (there are even DOM
operations for doing so), it's pretty safe to say that you are
deleting the secondary resource.
This is because RFC 2854 constrains the semantics of fragment IDs on
HTML documents in such a way that it becomes clear what creating and
deleting them means. The same would apply to any other media type
where fragments identify parts of the document.
This is not the case for RDF media types, where the semantics of
fragment IDs is essentially: “They identify whatever the full hash URI
identifies according to the RDF graph in the document” (too lazy to
dig out the reference -- the media type registration RFC for
application/rdf+xml, which points to some section of some RDF spec
that according to my understanding can be summarised as above).
So perhaps I should say that *in general* you cannot really delete
resources, unless some spec (especially media type specs) defines the
semantics of the resources in such a way that you can delete them.
Feel free to challenge some more ;-)
All the best,
Richard
Best,
Richard
Thanks again,
Nathan
Here are some examples, which may seem like over kill but some are
interesting and generally I *feel* rules like this should be either
always true, or always false, never varying.
examples:
if I remove a database table, then all it's rows also no longer
exist.
if I remove London then the Tower of London also no longer exists.
if somebody removes me, then my arms also no longer exist.
if I remove test.html then test.html#whatever no longer exists.
if I remove test.rdf then test.rdf#this no longer exists
if I remove http://www.w3.org/People/Berners-Lee/card then
http://www.w3.org/People/Berners-Lee/card#i no longer exists.
conversely:
if I remove a row, the table still exists
if I remove the Tower of London, London still exists
if you remove my arms, I still exists and I'll find another way to
type.
if I remove test.html#whatever test.html still exists
if I remove test.rdf#this, test.rdf still exists
if I remove http://www.w3.org/People/Berners-Lee/card#i then
http://www.w3.org/People/Berners-Lee/card still exists.
If the above is true (secondary resource must also be deleted on
removal
of primary resource), then I should never use a fragment
Identifier to
refer to a non-virtual object (i.e. "me" a Person) - because I
can't be
deleted by simply removing a resource. (?)
Regards!
Nathan
