1. RDFS-Plus See D. Allemang and J. Hendler, Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL, Morgan Kaufmann, 2008 Present a subset of OWL, RDFS-Plus, for several reasons:  Pedagogically, these constructs are a gentle addition to those already familiar from RDFS  Practically, this set of constructs has considerable utility More case studies use RDFS-Plus than RDFS alone  Computationally, this OWL subset can be implemented using a wide variety of inferencing technologies Lessens the dependency of the Semantic Web on any particular technology.

2. RDFS-Plus (like RDF) is expressed entirely in RDF The new resources are in namespace owl Their meanings (as in RDFS) are specified by the rules governing inferences made with them As with RDFS, the actions of an inference engine combine features of the schema language in novel ways

3. Inverse If a relationship (e.g., hasParent ) is interesting enough to mention, there’s probably another (e.g., hasChild ) that’s also interesting The inverse of a property is another property that reverse its direction The rule: Given P owl:inverseOf Q and x P y infer y Q x E.g., given lit:Shakespeare lit:wrote lit:Macbeth. lit:Macbeth lit:setIn geo:Scotland. and lit:wrote owl:inverseOf lit:writtenBy. lit:setIn owl:inverseOf lit:settingFor. infer lit:Macbeth lit:writtenBy lit:Shakespeare. geo:Scotland lit:settingFor lit:Macbeth.

4. But the effect of inverseOf can be achieved just as easily by writing queries differently E.g., to find the plays setIn Scotland, use the inverse property settingFor in a query pattern: [geo:Scotland lit:settingFor ?play. ]  But can avoid the inverse property and just write [?play lit:setIn geo:Scotland. ]

5. Challenge: Integrating Data that Do Not Want to be Integrated In the Property Union challenge, we had 2 properties, borrows and checkedOut  Combined them under a single property by making them both sub-properties of hasPossession  Lucky the 2 data sources had the same domain ( Patron ) and range ( Book ) But suppose the domain and range of the 2 nd data source are reversed:  It’s an index of books; for each book, there’s a field for the patron the book is signedTo

6. Challenge 10 Merge signedTo and borrows as we merged borrows and checkedOut Solution Use owl:inverseOf so the domains and ranges do match  Define a new property as the inverse of signedTo : :signedTo owl:inverseOf :signedOut. Now use the original Property Union pattern to merge signedOut and borrows : :signedOut rdfs:subPropertyOf :hasPossession. :borrows rdfs:subPropertyOf :hasPossession.

7. Given the triples :Amit :borrows :MobyDick. :Marie :borrows :Orlando. :LeavesOfGrass :signedTo :Jim. :WutheringHeights :signedTo :Yoshi. then, with the rule for inverseOf, we infer :Jim :signedOut :MobyDick. :Yoshi :signedOut :WutheringHeights. and, with subPropertyOf, we have (as desired) :Amit :hasPossessionOf :MobyDick. :Marie :hasPossession :Orlando. :Jim :hasPossession :LeavesOfGrass. :Yoshi :hasPossession :WutheringHeights.

8. Solution (Alternative) The choice to specify an inverse for signedTo rather than for hasPossession was somewhat arbitrary Use the same rules for owl:inverseOf and rdfs:subPropertyOf  in a different order but  resulting in the same hasPossession triples :signedTo rdfs:subPropertyOf :possessedBy. :borrows rdfs:subPropertyOf :hasPossession. :possessedBy owl:inverseOf :hasPossession. We want to support not only desired inferences but also reuse  A future query could be interested in hasPossession or in possessedBy  And we might later wish to combine hasPossession or possessedBy with another property

9. So we might use both solutions together by using inverseOf and subPropertyOf systematically:  Specify inverses for every property, regardless of subProperty level :signedTo owl:inverseOf :signedOut. :signedTo rdfs:subPropertyOf :possessedBy. :signedOut rdfs:subPropertyOf :hasPossession. :lentTo owl:inverseOf :borrows. :lentTo rdfs:subPropertyOf :possessedBy. :borrows rdfs:subPropertyOf :hasPossession. :possessedBy owl:inverseOf :hasPossession. Fig. 1 displays the systematic nature of this structure

10. Shouldn’t there be owl:inverseOf arrows point right-to-left as well as those point left-to-right in Fig. 1?  Yes, but we needn’t assert them—see the next challenge

