Question regarding Implementing Linked Open Services

[Mohsen Taheriyan]

I tried to implement a sample of Linked Open Service (LOS) for myself,
but I faced a problem. I really appreciate if you can help me on this.

I describe my problem with an example. Suppose that we have a RDF
store and two web services.

WS1:
consumes:
{?x a wgs84:Point;
wgs:lat ?lat;
wgs:long ?long}

produces:
{?x myontology:in ?y .
?y a myontology:City;
?y myontology:hasName ?z}
----------------------------------------------
WS2:
consumes:
{?x a myontology:City;
myontology:hasName ?y}

produces:
{?x weather:celsiusTemperature ?z .}
----------------------------------------------
Initial RDF Store:
(p1, rdf:type, wgs84:Point)
(p1, wgs84:lat, 12.765)
(p1, wgs84:long, -23.467)


Ok, I am trying to chain these two web services. My problem is that if
the first webservice does not provide URI for the generated City, how
I can link the output data of second webservice to my rdf store.

For example, the first webservice returns me these rdf statements:
(p1, myontology:in _:n1)
(_:n1, rdf:type, myontoloy:City)
(_:n1, myontology:hasName, "Los Angeles")

I put all the output directly into my rdf store. Then my rdf store
would be like this:

p1 a wgs84:Point ;
myontology:in
[ a myontology:City ;
:hasName "Los Anegeles" ;
] ;
wgs84:lat "12.765" ;
wgs84:long "-23.467" .

Now, when I execute the consumption SPARQL construct of second web
service on my rdf store. It gives me blank nodes: ([], rdf:type,
myontology:City) , ([], myontology:hasName, "Los Angeles").

If I give these two rdf statements as input to the WS2, I cannot ling
the output to my existing rdf statements in rdf store.

I could not get from your papers how I can overcome this problem.
Maybe I'm missing a point. I would be very grateful if anybody can
help me.

[Reto]

Hello!

You indeed outline an interesting problem, however, in my opinion not
one that is really based on the principles of linked services, but
much more on a fundamental issue with reading and writing blank nodes
from RDF stores. In fact, what the initial Linked Open Services
principles required was the linking of input and output resources, so
as to connect the pre-state directly to the post-state of a service's
knowledge base. In other words, the output of WS1 should make the
relationship between the input and the output clear, and so should
WS2, in particularly for the fact that from the output graph alone it
would not be clear which temperature you refer too - and in fact, that
is exactly the problem you are suffering from here... According to the
suggestions from the Linked Open Service principles, the description
of WS2 should be:

----------------------------------------------
WS2:
consumes:
{?x a myontology:City;
myontology:hasName ?y}

produces:

{?x myontology:hasName ?y ;

weather:celsiusTemperature ?z .}
----------------------------------------------

This already greatly helps in approaching your problem.

There is also a second advise that I personally would give you, and
that is not related to linked service principles but to the actual
implementation of your WS1. I strongly suggest that you avoid
returning a blank node for the city if there is a means to do so...
this would also help, in addition to the conformance to principle 3;
although the currently published principles on linkedopenservices.org
do no longer explicitly reflect the idea of providing the link between
input and output after the execution of a service.

Hope these thoughts help you further...

Best,
Reto

[Steffen Stadtmüller]

Hi,

in general I agree with Reto: the problem here is, that the relation
between input and output is not clear in WS2. However, your service
description is fine and claims this relationship with ?x, the problem
lies in your input data. In general I would strongly discourage using
input data, that allows save variables (i.e., variables that appear in
input and output description) to be bound with blanks.

A Change of the service description as proposed by Reto solves your
problem to some extend, but would still lead to some problems:
Consider an example with INPUT:

[ a myontology:city;
myontology:hasName "hometown"]

and OUTPUT:
[ myontology:hasName "hometown";
weather:celsiusTemperature "30"]

Semantically speaking the service would return a temperature of
something that has the same name as the city described in the INPUT
(but not necessarily the same thing). Your service description on the
other hand claims that you give the temperature of the described city
(by using ?x as save variable).
So the best solution would be to identify the city with a real URI (as
Reto suggested), or if you have no way of doing so, you should go all
the way and change the service description to:

