07.12 Definitions of the classes and properties that make up the SSWAP Protocol. A required class. In the concept of a service mapping an input to an output, the sswap:Subject corresponds to the input. The property sswap:mapsTo explicitly demarcates the mapping (or transformation) from this input to its output. One can also use sswap:mapsTo to describe inverse mappings where the stated relationship is *from* a sswap:Object to a sswap:Subject. Required predicates: <none> Optional predicates: mapsTo metadata While the sswap:mapsTo predicate is not strictly required, there must be at least one mapsTo relation from either a sswap:Subject to a sswap:Object or a sswap:Object to a sswap:Subject (designating an inverse mapping). In most cases, services will use the former to express their mapping. SSWAP classes use recognizable patterns to express required and optional predicates. Basically, cardinality constraints on predicates within an owl:equivalentClass block describe required predicates, while the same inside rdfs:subClassOf blocks describe optional predicates. This model can be used by any service in its own Resource Description Graph to express required and optional arguments. Cardinality may be explicit (using owl:cardinality, owl:minCardinality, and owl:maxCardinality) or implicit (e.g., owl:someValuesFrom). For required properties, enter each property's cardinality restriction within an owl:equivalentClass owl:intersectionOf block to assert that the combined set of all such properties and restrictions are necessary and sufficient--i.e., that they define the class. For an optional property, enter the property's cardinality restriction with an rdfs:subClassOf assertion. For example, given: <owl:Thing rdf:about="anInvocationObject"> <rdf:type rdf:resource="&sswap;Subject"> <rdf:type rdf:resource="MyServiceInvocationObject> </owl:Thing> (Note that in the above [and below] syntax, we follow the SSWAP convention and place every term in its own file, thus the syntax of "rdf:resource="MyServiceInvocationObject", and not "rdf:resource="#MyServiceInvocationObject"). then in a separate file defining the class: <owl:Class rdf:about="MyServiceInvocationObject"> <!-- This block creates the necessary and sufficient conditions--the definition--for this class. If an individual is not explicitly asserted to be belonging to this class (no rdf:type statement), but it satisfies everything in the owl:equivalentClass block, then a reasoner can and will conclude that indeed the individual is of this class and can add an explicit rdf:type statement to that effect to the knowledge base. Similarly, if an individual is declared to be of this class (either because of an explicit rdf:type assertion, or because it is the RDF subject of a property that has this class as it's rdfs:domain, or it is the RDF object of a property that has this class as it's rdfs:range), then a reasoner can conclude that this individual has certain predicates, as logically necessary re the cardinality constraints below. If a logical impossibility exists between an assertion or derivation that an individual is a member of this class, and the implications of the statements below, then the ontology is considered inconsistent. In that manner, consistency checking can be used as a type of (limited) validator. --> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <!-- use cardinality to limit the number of semantically distinct values for a predicate on any given individual of this class. Note that cardinality is not restricting the number of occurrences of the predicate (e.g., 0, 1, 2, ...), just the number of semantically distinct values. When we restrict an owl:DatatypeProperty to a cardinality of 1, we are saying that the predicate can only point to one distinct value. For example, if the data type is &xsd;decimal (any real number), and one instance of the predicate points to "1" and another points to "1.0", then the values are semantically the same and thus the statements are legal. But if one pointed to "1" and the other to "2", then the ontology would be inconsistent. In this manner we can use consistency to partially validate the graph with respect to a predicate. But if there were no predicates, the ontology would not be inconsistent. With a cardinality of exactly 1 inside an owl:equivalentClass block, the reasoner was presented with an individual claiming to be of this class but lacking the predicate, the reasoner would conclude that the predicate "existed" (i.e., the individual had it), but that it simply had not (yet) been stated. This behavior is a consequence of what is called the Open World Assumption. In this manner, you cannot use a consistency check to validate that all individuals of this class have the predicate explicitly stated. (A subtle exception is if the predicate's range was defined to be an enumeration [owl:oneOf] exactly one value, or if the predicate's use in this class's definition was restricted by owl:hasValue. In those cases the reasoner would have sufficient knowledge of the value of the predicate and could deduce the assertion itself). Given all this, below we limit our 'requiredParameter' to one and exactly one integer value. --> <owl:Restriction> <owl:onProperty rdf:resource="requiredParameter"/> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality> </owl:Restriction> <!-- we can use cardinality restrictions on owl:ObjectPropert[ies], though the validation implications are somewhat different. Here, if the cardinality is set to exactly 1, and two instances of the predicate each pointed to lexically distinct (or identical) URIs, a reasoner would conclude that the two entities represented by the URLs are semantically the same--just as if you had joined them with an owl:sameAs relation. Be careful with this because this can introduce some subtle implications that may make the ontology inconsistent later.--> <owl:Restriction> <owl:onProperty rdf:resource="requiredData"/> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality> </owl:Restriction> <-- One cannot use cardinality restrictions on owl:TransitivePropert[ies]. It is unlikely that a predicate used an argument for a service would be transitive, but there are other patterns (below) that imply cardinality without the explicit use of owl:cardinality, owl:minCardinality, or owl:maxCardinality. --> <!-- this says that each and every value (RDF object) of the 'requiredData' predicate is of class dataClass. This is called a universal restriction. It in itself makes no cardinality implications, but it is often used in concert with the existential restriction below. --> <owl:Restriction> <owl:onProperty rdf:resource="requiredData"/> <owl:allValuesFrom rdf:resource="dataClass"/> </owl:Restriction> <!-- this says that at least one of the requiredData values is of the class 'dataClass'. This is called an existential restriction. By saying "at least one", it implies a minCardinality of 1 without explicitly using owl:minCardinality, so it is also called a Qualified Cardinality Restriction. Because in this example this restriction is inside an owl:equivalentClass block, an individual must have at least one instance of this property pointing to something of the class 'dataClass' for it to be a member of this class. --> <owl:Restriction> <owl:onProperty rdf:resource="requiredData"/> <owl:someValuesFrom rdf:resource="dataClass"/> </owl:Restriction> <!-- it is also valid to use owl:allValuesFrom and owl:someValuesFrom on owl:DatatypePropert[ies], though you don't see this very often: --> <!-- this says that for this class definition, requiredParameter is constrained such that all values of are integers ... --> <owl:Restriction> <owl:onProperty rdf:resource="requiredParameter"/> <owl:allValuesFrom rdf:resource="&xsd;nonNegativeInteger"/> </owl:Restriction> <!-- ... and at least one value (as an integer) exists, thus establishing a qualified cardinality restriction. --> <owl:Restriction> <owl:onProperty rdf:resource="requiredParameter"/> <owl:someValuesFrom rdf:resource="&xsd;nonNegativeInteger"/> </owl:Restriction> <!-- another way to impose cardinality is to list every individual in a class. This is called enumeration, and is the logical equivalent of a "radio button" or "pulldown menu" delineating the exact choice of valid values. Enumeration can be done with either owl:DatatypePropert[ies] or owl:ObjectPropert[ies]. Enumeration can also be imposed globally--for all uses of the predicate, not just its use in this class's definition—by using it in the predicate's rdfs:range (see below). --> <owl:Restriction> <owl:onProperty rdf:resource="requiredFlag"/> <owl:allValuesFrom> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <rdf:Description rdf:about="flag_1"/> <rdf:Description rdf:about="flag_2"/> </owl:oneOf> </owl:Class> </owl:allValuesFrom> </owl:Restriction> <!-- the above relations restrict a predicate vis-a-vis this, and only this class definition. To make a global cardinality assertion that a predicate has one and only one semantically distinct *value* (i.e., RDF object) for each individual subject (it can have different values across individuals), define the predicate to be owl:FunctionalProperty (e.g., if (s,y1), (s,y2) then the reasoner can infer y1 = y2 for each semantically distinct s). To make the global cardinality assertion that a predicate has one and only one semantically distinct * RDF subject* for a given value (RDF object), define the predicate to be owl:InverseFunctionalProperty (e.g., if (s1,o), (s2,o) then the reasoner can infer s1 = s2 for each semantically distinct o). In OWL-DL, owl:InverseFunctionalProperty only applies to owl:ObjectPropert[ies]. As a global property of the predicate, these assertions are not done here in this class's definition, but in the predicate's definition; e.g.: <owl:DatatypeProperty rdf:ID="parameter"> <rdf:type rdf:resource="&owl;FunctionalProperty"/> </owl:DatatypeProperty> --> <!-- You can also globally define a predicate's domain and range. Again, because these are restrictions on the predicate in any and all of its uses, you do that in the predicate's definition, not in a class's definition. Note that when you define a predicate's domain (rdfs:domain) or range (rdfs:range), you are not just saying that those are the circumstances in which the predicate can be used--for example, if the domain is ClassA, then it can be used as a property of any individual of ClassA, but not of ClassB. This is not the statement being made. When you use rdfs:domain and rdfs:range you are telling a reasoner that the predicate can be used *anywhere*, and that the reasoner can then infer that the subject is of ClassA (in the case of rdfs:domain) and/or that the object is of ClassA (in the case of rdfs:range)--just as if you had explicitly rdf:type[d] the individual as such. If an individual is of a class that is disjoint with the domain or range and the predicate is used, then the ontology will be inconsistent. --> <!-- You will notice that nowhere in the above is it possible to required that an individual have a predicate explicitly stated. The existence of a predicate may be logically implied, but it cannot be demanded as explicitly stated in a class definition. This actually has weaker consequences than one may think. Once you've made the logical requirement that an individual has a predicate, all a service needs to do is ask for it and be prepared that it may not be available in ill-formed individuals. --> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> <!-- Essentially all of the above also applies to optional arguments, except that for optional arguments we say that this class is a rdfs:subClassOf a class with cardinality restrictions on the predicate. One benefit of using owl:equivalentClass and rdfs:subClassOf to declare required and optional arguments is that it constrains the predicates in their uses for a given class and application. If we introduced something like "requireDatatypeProperty" and "optionalDatatypeProperty" (and the same for ObjectProperties), and then used rdfs:subPropertyOf, then we would be casting predicates globally as required or optional. Yet perhaps one provider's required argument is another's optional argument, so that solution would be overly restrictive in those cases. --> <!-- Here, we use owl:maxCardinality to state that we are a specialization on the class that has members that have 0 or 1 semantically distinct values for 'optionalParameter'. rdfs:subClassOf creates a necessary but not sufficient condition. So for an individual to be a member of this class, it does (must have) the restriction below; but given an individual with that restriction, a reasoner cannot conclude that it is indeed a member of this class without additional information. You can have multiple rdfs:subClassOf blocks, listed one after the other. They are logically combined as an intersection, though you do not need the explicit owl:intersectionOf semantics. --> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="optionalParameter"/> <owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality> </owl:Restriction> </rdfs:subClassOf> <!-- OWL, as a web ontology language, cannot unambiguously specify default values for predicates. But we can express default values using a simple best practices model. For default values, simply instantiate an individual (often a blank node) of this class in the SSWAP Resource Description Graph (RDG), e.g., as the sswap:Subject. Then set the parameter to the default value on the individual, e.g.: <sswap:Subject rdf:about="anInvocationObject"> <requiredParameter rdf:datatype="&xsd;nonNegativeInteger">1</requiredParameter> </sswap:Subject> In using the RDG as a template for the resource invocation graph to be sent back to the provider, either keep the value as-is (i.e., accept the default), or change it to reflect the new value. Thus, default values are not part of the class's definition, but are part of the class's use in an RDG. This allows different providers to share class definitions while using different default values. --> </owl:Class> 1 0 A required class. In the concept of a service mapping an input to an output, the sswap:Object corresponds to the output. The property sswap:mapsTo explicitly demarcates the mapping (or transformation) from an input to this output. One can also use sswap:mapsTo to describe inverse mappings where the stated relationship is *from* a sswap:Object to a sswap:Subject. Required predicates: <none> Optional predicates: mapsTo metadata 1 0 A required class. This class designates the provider of one or more resources. Providers claim ownership of resources and are anticipated to be associated with actual organizations such as W3C, NCBI, etc. Providers may state that they provide multiple resources by using multiple providesResource properties. It is expected that the provider description will be in its own file, separate from the Resource Description Graphs. Required predicates: name Optional predicates: aboutURI metadata oneLineDescription providesResource The owl:Restriction on sswap:providedBy refines the class definition so as to prohibit the reasoner from otherwise incorrectly infering that swap:Provider is a rdfs:subClassOf sswap:Resource. sswap:providedBy is not a valid predicate for a sswap:Provider. See sswap:Resource for notes on sswap:providesResource and sswap:providedBy. 1 1 1 0 1 0 Super class of all SSWAP classes. SSWAP classes use recognizable patterns to express required and optional predicates. Basically, cardinality constraints on predicates within an owl:equivalentClass block describe required predicates, while the same inside rdfs:subClassOf blocks describe optional predicates. This model can be used by any service in its own Resource Description Graph to express required and optional arguments. See sswap:Subject, since this is the class that resource providers will use to express the input data types of their services. Conditions for inclusion in the class are weak: in accordance with the open world assumption, any individual can be a member of this class except those known to belong to a class disjoint from every SSWAP subclass. 1 1 1 1 1 A required class. This class designates the semantically described resource. Resources that "do things," for example, transform input (sswap:Subject) to output (sswap:Object) are commonly called services. Resources may also be web pages, ontologies, etc. A sswap:Resource sswap:operatesOn one or more sswap:Graphs, where the sswap:Graph acts as a data structure containing the mapping of some input (sswap:Subject) to some output (sswap:Object). All sswap:Resource(s) have a sswap:Provider (indicated by the sswap:providedBy predicate) which claims ownership of the resource (reciprocated by the sswap:providesResource predicate). If the resource's URL is a lexical sub-path of the provider, then the provider does not have to reciprocate the sswap:providesResource claim; but if the resource is claiming ownership by a provider whose URL is not a lexical sub-path, then the provider must explicitly reciprocate the claim with by using sswap:providesResource. Similarly, if a provider claims a resource which is not in a sub-path, then the resource must reciprocate the claim. Required predicates: name operatesOn providedBy Optional predicates: aboutURI inputURI metadata oneLineDescription outputURI 1 1 A required class. A sswap:Graph delineates a root or entry point for a suite of mappings. For services, a "mapping" embeds the concept of taking some input and returning some output. An individual of this class is the object of the sswap:hasMapping relationship from sswap:Resource. By differentially using sswap:operatesOn and sswap:hasMapping, one can, for example, differentiate between a pair of lists and a list of pairs. Required predicates: hasMapping Optional predicates: metadata 1 A property that connects a sswap:Graph to a sswap:Subject. The sswap:Subject's subgraph then contains the relevant mappings of an input (sswap:Subject) to its output (sswap:Object). A property that connects a sswap:Subject to a sswap:Object, or vice-versa. For services, this is usually used to establish the transformation from the input to the output. This property is directional (implies a mapping from the domain to the range), but can be used as its own inverse. So one may delineate a mapping from sswap:Subject to sswap:Object, and use another sswap:mapsTo to delineate a mapping from sswap:Object to sswap:Subject. Super property for all sswap object properties. This property is not used directly so it has no domain and range. Super property for all sswap datatype properties. This property is not used directly so it has no domain and range. A one line, human-readable description that programs may use to display brief information about a sswap:Resource or sswap:Provider. A human-readable name of an sswap:Resource or sswap:Provider. This property may be used by programs to display a name to users. Resources may require special user interfaces to gather input such as using web pages to solicit input from users. Programs that are preparing to invoke a resource may direct users to the URI pointed to by this property for the appropriate user interface. Points to a URI that may contain words, phrases, or other such text that programs may use to parse keywords associated with the property's object. Points to a URI for additional information about its domain object. It is expected that the URI may be a human-readable web page (an HTML resource). Programs may dereference the URI to provide users with additional information describing a sswap:Resource or sswap:Provider. A property identifying the entity providing the Resource. The Provider's URL must be in the same domain as the Resource, unless the Provider explicitly claims the Resource by including a providesResource statement, pointing at the Resource, in the Provider's description graph. Resources may require special user interfaces to display output such as using web pages to display output to users. Programs that are handling a resource's response may direct users to the URI pointed to by this property to handle the result graph. A property that connects a sswap:Resource to a sswap:Graph. The sswap:Graph's subgraph then contains the relevant mappings of an input (sswap:Subject) to its output (sswap:Object). A property identifying the provided Resource. The Resource's URL must be in the same domain as the Provider, unless the Resource explicitly claims the Provider by including a providedBy statement, pointing at the Provider, in the Resource's description graph.