11. Challenge: Using the Modeling Language to Extend the Modeling Language Extra OWL features beginners find missing often can be supported by OWL as a combination of other features Challenge 11 Define a superClassOf property, so the parent class is the subject of all definitional triples  Use namespace myowl for this relation, :Food myowl:superClassOf :bakedGood; myowl:superClassOf :Confextionary; myowl:superClassOf :PackagedFood; myowl:superClassOf :PreparedFood; myowl:superClassOf :ProcessedFood. With rdfs:subClassOf, all triples would go the other way

12. Solution For any triple of the form P myowl:superClassOf Q. we want to be able to infer Q rdfs:subClassOf P. Do this simply by declaring an inverse: myowl:superClassOf owl:inverse rdfs:subClassOf. Beginners often think they have no right  to extend the meaning of the OWL language or  to make statements about the OWL and RDFS resources (e.g., rdfs:subClassOf )

13. In fact, the standards don’t prevent us from putting the subject of the above in the RDFS namespace: rdfs:superClassOf owl:inverse rdfs:subClassOf. But referring to a resource in the RDFS namespace suggests to a human reader of the model that this relation is part of the RDFS standard  Selecting namespaces for resources that extend OWL is a delicate matter

14. Challenge: The Marriage of Shakespeare Earlier, we could assert that Anne Hathaway married Shakespeare but couldn’t assert that Shakespeare married Anne Challenge 12 Infer marriages in the reverse direction from that in which they’re asserted

15. Solution Just declare bio:married to be its own inverse: bio:married owl:inverse bio:married. Now a triple using bio:married is automatically inferred to hold in the other direction E.g., given bio:AnneHatheway bio:married lit:Shakespeare. we can infer lit:Shakespeare bio:married bio:AnneHathaway. This pattern of self-inverses is so common that it’s built into OWL using special construct owl:SymmetricProperty

16. Symmetric Properties Unlike owl:inverseOf (a property relating 2 other properties), owl:SymmetricProperty is an aspect of a single property  Expressed as a class P a owl:SymmetricProperty. From this, infer P owl:inverseOf P. E.g., we can assert bio:married a owl:SymmetricProperty.

17. Using OWL to Extend OWL In Fig. 1, all inverses go in one direction  But we need them to go in both directions—see Fig. 2 We asserted left-to-right triples: :possessedBy owl:inverseOf :hasPossession. :signedTo owl:inverseOf :signerOut. :lentTo owl:inverseOf :borrows.

18. We want to be able to infer right-to-left triples: :hasPossession owl:inverseOf :possessedBy. :signedOut owl:inverseOf :signedTo. :borrows owl:inverseOf :lentTo.

19. Challenge 13 Infer these triples without having to assert them Solution We want owl:inverseOf to work in both directions, i.e., to be its own inverse: owl:inverseOf owl:inverseOf owl:inverseOf. A more readable and understandable way of saying the same is owl:inverseOf a olw:SymmetricProperty. In either case, we get the bidirectional inverses of Fig. 2

20. Transitivity In math, relation R is transitive if R(a,b) and R(b,c) implies R(a,c) Like owl:SymmetricProperty, owl:TransitiveProperty is a class of properties P a owl:TransitiveProperty. Rule: Given P a owl:TransitiveProperty, x P y, and y P z, infer x P z Using transitivity repeatedly, we can pull together the start and end individuals of a chain of individuals related by a transitive property P Given x 0 P x 1, x 1 P x 2, …, and x n-1 P x n, infer x 0 P x n

21. Typical examples of transitive properties include  Ancestor/descendant: If x is an ancestor of y and y is an ancestor of z then x is an ancestor of z  Geographical containment: If Tokyo is in Japan and Japan is in Asia, then Tokyo is in Asia

22. Challenge: Relating Parents to Ancestors A model of genealogy includes parents and ancestors  We’d like them to fit together  But ancestors are transitive while parents aren’t Challenge 14 Allow a model to maintain consistent ancestry info, given parentage info

23. Solution First define the parent property to be a subPropertyOf the ancestor property: :hasParent rdfs:subPropertyOf :hasAncestor. Then declare ancestor (only) to be transitive: :hasAncestor a owl:TransitiveProperty. E.g., assert :Alexia :hasParent :WillemAlexander. :WillemAlexander :hasParent :Beatrix. :Beatrix :hasParent :Wilhelmina. Because of  the subPropertyOf relation between hasParent and has hasAncestor and  the fact that hasAncestor is transitive, we can infer what’s on the next slide (see Fig. 3)