----------------------------------------------
WS2:
consumes:
{ [ a myontology:City;
myontology:hasName ?y ] }
produces:
{ [ myontology:hasName ?y ;
weather:celsiusTemperature ?z ] }
----------------------------------------------

because that is what your service does, really.

Another real dirty solution to your specific problem (just working on
a single triplestore) would be to SELECT the blanknode and holding it
programmatically (depending on your implementation e.g. as a java
variable of Type "RDFNode"). Then you could build the new triple with
temperature using exactly the same blanknode as subject and save this
triple back to your store. so your store would hold:
[ a myontology:city;
myontology:hasName "hometown";
weather:celsiusTemperature "30"]

This would make use of the fact, that most implementations use
internal identifiers for blanknodes, which you would reuse. But
considering that it should be possible to call a Linked Service "from
the outside" in a RESTful style (i.e. HTTP POST the INPUT to it and
getting RDF as response), this way certainly is more of a hack than a
real solution.

hope this was helpful.

Regards,
Steffen

[Barry Norton]

In general though, we might like to be able to expect (or promise) that certain parts of the output, unrelated to the input, are delivered as identified resources, not as blank nodes.

There are two troublesome 'solutions' here:

1) The built-in to say something is a URI belongs (correct me if I'm wrong) in a FILTER, which we wanted to avoid

2) It's only from Linked Data best practice that we expect a resolvable URI, it might be even nicer to mix a (resource-oriented) service model to explicitly say that the identified resource is GETtable (even that it is DELETEable, or POSTable with itself a graph-pattern-based IO).

On the one hand the latter, and possibly mixing the IO and service model, is always what I had in mind for Linked Services.

On the other this may be overkill and reduce the (rather widely affirmed, now) comprehensibility of our descriptions.

Thoughts?

Barry

[Steffen Stadtmüller]

Well, I agree that only relying on SPARQL, we would have to use a
FILTER to assure that a variable is bound only by resolvable URIs.
This might be the best solution for the problem, even though it makes
things in other areas much more complicated.

Another way would be to define a Linked Service Vocabulary/Schema,
which could (if required) be used in the service descriptions/
templates. Such a vocabulary would allow (among other things) to
describe common service failures, that might occur and also state that
certain resource will be resolvable, e.g.:
?x a linkedService:resolvableResource

From a technical point of view this still would not prevent ?x to be
bound with a blank, but at least a service designer could claim it.
Still, I don't like this solution.

The third way (how it is right now) is to hand this problem over to
the service consumer: everybody retrieving RDF via a linked service,
who relies on some resources to be resolvable has to verify this by
ASKing the output. So at this point the service consumer would have to
use the FILTER (and should be able to do so without problems) , we
don't want in the service descriptions.

Steffen

[Barry Norton]

Problem is that if you're (design time) composing this is precisely the
kind of thing you want to know ahead of invocation.

That's precisely why I think it's a problem that needs thought.

Barry

>> On Wed, Jul 13, 2011 at 10:49 AM, Steffen Stadtm�ller<

[Steffen Stadtmüller]

This is certainly true.

On the other hand: In scenarios where a service response (always)
provides blanks at a certain node, a blank should be used in the
description as well (hence, we are talking about unsave variables).
And in case sometimes it is a blank node and sometimes a resolvable
URI (I wonder if there are a lot of these cases), the description
could still look like:
{ { ?x a ex:something }
UNION
{ [] a ex:something } }

But then again, this would imply that variables will always be bound
by URIs, which is kind of counterintuitive to the original SPARQL
semantics...

Steffen

[Mohsen Taheriyan]

> In other words, the output of WS1 should make the relationship between
> the input and the output clear, and so should WS2

I don't understand why you are saying that there is no relation
between input and output in my service descriptions. I was assuming
that the variable ?x (a resource) is supposed to establish a link
between them. My description is very similar to the description of
GeoName search service you gave on your papers:
input "?x geo:name ?name ."
output "?x wgs84:lat ?lat; wgs84:long ?lng ."
Maybe my thoughts on third principle of LOS is wrong. Would you please
clarify this more?

[Reto Krummenacher]

The variable alone is not enough to make the connection, in particular
if you bind the variable to blank nodes which have no "connectivity"
value beyond the particular graph they are used in. In other words,
you can name your variables as you like in the service descriptions,
as the binding is not provided by the variable names but by the shared
resources between input and output.

best,
reto