Semantic Web for the Working Ontologist: Chapter 14

In this week's chapter, Dean Allemang and Jim Hendler cover "Good and bad modeling practices". To be clear, some of the "bad" modeling practices they include, are bad only in the context of the semantic web: they are standard in object systems and only become problematic when ported into an open environment where Anyone can say Anything about Anything, as opposed to a closed data system.

The chapter opens by outlining three ways to start model-building

1. "find models on the Web that suit your needs" - that way you don't end up wasting time and other resources redoing work that somebody's already been done
2. "leverage information assets that already have value for your organization": the information you're working with is likely to already be "vetted"
3. start from scratch, using "standard engineering practices … including the development of requirements definitions and test cases.

Whichever route you choose, there are questions that must be answered: is this model useful? What do we need this model to do? "This poses two issues for the modeler: How do I express my intended purpose for a model? How do I determine whether a model satisfies some purpose?' One way to do this is to frame "competency questions" – ie, questions the model will need to answer – before developing it.


The AAA assumption adds a massive element of complexity to the entire process, because

"On the Semantic Web, it is expected that a model will be merged with other information, often from unanticipated sources. This means that the design on a semantic model must not only respond to known requirements … but also express a range of variation that anticipates to some extent the organization of the information with which it might be merged."

All a bit mind-boggling, really.

The advice the authors give for dealing with this involves quoting the March Hare from Alice in Wonderland "say what you mean and mean what you say"

"Say what you mean and mean what you say"

Which translates into ensuring that

• the names you use for entities are meaningful
• you follow simple conventions (such as starting class and individual names with uppercase letters, property names with lowercase letters and naming classes with singular, rather than plural, nouns)
• you plan carefully in order to distinguish classes from individuals (this can be tricky)

 Once assembled, your shiny new model can be tested by by ensuring it answers the competency questions framed beforehand. Analysing "the inferences that the model entails" can determine "whether it maintains consistent answers to possible competency questions from multiple sources.




The remainder of the chapter is taken up with analysis of four common modeling errors:

1. Rampant classism -– where everything is defined as a class, even if it should be an individual
2. Exclusivity – the flawed assumption that "the only candidates for membership in a subclass are those things that are already known to be members of a superclass".
3. Objectification – where a system is built for the web that "has the same meaning and behaviour as an object system", which doesn't take into account "AAA, Open World and Nonunique Naming"
4. Creeping conceptualization – when good modelers go bad (oh, ok, just get carried away) and "the idea of 'design for reuse' gets confused with 'say everything you can'" as modelers try to anticipate every conceivable use for their model and model all conceivable uses.

Ultimately, the authors say the way of telling if you've built a model that is useful and conforms to the assumptions inherent in the Semantic Web is "by making sure that the inferences it supports are useful and meaningful". Which seems slightly tautological, but hey, what do I know?



Next week I'm on holiday, and, in a shock break with tradition, am staying somewhere with no wifi. So I won't be blogging. Or – probably – coping with the lack of connectivity. Back in a fortnight…

Semantic Web for the Working Ontologist: Chapter 12

Data modeling gets intricate

This week, it's "Counting and sets in OWL". Intricate stuff for a newbie data modeler, and takes me back to A level maths (I scraped a pass. With tutoring).

As the title suggests there's a lot of set theory here. The chapter kicks off with a reminder about restrictions and how they can be used

• "to define notions like Vegetarian"
• "to sift information from a table"

and

• "to manage groups of people"

Intersections, unions and other class relationships 

The rest of the chapter then covers how combining restrictions with the set theory language provided in OWL enables complex and precise relationships and identities to be defined. OWL set theory language includes

• intersections: an intersection of two or more classes = a new class owl:intersectionOf
• unions: all the members of all the classes combined owl:unionOf
• complements: " the complement of a set is the set of all things not in that set". owl:complementOf. This needs to be used with care as say, the complement of the set of, say, everyone in the Iranian women's football squad includes not only everyone in Iran who isn't in the national football squad, but everything else in the known (and unknown) universe: animate, inanimate and other*.
• disjoints - two sets with no members in common. eg: ":Meat owl:disjointWith :Fruit"

