Closed xristy closed 5 years ago
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 ?
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?
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
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
fine w/ me if there's no describe
endpoint if we don't need the service.
OK then, let's forget about /describe. We will adjust Resgraph.arq (for the rfc011 compliance) when necessary.
It will be best to change the endpoint
http://purl.bdrc.io/resource/
to actually return the entire resource, and to create a new endpointhttp://purl.bdrc.io/describe/
to provide the current functionality ofhttp://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.