http resolution for URIs present in a remote dataset

[Singh Anuj]

Hi,

I am working with ShowVoc and I have registered a concrete dataset (VKG) in metadata registry. This dataset has a SPARQL endpoint http://vkg.exp.com/sparql . Registering VKG in metadata registry enable us to pull the triples/ information related to the URIs of VKG in ShowVoc UI. For e.g. http://vkg.exp.com/data/12345 is a URI/ subject of a node in VKG, if I double-click on this URI in ShowVoc UI, ShowVoc will open a modal box and display the information of the URI/ node, and ShowVoc is doing this by fetching relevant triples/ information from http://vkg.exp.com/sparql endpoint.

My question is, if there is any way by which I can also specify the http resolution rules for http://vkg.exp.com/data/.* pattern in ShowVoc and ShowVoc is able to resolve URIs like http://vkg.exp.com/data/12345.ttl by querying http://vkg.exp.com/sparql endpoint? 

Any information on this would be very helpful.

Kind regards

Anuj

[Armando Stellato]

Dear Anuj,

 

thanks for your comment, it’s a pleasure to see advanced features of ShowVoc being adopted and…even attempted to be combined :-)

 

I took some time to reply as the combination of features (resolution of external URIs through knowledge in the metadata registry – MDR – and the http resolution manager) was not meant to be part of the system (the http resolution is meant to be there for datasets managed through ShowVoc) yet, incidentally, could be obtainable somehow, with some hacking :-) So we did some testing.

 

However, it seems it is not possible, as foreseen.

 

In the HTTP Resolution Manager, you have the list of datasets hosted on ShowVoc and must configure the resolution for them, not for external ones. This could have been – in terms of the hacking I mentioned – not a stop condition, as one could have faked a dataset in order to let SV resolve external URIs, should the resolution follow the general mechanism which queries first the MDR to see where datasets for a given URI space are being hosted (locally first, then externally). However, in the case of the HTTP resolution, this passage is skipped and the dataset is queried directly, exactly because it is thought for that (and, as HTTP resolution needs to be lightweight and fast, we opted, at the time, for that solution).

I am considering this as an interesting evolution (making it in case more explicit, not solved through some hacking of the system), however I find it hard to consider it really a use case scenario. I mean, if I’m not the owner of a certain dataset, why would I provide http resolution for that external dataset? (I’m probably not even owning the domain of the URIs of the dataset). Vice versa, if I’m the owner, why not simply hosting it on ShowVoc if I want to use the http resolution offered by it? Hosting the dataset on SV is the least effort.

A corner case could be that you own domain D, you have ShowVoc (for other stuff) and you have a certain dataset owned by you which, however, is kept more up-to-date, for whatever reason, on a separate store. Is that your case?

 

Kind Regards,

 

Armando

 

 

--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/68ba606a-bf0a-423f-a320-42fa1e2b3fcdn%40googlegroups.com.

[Singh Anuj]

Hi Armando,

Correct, we have a separate dataset (virtual knowledge graph) which is accessible through a specific SPARQL endpoint, we were thinking of using ShowVoc to provide http resolution for both type of datasets (hosted on ShowVoc and hosted outside ShowVoc). In both the scenarios, we are the owners of the datasets, thus we have the control over their domain, it is just we want to avoid having multiple http resolution services and just leverage ShowVoc if we can.

Hope this clarifies.

Kind regards

Anuj 

[Armando Stellato]

Dear Anuj,

 

thanks, all clear and as expected.

It’s just, like I said, I think the added value of such a feature is minimal, as in the end ingesting the dataset periodically in ShowVoc (yes, with some data replication, but besides memory occupation, the main job is just having a workflow guaranteering that data is periodically synced from your other endpoint to ShowVoc) is not a big issue

 

Just looking for another possibility: which technology are you using for the other endpoint? If it’s RDF4J or GDB, you could just use one endpoint.

 

That said, I wouldn’t exclude the extension you mention, but I should check how much this could be a priority in the context of the funding ShowVoc gets

 

Kind regards,

 

Armando

 

 

 

 

 

.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/91b3921c-c981-4858-8a86-0dd1fa12ebden%40googlegroups.com.