and is complemented (but not in the set theory sense) by OWL's use of cardinalities: these refer to "the number of distinct values for a particular property some individual has".

Anyone can (still) Say Anything about Any topic 

Given the Open World Assumption – Anyone can say Anything about Any topic – this can be a tricky value to establish in many instances. However, there are some numeric values that do stay stable for long enough for, at least, upper and lower limits to be articulated. For example, the number of people on each team at the start of a league football match will be n=11 (owl:cardinality 11). The number of people in the squad from which the team is picked will be >11 (owl:minCardinality 12).

"Cardinality refers to the number of distinct values a property has".

n=11

There is also, naturally, owl:maxCardinaity

Using owl:oneOf closes a set, but, given the Open World assumption, it should only be applied judiciously, "in situations in which the definition of a class is not likely to change – or at least not change very often".

For an example the authors take us back to the planets in the solar system:

ss:SolarPlant ref:type owl:Class
 owl:oneOf (ss:Mercury ss:Venus ss: Earth ss:Mars
                     ss:Jupiter ss:Saturn ss:Uranus ss:Neptune) .

"When combined with owl:someValuesFrom… [this] … provides a generalization of owl:hasValue. Whereas owl:hasValue specifies a single value that a property can take, owl:someValuesFrom combined with owl:oneOf specifies a distinct set of values that a property can take."

This enables an inference to be drawn that tells us that "some  triple from a small set holds, but we don't know which one". Owl:oneOf, is also commonly used with owl:AllDifferent to specify that the members of a set are, as one might expect, all different from each other. This is essential, because we can't assume that things in the same set aren't called by different names.

Can't get no satisfaction

The remainder of the chapter (Yep. It was another long one this week.) is devoted to contradictions, unsatisfiable classes, inferring class relationships and reasoning with individuals and with classes.

• Contradictions exist when data modeling produces results that are "logically inconsistent": when a model reflects something impossible in the real world. Because "a model is a description of the world" it "can be mistaken". 
• An unsatisfiable class is one with no members.
• Inferring class relationships involves the application of OWL's set language and other restrictions to make inferences about classes.
• Reasoning with individuals and classes. Where reasoning with individuals "draws specific conclusions about individuals in a data stream", class reasoning "determines how data are related in general". The combination of the two, in the authors' words means "we have a powerful system that smoothly integrates general reasoning with specific data transformations".

Next time "Ontologies on the Web–putting it all together". That'll be in a fortnight. Not sure, as yet, what's coming next week…

*In other words, ex:AnimateThings may not be owl:complementOf  ex:InanimateThings. There might be a third class, say, ex:SchrodingersThings…

Semantic Web for the Working Ontologist: chapter 1

Ok - here goes.

Chapter 1: What is the Semantic Web?

I now understand the difference between

* URLs (Universal Resource Locators), the "addresses" that enable search engines to locate and show individual web pages
and
* URIs (Universal Resource Identifiers), that allow search engines to find and link individual items of information within different web pages.

I also know that the "data model" used in the drive towards international consistency in the way that individual pieces of information are described is called the Resource Description Framework abbreviated to RDF. And that an "ontology" is simply the attempt to classify information in a document (or elsewhere) in a way that fits a particular, agreed standard.

I had, of course, heard all those terms before. What I didn't understand was why the standards exist, what they enable to happen, and critically, the assumptions that underpin them…

• the AAA slogan: Anyone can say Anything about Any topic, which means that we can't assume that
• two entities with different names are different things
• two entities with the same name are the same thing
• different people will agree that the same thing should be classified in the same way
• the Open World Assumption: there is always more that can be said - which means that we "may draw no conclusions that rely on assuming that the information available at any one point is all the information available." (p10)

A key quote for me from this chapter is "The Semantic Web is… about coping in a world where not everyone will agree, and achieving some degree of interoperability nevertheless." (p9)

Love this acceptance of messiness and the idea of such a huge classificatory project that acknowledges the eternal impossibility of getting everything right, but is still going for it, anyway…

Would be grateful if people could let me know if I've misunderstood anything…