Fwd: Fwd: [Graph patterns as IO descriptions]
Barry Norton
John raises an interesting point about the Linked Open Services and
Linked Data Services work, which we've agreed to move on-list:
John Domingue<j.b.do...@open.ac.uk> wrote:
>>>> I think the overall issue i see with SPARQL queries is that they
>>>> are quite low level. Is your approach somehow analagous to
>>>> describing standard web services through SQL queries? Wouldn't be
>>>> hard to reason over your descriptions?
Barry Norton<barry....@aifb.uni-karlsruhe.de> replied:
>>> Could be (too low level). This has been a reaction from Dieter
>>> too. But the argument is that that's how Linked Data people think
>>> about their data.
>>>
>>> What's more reducing every syntactic input component to annotation
>>> with a single ontological class (a la OWL-S - WSMO went further
>>> and then SAWSDL based MSM approach took a step back again)
>>> demonstrably doesn't work - you cannot reason about the data
>>> exchanged.
>>>
>>> On SPARQL/graph pattern-based 'reasonability', all I can say is
>>> that the Galwayers*, then Andreas and Sebastian (see their current
>>> ESWC submission - hopefully paper) and latterly myself and the new
>>> Karlsruhe PhD, Steffen Stadtm�ller, have all been making headway on
>>> this technically.
>>>
>>> * http://www.computer.org/portal/web/csdl/doi/10.1109/SKG.2008.87
John replied:
>> I see - the general reasoning though is:
>>
>> i) 'old' approaches are broken for reasons X, Y .....
>>
>> ii) let's try something else which the LD community likes
>>
>> I understand but we need to think more from first principles on
>> what it means to integrate services and Linked Data
>>
>> thanks for the characterisation
Barry replied:
> First principles are very much the other side to what we're bringing
> together with LIDS and LOS:
>
> LIDS: The input is characterised by a canonical URI.
>
> LOS: The input should be allowed to be submitted as an RDF graph.
>
> Alignment: If this canonical URI is generated by the server (either
> characterising the whole graph, or identifying this as a stored
> resource), it should be returned in the standard Location, or
> Content-Location respectively (cf [1]), HTTP header.
>
> LIDS and LOS: The output is explicitly related to the input via this
> URI (e.g., ... foaf:basedNear ... in the reverse geolocation services)
>
> LIDs and LOS: The service should honour an Accept HTTP header
> request for RDF/XML and Turtle.
>
> Etc. etc. (all before we talk about the use of SPARQL for
> descriptions)
>
>
> Then on top of this
>
> New LOS: The service should respond to an OPTIONS HTTP request with
> an RDF-based (SPARQL-including) service representation (I'm not sure
> if this would be purely SPARQL-based in pure LIDS)
>
> [1] http://iand.posterous.com/a-guide-to-publishing-linked-data-without-red
Barry
Barry Norton
I think that's orthogonal, though, to how (which formalism) is best to
use to annotate the message. If you just annotate with classes (RDFS or
OWL) then you don't know at the semantic level what will actually be
included in the message without the use of a rule language (and I'm
aware of no query containment implementation for RIF BLD, the only
standard in this space).
Following up on your three-level distinction (which I understand, but in
recent years reject), the thing is that there is no syntactic
description to build orthogonally on with REST. There's WADL, but it's
basically only useful if your message payload is described in XML Schema
(and woefully underused even then).
Barry
On 10/02/2011 19:58, John Domingue wrote:
> Barry, in previous work we had the following separation:
>
> a) component implementation - developers free to use anything
>
> b) syntactic description - a typically XML based description
>
> c) semantic annotation - in some standard formalism
>
>
> your constraints below are all on one entity/role and seem like they
> might be a barrier to adoption. I'm thinking here more about the 5
> star system used to promote linked data in data.gov.uk and also the
> roles that brokers played in previous work.
>
> I think that any framework which will be taken up widely must
> incorporate all types of services (or at least all types of REST
> services).
>
> Maybe I'm guilty of thinking that the work below is more restrictive
> than it really is.
>
> John
>> --
>> The Open University is incorporated by Royal Charter (RC 000391), an
>> exempt charity in England & Wales and a charity registered in
>> Scotland (SC 038302).
>>
>
> _________________________________________
> Deputy Director, Knowledge Media Institute, The Open University
> Walton Hall, Milton Keynes, MK7 6AA, UK
> phone: 0044 1908 653800, fax: 0044 1908 653169
> email: j.b.do...@open.ac.uk web: kmi.open.ac.uk/people/domingue/
>
> President, STI International
> Amerlingstrasse 19/35, Austria - 1060 Vienna
> phone: 0043 1 23 64 002 - 16, fax: 0043 1 23 64 002-99
> email: john.d...@sti2.org web: www.sti2.org
>
>
>
>
>
>
>
>
John Domingue
a) REST implementor
b) Semantic Annotator
c) Semantic Repository manager
the world can happily carry on with a) while those that care do b) and
c).
Of course I don't expect you to agree with this Barry (although the
BBC world cup website descriptions talk about multiple roles) but I
think to clarify differences in thinking. I think you put too much
burden on a) [again I may be misinterpreting what you've said].
John
>>>>>> Karlsruhe PhD, Steffen Stadtmüller, have all been making
Barry Norton
Indeed, we deliberately put all the burden on (a) or, alternatively (a2)
the REST/LOS wrapper creator.
There is absolutely no canonical way to describe the whole world of REST
services - something I've heard Carlos say too. Indeed for 'real' REST,
versus HTTP APIs in general, the idea of building a complete static
description is anathema.
If, on the other hand, you follow a few principles and best practice
(which is exactly how Linked Data works), you can have an openly
accessible set of resources with which you can interact fairly
generically (by submitting and receiving RDF), without committing to
some overblown and walled-in services platform.
Put simply we combine RDF, SPARQL and all the HTTP verbs to go that bit
further than current Linked Data best practice (which works great for
data retrieval, but doesn't step much beyond it yet).
Barry
>>>>>>> Karlsruhe PhD, Steffen Stadtm�ller, have all been making headway on
John Domingue
Note though that being canonical or complete are not hard constraints
for me. There's better and worse and things in between but I would
like to be open to all types of descriptions attempting to mirror how
the Web does not care about the quality of Web pages and is lax about
even HTML syntax and data.gov.uk gives data owners 1 star for putting
up PDFs.
[but again maybe I'm caricaturing your position too much - sorry for
that]
John
>>>>>>>> Karlsruhe PhD, Steffen Stadtmüller, have all been making
Andreas Harth
On 02/10/2011 08:29 PM, John Domingue wrote:
> glad that we are clear on the differences in approaches.
it'd help me understand the differences better to see an example
of your service description format - right now, the discussion
is a bit abstract.
Best regards,
Andreas.
Barry Norton
Just a quick follow-up: which of the roles for you, John, is the one
that creates 'liftings' and 'lowerings' in the established sense?
That's (b), no?
Barry
On 10/02/2011 20:15, John Domingue wrote:
>>>>>>> Karlsruhe PhD, Steffen Stadtm�ller, have all been making headway on
John Domingue
what I'm saying is independent of any description:
a) I simply remove any restriction on REST services which can be
described
b) I describe them using some ontology which can be respresented in RDF
c) I put the RDF descriptions in some RDF reposititory with some
suitable machinery on top.
I think that Barry has restrictions at the level of a) above
John
John Domingue
different service
and (before you say so) lifting and lowering is a /real pain/
John
>>>>>>>> Karlsruhe PhD, Steffen Stadtmüller, have all been making
Andreas Harth
On 02/10/2011 09:44 PM, John Domingue wrote:
> what I'm saying is independent of any description:
>
> a) I simply remove any restriction on REST services which can be described
>
> b) I describe them using some ontology which can be respresented in RDF
>
> c) I put the RDF descriptions in some RDF reposititory with some
> suitable machinery on top.
>
> I think that Barry has restrictions at the level of a) above
interesting comments!
a) LOS have RDF as both input and output, while LIDS take name/value
parameters as input and provide RDF as output.
Describing any REST service (including HTML forms or JSON APIs) is a
bit generic if someone wants to process the output further using semantic
technology; if you have a method to cope with arbitrary output then
fine by me. LIDS and LOS then just seem to be subsets of the class
of services you plan to cover.
b) LIDS descriptions are RDF [1]. I think that won't be the final
format, but the direction should become visible. I reckon LOS descriptions
could use a similar SPARQL-in-RDF syntax, with additional triples for
things as author or policies or state.
c) As the descriptions are expressed in RDF, they can be processed with
standard RDF machinery.
It seems we have quite a few commonalities on the conceptual level. I'm
curious to see if we can also find a common ground for the actual services
and descriptions.
Best regards,
Andreas.
John Domingue
I agree that there are a lot of conceptual overlaps and as you said
earlier maybe your work is somehow a subset of what we describe. As
I've indicated we really want to be broad here in the types of
services that we cover.
For a characterisation of our formats I think the best starting place is
if you have detailed questions on our annotations then Carlos is best
positioned to answer these
cheers
John
Barry Norton
John, LIDS and LOS descriptions are not a subset of yours unless and
until we know how we should use your approach to annotate service
descriptions with graph pattern-based IO.
LIDS and LOS implementations are not a subset of yours if yours require
some infrastructure (beyond the Web) to execute (in particular to
understand and execute lifting and lowering, which I think we agree
cannot be general).
Barry
John Domingue
what i mean is that you can only work with a subset of the services on
the Web than we can so your approach covers a subset of the world that
we do.
John
John Domingue
"your work covers a subset of the available services online on the Web
that we cover"
I need to be more careful with my language
John
Barry Norton
Not true. Your approach is predicated on making liftings and lowerings
for services 'out there on the Web'.
If you can make liftings and lowerings you can expose these as wrappers
on the Web - this is what LIDS and LOS and many other people wrapping
(of RDFizing) services and APIs do. (LIDS and LOS just provide best
practice guidelines for doing so).
The difference in exposing these wrappers is that no one is required to
use some proprietary infrastructure to interact with the services (e.g.,
the SOA4All platform).
Barry
Barry Norton
Same comment. If you can lift and lower services then you can expose
them using our principles and isolate their users from the technology
you use.
Barry
John Domingue
I hadn't seen that in any of your descriptions of your approach in
emails or paper ..... so now I'm accusing you of somehow hiding away
some significant effort on the part of developers or at least not
fully incorporating that into your approach [that is fully including
the RDFizing stage].
But again I might be wrong about that.
There is the question of who does the RDFizing and in some sense it
replicates the lifting/lowering role and work.
On the last comment: when I talked to Naso about the BBC world cup
website he strongly believed that there will always be a role for
intermediaries who select some Linked Data sets and produce a cleaned
up version of the more-aligned-data for others to then create
applications on top of. I also see intermediary platforms being very
useful in niches such as web search and social networks. So again I
think we differ here too.
cheers
John
Barry Norton
Barry, if you include RDFizing of services on the Web then I agree.
I hadn't seen that in any of your descriptions of your approach in emails or paper .....
Please see also:
http://openlids.org/
Existing LIDS
In the following we link to some LIDS:
- Needs authentication.
and
http://www.linkedopenservices.org/services/
 |
