Re: url patterns for describedby target resource

On 16/06/2020 04.36, Paul Tyson wrote:
> The LDP Primer [1] shows one example of creating a non-RDF resource and
> an associated RDF description of it:
> 
> HTTP/1.1 201 Created
> Location: http://example.org/alice/avatar
> Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
> Link: <http://example.org/alice/avatar/meta>; rel="describedby"
> Content-Length: 0
> 
> It seems reasonable, but not necessary, to derive the describedby URL
> from the resource URL, but the pattern illustrated here could easily
> intrude on the legitimate namespace of non-RDF resources.
> 
> Does anyone know of other patterns for generating describedby URLs for
> non-RDF resources?
> 
> Thanks in advance for suggestions.
> 
> Best,
> 
> --Paul
> 
> [1]
> https://www.w3.org/TR/ldp-primer/#creating-a-non-rdf-binary-resource-post-an-image-to-an-ldp-bc


LDP doesn't prescribe a URI Template for description resources. Servers
can construct their URI as they like. Keep in mind that clients would
only be expected to follow the describedby link relation (as opposed to
deriving the URI of the description resource from the resource that's
making the association).

Some servers use .meta suffix and variations eg.
http://example.org/alice/avatar.meta

Some servers construct URIs including a UUID string eg.
http://example.org/alice/{uuid}

...

Regarding the example http://example.org/alice/avatar/meta , I would not
consider that to be a good pattern. It potentially conflicts with
slashes as segments in URI path (RFC 3986) - especially for common
filesystem-backed servers eg. if http://example.org/alice/avatar is a
file http://example.org/alice/avatar/ would not be a directory (or LDP
Container) and so http://example.org/alice/avatar/meta is awkward in
practice.

It somewhat goes against the LDP best practice to use a trailing slash
in container URIs:

https://www.w3.org/TR/ldp-bp/#include-a-trailing-slash-in-container-uris

Needless to say, neither LDP or URI specs prevent minting of avatar ,
avatar/ , avatar/meta and have them dereferenceable.

The direction we are taking in the Solid ecosystem is that semantics of
the slash character in URI path is shared by servers and clients:

https://solid.github.io/specification/#uri-slash-semantics

That will play well with the two example approaches that I've mentioned
above.

-Sarven
https://csarven.ca/#i

Received on Tuesday, 16 June 2020 09:07:59 UTC