describe versus resource

[xristy]

It will be best to change the endpoint http://purl.bdrc.io/resource/ to actually return the entire resource, and to create a new endpoint http://purl.bdrc.io/describe/ to provide the current functionality of http://purl.bdrc.io/resource/.

The problem w/ the current behavior is that we advertise the namespace, http://purl.bdrc.io/resource/, to be the namespace of entire managed resources not an abstract or summary of the resource.

[MarcAgate]

This has been addressed in https://github.com/buda-base/lds-queries/commit/99c08c781436d9252ceb980eedd61f0c5447fe29 . Do we really need to have a dedicated /describe endpoint ? Who is gonna be interested in it now we have a full model through the /resource endpoint ?

[xristy]

There was a reason that you were using describe for http://purl.bdrc.io/resource/ references.

I don't see that the reason has become moot. It still seems reasonable to provide the summary benefits of describe. So one solution is to provide a describe endpoint. Do you have another solution?

[eroux]

I think the idea of the describe query was just to return the triples about the resource, I don't think anyone is interested in a describe per se, especially since names and events will have URIs so they won't appear in the describe anymore... let's forget about the describe/ endpoint

[xristy]

BTW once the rfc011 stuff is completed then the graph will be bdg:XXXX rather than bdr:XXXX so the Resgraph.arq will need to be adjusted once the rfc011 version of the overall dataset is deployed

[xristy]

fine w/ me if there's no describe endpoint if we don't need the service.

[MarcAgate]

OK then, let's forget about /describe. We will adjust Resgraph.arq (for the rfc011 compliance) when necessary.