24. :Alexia :hasAncestor :WillemAlexander. :WillemAlexander :hasAncestor :Beatrix. :Alexia :hasAncestor :Beatrix. :WillemAlexander :hasAncestor :Wilhelmina. :Alexia :hasAncestor :Wilhelmina. Info about the heritage is integrated, whether it originated with hasParent or with hasAncestor  But info about hasParent is only available as asserted— not transitive

25. Challenge: Layers of Relationships It’s sometimes controversial whether a property is transitive  E.g., Favre’s thumb is part of Favre and Favre is part of the Vikings, but … To anticipate possible uses of the model, support both points of view when controversy might arise Challenge 15 Simultaneously maintain transitive and non-transitive versions of part of info

26. Solution Define 2 versions of the partOf property in different namespaces (or with different names) with  one a subPropertyOf the other and  the super-property declared transitive dm:partOf rdfs:subPropertyOf gm:partOf. gm:partOf a owl:TransitiveProperty. Depending on which interpretation of partOf an application needs, it can query the appropriate property

27. Managing Networks of Dependencies Now see how the constructs r dfs:subPropertyOf, owl:inverseOf, and owl:transitiveProperty can be combined to model aspects of networks of dependencies In workflow management, the sequence of tasks in a complex working situation is represented explicitly  The progress of each task is tracked in that sequence Workflow is modeled in a Semantic Web so that parts of it can be shared with others  This encourages reuse, review, and publication of work fragments

28. Take a simple example: making ice cream  Slice a vanilla bean lengthwise, scraping the contents into 1 cup of heavy cream  Bring the mixture to a simmer (but don’t boil) While the cream is heating …  Separate 3 eggs  Add ½ cup white sugar  Beat until fluffy Then …  Gradually add the warm cream, beating constantly  Return the custard mixture to medium heat, and cook until mixture leaves a heavy coat on the back of a spatula  Chill well  Combine custard with 1 cup whole milk  Turn in ice cream freezer according to manufacturer’s instructions

29. Property dependsOn represents dependencies between steps  Its inverse is enables :SliceBean :enables :HeatCream. :SeparateEggs :enables :AddSugar. :AddSugar :enables :BeatEggs. :BeatEggs enables :GraduallyMix. :HeatCream :enables :GraduallyMix. :GraduallyMix :enables :CookCustard. :CookCustard :enables :Chill. :Chill :enables :AddMilk. :AddMilk :enables :TurnInFreezer.

30. Challenge 16 For a given step, we’d want to know all the steps it depends on or all that depend on it Solution Use the subPropertyOf / TransitiveProperty pattern for both dependsOn and enables (see Fig. 6): :dependsOn rdfs:subPropertyOf :hasPrerequisite. :hasPrerequisite a owl:TransitiveProperty. :enables rdfs:subPropertyOf :prerequisiteFor. :prerequisiteFor a owl:TransitiveProperty.

31. We can then infer, e.g., that GraduallyMix has 5 prerequisites: :GraduallyMix :hasPrerequisite :AddSugar ; :hasPrerequisite :SeparateEggs ; :hasPrerequisite :SliceBean ; :hasPrerequisite :HeatCream ; :hasPrerequisite :BeatEggs.

32. Challenge 17 In a realistic setting, we’d manage several interacting processes and might even lose track of what steps are in the same procedure In the recipe example, can we connect the steps in the same recipe together? Solution Combine both fundamental relationships ( enables and dependsOn ) as common sub-properties of neighborStep  Make neighborStep a sub-property of a transitive property, inSameRecipe :dependsOn rdfs:subPropertyOf :neighborStep. :enables rdfs:subPropertyOf :neighborStep. :neighborStep rdfs:subPropertyOf :inSameRecipe. :inSameRecipe a owl:TransitiveProperty.

33. Any step directly related (related by dependsOn or enables ) to another step has that step as a neighborStep  Any combination of neighbors is rolled up with inSameRecipe In fact, any 2 steps here will be related by inSameRecipe  This includes relating each step to itself—e.g., :GraduallyMix :inSameRecipe :GraduallyMix. This might not be what we want

34. Challenge 18 Define a property that relates a recipe only to the other steps in the same recipe Solution Earlier defined properties hasPrerequisite (looking downstream along the dependencies) and prerequisiteFor (looking upstream): :dependsOn rdfs:subPropertyOf :hasPrerequisite. :hasPrerequisite a owl:TransitiveProperty. :enables rdfs:subPropertyOf :prerequisiteFor. :prerequisiteFor a owl:TRansitiveProperty. Now join these under a common super-property that isn’t transitive: :hasPrerequisite rdfs:subPropertyOf :otherStep. :prerequisiteFor rdfs:subPropertyOf :otherStep.

