Re: Expensive links in Linked Data

Thank you all for your messages and the pointers. Good to hear there is a working group working on these issues - not so good to have to wait until 2014.

@Kingsley
> Is this for Linked Data standards or Linked Data platforms to solve?

well of course platforms can help, but my question is about a recommended way to express particular things, not about how to compute them. 
It wouldn't say that it is a question of "standard" either: more a question of vocabulary. Is there a vocabulary out there that can be used in the situation I mentioned.

Note that the question of cursors (~many values for a given property) is not the only one. Here are some use-cases I have:

1) The first one is really simple:
Given :entity1, I know that there is one and only triple involving a given property (:expensiveProp):
:entity1 :expensiveProp :entity2

but the computation of the URI ":entity2" is costly. 
I have a service, at URL :entity1?prop=expensiveProp, that computes the corresponding :entity2 URI. When :entity1?prop=expensiveProp is fetched, it redirects to :entity2.

So, my first idea was to replace, in the description of :entity1, the triple:
:entity1 :expensiveProp :entity2
by:
:entity1 :expensiveProp :entity1?prop=expensiveProp

Problem is: the client, when following the link ":expensiveProp", expects to get information about ":entity1?follow=expensiveProp", not about :entity2.

To solve that, :entity1?follow=expensiveProp must not redirect to :entity2, but directly return the description of :entity2, including the statement 
:entity1?follow=expensiveProp owl:sameAs :entity2
(and probably also :entity1 :expensiveProp :entity2)

This seems to do the trick. But this requires some effort from the client: it assumes that the client takes care of the owl:sameAs (or that it aggregates the data about entity1) That's more or less OK, but it doesn't expand well to sightly more complicated situations:

2) same case:
:entity1 :expensiveProp :entity2
except that I don't know whether there is one such triple or none.

Solution above does not work: you could imagine that :entity1?prop=expensiveProp would return a 404, but you'd have already stated:
:entity1 :expensiveProp :entity1?prop=expensiveProp
This is bad. We could do the following
:entity1 :hasExpensivePropComputation :entity1?prop=hasExpensivePropComputation
and explain in the documentation the meaning of ": hasExpensivePropComputation" but this is unpleasant, in particular in a user point of view, unless there is a "standardized" way to define the semantic relation between the ":expensiveProp" and the ":hasexpensivePropComputation" properties.

What do you think of the following solution, involving a small dedicated vocabulary:

:entity1 rdfs:seeAlso [
	a v:Link;
	v:propertyLink :expensiveProp;
	v:linkedResource :entity1?link=expensiveProp
]

when GETting :entity1?link=expensiveProp, if there are one or more values for expensiveProp:
entity1 expensiveProp entity20, entity21, entity22, . 
else (no value): a 404, or nothing in the returned RDF.

In several other situations, I found it appealing to have this kind of "Link" class, so there some kind of recurring pattern here.
Note also that we could add more information in the description of the Link, such as:

:entity1 rdfs:seeAlso [
	a v:Link;
	v:propertyLink :expensiveProp;
	v:linkedResource :entity1?link=expensiveProp;
	v:equivalentSparqlQuery "CONSTRUCT {:entity1 :expensiveProp ?o} WHERE { :entity1 :expensiveProp ?o.}"
]

Thanks again,

fps

Received on Monday, 1 October 2012 10:54:16 UTC