Re: URI Fragments

Richard Cyganiak wrote:
> 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.

you can prevent it being used as an identifier for something else and
prevent possible ambiguity. For instance I'd like to reserve
http://webr3.org/nathan as my webid until I have a foaf profile up
there. Change this scenario to a shared server managed space and you
need to create that "conceptual map" even if it does map to an empty
set. (?)

>> 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.

ahh a side note of my own on that point: 301 Moved Permanently would be
perfect for changing uri references in the web of linked data

"The requested resource has been assigned a new permanent URI and any
   future references to this resource SHOULD use one of the returned
   URIs.  Clients with link editing capabilities ought to automatically
   re-link references to the request-target to one or more of the new
   references returned by the server, where possible."

but only when the resource doesn't have a fragment; otherwise it would
be ambiguous.

>> 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.

Personally I think it does.. 410 Gone
"The requested resource is no longer available at the server and no
   forwarding address is known.  This condition is expected to be
   considered permanent.  Clients with link editing capabilities SHOULD
   delete references to the request-target after user approval."

to me that says resource is deleted (gone), permanently, delete all
references if you can please.

again though, only when the resource doesn't have a fragment; otherwise
it would be ambiguous.

>> 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.

see above re 410 Gone.

>>> 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

actually I'd just like your thoughts on the aforementioned 410 Gone and
301 Moved Permanently; we are dealing with linked data which is bound to
http via the dereferencing aspect; so makes sense to consider (as was
done with 303)?

Regards & really, thanks for taking the time to address the points.

Nathan

Received on Friday, 12 March 2010 20:10:45 UTC