35. We’ve already seen the triples we can infer for hasPrerequisite involving GradualyMix :GraduallyMix :hasPrerequisite :AddSugar ; :hasPrerequisite :SeparateEggs ; :hasPrerequisite :SliceBean ; :hasPrerequisite :HeatCream ; :hasPrerequisite :BeatEggs. For prerequisiteFor, we get :GraduallyMix :prerequisiteFor :AddMilk ; :prerequisiteFor :CookCustard ; :prerequisiteFor :TurnInFreezer ; :prerequisiteFor :Chill. For otherStep, the set of triples involving GraduallyMix is just the union of the above 2 sets  There is no reflexive triple

36. Fig. 7 shows the 2 patterns For inSameRecipe, a single transitive property is at the top of the subproperty tree  Both primitive properties are brought together  Any combinations of the resulting property ( neighborStep ) are chained together as a transitive property ( inSameRecipe ) For otherStep, the top property itself isn’t transitive  It’s a simple combination of 2 transitive properties  Inference for each is done separately, and the results combined

37. Equivalence In RDF, the URI provides global identity, valid across data sources  Lets us refer to a single entity in a distributed way But suppose we have info from multiple sources controlled by multiple stakeholders  Stakeholders might use different URIs to refer to the same entity In a federated setting, want to stipulate that 2 URIs actually refer to the same entity

38. Equivalent Classes We’ve used the double- subClassOf idiom to express that one class, A, has the same elements as another, B A rdfs:subClassOf B. B rdfs:subClassOf A. When 2 classes are known always to have the same members, they’re equivalent RDFS-Plus has a simpler way to express equivalence of classes A owl:equivalentClass B. For classes A and B and individual x, we have 2 rules: Given A owl:equivalentClass B and x a A, infer x a B Given B owl:equivalentClass A and x a B, infer x a A

39. But the following is given owl:equivalentClass a owl:SymmetricProperty.  So we don’t need the 2 nd rule—infer it from the 1 st We don’t even need the 1 st rule since it’s also given that owl:equivalentClass rdfs:subPropertyOf rdfs:subClassOf. To see how this works, suppose we have :Analyst owl:equivalentClass :Researcher.  From this and the rdfs:subClassOf rule, we have :Analyst rdfs:subClassOf :Researcher.  By symmetry, we also have :Researcher owl:equivalentClass :Analyst.  And, by the rdfs:subClassOf rule again, :Researcher rdfs:subClassOff :Analyst.

40. So, given equivalence, we get the double- subClassOf characterization from what’s built in Equivalence means only that the 2 classes have the same members  Other properties of the classes (e.g., rdfs:label values) aren’t shared  So, if 2 classes are merged from different applications, each application still displays the class by the original print name Only the members change

41. Equivalent Properties We’ve used the double-s ubPropertyOf idiom to express that one property, P, is equivalent to another, Q P rdfs:subPropertyOF Q. Q rdfs:subPropertyOf P. RDFS-Plus also has a simpler way to express property equivalence P owl:equivalentProperty Q. For properties P and Q ad individuals x and y, we again have 2 rules: Given P owl:equivalentProperty Q and x P y, infer x Q y Given P owl:equivalentProperty Q and x Q y, infer x P y

42. But, again, these rules can be derived from what is built in owl:equivalentProperty rdfs:subPropertyOf owl:subPropertyOf. owl:equivalentProperty a owl:SymmetricProperty. Starting with :borrows owl:equivalentProperty :checkedOut.  by the subPropertyOf rule we get :borrows rdfs:subPropertyOf :checkedOut.  By SymmetricProperty, we also get :checkedOut owl:equivalentProperty :borrows.  whence, again by the subPropertyOf rule, :checkeOut rdfs:subPropertyOf :borrows.

43. Rather than just noticing that the rule governing owl:equivalentProperty is the same as that governing rdfs:subPropertyOf (except it works both ways), we actually express these facts with triples By making owl:equivalentProperty a sub-property of rdfs:subPropertyOf, we explicitly assert that they’re governed by the same rule By making o wl:equivalentProperty an owl:SymmetricProperty, we assert that this rule works in both directions This makes the relationship between the parts of the OWL language explicit and, in fact, models them in OWL