Services |
Welcome to the page for active LOS! services.
At the moment these fall into three categories:
- Geo(graphical) services
-
A number of geographical LOS have been produced.
These can be divided into two categories:
- LOS! Wrappers have been produced for a number of services from geonames
- A new LOS! has been produced for spatial resources to expand on functionality offered at geonames.
[Those above are wrappers, all these below are built from scratch]
- Ontology services
-
Ontology services allow a predefined vocabulary/ontology to be stored as a resource (and will allow RDF to be submitted against it to judge consistency/return inferences).
Two types of ontology are currently supported:
- Query services
-
Query services allow a predefined query to be stored as a resource and RDF to be submitted against it (somewhat the inverse of a SPARQL endpoint).
Two types of query are currently supported:
- Transform(ation) services
-
Transform services allow a predefined transform to be stored as a resource (and will allow input docs to be submitted against it to obtain RDF/XML, i.e., 'lifting', or vice versa, 'lowering').
Only one type of transform is currently supported:
Barry Norton
>
> replicates the lifting/lowering role and work.
Why 'replicate'? The same subtasks are involved, but instead of forcing
people into the use of OWL-S-VM/WSMX/IRS/SOA4All platform you put the
results of your labours out there openly on the Web.
> On the last comment: when I talked to Naso about the BBC world cup
> website he strongly believed that there will always be a role for
> intermediaries who select some Linked Data sets and produce a cleaned
> up version of the more-aligned-data for others to then create
> applications on top of. I also see intermediary platforms being very
> useful in niches such as web search and social networks. So again I
> think we differ here too.
>
I don't think we disagree on what you're saying. We just disagree on
whether you should have to use some proprietary platform to get the
benefits.
Again, the Linked Service principles on which LIDS and LOS hope to
converge (with your input, if at all possible) just concern how to use
RDF, SPARQL and HTTP to get open, generic access to these things.
Barry
John Domingue
paper at http://linkeddata.future-internet.eu/images/1/15/FIA2010_Dynamic_Linked_Data_via_Linked_Open_Services.pdf
1. Describe services’ input and output as SPARQL graph patterns.
2. Communicate RDF by RESTful content negotiation.
3. The output should make explicit its relation with the input.
Associated with the last principle is an optional fourth:
4 Make the lifting/mapping openly available as SPARQL CONSTRUCT queries.
So yes you're right you do cover the wrapping (or lifting/lowering)
but I would say our principles are broader (no implication of better
though!)
1. Describe the service using some notation which can be mapped to the
minimal service model which is encoded in RDF. Not
2. N/A
3. N/A (but is a good engineering practice!)
4. We /should/ have lifting and lowering in soa4all with tool support
and also make the mappings explicit - I wouldn't restrict to SPARQL
though.
more comments below
On 11 Feb 2011, at 10:47, Barry Norton wrote:
> On 11/02/2011 11:32, John Domingue wrote:
>>
>> There is the question of who does the RDFizing and in some sense it
>> replicates the lifting/lowering role and work.
>
> Why 'replicate'? The same subtasks are involved, but instead of
> forcing people into the use of OWL-S-VM/WSMX/IRS/SOA4All platform
> you put the results of your labours out there openly on the Web.
not sure if I understand this one. Any Linked Data set needs to sit in
some repository right? to enable the processing of SPARQL queries
right. In iServe there's a layer on top of an RDF repository What's so
different for 'out there on the Web' for Linked Data sets that I miss?
Also there's no reason why all of our tools couldn't just serialise
any contents as XML-RDF right? not sure what 'forcing' means here.
>
>
>> On the last comment: when I talked to Naso about the BBC world cup
>> website he strongly believed that there will always be a role for
>> intermediaries who select some Linked Data sets and produce a
>> cleaned up version of the more-aligned-data for others to then
>> create applications on top of. I also see intermediary platforms
>> being very useful in niches such as web search and social networks.
>> So again I think we differ here too.
>>
>
> I don't think we disagree on what you're saying. We just disagree on
> whether you should have to use some proprietary platform to get the
> benefits.
as above - also note soa4all is open source
John
>
> Again, the Linked Service principles on which LIDS and LOS hope to
> converge (with your input, if at all possible) just concern how to
> use RDF, SPARQL and HTTP to get open, generic access to these things.
>
> Barry
>
Barry Norton
John wrote:
> 1. Describe the service using some notation which can be mapped to the
> minimal service model which is encoded in RDF.
Actually MSM plus annotations based on 'model references', right? And
(all non-IO?) annotations should be encoded in WSMO-Lite?
Even that can't be your whole principle or you'd accept MSM descriptions
with modelReferences, from MSM Input- and OutputMessages, to instances
from the SPIN RDF model (i.e. SPARQL fragments, hence LIDS and LOS
descriptions).
Your principle is that the MSM model should have message (parts)
annotated with RDFS classes whose instances are expected to be produced
by the lifting. I think (I'd appreciate clarification).
> 2. N/A
That's why the subset argument doesn't hold. This means 'your' services
are not (necessarily) open at the semantic level.
> 3. N/A (but is a good engineering practice!)
That's why using your services doesn't (necessarily) produce Linked Data.
> 4. We /should/ have lifting and lowering in soa4all with tool support
> and also make the mappings explicit - I wouldn't restrict to SPARQL
> though.
There are definitely alternatives to SPARQL. Simply pointing to classes,
though, doesn't work. And relying on WSMO-Lite for further annotations
(Conditions and Effects) doesn't work because there's no standard
language, other than SPARQL, for which the machinery exists to make
clear what is communicated (semantically).
> not sure if I understand this one. Any Linked Data set needs to sit in
> some repository right? to enable the processing of SPARQL queries
> right. In iServe there's a layer on top of an RDF repository What's so
> different for 'out there on the Web' for Linked Data sets that I miss?
I'm not talking about service descriptions - iServe makes service
descriptions into Linked Data, this is great. No arguments.
But I'm talking about service interactions. I.e., what you get when you
call the service.
> Also there's no reason why all of our tools couldn't just serialise
> any contents as XML-RDF right? not sure what 'forcing' means here.
And Google could expose their crawl data and indices as RDF. But
unless/until they do that's not Linked Data.
> as above - also note soa4all is open source
>
Sure. And you might plunder it for machinery to make open services. We have.
Barry
John Domingue
for 2 and 3 you have restrictions and we don't - so we are broader
for 4 "doesn't work" doesn't mean a lot. What I mean is that one can
be open to all types of descriptions without prescribing certain types.
> But I'm talking about service interactions. I.e., what you get when
> you call the service.
still don't understand what or who we are forcing.
John
Barry Norton
> still not convinced Barry
>
> for 2 and 3 you have restrictions and we don't - so we are broader
>
Sure. In the sense that someone who doesn't necessitate use of any
semantic / Linked Data technologies at all is the broadest.
In the sense that PDF is 'broader' than Linked Data. (Doesn't seem to
mean much.)
Practically, though, if all LIDS / LOS service have descriptions that
are iServe descriptions (which is surely implied by your argument having
any deeper meaning) then how should we use SWEET/SOWER to annotate their
descriptions and store them in iServe?
> for 4 "doesn't work" doesn't mean a lot. What I mean is that one can
> be open to all types of descriptions without prescribing certain types.
Again, the underlying question is: using the available machinery can one
tell what, in terms of Linked Data, one can expect to obtain from
interacting with a service?
If you just annotate with classes the answer is no.
That matters if you're going to build a Linked Data-oriented application
(like the BBC World Cup system) with third party services.
>> But I'm talking about service interactions. I.e., what you get when
>> you call the service.
>
> still don't understand what or who we are forcing.
So show me a service that I can interact with over HTTP, using only
Linked Data technologies (RDF and SPARQL) without being 'on a bus' or
'in an execution environment'.
Barry
John Domingue
On 11 Feb 2011, at 12:49, Barry Norton wrote:
> On 11/02/2011 13:31, John Domingue wrote:
>> still not convinced Barry
>>
>> for 2 and 3 you have restrictions and we don't - so we are broader
>>
>
> Sure. In the sense that someone who doesn't necessitate use of any
> semantic / Linked Data technologies at all is the broadest.
>
> In the sense that PDF is 'broader' than Linked Data. (Doesn't seem
> to mean much.)
don't agree. In the sense that "Semantic Web is and extension of the
Web" and all approaches should take them into account. As far as I see
I don't see any advantage in what you do over us in this respect.
>
>
> Practically, though, if all LIDS / LOS service have descriptions
> that are iServe descriptions (which is surely implied by your
> argument having any deeper meaning) then how should we use SWEET/
> SOWER to annotate their descriptions and store them in iServe?
>
>
>> for 4 "doesn't work" doesn't mean a lot. What I mean is that one
>> can be open to all types of descriptions without prescribing
>> certain types.
>
> Again, the underlying question is: using the available machinery can
> one tell what, in terms of Linked Data, one can expect to obtain
> from interacting with a service?
don't agree that you should get this from interacting with a service -
places too much burden and i see no reason why this functionality
should be fixed there
>
> If you just annotate with classes the answer is no.
easy to build on this though and places less burden on developer
>
> That matters if you're going to build a Linked Data-oriented
> application (like the BBC World Cup system) with third party services.
>
>
>>> But I'm talking about service interactions. I.e., what you get
>>> when you call the service.
>>
>> still don't understand what or who we are forcing.
>
> So show me a service that I can interact with over HTTP, using only
> Linked Data technologies (RDF and SPARQL) without being 'on a bus'
> or 'in an execution environment'.
this is not useful - i mean providing this functionality is not useful
John
Barry Norton
As far as I see I don't see any advantage in what you do over us in this respect.
using the available machinery can one tell what, in terms of Linked Data, one can expect to obtain from interacting with a service?
don't agree that you should get this from interacting with a service - places too much burden and i see no reason why this functionality should be fixed there
If you just annotate with classes the answer is no.
easy to build on this though and places less burden on developer
I'm not sure what you mean with 'build on', but if I'm going to build with services I'd like to understand what I'll get from them.
So show me a service that I can interact with over HTTP, using only Linked Data technologies (RDF and SPARQL) without being 'on a bus' or 'in an execution environment'.
this is not useful - i mean providing this functionality is not useful
Barry
John Domingue
On 11 Feb 2011, at 13:06, Barry Norton wrote:
> On 11/02/2011 13:56, John Domingue wrote:
>>
>>
>> As far as I see I don't see any advantage in what you do over us in
>> this respect.
>>
>
> A positive answer to this:
>
>>> using the available machinery can one tell what, in terms of
>>> Linked Data, one can expect to obtain from interacting with a
>>> service?
>>
> But:
>
>> don't agree that you should get this from interacting with a
>> service - places too much burden and i see no reason why this
>> functionality should be fixed there
>
> OK. But how should I know? By reading XSLT? Or natural language
> descriptions?
>
something like the more there is the more functionality you get
>
>
>>> If you just annotate with classes the answer is no.
>>
>> easy to build on this though and places less burden on developer
>
> It's less burden for the developer, but so is publishing PDF rather
> than RDF.
>
> I'm not sure what you mean with 'build on', but if I'm going to
> build with services I'd like to understand what I'll get from them.
>
>
>>> So show me a service that I can interact with over HTTP, using
>>> only Linked Data technologies (RDF and SPARQL) without being 'on a
>>> bus' or 'in an execution environment'.
>>
>> this is not useful - i mean providing this functionality is not
>> useful
>
> OK. That's a difference in philosophy. Let's just agree to disagree
> there.
OK. but to provide SPARQL one needs some sort of RDF repository and to
find a web page one needs a web search engine.
Andreas Harth
On 02/11/2011 02:10 PM, John Domingue wrote:
> OK. but to provide SPARQL one needs some sort of RDF repository and to
> find a web page one needs a web search engine.
yes you might need an RDF repository/registry or a web search engine
for discovery. However, in a layered approach, the technology which
provides access to a service and the technology which allows for
discovery can be built and operated by different organisations.
An analogy could be the web architecture (you don't have to use Google
infrastructure to publish a web page) vs. Facebook architecture (where
most of the functionality runs on their platform).
Let's say both architectures can be useful and have their merits, and
which one you choose is a matter of personal taste.
Best regards,
Andreas.