using a sum function and have adopted a matchmaker-based approach. A ser- ... Classad [13,14] is a matchmaking framework to resource management in dis-.
SPARQL-Based Set-Matching for Semantic Grid Resource Selection Said Mirza Pahlevi, Akiyoshi Matono, and Isao Kojima National Institute of Advanced Industrial Science and Technology (AIST) Grid Technology Research Center Tsukuba, Ibaraki 305-8568, Japan
Abstract. Grid is an emerging technology that enables the sharing of a wide variety of resources. However, effective and accurate grid resource matching is difficult because of the dynamic characteristics and heterogeneity of grid resources. Grid resource matching mechanisms that utilize semantic Web technologies have been proposed to deal with this issue, although none support set matching of grid resources based on their semantic description. This paper proposes a novel set-matching algorithm that uses standard RDF query language SPARQL [1] to semantically match a set of grid resources and SPARQL query features to efficiently perform set matching. We evaluated the efficiency and effectiveness of the algorithm by performing a set of experiments and present the results.
1
Introduction
The semantic grid [2] applies semantic Web technologies in the grid environment. For better automated resource discovery and selection, semantic grid applications use semantic Web annotation frameworks to describe resources and services. For example, the MyGrid project [3] has a service ontology that extends the DARPA agent markup language for services (DAML-S) [4] ontology and allows services to be queried and matched by subsumption reasoning over the service descriptions. Grid resource discovery and selection also include a task known as set matching that discovers a set of resources matching application requirements [5]. Set matching is especially important in the grid environment because a grid is essentially a distributed, heterogeneous collection of computers that, in principle, can be used as a computing platform; because of the rapid proliferation of the semantic Web/grid and the resource heterogeneity, the ability to semantically match grid resources is crucial. The following motivational example illustrates the benefits of semantic set matching. Suppose that we have a set of computers with CPU architectures classified according to the CPU ontology shown in Fig. 1. Further suppose that the query is: find a set of Intel CPU computers with aggregated disk space greater than 8 GB. A syntactic match-based approach returns an empty result, because the total disk space of n3 and n4 with Intel CPU architectures is less than 8 GB. Subsumption reasoning, however, infers that the CPU architecture of n2 (which A. ter Hofstede, B. Benatallah, and H.-Y. Paik (Eds.): BPM 2007 Workshops, LNCS 4928, pp. 461–472, 2008. c Springer-Verlag Berlin Heidelberg 2008
462
S.M. Pahlevi, A. Matono, and I. Kojima (3GB)
(3GB)
(4GB)
n3
n1
CPU
n4 (4GB) n5
(4GB) n2 Intel
Sun
Ultra sparc
Super sparc
rdfs:subClassOf
Pen tium
Ita nium rdf:type
AMD
Athlon
Op teron
( ): disk space
Fig. 1. A CPU architecture ontology and the instances
is a Pentium) is also Intel, so that the result will be {n2 , n3 , n4 }, with a total disk space equal to 10 GB. The SPARQL query language [1], which is currently a World Wide Web Consortium (W3C) candidate recommendation, is used for querying RDF data and will become a standard query language for the semantic Web. The demand for standard methods to access RDF data in a grid environment led the Open Grid Forum (OGF) [6] to define specifications for accessing RDF data using the SPARQL query language [7]. Therefore, we argue that the semantic set matching for the grid should use SPARQL as the query language. Using SPARQL as the set-matching query language provides the following advantages. First, unrestricted target resource description1 repositories. Because SPARQL is a “standard” query language and many free SPARQL query engine implementations are available [8], the target repository for set matching can be easily switched if the repository is associated with a SPARQL query engine. Second, complex set matching. A requester can use the rich SPARQL constructs (e.g., options and filtering) for advanced set matching. Furthermore, resource descriptions can be retrieved from several sites using the SPARQL “named graph” and “from named” constructs, which allow for set matching to distributed resource descriptions. Third, semantic set matching. SPARQL does not support RDF data inference. However, a semantic match can be obtained by applying SPARQL to inferred RDF data/triples constructed using an RDF reasoner. In this paper, we propose a set-matching mechanism based on SPARQL that enables semantic matching of grid resources. To the best of our knowledge, no studies have been conducted on this issue to date. Set matching in a grid environment using SPARQL is challenging, for the following reasons: 1. SPARQL does not support the aggregation functions necessary for set matching. 2. Because resource description repositories may be scattered over the grid, the set-matching system should be able to select one repository as a search target and to switch from one repository to another. 3. Set matching may include computationally expensive combinatorial searches. 1
Henceforth, we will use resource and resource description interchangeably.
SPARQL-Based Set-Matching for Semantic Grid Resource Selection
463
To cope with the first and second issues, we have extended SPARQL slightly using a sum function and have adopted a matchmaker-based approach. A service requester uses the extended SPARQL to formulate a set-matching query that is sent to a matchmaker. The matchmaker communicates with the resource repositories using standard SPARQL query language and thus absorbs the nonstandard part. We avoided the third issue by proposing a simple and efficient greedy retrieval algorithm that makes use of powerful SPARQL constructs. To reduce data transfer cost, the algorithm retrieves as small as possible data from the repository. In constrast, a naive algorithm will retrieve the most of the repository data and perform combinatorial search over the data. The rest of the paper is organized as follows. Section 2 briefly reviews related works. Section 3 explains the basic system architecture. Section 4 describes the proposed set matching algorithm. Section 5 presents experiment results that clarify the effectiveness and characteristics of the algorithm. Section 6 discuss the algorithm usage guideline and advanced set matching using SPARQL constructs. The final section gives conclusions and outlines future activities.
2
Related Work
The Globus Monitoring and Discovery System (MDS) [9] is the information services component of the Globus Toolkit [10] that provides information about the available resources on the grid and their status. This service collects data from various sources and provides a query/subscription interface to that data. The Semantic MDS (S-MDS) [11] extends the MDS by applying semantic Web technologies to annotate the metadata of grid resources. It describes the grid resources using OWL-S ontology [12] and provides an efficient mechanism to aggregate and maintain the ontology instances. Since S-MDS provides a SPARQL query interface to the ontology data and allows reasoning over the data prior to query processing our set-matching system can work well with S-MDS. Classad [13,14] is a matchmaking framework to resource management in distributed environment. In this framework, a service advertisement and request are formulated using a semi-structured data model called classified advertisements (classad) which consists of attribute-value pairs. A matchmaker syntactically matches the advertisement and the request based on constraints specified by attributes in the classads. Redline [5] is a grid matchmaking system that reinterprets matching as a constraint problem and exploits constraint-solving technologies to implement matching operations. It provides set-matching which is not supported by classad. Classad and Redline, however, are based on text matching rather than semantic matching. Ontology-based Matchmaker (OMM) [15] is an ontology-based resource selector for the grid. Resources and requests are described by (different) ontologies and they are matched using matching rules. Different from OMM, a semantic matching system proposed in [16] used SPARQL as a requester query language. The system provides query rewriting and result ordering mechanisms that enable a matchmaker to order results based on class subsumption relationships. Both
464
S.M. Pahlevi, A. Matono, and I. Kojima
methods provide semantic matching of grid resources but they do not support set-matching.
3
System Architecture
Fig. 2 shows the basic architecture of our set-matching system. Targeted grid resources are described using RDF/OWL and the descriptions are stored in an RDF repository system that is associated with a SPARQL query engine. A matchmaker stands between the repository system and the service requester, which formulates a resource request in SPARQL.
Extended SPARQL query
Service Service Service Provider Provider Provider
SPARQL query
register query’
query’
set match
Query Query Interface Interface
Client Client Interface Interface
Service Requester
query
query
Set-Matching Set-Matching Composer Composer
set match
results
RDF Repository System
results
Matchmaker
Fig. 2. Basic system architecture
To enable set matching using SPARQL, we slightly extended SPARQL with a sum function specified in a filter clause. For example, the query below retrieves a set of resources in which each resource has an available memory greater than 200 MB and the aggregate memory of the set is greater than 8000 MB. SELECT ?res WHERE{ ?res memory ?m. FILTER(?m > 200). FILTER(SUM(?m) > 8000).} We call a predicate whose values are summed up an aggregation predicate (i.e., memory); the predicate’s variable (i.e., ?m) the aggregation variable; the predicate’s aggregation value (i.e., 8000) the required aggregation value; and a condition with a sum function (i.e., SUM(?m) > 8000) an aggregation condition. The sum of aggregation predicate values from matched resources is the resulting aggregation value of the predicate. The set-matching composer in the matchmaker accepts an extended SPARQL query from a requester, eliminates any aggregation conditions, and forwards the query to the repository. Upon receiving the query results, the composer determines whether the aggregation conditions are satisfied. If they are satisfied, the composer returns the results to the requester as an answer; if they are not, it caches the results, modifies the query, and resends it to the repository. The details of the retrieval algorithm are given in Section 4.
SPARQL-Based Set-Matching for Semantic Grid Resource Selection
4
465
SPARQL-Based Set Matching
4.1
Goal and Outline
Given a SPARQL query containing one or more aggregation conditions, the matchmaker repeatedly retrieves a number of resources from the repository while modifying the query. The retrievals are performed until the aggregation conditions are satisfied or until it is known that the conditions cannot be satisfied. The retrievals are based on the following requirements: (1) data volume transferred from the repository to the matchmaker (i.e., the answer-set size) should be as small as possible. That is, it should be proportional to the required aggregation values and (2) the number of queries sent to the repository (the retrieval number) should be as small as possible. To reduce the answer-set size and query number, the matchmaker modifies a requester query as follows: 1. It inserts an ORDER BY DESC clause into the query to place the “most promising” resources at the top of the matched results. The most promising resources are those with relatively large aggregation predicate values. 2. Based on 1), the matchmaker estimates the number of resources that need to be retrieved from the repository to satisfy the aggregation conditions, and sets this estimate as the LIMIT value of the query. 3. It inserts FILTER clauses into the query to eliminate resources that have already been retrieved in previous retrievals. 4.2
Set-Matching Algorithm
For each (possible) aggregation predicate p, the matchmaker retrieves n sample resources from a repository using the following simple SPARQL query: SELECT ?value WHERE {?res p ?value} ORDER BY DESC(?value) LIMIT n The ORDER BY DESC clause retrieves resources whose p values are relatively large. An estimated average of p values of resources stored in the repository, p.estAvgV alue, is calculated by taking the average of p values in the samples. This calculation can be done once at the system startup or regularly at specific time intervals. Algorithm 1 shows the set-matching procedure. It first removes the aggregation predicates from a requester query q and puts them into a list plist (line 3). The algorithm then retrieves a set of resources from the repository based on the aggregation predicates (lines 5 – 11). During retrieval, the algorithm calculates the resulting aggregation value of a current aggregation predicate based on a result accumulation buffer accres (line 5), then calculates the remaining aggregation value by subtracting this value from the required aggregation value (line 6). If the remaining value is greater than 0 (i.e., if the aggregation condition is not yet satisfied), the algorithm sets the ORDER BY DESC of q using the aggregation variable of the predicate2 (line 8) 2
An ORDER BY DESC clause is inserted if it does not exist.
466
S.M. Pahlevi, A. Matono, and I. Kojima
Algorithm 1. Set Matching
1 2 3 4 5 6 7 8 9 10 11 12 13
Input: SPARQL query q. Output: A set of resources. begin accres ← ∅; plist ← aggregation predicates in q; foreach p in plist do ctotal ← Sump (accres); remainAggV alue ← p.reqAggV alue − ctotal; if remainAggV alue > 0 then q.ORDER BY DESC ← p.valueV ar; res ← Retrieve(q, p, remainAggV alue); if res is ∅ then return unsatisfiable; append res to accres; return accres; end
Algorithm 2. Retrieve
11
Input: SPARQL query q, an aggregation predicate p, target aggregation value tarAggV alue Output: A set of resources begin res ← ∅, ctotal ← 0; while true do q.LIMIT ← (tarAggV alue − ctotal)/p.estAvgV alue; res ← send q and get the results; if res is empty then return ∅; append res to res; p.estAvgV alue ← Minp (res ) × α; ctotal ← Sump (res); q.FILTER ← condition to exclude resources in res ; if ctotal ≥ tarAggV alue then return res;
12
end
1 2 3 4 5 6 7 8 9 10
and then retrieves additional resources from the repository using the Retrieve function (line 9). If the returned result is empty, the aggregation condition of the predicate cannot be satisfied, and the algorithm returns an “unsatisfied” message (line 10). Results greater than 0 are appended to accres (line 11) and are considered at the next retrieval. Algorithm 2 shows the retrieval procedure used by the set-matching algorithm. This algorithm repeatedly retrieves a set of resources and does the following during each retrieval: 1) Updates the LIMIT value of the query based on the remaining aggregation value at that retrieval (line 4), and 2) inserts a FILTER clause into the query to exclude resources that have been retrieved (line 10).
SPARQL-Based Set-Matching for Semantic Grid Resource Selection
467
On receiving query results from the repository, the algorithm inserts the results into a buffer res (line 5), updates the estAvgV alue of the aggregation predicate based on the newly retrieved resource set (line 8), and calculates the total for the aggregation predicate values in res (line 9). If the total value satisfies the target aggregation value (tarAggV alue), the algorithm returns res (line 11); otherwise it modifies q and resends it to the repository. The LIMIT value of the query restricts the matched result size and affects the total number of retrievals/queries, so the estAvgV alue (line 8) must be well estimated. Because the query results are ranked in descending order according to the aggregation predicate values and the aggregation predicate values of resources to be retrieved in the next turn cannot exceed the minimum predicate value in the current results, the estAvgV alue is estimated as Minp (res ) × α, where Minp (res ) is the minimum aggregation predicate p value in res and α (0 < α ≤ 1) is a correction factor. α is used to adjust estAvgV alue because the average of p values of subsequent results is likely to be less than Minp (res ). 4.3
An Example
Suppose that a repository contains descriptions of eight computers: r1 (800, 500), r2 (800, 400), r3 (700, 900), r4 (500, 100), r5 (400, 100), r6 (300, 400), r7 (300, 450), and r8 (350, 900), where r(x, y) denotes computer r with x MB available memory and y MB available disk space. Further suppose that a requester query is q0 , as shown in Fig. 3, sample size n = 2, α = 1.0, and the aggregation predicate memory is processed first. Note that, the initial estAvgV alue of memory and diskspace which are calculated from the sample are 800 and 900, respectively. Initially, because accres is still empty, we get ctotal = 0 (line 1.5)3 and remainAggV alue = 3000 (line 1.6). The algorithm modifies q0 into q1 by inserting “ORDER BY DESC (?m)” (line 1.8) and “LIMIT 4” (line 2.4). Note that LIMIT is 4 because it is estimated that four computers, each with memory of 800 MB, will satisfy the aggregation condition. The algorithm then sends q1 (Fig. 3) to the repository and gets res = (r1 , r2 , r3 , r4 ) as the result (line 2.5). Next, res is appended into res (line 2.7) and estAvgV alue of the predicate and ctotal is calculated, producing 500 (line 2.8) and 2800 (line 2.9), respectively. Because ctotal is still less than 3000, the algorithm modifies q1 into q2 (lines 2.10 and 2.4), sends it to the repository, and gets res = (r5 ) as the result. Now ctotal is greater than 3000 (i.e., 3200), so res = (r1 , r2 , r3 , r4 , r5 ) is returned (line 2.11). Next, the second predicate diskspace is processed. At this point, ctotal and remainAggV alue with respect to diskspace are 2000 and 500, respectively. Because ctotal is less than the required aggregation value of 2500, the algorithm modifies q2 into q3 , sends it to the repository, and obtains r8 as the result. Finally, the algorithm returns (r1 , r2 , r3 , r4 , r5 , r8 ) as the answer, with the resultAggV alue of memory and diskspace equal to 3550 and 2900, respectively. If diskspace is processed first, the answer will be (r1 , r2 , r3 , r4 , r7 , r8 ) with the resultAggV alue of memory and diskspace equal to 3450 and 3250, respectively. 3
line x.y denotes line y at algorithm x.
468
S.M. Pahlevi, A. Matono, and I. Kojima q0 = SELECT ?res WHERE { ?res memory ?m. FILTER(SUM(?m) ≥ 3000). ?res diskspace ?d. FILTER(SUM(?d) ≥ 2500)} q1 = SELECT ?res WHERE { ?res memory ?m. ?res diskspace ?d} ORDER BY DESC(?m) LIMIT 4 q2 = SELECT ?res WHERE { ?res memory ?m. ?res diskspace ?d. FILTER((?res != r1 ) && (?res != r2 ) && (?res != r3 ) && (?res != r4 ))} ORDER BY DESC(?m) LIMIT 1 q3 = SELECT ?res WHERE { ?res memory ?m. ?res diskspace ?d. FILTER((?res != r1 ) && (?res != r2 ) && (?res != r3 ) && (?res != r4 )). FILTER(?res != r5 )} ORDER BY DESC(?d) LIMIT 1 Fig. 3. Requester and modified queries
5
Performance Evaluation
We use OGSA-DAI-RDF [17], developed by the National Institute of Advanced Industrial Science and Technology (AIST), as an RDF repository system deployed in a Linux node. The repository contains 200 resource descriptions written in OWL. Each resource has two (dynamic) predicates, memory and diskspace; the values of these predicates are updated every 90 s by assigning a random number ranging from 0 to 1000. The matchmaker and requester are deployed on different nodes, connected to the repository via a LAN. The sample size n is set to 10, and sample resources are retrieved once at the beginning of each experiment. We use the following parameters: (1) Correction factor α, with values of {0.25, 0.5, 0.75, 1}. (2) Difference ratio of the two predicates’ required aggregation values (dr), with values of {0.25, 0.5, 0.75, 1}. The required aggregation value of the primary predicate (i.e., a predicate with a bigger value) is set to m × 500, where m = {5, 10, 20, 40, 80, 160}, and 500 is the average predicate value4 , while the secondary predicate (i.e., a predicate with a smaller value) is to the primary predicate value multiplied by dr. (3) A predicate processing order (first or last). We performed 192 experiments with different α, dr, required aggregation values, and processing orders. In each experiment, we sent a requester query to the repository 50 times and calculated the average number of queries sent by the algorithm to the repository and the resulting set size. We organized the results into two main topics, described in the next two subsections. 1. Query number and set size with respect to the required aggregation values for various α values (Section 5.1). 4
We set this value to evaluate the performance of the algorithm for various results/answer-set sizes, i.e., between approximately 2.5% and 80% of the repository size.
SPARQL-Based Set-Matching for Semantic Grid Resource Selection
469
2. Query number and set size for dr < 1 and different predicate processing orders (Section 5.2). 5.1
Query Number and Set Size for Various α
This section evaluates the query number and set size for different α values and finds an optimum range of alpha values that provides the best performance.
200
10
α=0.25 α=0.5 α=0.75 α=1.0
6 4
120 80 40
2
0
0 2500
5000 10000 20000 40000 Aggregation value of both predicates
2500
80000
Fig. 4. Query number for dr = 1 10
200
Set size
4 2
80000
α=0.25 α=0.5 α=0.75 α=1.0
160
6
5000 10000 20000 40000 Aggregation value of both predicates
Fig. 5. Set size for dr = 1
α=0.25 α=0.5 α=0.75 α=1.0
8 Query number
α=0.25 α=0.5 α=0.75 α=1.0
160
Set size
Query number
8
120 80 40 0
0 2500
5000 10000 20000 40000 Aggregation value of primary predicate
80000
Fig. 6. Query number for dr = 0.5
2500
5000 10000 20000 40000 Aggregation value of primary predicate
80000
Fig. 7. Set size for dr = 0.5
Fig. 4 and Fig. 5 show the query number and set size for dr = 1; Fig. 6 and Fig.7 show the results for dr = 0.55 . As shown in the figures, doubling the required aggregation value causes a proportional increase in set size, but without any significant increase in the query number. Moreover, for small and medium set sizes (up to approximately 35% of the repository size), the query number generally remains small. The algorithm performs best for α = 0.5 and α = 0.75; at these values, the set size increases proportionally to the aggregation value and the query number is, at most, twice the value of the aggregation predicate number. 5
The results for two other dr values were similar to dr = 0.5 and are omitted.
470
S.M. Pahlevi, A. Matono, and I. Kojima
Overestimating the estAvgV alue (i.e., setting α to 1.0) results in a relatively low set size increase, but a larger increase in query number. Conversely, underestimating it (i.e., setting α to 0.25) produces a relatively large set size increase, with a relatively small increase in query number. This is because a larger (smaller) estAvgV alue produces a smaller (larger) LIMIT value of the query. A small (large) limit value forces the algorithm to send more (less) queries to the repository, because each query retrieves a few (many) resources. 5.2
Query Number and Set Size for dr < 1
This Section evaluates the query number and set size when the aggregation values of the two predicates are different. Based on the previous result α is set to 0.75. Fig. 8 and Fig. 9 show the results for the query number and set size, respectively. Each point in the graph represents the ratio of the query number/set size when the primary predicate is processed last to query number/set size when it is processed first. 5 dr=0.25 dr=0.5 dr=0.75
4
dr=0.25 dr=0.5 dr=0.75
4 Ratio of set size
Ratio of query number
5
3 2
3 2 1
1
0
0 2500
5000 10000 20000 40000 Aggregation value of primary predicate
80000
Fig. 8. Query number ratio for α = 0.75
2500
5000 10000 20000 40000 Aggregation value of primary predicate
80000
Fig. 9. Set size with for α = 0.75
As shown in the figures, processing the primary predicate earlier decreases the query number by up to 50% while keeping the set size mostly unchanged. This is because early processing of the primary predicate makes it likely that the relatively small required aggregation value of the second predicate will be fully satisfied, which, in turn, decreases the number of queries sent to the repository. In addition, Fig. 8 indicates that, on average, a smaller dr produces a larger decrease in query number, because with a smaller dr, it is more likely that the required aggregation value of the non-primary predicate will be satisfied after the earlier predicate is processed.
6 6.1
Discussion Set-Matching Guidelines
In general, each (numerical) aggregation predicate p has a different domain value, ranging from 0 or 1 to a specific maximum number. Note that our retrieval
SPARQL-Based Set-Matching for Semantic Grid Resource Selection
471
algorithm always retrieves matched resources in descending order, according to the aggregation predicate values. Therefore, we can normalize the p.reqAggV alue (the x axis in the graphs) as a maximum required resource number for p, which is calculated as p.reqAggV alue/(initial p.estAvgV alue), where the denominator is the average of p values in the initial n sample resources. Our results suggest the following guidelines for the set-matching algorithm: (1) Set the value of α between 0.5 and 0.75; (2) If the maximum required resource numbers are very different, the primary predicate should be processed first. It is important to note that, for enabling semantic set-matching, an RDF repository should store resource descriptions including their entailments. We also perform experiments for a query with a single predicate and compare the results to those of a query with two predicates. As expected, the results show that the query number and result size increase as the predicate number increases. 6.2
Complex Set-Matching
The value constraint provided by SPARQL enables syntactic match that performs string and arithmetic comparisons. This feature, for example, can be used to restrict resources that can be included in a result-set to those that have a specific minimum memory value or to those organized or owned by a specific VO or user. SPARQL allows several graph patterns to be used in a query and allows them to refer to same common variables. This enables a set matching that includes a gang match [14], which matches a single request with multiple types of resources. The following example which is based on [14] demonstrates the idea. The purpose is to match a job (resource request) with two types of resources: computers and software package licenses. A job that uses the packages needs to allocate both a set of computers and a license before it can run. Assuming the two resources are described by different RDF graphs and the computer RDF graph is the default graph, the following query requests a set of Intel CPU computers in which each computer has memory greater than 500 MB and the aggregate memory of the set is greater than 8000 MB. In addition the computers must have a license to run “sim app” application. The license is verified based on the computer addresses. Note that the two graph patterns refer to the same variable ?addr. SELECT ?comp WHERE {?comp architecture ?arch. ?arch rdf:type Intel. ?comp memory ?m. FILTER(?m > 500). FILTER(SUM(?m) > 8000). ?comp address ?addr. FILTER(?addr =”foo.go.jp“). GRAPH PackageLicense{ ?license hasValidHost ?addr. ?license hasApplication ?app. FILTER(?app =”sim app“).} }
472
7
S.M. Pahlevi, A. Matono, and I. Kojima
Conclusions and Future Work
A common characteristic of many grid applications is a need to allocate multiple resources simultaneously. We have proposed such allocation mechanism that is based on semantic Web technologies. The mechanism uses SPARQL to take the advantages of the standard query language and the powerful query constructs. We have evaluated the mechanism by running a set of experiments. The results are promising that the answer-set size is proportional to the required resource number and the query number is, at most, twice the value of the aggregation predicate number. We are now working on applying the mechanism in a real grid environment by incorporating it with the work done in [11] and [17]. In addition, to achieve better scalability and cope with the distributed nature of the grid we plan to work on a distributed structure of the set-matching system.
References 1. 2. 3. 4. 5.
6. 7. 8. 9. 10. 11.
12. 13.
14.
15. 16.
17.
Prud’hommeaux, E., Seaborne, A.: SPARQL query language for RDF (2007) http://www.semanticgrid.org/ http://www.mygrid.org.uk/ http://www.daml.org/ Liu, C., Foster, I.: A Constraint Language Approach to Matchmaking. In: RIDE 2004. Proc. of the 14th International Workshop on Research Issues on Data Engineering: Web Services for E-Commerce and E-Government Applications, pp. 7–14 (2004) http://www.ogf.org/ Kojima, I., Said, M.P.: WS-DAI-RDF(S) querying (2006) http://esw.w3.org/topic/SparqlImplementations http://www.globus.org/toolkit/mds/ http://www.globus.org/toolkit/ Said, M.P., Kojima, I.: Towards Automatic Service Discovery and Monitoring in WS-Resource Framework. In: Proc. of the 1st International Conference on Semantics, Knowledge and Grid, pp. 932–938 (2005) http://www.daml.org/services/owl-s/ Raman, R., Livny, M., Solomon, M.: Matchmaking: Distributed resource management for high throughput computing. In: Proc. of the 7th IEEE International Symposium on High Performance Distributed Computing, pp. 140–146 (1998) Raman, R., Livny, M., Solomon, M.: Policy Driven Heterogeneous Resource CoAllocation with Gangmatching. In: Proc. of the 12th IEEE Int’l Symp. on High Performance Distributed Computing (HPDC-12), pp. 80–89 (2003) Tangmunarunkit, H., et al.: Ontology-based Resource Matching in the Grid—The Grid meets the Semantic Web. In: Proc. of SemPG03, vol. 2870, pp. 706–721 (2003) Said, M.P., Matono, A., Kojima, I.: SPARQL-based OWL-S Service Matchmaking. In: Proc. of 1st International Workshop on Semantic Matchmaking and Resource Retrieval: Issues and Perspectives, pp. 35–50 (2006) OGSA-DAI-RDF, http://wiki.dbgrid.org/index.php?OGSA-DAI-RDF
