Closed xristy closed 5 years ago
Upon further reflection, some endpoint must be available to retrieve an entire graph since http://purl.bdrc.io/resource/XXX
currently only retrieves the result of a SPARQL describe
which doesn't actually return the entire entity resource - as it would be seen in a file from the git repo.
This applies particularly to :Entity
s with parts like :Item
s and, of course, :Work
s which have parts that are not included in the describe
results.
It's somewhat counter-intuitive that URLs of the form http://purl.bdrc.io/resource/...
doesn't return the entire resource.
Taking a look at the http://purl.bdrc.io/ home page, you'll see that the http://purl.bdrc.io/query
endpoint is already taken and always returns results of type table, or csv or json, etc.., while the endpoint http://purl.bdrc.io/graph/
always returns a graph by default serialized as jsonld.
Therefore we should rename the http://purl.bdrc.io/graph/
endpoint as something else than http://purl.bdrc.io/query
. Could be something like http://purl.bdrc.io/jsgraph/, WDYT ?
I don't think we need to dissociate the /query
and /graph
endpoint, the result could change according to the query type...
Getting an entire graph for a given resource and resource Type is just a matter of creating a new graph template.
EDIT: there will be /query/table
and /query/graph
thanks! this sounds like a good solution.
@eroux I've filled in the doc. Resgraph.arg could revert to describe ?R_RES
couldn't it?
ResInfo.arq is now the "describe". Should we switch to it when Resgraph.arq returns a 404 ?
maybe ResInfo.arq should be used in place of Resgraph.arq except when requesting an entire top-level graph?
I think not answering RDF when querying a URI is kind of a red line for me... I think Resgraph.arq is well adapted to the /graph
endpoint, I would suggest adjusting the query used by the /resource
endpoint to return some triples for each URI in the system
Fine ResInfo.arq for the /resource/ and Resgraph.arq for the /graph/.
So during today's conference call we had a brief discussion about this and I think we concluded that we want to have the http://purl.bdrc.io/resource/
endpoint be able to deliver both full graphs and describe results based on:
http://purl.bdrc.io/resource/W12827?graph
or http://purl.bdrc.io/resource/W12827?describe
describe
be default so http://purl.bdrc.io/resource/W12827
is equivalent to http://purl.bdrc.io/resource/W12827?describe
It is desirable to implement both the profile and the query parameter approaches since the query parameter is easier to enter into the address bar on a browser and the profile may be more useful for scripts.
There is also a possible extension like approach, http://purl.bdrc.io/resource/W12827.graph
or perhaps http://purl.bdrc.io/resource/W12827/describe
.
In summary the http://purl.bdrc.io/resource/
endpoint/namespace should be allowed to serve various forms of the metadata content.
The http://purl.bdrc.io/graph/W12827
can be treated as a synonym for http://purl.bdrc.io/resource/W12827?graph
Implemented as of commit dfafdb2 It is also possible to request any serialization of the resulting graph, as follows: http://purl.bdrc.io/resource/W22084.json?graph profile header based config is not implemented yet: which mechanism should prevail when we have both a header and a query parameter ? (i.e -H "profile:describe"} and http://purl.bdrc.io/resource/W22084?graph) I know it should not happen, but it's possible...
default behaviour is "describe"
Looking good. As for your question, I don't know whether profile or query parameter should take precedence. I could also see some sort error.
When I try http://purl.bdrc.io/resource/W22084
that goes to library with a describe result - btw w/o a list of parts(?)
When I try http://purl.bdrc.io/resource/W22084.ttl
I get the entire graph rather than the describe so it doesn't appear that the default is describe in this case
When I try http://purl.bdrc.io/resource/W22084.ttl?describe
I do get a describe result which includes the list of parts so it appears that library app is missing the parts list somehow
The default has been corrected now. Everything looks ok and yes, it seems like the library is missing parts. Now, is the header profile option really brings more to the service ? If so, I'll implement it and throw an exception when header values and query params are not consistent.
there is a list of parts in the library but it's completely folded by default and almost invisible, I'll report that
It would be helpful to change the current ldspdi endpoint
http://purl.bdrc.io/graph/
tohttp://purl.bdrc.io/query
which will then free up the former to be used as:The
bdg:
namespace will refer to Named graphs.This change will of require some alternative means to indicate that the expected results of a query will be a graph rather than a table or csv or json, etc.
Could there be a uniform way of indicating the requested form of the results of a query?