44. Same Individual owl:equivalentClass and owl:equivalentProperty provide simple ways to express what’s already expressible in RDFS  They don’t increase the expressive power of RDFS-Plus Things in the world, members of classes, are called individuals (i.e., real-word resources)  We’ve seen surgeons, plays, countries, playwrights, … But, in the absence of agreement on global names, different Web authors select different URIs for the same individual

45. When info from the different sources is brought together in the distributed network of data, the Web infrastructure has no way to know that certain pairs of names should be treated as denoting the same individual The flip side is that we can’t assume that, just because 2 URIs are distinct, they denote distinct individuals The Non-unique Naming Assumption: We must assume (until told otherwise) that some Web resource might be referred to using different names by different people When we do determine that 2 individuals are in fact the same, we use the owl:sameAs property

46. As an example, suppose we have the following triples about the literary career of William Shakespeare: lit:Shakespeare lit:wrote lit:Hamlet ; lit:wrote :lit:Othello ; Etc. Suppose we have access to the Stratford Parish Register (namespace prefix spr: ), with the following baptism info spr:Gulielmus spr:hasFather spr:JohannesShakspere. spr:Hamnet spr:hasFather spr:WilliamShakspere. Etc. Suppose research finds that spr:Gulielmus, spr:WilliamShakspere, and lit:Shakespeare all refer to the same individual If we’d known this before representing the Stratford Parish Register in RDF, we could have used the same URI in all cases  But the URIs from each data source have been chosen

47. We can assert of 2 of the resources spr:WilliamShakspere owl:sameAs lit:Shakespeare. The rule for owl:sameAs Given A owl:sameAs B and a triple containing A, infer a triple that is identical except that A is replaced by B So, given any triple of the form spr:WilliamShakspere P O. we can infer lit:Shakespeare P O. And, from any triple of the form S P spr:WilliamShakespeare. we can infer S P lit:Shakespeare.

48. We also have that owl:sameAs is symmetric owl:sameAs a owl:SymmetricProperty.  So we can replace any occurrence of lit:Shakespeare with spr:WilliamShakspere as well We can now infer, e.g., spr:WillaimShakspere lit:wrote lit:Hamlet ; lit:wrote :lit:Othello ; Etc. as well as, e.g., spr:Hamnet spr:hasFather lit:Shakespeare. Etc.

49. Challenge: Merging Data from Different Databases Recall how to interpret info in a table as RDF triples Each row becomes an individual Each cell becomes a triple  The subject is the individual corresponding to the row  The predicate is made up from the table name and the column name  The object is the cell contents Table 1 shows 63 triples for the 7 columns and 9 rows

50. Some of the triples relating to Manufacture_Location mfg:Product1 mfg:Product_Manufacture_Location "Sacramento". mfg:Product2 mfg:Product_Manufacture_Location "Sacramento". mfg:Product3 mfg:Product_Manufacture_Location "Sacramento". mfg:Product4 mfg:Product_Manufacture_Location "Elizabeth". mfg:Product5 mfg:Product_Manufacture_Location "Elizabeth". Suppose another division in the company keeps a table of the facilities needed to produce various parts—Table 2 Some of the products in Table 1 appear in Table 2 and some don’t

51. Challenge 19 Using the products in both tables, write a federated query cross- referencing cities with the facilities required for the production there Solution If the tables were in a single database, there could be foreign-key references from one table to the other  We could join the 2 tables But the tables are from different databases, there’s no such common reference

52. When we turn the tables into triples, the individuals corresponding to rows are assigned global identifiers  Use namespace p: for the 2 nd table Some of the triples corresponding to the required facilities p:Product1 p:Product_Facility "Assembly Center". p:Product2 p:Product_Facility "Assembly Center". p:Product3 p:Product_Facility "Assembly Center". p:Product4 p:Product_Facility "Assembly Center". p:Product5 p:Product_Facility "Factory". The global identifiers aren’t the same, so we need p:Product1 owl:sameAs mfg:Product4. p:Product2 owl:sameAs mfg:Product6. p:Product4 owl:sameAs mfg:Product3. p:Product5 owl:sameAs mfg:Product1. p:Product7 owl:sameAs mfg:Product5. p:Product8 owl:sameAs mfg:Product8.

53. Now matching the SPARQL pattern [?p p:Product_Facility ?facility. ?p mfg:Product_Manufacture_Location ?location.] and displaying ?facility and ?location gives the results in Table 3 The solution relied on knowing which product in one table matched with which in the other In a real situation, the data in the tables change frequently  Not practical to assert all the owl:sameAs triples by hand See what follows

