-
Notifications
You must be signed in to change notification settings - Fork 2
/
SADI-W3C-Member-Submission.html
1574 lines (1279 loc) · 68.5 KB
/
SADI-W3C-Member-Submission.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>Semantic Automated Discovery and Integration</title>
<meta charset='utf-8'/>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "Member-SUBM",
shortName: "SADI",
previousMaturity: "FPWD",
previousPublishDate: "2016-1-25",
localBiblio: {
"OWL-S": {
title: "OWL-S: Semantic Markup for Web Services",
href: "https://www.w3.org/Submission/OWL-S/",
publisher: "W3C"
},
"WSMO": {
title: "Web Service Modeling Ontology (WSMO)",
href: "https://www.w3.org/Submission/WSMO/",
publisher: "W3C"
},
"REST": {
title: "Representational State Transfer (REST)",
href: "https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm",
authors: [
"Roy Fielding"
]
}
},
logos: [
{
src: "http://sadiframework.org/content/wp-content/themes/SADI/images/sadi-header.png",
href: "http://sadiframework.org",
alt: "SADI - Semantic Automated Discovery and Integration",
width: 300,
id: 'SADILogo'
}
],
authors: [
{ name: "Mark Wilkinson",
url: "http://wilkinsonlab.info/",
company: "CBGP-UPM",
companyURL: "http://www.cbgp.upm.es/"
},
{ name: "Benjamin Vandervalk",
url: "https://www.linkedin.com/in/ben-vandervalk-8a65401",
company: "Michael Smith Genome Sciences Centre, BC Cancer Agency",
},
{ name: "Luke McCarthy",
url: "https://www.linkedin.com/in/elmccarthy",
},
],
editors: [
{ name: "Michel Dumontier",
url: "http://semanticscience.org/",
company: "Stanford University",
companyURL: "http://www.stanford.edu/"},
{ name: "Chris Baker",
url: "",
company: "University of New Brunswick",
companyURL: "http://www.unb.ca/"
},
{ name: "Alexander Ryazanov",
url: "",
},
{ name: "Mikel Egaña Aranguren",
url: "",
},
],
wg: "HCLS",
wgURI: "https://www.w3.org/blog/hcls/",
wgPublicList: "",
wgPatentURI: "",
};
</script>
</head>
<body>
<section id='abstract'>
<h2></h2>
<p>
This document describes Semantic Automated Discovery and Integration
(SADI), a set of design patterns defining the behavior of data retrieval and/or analysis resources
that must interoperate on the Semantic Web. These behaviors facilitate
the native use of Semantic Web data as input, facilitate the integration of output data back into
the Semantic Web, and facilitate semantic discovery of the resource itself.
With SADI, interoperability and Semantic Web integration depend on two features:
(a) the shared use of predicate vocabularies, rather than shared Schemas or <i>ad hoc</i>
data formats, and (b) requiring that the resource creates an explicit semantic relationship (predicate) connecting
the input and output data.
We present a specification that applies these design patterns
to the case of Web Services. In this specification, OWL is used to
describe service input and output datatypes, and RDF data is consumed and produced
natively through service invocations via HTTP POST. SADI Web Services enable: i)
automated discovery of services that provide data or computations of
interest, and ii) automated matchmaking between local data and
available services. By iterative application of these two
capabilities, SADI enables semi-automated construction of arbitrarily
complex workflows across independent service providers.
</p>
</section>
<section id='sotd'>
<p>This document is governed by the <a id="w3c_process_revision" href="https://www.w3.org/2015/Process-20150901/">1 September 2015 W3C Process Document</a>. </p>
</section>
<section class='conformance'>
<h2>Conformance</h2>
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST, MUST NOT, REQUIRED,SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [[RFC2119]].
</section>
<br/><br/>
<section id='sadipatterns'>
<h2>SADI Design Patterns</h2>
SADI specifies <b>only three</b> behaviors that must be true of all implementations, and one behavior that must be true of any public-facing implementation:
<ol>
<li>The resource MUST consume and produce RDF data natively</li>
<li>The resource MUST return the same individuals/instances that it consumed - i.e. the root URI(s) of the RDF graph(s) it consumed MUST be the root URI(s) of the RDF graph(s) returned.</li>
<li>New data created by the resource MUST be connected to that URI (directly or indirectly) by an RDF predicate</li>
<li>All resources SHOULD, and public-facing resources MUST, provide descriptive metadata following
the <a href='http://www.nature.com/articles/sdata201618'>FAIR Data Principles</a>.
This MUST include descriptors of the input and output data (in RDF Schema, OWL, or other widely-accepted descriptive format),
and SHOULD include:
<ul>
<li>a semantically marked-up description of the functionality of the resource and/or the operations that lead to the output</li>
<li>human and, when possible, machine-readable citation information, including author of the resource, versions of software it uses, and other relevant metadata</li>
</ol>
These behaviors result in a wide range of consequences that facilitate interoperability and integration with other Semantic Web resources:
<ul>
<li>Linked data does not need to be transformed before being passed into the resource.
As such, the semantic content of the graph is preserved.
This cannot be guaranteed when converting data into, for example, XML or other non-semantic data structures</li>
<li>Because the output must be linked to the input,
the result of accessing the resource is an unbroken chain of linked data,
centered on the input URI. In effect, all resources have exactly the same function - that is, to 'annotate' the input data.</li>
<li>Because the input and output graphs are rooted in the same node (URI),
there is no need for any additional messaging structure for multiplexed access.
The resource might consume many inputs simultaneously, but there is no need (on either side
of the transaction) to monitor or record the identity or order of these multiple inputs/outputs.
The client simply merges the output into the existing graph, and it aligns correctly based on the shared URI.</li>
</ul>
<p>Adhering to these design patterns are the only requirements for SADI-compliance, and can be applied to any transaction-based resource.
Additional utility can be gained by, for example, creating a searchable index of the resource descriptors; however,
these are only a requirement for resources intended to be used by third-parties.</p>
</section>
<br/>
<section id='sadiwebservices'>
<h2>Applying SADI to the Web Services case</h2>
<section id='summary'>
<h4>Summary</h4>
<p>
SADI Semantic Web Services defines a set of behaviors and design patterns
for implementing stateless web
services that natively consume RDF data as input and generate RDF
data as output. Its primary purpose is to increase the
interoperability of services across independent providers. Under
SADI, the schemas for the input and output RDF data of a service are
defined by the service's <i><i>input OWL class</i></i> and <i><i>output OWL class</i></i>,
respectively. Provider-specified metadata about a service, including
the URIs of the input and <i>output OWL class</i>es, is published as an RDF
document that is retrievable by an HTTP GET on the service URL.
Service invocation is accomplished by issuing an HTTP POST request to
the service URL with an appropriate <i>input RDF document</i> as the request
body. The <i>input RDF document</i> contains one or more instances of the
<i>input OWL class</i> which represent independent inputs to the service,
and in response the service returns an <i>output RDF document</i> with a
corresponding number of instances of the <i>output OWL class</i>. Each
<i>output instance</i> has the same root URI as its corresponding input
instance, in order to ensure that the data consumed and generated by
the service are explicitly linked.
</section>
<section id='introduction'>
<h4>Introduction</h4>
The principal benefit of web services is that they enable widespread
and convenient reuse of software components, independent of the
larger applications or goals being realized by the client software.
However, in the current climate of WSDL/XML [[WSDL]] and RESTful
services [[REST]], the successful implementation of web service clients
still depends on detailed human knowledge of the particular services
being used. For WSDL/XML services, software developers must be
familiar with the particular XML schemas consumed and generated by a
service and must implement transformations of local application data
to and from those schemas as necessary. Automatic code generators
for WSDL clients assist in this task, but developers must still
understand the structure of the input/output data and the meaning of
the various components. Likewise, developers of RESTful clients must
be familiar with the semantics and permitted values of the named
parameters for each service and must implement transformations on the
service output data as necessary. The requirement on software
developers to learn and accomodate the particular interfaces and data
schemas of each service has a high cost in terms of human labour.
Moreover, variability in the design of schemas and interfaces creates
obstacles for the coordinated use of web services across different
providers.
<br/><br/>
SADI addresses the variability of data representation through the use
of Semantic Web standards, namely RDF [RDF] and OWL [OWL]. As these
standards have been specifically designed to facilitate integration
and processing of data across multiple sites, they possess
significant advantages over XML and ad hoc data formats for encoding
web service input/output. In particular, RDF enables automated
merging of data sets and OWL enables automated logical reasoning over
data. Meaningful data integration always requires some level of
agreement between providers regarding data representations. However,
under SADI, providers must only agree at the more granular level of
predicate vocabularies, rather than on complete representations of
datatypes.
<br/><br/>
SADI addresses the variability of service interfaces by proposing
conventions for retrieving metadata about services and for invoking
services. Briefly, metadata about a service is retrievable as an RDF
document by issuing an HTTP GET to the service URL, while service
invocation is realized by issuing an HTTP POST to the service URL
with an <i>input RDF document</i> as the request body. The response to a
service invocation is likewise an RDF document.
</section>
<section id='terminology'>
<h4>Terminology</h4>
Readers of this document are expected to have a general familiarity
with the HTTP protocol [[RFC2616]], RDF [[RDF-SYNTAX]], and OWL [[owl-features]]. In
addition, this document uses the following SADI-specific terminology:
<ul>
<li><i>input OWL class</i> -- an OWL class that defines the required
structure (i.e. schema) of a single input to a SADI service. Each
SADI service has exactly one <i>input OWL class</i>.</li>
<li><i>input instance</i> -- an RDF node that is an instance of the input
OWL class for a given SADI service, and thus is a valid input for
that service. In general, an RDF node is an instance of an OWL class if it satifisies the property restrictions of the OWL class.
Membership of an RDF node in a given OWL class can be determined
using an OWL reasoner or can be directly asserted by assigning an
rdf:type value that is equal to the OWL class URI.</li>
<li><i>input RDF document</i> -- a document containing one or more input
instances for a SADI service. A SADI service is invoked by
issuing an HTTP POST to the service URL with the input RDF
document as the request body.
<li><i>output OWL class</i> -- an OWL class that defines the required
structure (i.e. schema) of a single output from a SADI service.
Each SADI service has exactly one <i>output OWL class</i>.</li>
<li><i>output instance</i> -- an RDF node that is an instance of the output
OWL class for a given SADI service, and thus is a valid output for
that service. In general, an RDF node is an instance of an OWL
class if it satifisies the property restrictions of the OWL class.
Membership of an RDF node in a given OWL class can be determined
using an OWL reasoner or can be directly asserted by assigning an
rdf:type value that is equal to the OWL class URI.</li>
<li><i>output RDF document</i> -- the result of a SADI service invocation,
which contains one or more <i>output instance</i>s. For a given service
invocation, the number of <i>output instance</i>s in the output RDF
document should be equal to the number of <i>input instance</i>s in the
<i>input RDF document</i>. Further, the URIs of corresponding input and
<i>output instance</i>s are always equal.</li>
<li><i>service execution parameter</i> -- a value which is separate from
the <i>input instance</i>s for a service invocation, but affects how the
<i>input instance</i>s are processed. For example, a "Hello, World!"
service that returns a natural language greeting might have a
<i>service execution parameter</i> indicating the desired output language
for the greeting.</li>
<li><i>parameter OWL class</i> -- an OWL class that defines the required
structure (i.e. schema) of <i>service execution parameter</i>s for a SADI
service. Similarly to input and <i>output instance</i>s, service
execution parameters may have arbitrarily complex representations
in RDF. The <i>parameter OWL class</i> describes a graph that contains
<i>all</i> <i>service execution parameter</i>s. If a service has multiple
execution parameters, their RDF representations must be connected
in a single RDF graph that is an instance of the parameter OWL
class.</li>
<li><i>parameter instance</i> -- an RDF node that is an instance of the
<i>parameter OWL class</i> for a given SADI service, and thus is a valid
set of execution parameters for that service. The input RDF
document for a service invocation may contain at most one
<i>parameter instance</i>, which affects the processing of all input
instances within the <i>input RDF document</i>.</li>
<li>default parameter instance</i> -- an instance of the parameter OWL
class that represents the default values for all service execution
parameters. These values are used when an <i>input RDF document</i> does
not explicitly specify values for execution parameters.</li>
</ul>
</section> <!-- close terminology-->
<section>
<h4>Motivation</h4>
The original motivation for the development of SADI was the
complexity of discoverying, accessing, and integrating public data
and software in the domain of bioinformatics. While there are
currently thousands of interrelated bioinformatics databases and
software tools freely available on the web, they are published using
a plethora of incompatible data models, schemas, and software
interfaces that impedes their combined use. The authors sought to
develop a set of best practices for publishing data and software
resources that would simultaneously offer the benefits of Semantic
Web standards and technologies, such as the ability to automatically
merge data sets and to automatically compute logical inferences from
data.
<br/><br/>
While the development of SADI has been motivated by bioinformatics,
there is nothing that prevents its application to other domains. It
is applicable in any scenario where integrating data and/or software
across multiple sites is required.
</section><!-- close motivation-->
<section>
<h4>Design Goals:</h4>
<section>
<h4>Interoperability with the Semantic Web</h4>
One of the primary goals of SADI is to create web services that are
compatible with the Semantic Web. In particular, it is desirable that
services should be able to exchange data directly with various
consumers and producers of RDF data such as triple stores, static RDF
documents, OWL reasoners, and RDF browsers. For this reason, SADI
services consume a standard RDF document as input and generate a
standard RDF document as output.
<br/><br/>
Another key point of compatibility with the Semantic Web is the use
of OWL to define the requirements for the input data, output data,
and execution parameters of a service. This permits the use of an
OWL reasoner as the main vehicle for data and service matchmaking
tasks, such as:
<ul>
<li>identifying services that can consume a subset of a given RDF
graph as input</li>
<li>extracting <i>input instance</i>s for a service from a given RDF graph</li>
<li>matching the output interface of one service to the input
interface of another service, in order to create service execution
chains (workflows)</li>
</ul>
The intent of SADI is to facilitate the use of web services within
Semantic Web applications. For example, the authors have developed a
prototype query engine called SHARE [SHARE] that integrates SADI
services with a SPARQL query engine, a triple store, and an OWL
reasoner in order to answer queries over the data that can be
generated by a collection of SADI services.
</section><!-- close interoperability-->
<section>
<h4>Stateless Services</h4>
The scope of SADI is limited to stateless services so that services
and clients can be implemented in a straightforward manner, at the
expense of certain types of advanced applications. The set of
stateless services includes services that perform any type of data
retrieval or data analysis, but excludes services that effect changes
in the real world. A common example of the latter type of service is
a service that makes a withdrawal from a bank account. Previous
Semantic Web Service standards such as WSMO and OWL-S have been
developed to model such stateful services. However, the formal
description of stateful services is complex, and the design of
software agents to coordinate such services is an ongoing research
problem.
</section><!-- close stateless-->
<section>
<h4>Batch Processing of Inputs</h4>
In order to minimize overhead due to network latency, it should be
possible to group independent inputs for a service into a single
request, and to receive the corresponding outputs in a single
response. In SADI, the <i>input RDF document</i> for a service invocation
may contain any number of <i>input instance</i>s which represent independent
inputs to the service. Likewise, the <i>output RDF document</i> may contain
any number of independent <i>output instance</i>s.
</section> <!-- close batch-->
<section>
<h4>Support for Long-running Services</h4>
The processing time of a service should not be limited to the
lifetime of a TCP connection. Asynchronous SADI services support long-running computations by means of client polling and HTTP
redirects, as described in Asynchronous Services (Section 10.2).
</section> <!-- close long running-->
<section>
<h4>Explicit Relationship Between Service Input and Output</h4>
It is desirable to ensure that related input and <i>output instance</i>s
from a service invocation are explicitly linked. This saves a client
from the task of tracking input/output relationships on its own, and
ensures that the RDF produced by service invocations forms a
connected graph that is queriable in a meaningful manner. In SADI,
related input and <i>output instance</i>s are linked because they share the
same URI. This constraint is demonstrated concretely in Running
Example: The SADI "Hello, World!" Service (Section 8) and is
described more formally in The Output OWL Class (Section 9.3.2).
</section><!-- close relationship-->
<section>
<h4>Minimal Constraints on Data Modeling</h4>
Aside from the constraint of the previous section, SADI does not
provide any rules about how service input and output data should be
modeled in RDF. Service providers are free to encode the data using
any OWL or RDFS ontologies deemed suitable. Further, the input and
<i>output RDF document</i>s for a service invocation consist only of data
that is consumed or generated by the service, respectively. There
are no SADI-specific messaging structures required within the input/
<i>output RDF document</i>s.
</section><!-- close constraints-->
</section><!-- close design goals-->
<br/>
<section>
<h2>Relationship to Other Web Service Standards</h2>
<section>
<h4>Web Services Description Language (WSDL)</h4>
WSDL [[WSDL]] is an XML schema that is the current de facto standard
for machine-readable description of web service interfaces. At the
time of writing this document, the most recent version of WSDL is
WSDL 2.0.
<br/><br/>
The most important difference between SADI and WSDL is that SADI uses
RDF for message content, whereas WSDL conventionally uses XML. WSDL
uses XML Schema [[xmlschema-formal]] as the default schema language for
message structures, but is also extensible to use other schema
languages. To date, there have been proposals for extensions that
use Document Type Definitions (DTDs) and RelaxNG as alternative
schema languages for WSDL. In principle, a similar extension could
be created for the use of OWL as a schema language, although none has
been put forward to date.
<br/><br/>
SADI uses only a small, fixed subset of the behaviours that can
described by WSDL. In the terminology of WSDL, SADI services must
have:
<ul>
<li>one operation per service, where an operation is an interaction
between the client and the service to accomplish some result. An
operation is analogous to a function call in a programming
language.</li>
<li>one endpoint per service, where an endpoint is a URL where
the client interacts with the service</li>
<li>a fixed protocol, where the protocol is the mechanism for
transporting messages between the client and the service. All
SADI services use HTTP as the underlying protocol.</li>
<li>a fixed message exchange pattern, where a message exchange
pattern is a sequence of messages that are exchanged between a
client and a service during an operation. SADI services have one
of two possible message exchange patterns, corresponding to
synchronous services (Section 10.1) and asynchronous services
(Section 10.2).</li>
</ul>
The only variables of a SADI service interface are the graph
representations of the input data, the output data, and the service
execution parameters, which are defined by the <i>input OWL class</i>
(Section 9.3.1), the <i>output OWL class</i> (Section 9.3.2), and the
<i>parameter OWL class</i> (Section 9.4.1), respectively. For SADI, these
three OWL classes are the functional analog of a WSDL service
description file.
</section>
<section>
<h4>Semantic Annotations for WSDL (SAWSDL)</h4>
SAWSDL [SAWSDL] is a small set of extensions to the WSDL XML schema
that facilitates the mapping of XML-based services to a semantic data
model (e.g. RDF). Specifically, SAWSDL defines 3 additional XML
attributes for WSDL:
<ul>
<li> modelReference</li>
<li> loweringSchemaMapping</li>
<li> liftingSchemaMapping</li>
</ul>
<i>modelReference</i> is used to annotate elements of a WSDL interface
with entities from a semantic data model, such as class URIs from an
OWL ontology. <i>liftingSchemaMapping</i> and <i>loweringSchemaMapping</i> are
used to provide mappings of XML datatypes to and from a semantic data
model, respectively. The values of <i>liftingSchemaMapping</i> and
<i>loweringSchema</i> are URIs that identify documents that define the
transformation; however, SAWSDL is agnostic with respect to the
specific mapping language that is used. For example, when
translating between XML and RDF, the required mappings might be
accomplished with XSLT for the lifting transformation and SPARQL
followed by XSLT for the lowering transformation.
<br/><br/>
SAWSDL can be used as an adaptor layer that maps a WSDL service to
the expected behaviour of a SADI service.
</section>
<section>
<h4>OWL-S and the Web Service Modeling Ontology (WSMO)</h4>
OWL-S [[OWL-S]] and WSMO [[WSMO]] are two previous Semantic Web Services
standards that are similar in their goals and approaches. Both
standards define ontologies for describing the capablities and
choreographies of stateful web services, where capabilities are
changes to the world that are effected by a service, and
choreographies are the sequences of messages exchanged between a
client and a service during an interaction. (Choreographies
correspond to message exchange patterns in WSDL.) OWL-S and WSMO
exceed the descriptive power of WSDL by providing a generic framework
for modeling both the internal state of a service and the state of
external variables that are affected by the service (e.g. a credit
card balance). Transitions between states are formally described by
boolean formulas that express preconditions and postconditions for an
event.
<br/><br/>
The principal difference between OWL-S and WSMO is that OWL-S uses
OWL as its ontology language, whereas WSMO uses a more expressive
language called the Web Service Modeling Language (WSML). The OWL-S
and WSMO standards are complex, and the development of software
agents to coordinate OWL-S/WSMO services to accomplish higher order
tasks in an ongoing area of research.
<br/><br/>
In comparison to OWL-S and WSMO, SADI is a simpler standard that is
limited to the description of stateless services. SADI uses OWL
ontologies only for defining the schema of input data, output data,
and <i>service execution parameter</i>s, and not to define the effects or
choreography of a service. The choreography of a SADI service is
fixed to one of two possibilities, corresponding to synchronous
services (Section 10.1) and asynchronous services (Section 10.2)
respectively.
</section>
</section>
<br/>
<section>
<h2>Security Considerations</h2>
SADI services and clients are subject to the same security
considerations as servers and clients that use the HTTP protocol, as
described in Section 15 of [[RFC2616]].
</section>
<br/>
<section>
<h2> Running Example: The SADI "Hello, World!" Service</h2>
To illustrate the different aspects of the SADI protocol in a
concrete manner, we will frequently make reference to the SADI
"Hello, World!" service located at
http://sadiframework.org/examples/hello. The purpose of this section
is to describe the behaviour of this service and at the same time to
provide a brief, non-normative introduction to the key aspects of the
SADI protocol.
<br/><br/>
The SADI "Hello, World!" service consumes one or more <i>input instance</i>s
representing people with names (e.g. "Guy Incognito") and returns
corresponding <i>output instance</i>s representing greetings for each person
(e.g. "Hello, Guy Incognito!"). The following shows an example
<i>input RDF document</i> for the service, in N3:
<pre class='example highlight'>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix hello: <http://sadiframework.org/examples/hello.owl#> .
@prefix input: <http://sadiframework.org/data/examples/hello-input.n3#> .
input:GuyIncognito
a hello:NamedIndividual;
foaf:name "Guy Incognito" .
input:HomerSimpson
a hello:NamedIndividual;
foaf:name "Homer Simpson" .
</pre>
In response, the service generates the following <i>output RDF document</i>:
<pre class='example highlight'>
@prefix hello: <http://sadiframework.org/examples/hello.owl#> .
@prefix input: <http://sadiframework.org/data/examples/hello-input.n3#> .
input:GuyIncognito
a hello:GreetedIndividual;
hello:greeting "Hello, Guy Incognito!" .
input:HomerSimpson
a hello:GreetedIndividual;
hello:greeting "Hello, Homer Simpson!" .
</pre>
In this example, the <i>input RDF document</i> contains two <i>input instance</i>s
with the URIs input:GuyIncognito and input:HomerSimpson. Each input
instance is processed independently by the service, and so the same
result could be generated by invoking the service twice with the
input graphs for Guy Incognito and Homer Simpson separately, and
afterwords performing an RDF-merge on the two <i>output RDF document</i>s.
The <i>input instance</i>s are identified by the service as those URIs
having an rdf:type matching the service's <i>input OWL class</i> (hello:
NamedIndividual). The purpose of the <i>input OWL class</i> is to describe
the expected structure of the <i>input instance</i>s. More will be said
about the purpose and design of the <i>input OWL class</i> in The Input OWL
Class (Section XXXX).
<br/><br/>
Analogously to the case for <i>input instance</i>s, each <i>output instance</i> in
the <i>output RDF document</i> is assigned an rdf:type equal to the URI of
the service's <i>output OWL class</i> (hello:Greetedindividual). The
purpose of the <i>output OWL class</i> is to describe the expected
structure of the <i>output instance</i>s generated by the service.
Comparing the input and <i>output RDF document</i>s, the reader will observe
that the URI of each <i>output instance</i> is equal to URI of its
corresponding <i>input instance</i> (input:GuyIncognito and input:
HomerSimpson, respectively). This is a general requirement for SADI
services that ensures that related input and <i>output instance</i>s are
always explicitly linked. As a result, SADI clients are able to
merge the input and <i>output RDF document</i>s from a service invocation
into a single, coherent RDF graph that captures the relationships
between the input and output data. For example, a client could load
the two RDF documents above into a triple store, and then pose
queries against the triple store such as "What is the greeting for
Homer Simpson?".
</section>
<section>
<h2>Service Metadata</h2>
The metadata for a SADI service provides information that is
potentially helpful to human and/or software clients attempting to
use the service. All provider-specified metadata for a SADI service
MUST be retrievable as an RDF document by issuing an HTTP GET request
to the service URL. Within the RDF document, all metadata items MUST
be represented as part of a single, connected RDF graph whose root
URI is the URL of the service.
<br/><br/>
The metadata graph MUST include the following items:
<ul>
<li><i>input OWL class</i> -- an OWL class describing the expected
structure of the input RDF graphs consumed by the service</li>
<li><i>output OWL class</i> -- an OWL class describing the expected
structure of the output RDF graphs generated by the service</li>
If the service has one or more execution parameters, the metadata
graph MUST also include:
<li><i>parameter OWL class</i> -- an OWL class describing execution
parameters for the service</li>
<li>default <i>parameter instance</i> -- an instance of the parameter OWL
class which provides default values for the service execution</li>
</ul>
The following items are optional:
<ul>
<li>service name -- a human readable label for the service</li>
<li>description -- a human readable description of the service
functionality</li>
<li>contact e-mail address -- an e-mail address where the provider
of the service may be contacted</li>
<li>service type URI(s) -- one or more rdf:type URIs indicating the
type of service. These URIs may be used to categorize the service
by a wide variety of criteria, such as the task performed, the
algorithm utilized, or the intended users of the service. An
example of an ontology that could be used for these annotations is the 'Operation'
branch of the <a href='https://www.ebi.ac.uk/ols/beta/ontologies/edam/terms?iri=http%3A%2F%2Fedamontology.org%2Foperation_0004'>EDAM Ontology</a></li>
<li>unit test(s) -- one or more input RDF graph(s) that MUST
constitute valid input(s) to the service. The expected output RDF
graphs corresponding to these input graphs MAY also be provided.</li>
<li>authoritative flag -- a boolean value that MUST be true if the
person or organization hosting the service is also the author or
owner of the data underlying the service, or the author or curator
of the software which will generate the service output. If a SADI
service acts as an interface to third party data or software, the
value of the authoritative flag MUST be false. This is to provide
some Quality-of-Service information in cases where multiple
services report to provide the same output data.</li>
</ul>
In addition, any other items deemed useful to clients of the service
MAY be included in the metadata graph.
</section>
<section>
<h2>Retrieving Service Metadata</h2>
An RDF document containing the metadata graph MUST be retrievable by
an HTTP GET request to the service URL.
<br/><br/>
The GET request MAY include an Accept header indicating the desired
RDF serialization format for the response document. A SADI service
MUST support content types of text/rdf+n3 for N3 and application/
rdf+xml for RDF/XML, and MAY support additional content types for
these formats or for any other RDF serialization formats. In the
event of an omitted, unrecognized, or unsupported content type, the
default content type used for the response MUST be RDF/XML.
</section>
<section>
<h2>Representing Service Metadata in RDF</h2>
The schema for the metadata graph is beyond the current scope of the
SADI specification.
<br/><br/>
At the time of writing, all SADI services and SADI-related tools
known to the authors use the myGrid/Moby service ontology [myGrid/
Moby] to encode the service metadata graph. For illustrative
purposes, the service metadata graph for a parameterized version of
the "Hello, World!" service
(http://sadiframework.org/examples/hello-param) is shown below in N3
format.
<pre class='example highlight'>
@prefix protege-dc: <http://protege.stanford.edu/plugins/owl/dc/protege-dc.owl#> .
@prefix mygrid: <http://www.mygrid.org.uk/mygrid-moby-service#> .
@prefix hello: <http://sadiframework.org/examples/hello.owl#> .
@prefix test: <http://sadiframework.org/examples/t/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
<http://sadiframework.org/examples/hello-param>
a mygrid:serviceDescription ;
#----------------------------------------
# Service Name
#----------------------------------------
mygrid:hasServiceNameText
"ParamaterizedHelloWorld"^^xsd:string ;
#----------------------------------------
# Service Description
#----------------------------------------
mygrid:hasServiceDescriptionText
"A \"Hello, world!\" service where the output language is
specified in a parameter"^^xsd:string ;
#----------------------------------------
# Contact E-mail Address, Authoritative Flag
#----------------------------------------
mygrid:providedBy
[ a mygrid:organisation ;
protege-dc:creator "[email protected]"^^xsd:string ;
mygrid:authoritative "false"^^xsd:boolean
] ;
mygrid:hasOperation
[ a mygrid:operation ;
#----------------------------------------
# Input OWL Class
#----------------------------------------
mygrid:inputParameter
[ a mygrid:parameter ;
mygrid:objectType hello:NamedIndividual
] ;
#----------------------------------------
# Parameter OWL Class, Default Parameter Graph
#----------------------------------------
mygrid:inputParameter
[ a mygrid:secondaryParameter ;
mygrid:objectType hello:SecondaryParameters ;
mygrid:hasDefaultValue
[ a hello:SecondaryParameters ;
hello:lang "en"^^xsd:string
]
] ;
#----------------------------------------
# Output OWL Class
#----------------------------------------
mygrid:outputParameter
[ a mygrid:parameter ;
mygrid:objectType hello:GreetedIndividual
] ;
#----------------------------------------
# Unit Test
# (test input/output RDF included directly)
#----------------------------------------
mygrid:hasUnitTest
[ a mygrid:testCase ;
mygrid:exampleInput
[ a hello:InputClass ;
foaf:name "Guy Incognito"
] ;
mygrid:exampleOutput
[ a hello:OutputClass ;
hello:greeting "Hello, Guy Incognito!"
]
] ;
#----------------------------------------
# Unit Test
# (test input/output RDF in external documents)
#----------------------------------------
mygrid:hasUnitTest
[ a mygrid:testCase ;
mygrid:exampleInput test:hello-param-input.rdf ;
mygrid:exampleOutput test:hello-param-output.rdf
]
] .
</pre>
</section>
<section>
<h2>Describing Service Interfaces Using OWL</h2>
An RDF document containing the metadata graph MUST be retrievable by
an HTTP GET request to the service URL.
<br/><br/>
The GET request MAY include an Accept header indicating the desired
RDF serialization format for the response document. A SADI service
MUST support content types of text/rdf+n3 for N3 and application/
rdf+xml for RDF/XML, and MAY support additional content types for
these formats or for any other RDF serialization formats. In the
event of an omitted, unrecognized, or unsupported content type, the
default content type used for the response MUST be RDF/XML.
<br/><br/>
The input and <i>output OWL class</i>es for a service provide a machine-
readable representation of the service interface. This facilitates
the automation of various data and service matchmaking tasks, such
as:
<ul>
<li>identifying services that can consume a subset of a given RDF
graph as input</li>
<li>extracting <i>input instance</i>s for a service from a given RDF graph</li>
<li>matching the output interface of one service to the input
interface of another service, in order to create service execution
chains (workflows)</li>
</ul>
Moreover, the use of OWL for describing service interfaces enables
the use an OWL reasoner as the main vehicle for accomplishing these
tasks.
<section>
<h4>The Input OWL Class</h4>
The primary purpose of the <i>input OWL class</i> is to identify and extract
valid <i>input instance</i>s for a service from a given RDF data set. Each
SADI service has exactly one <i>input OWL class</i> which MUST either be
referenced by or directly included in the metadata graph for the
service.
<br/><br/>
For illustrative purposes, the following excerpt shows the definition
for hello:NamedIndividual, which is the <i>input OWL class</i> for the SADI
"Hello, World!" service:
<pre class='example highlight'>
<owl:Class rdf:ID="NamedIndividual">
<owl:equivalentClass>
<owl:Restriction>
<owl:onProperty rdf:resource="http://xmlns.com/foaf/0.1/name"/>
<owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1</owl:minCardinality>
</owl:Restriction>
</owl:equivalentClass>
</owl:Class>
</pre>
This class definition states that a URI is an instance of hello:
NamedIndividual if and only if it has one or more values for the
foaf:name property. As a result, each <i>input instance</i> for the "Hello,
World!" service is required to have at least one foaf:name property.
</section>
<section>
<h4> Instance Checking and the Input OWL Class</h4>
The identification of instances of an OWL class within an RDF graph
is a commonly supported operation of OWL reasoners, which we we will
refer to here as instance checking. The purpose of this section is
provide guidelines for writing an <i>input OWL class</i> that enables an OWL
reasoner to perform instance checking in a useful manner.
<br/><br/>
The most important consideration when authoring an <i>input OWL class</i> is
that the conditions for class membership should be defined using
necessary and sufficient ('if and only if') conditions. In OWL,
necessary conditions ('if') are defined using the rdfs:subClassOf
property whereas necessary and sufficient conditions ('if and only
if') are defined using the owl:equivalentClass property. For
example, the following two excerpts show alternate definitions of
hello:NamedIndividual which use necessary conditions and necessary
and sufficient conditions, respectively:
<pre class='example highlight'>
<owl:Class rdf:ID="NamedIndividual">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="http://xmlns.com/foaf/0.1/name"/>
<owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="NamedIndividual">
<owl:equivalentClass>
<owl:Restriction>
<owl:onProperty rdf:resource="http://xmlns.com/foaf/0.1/name"/>
<owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int">1</owl:minCardinality>
</owl:Restriction>
</owl:equivalentClass>
</owl:Class>
</pre>
The first definition uses only a necessary condition. It states that
a URI has one or more foaf:name properties if it is an instance of
hello:NamedIndividual. (A URI is known to be an instance of the
hello:NamedIndividual if it has an rdf:type value of hello:
NamedIndividual.) From this rule, a reasoner cannot deduce that a