Re: Redefining “resource”

Hi Dan,

On 25 May 2012, at 14:41, Dan Brickley wrote:
> -2 on redefining 'Resource'.

Does this involve torches and pitchforks yet or was that -3?

> The 1997 era specs tried using it in that way, but there has never
> ever been a clear account of the class of things that are picked out
> vs rejected.

This is not about what class of things is accepted or rejected.

It's about what relationship the thing has to the URI.

The URI identifies a resource, as defined by the relevant protocol. For example, if the URI starts with http:// then you can prod the resource with a GET. We may never know what exactly it is, but we can RESTfully interact with it.

The URI denotes an entity, as defined by social convention and possibly restricted by statements made in RDF. We may never know how to actually interact with it, but we can precisely describe what it is.

As far as the technical specifications are concerned, these can be the same or these can be different. That's a matter of modelling and best practices. But it's worth acknowledging that there are two different relationships involved.

> Deciding on which things are legally RESTy in this sense
> is a huge exercise in ontologising, and not something that should be
> baked into the core concepts.

Trying to distinguish these things based on what they *are*, based on their “nature” and their “properties”, is completely futile. The TAG has committed a massive blunder by trying to do exactly that with their “information resource” definition.

> By contrast, "Resource is our word for 'thing'" is pretty straightforward to explain.

Sure, but it's not what the URI spec or the HTTP spec or REST mean when they talk about resources, and leads to more fun when we actually *need* the HTTP/REST sense, as here in the named graphs discussion.

Best,
Richard

Received on Friday, 25 May 2012 14:21:03 UTC