search

buda-base / lds-pdi

http://purl.bdrc.io BDRC Linked Data Server
Apache License 2.0
2 stars 0 forks source link

change endpoint http://purl.bdrc.io/graph/ #126

Closed xristy closed 5 years ago

xristy commented 5 years ago

It would be helpful to change the current ldspdi endpoint http://purl.bdrc.io/graph/ to http://purl.bdrc.io/query which will then free up the former to be used as:

@prefix bdg: <http://purl.bdrc.io/graph/>

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?

xristy commented 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 :Entitys with parts like :Items and, of course, :Works 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.

MarcAgate commented 5 years ago

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 ?

eroux commented 5 years ago

I don't think we need to dissociate the /query and /graph endpoint, the result could change according to the query type...

MarcAgate commented 5 years ago

Getting an entire graph for a given resource and resource Type is just a matter of creating a new graph template.

MarcAgate commented 5 years ago

EDIT: there will be /query/table and /query/graph

xristy commented 5 years ago

thanks! this sounds like a good solution.

eroux commented 5 years ago

@xristy with the new query many use cases I had now give 404 errors. Can you please look at this doc and add a few words on what the query should return so that we can write a query that gives less 404?

xristy commented 5 years ago

@eroux I've filled in the doc. Resgraph.arg could revert to describe ?R_RES couldn't it?

MarcAgate commented 5 years ago

ResInfo.arq is now the "describe". Should we switch to it when Resgraph.arq returns a 404 ?

xristy commented 5 years ago

maybe ResInfo.arq should be used in place of Resgraph.arq except when requesting an entire top-level graph?

eroux commented 5 years ago

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

xristy commented 5 years ago

Fine ResInfo.arq for the /resource/ and Resgraph.arq for the /graph/.

xristy commented 5 years ago

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:

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

MarcAgate commented 5 years ago

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"

xristy commented 5 years ago

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

MarcAgate commented 5 years ago

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.

eroux commented 5 years ago

there is a list of parts in the library but it's completely folded by default and almost invisible, I'll report that