54. Computing Sameness—Functional Properties Functional Properties A functional property can take only 1 value for any given individual Rule Given P a owl:FunctionalProperty, x P A, and x P B, infer A owl:sameAs B Functional properties allow sameness to be inferred

55. For example, suppose from the Stratford Parish Register we have lit:Shakespeare fam:hasFather bio:JohannesShakespeare. and that from Shakespeare’s grave we have lit:Shakespeare fam:hasFather bio:JohnShakespeare. If we know from a background model of family relationships that fam:hasFather a owl:FunctionalProperty we may infer bio:JohannesShakespeare olw:sameAs bio:JohnShakespeare. For determining sameness, owl:InverseFunctionalProperty is much more common than owl:FunctionalProperty

56. Inverse Functional Properties Some consider owl:InverseFunctionalProperty the most important modeling construct in RDFS-Plus Think of owl:InverseFunctionalProperty as the inverse of owl:FunctionalProperty Rule Given P a owl:InverseFunctionalProperty, A P x, and B P x, infer A owl:sameAs B

57. An owl:InverseFunctionalProperty plays the role of a key field in a relational database Unlike with a relational database, RDFS-Plus doesn’t signal an error if 2 entities are found to share a value for an inverse functional property  Instead, it infers that the 2 are the same Any identifying number (e.g., SSN, driver’s license number, …) is an inverse functional property

58. Challenge 20 Infer the requied owl:sameAs triples from the data already asserted Solution Find an inverse functional property present in both data sets  Use it to bridge them Tables 1 and 2 both have a field called ModelNo  If 2 products have the same model number, they’re the same product, so mfg:Product_ModelNo a owl:InverseFunctionalProperty. Must arrange that we’re talking about a single property p:Product_ModelNo owl:equivalentProperty mfg:Product_ModelNo. Could do these steps in either order  And could write the last triple with subject and object reversed

59. So, since we have, e.g., p:Product1 p:Product_ModelNo "B-1430". mfg:Product4 mfg:Product_ModelNo "B-1430". we may infer p:Product1 owl:sameAs mfg:Product4. Likewise for the remaining sameAs triples Most real data integration situations rely on more elaborate notions of identity  Include multiple properties and encounter uncertain or ambiguous cases This problem can often be solved with combinations of OWL properties we’ll explore later  A fully general solution remains a research topic

60. Combining Functional and Inverse Functional Properties Often useful for a property to be 1-to-1, i.e., both functional and inverse functional  Often the case for identification numbers

61. Challenge 21 Assign to students id numbers used for billing and assigning grades No 2 students should share an id number  No student should have more than 1 id number Solution Define property hasIdenityNo with the appropriate domain and range :hasIdentityNo rdfs:domain :Student. :hasIdentityNo rdfs:range xsd:Integer. Enforce uniqueness by asserting :hasIdentityNo a owl:FunctionalProperty. :hasIdentityNo a owl:InverseFunctionalProperty.

62. More RDFS-Plus Constructs The small extensions RDFS-Plus provides greatly increase the applicability of RDFS  owl:inverseOf combines with rdfs:subClassOf to let us align properties that aren’t expressed in compatible ways in existing data schemas  owl:TransitiveProperty combines with rdfs:subPropertyOf in several novel ways, letting us model various relationships among chains of individuals From a Semantic Web perspective, the most applicable extensions are those dealing with sameness: sameAs, FunctionalProperty, InverseFunctionalProperty  They provide a way to describe how info from multiple sources is to be merged in a distributed web of info

63. Classes owl:DataTypeProperty and owl:ObjectProperty let us distinguish between  properties whose values are objects and  properties whose values are a data type They provide no additional semantics  They provide useful discipline and info for editing tools for, e.g., displaying models Most OWL tools prefer to distinguish datatype properties (e.g., ship:maidenVoyage ) and object properties (e.g., bio:married ) ship:maidenVoyage a owl:DatatypeProperty. bio:married a owl: ObjectProperty.

64. Another distinction OWL makes is between rdfs:Class and owl:Class  We’ve been using rdfs:Class but have introduced several OWL constructs to get to RDFS-Plus  Since OWL is based on RDFS, backward compatibility isn’t an issue, and the OWL specification stipulates owl:Class rdfs:subClassOf rdfs:Class. Most tools require that classes used in OWL models be declared members of owl:Class  In the RDFS-Plus examples, we’ve left class declarations implicit If explicit, they’d use owl:Class  Most model editors declare a class an owl:class automatically when it’s created We’ll discuss some subtle distinctions later