Semantic Web for the Working Ontologist: Chapter 16

In this, the last chapter of Semantic Web for the Working Ontologist, the authors riff briefly on the history and context of data modeling for the web: how the processes and practices build on the "heritage of of knowledge modeling languages", but do so in an environment that "is so revolutionary that it is often compared in cultural significance to the invention of the printing press".

"The Semantic Web is the application of advanced technologies that have been used in the context of artificial intelligence, expert systems and business rules execution in the context of a World Wide Web of information. The Semantic Web… isn't on the web; it is the Web"

Where it's different from anything that precedes it is the way it brings "information from many sources … to one's fingertips". But then a library does that. Or, arguably, an encyclopaedia. What really differentiates the Web is that it brings the information a) sorted and b) on demand.

The reason that OWL seems – and is – pretty "primitive" compared "to the knowledge representation systems that were developed in the context of expert systems" is not entirely because it's at a much earlier stage of development, but because of what people want from the web: "typically people don't want machines to behave like experts, they want to have access to information so they can exhibit expert performance at just the right time." Hmmm… True for search engines: don't know about you, but I definitely want a satnav, for instance, to behave like an expert…

Where the Semantic Web goes "one step further" than the Web, is that while the "Web is effective at bringing any single resource" to our attention, "if the information the user needs is not represented in a single place, the job of integration rests with the user." However, the Semantic Web "uses expert system technology to gather information so an individual can have integrated access to the web of information." The Semantic Web, in other words, makes the connections for the user. Unlike a satnav app, it doesn't tell the user what to do with them.

So, the fact that OWL is comparatively primitive "is appropriate for a Web language", because "a primitive knowledge modeling language can yield impressive results when it uses information sources from around the world." Its power is in how it accesses and assimilates the huge amounts of content available across the web – and in how it enables newly available content to be added to the mix as and when it's added to the Web. Data models "on the Semantic Web play the role of the intermediaries that describe the relationships among information from various sources". And the web ontology language tools covered in this book "provide the framework for the pieces an engineer can use to build a model with dynamic behaviour … and … provide mechanisms for specifying how information flows through the model" and how different bits of information relate to each other.

Or as one, much more technically adept friend put it: it's conceptually difficult because you're modeling information about information. And that, in itself, is tough to get your head round.

So what have I learned from this book?

It's difficult to say at this stage, because, aside from using it for the design of my new MOO Cards…

This makes more sense when you know the job title on the reverse is "Person"

 … I've yet to put anything I've read into practice.

However:

1. over the next few weeks, I'm going to try and model the relationships between as many as possible of the people who appear in the zoeography
2. there's a helpful "Frequently asked questions" section at the end of the book that directs readers to specific pages with instructions on specific issues

I'll report back later. Not sure exactly when: next week I'm planning to write about Blast Theory's Karen. And after that, I'm hoping to have more progress to report on the technical and design development of the zoeography.

In the meantime, if you've been reading this – thank you very much for doing so.
If this is your first visit, my journey through Semantic Web for the Working Ontologist started here.

Semantic Web for the Working Ontologist: Chapter 15

This week: "Expert modeling in OWL". In this – the penultimate chapter – Allemang and Hendler give provide a brief outline of four subsets of OWL 2, each of which is tailored to particular modeling requirements. They also describe, tantalisingly, how the OWL 2 standard "is rich in modeling constructs that go beyond the scope of this book".

OWL 2 is backward compatible with 1, which means that all the modeling techniques taught in this book remain valid, and that the additional constructs are additions to/refinements of, rather than replacements for OWL 1 constructs and practices.

Each of the four OWL 2 subsets uses the "same set of modeling constructs": ie: the same properties and classes, the same syntax. They differ in that each is tailored to serve a different purpose

OWL 2DL – D is for decidability
For projects where decidability is key. A system "is decidable if there exists an effective method such that for every formula in the system the method is capable of deciding whether the formula is valid (is a theorem) in the system or not." In other words, it's designed for applications where precise and discrete definitions of things/entities are crucial.

OWL DL is designed to enable modelers to create algorithms that can "determine which classes [in a given model] are equivalent to other classes, which classes are subclasses of other classes, and which individuals of are members of which classes."
OWL 2 EL – E is for executable
For projects that are mostly about federating data from a variety of sources in order to provide an "integrated picture of some sort of domain". In this type of modeling – used, for instance, by search engines that need to provide good rather than perfect answers (partly because they need to take into account the fact that humans ask good rather than perfect questions) – "the model describes how information can be transformed into a uniform structure".

So OWL 2 EL is designed to "improve computational complexity".

OWL 2 QL – Q is for Query
This subset of OWL 2 is designed for working with/leveraging relational databases, that require "fast responses to queries" applied to huge, specified data sets.

"Queries against an OWL 2 QL ontology and corresponding data can be rewritten faithfully into SQL".

OWL 2 RL – R is for Rules
This subset of OWL 2 is restricted to enable compatibility with rules-based processing. This is particularly useful for multipart  properties – where properties relate to each other in ways other than the hierarchichal. For instance, the concept of "aunt". I can only be an aunt if I am the sister of someone who is a parent. "Aunt" is thus a multipart property because it is made up of more than one property: parent and sister in that – diasy-chained – order.


Interestingly, multipart predicates were left out of OWL 1 "because they were thought to cause undecidability". But more recent work has demonstrated that "under certain conditions" this need not be the case.

From multipart predicates (which the authors illustrate with an example model of "'A child should have the same species as its parent"')

":Elsie :hasParent :Lulu
:Lulu :hasSpecies :Cow"

So "we can infer that

 :Elsie :hasSpecies :Cow"

Elsie and Lulu. Or two other cows.

 Incidentally, the authors also briefly discuss metamodeling ("using a model to describe another model), recommending the use of the Class-Individual Mirror pattern for this.

Next week - um, not sure yet. Might write about anxiety, connectedness and correspondence. Or something else. May be suffering from undecidability…

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 13

After all last week's, er, 'excitement', it's back to my attempt to grasp the theory of data modelling, RDF and its various iterations, OWL and associated concepts.

First off, I need to say there's something in chapter 13 – title: Ontologies on the Web—putting it all together – that I really don't get, and that's the use, in the section on Dimension checking in QUDT (the acronym for a specific ontology: Quantities, Units, Dimensions, Types) of vectors as a way of representing signatures for compound quantities.

When I say I don't get it – I understand the principle, that "QUDT defines eight basic quantities", including "length, time and mass", and that the process of dimensional analysis requires that units used to measure compound quantities require a signature showing how the … Oh…

Hang on … what I was going to say here was that I didn't understand how the vectors providing the signature for how these compound quantities are comprised from the eight basic quantities/units are calculated. Why, say, if "we write our vectors in the order [length, mass, time] then the vector for velocity is [1, 0, -1]", even though the authors explain how "the magnitude of the vector in that component begin the exponent of the the base quantity in the formula for the compound quantity".

I'd read that page at least four times before giving up. But it's just this second clicked. The vector for velocity is [1, 0, -1] because velocity = length/time. The zero's there because mass isn't a factor. Duh. Remarkably, I did pass maths A level. But only just, and with a lot of tutoring. And it was a loooooong time ago now…

Chapter 13 introduces and outlines the uses of three online ontologies: QUDT, Good Relations and ChEBI – Chemical Entities of Biological Use – which "is published as part of the Open Biological and Biomedical Ontologies Foundry (OBO)".

Developed by NASA, "the goals of QUDT are to provide

1. A standardized consistent vocabulary, focused on terminology used in science and engineering.
2. A set of consistent coded identifiers, for human and machine use.
   1. nd machines, avoiding problems with uncertainty and misinterpretation.
3. A collection of foundational vocabularies that can serve a variety of applications.
4. A framework designed for extensibility and evolution, but model-based (instead of just a typical dictionary) and governed."

Outside of engineering, it's widely used for online currency conversion.

The Good Relations ontology is used for commerce. It provides search engines with rich information about products and services, enabling them to assess the relevance of the the product or service to the "location, time, identity, profile, and preferences of the person behind the query" (from GoodRelations).The authors provide an example of how it can be used by a nail bar that also offers massages, both to publicise its services and to enable browsers to work out which service, provided by comparable beauty salons, offers the best value massage per minute.

And CheBI is

"a freely available dictionary of molecular entities focused on ‘small’ chemical compounds. The term ‘molecular entity’ refers to any constitutionally or isotopically distinct atom, molecule, ion, ion pair, radical, radical ion, complex, conformer, etc., identifiable as a separately distinguishable entity. The molecular entities in question are either products of nature or synthetic products used to intervene in the processes of living organisms." (from the ChEBI website)

Incidentally the ChEBI website features an "Entity of the Month". At the time of writing it's butyl anthranilate, a naturally occurring substance that scientists are currently testing as a safe insect repellent to protect fruit – and, potentially, people – from being eaten/bitten by flying insects…

ChEBI's Entity of the Month for July 2015. And some blueberries.

The authors also introduce the term owl:imports which allows one ontology to refer explicitly to another, and enables inferences to be drawn from the imported ontology within the ontology into which it has been imported.

That's it for this week. And, just so you know, there are three, short chapters to go…

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 11

Because I've enjoyed leaving everyone on tenterhooks after the cliffhanger at the end of chapter 10, and to prolong the joy, from now on, I'm going to alternate blogging a chapter of this book every fortnight, with musing on other subjects*

Anyway, this week's chapter covers basic OWL, and focuses on the use of owl:Restriction, which the authors tell us – almost breathless with excitement – "opens up whole new vistas in modeling capabilities".

In OWL, a Restriction is a special type of class: one that's defined "by describing the individuals it contains… in terms of existing properties and classes".

The chapter focuses on three kinds of restrictions:
owl:allValuesFrom – all values from a set of properties must apply
owl:someValuesFrom – one or more values from a set of properties apply
owl:hasValue – refers to a particular value for a property.

There's a difference between the first two of these which is subtle and not immediately obvious. someValuesFrom "is defined as a restriction class such that there is at least one member of a class with a particular property". That means that "there must be such a member". allValuesFrom, however, "means 'if there are any members, then they all must have this property", which doesn't "imply that there are any members". This will, apparently, be important later in the book (there are, gentle reader, still 5 chapters to go). Oh, and these three restrictions are often shortened to the keywords all, some, and value, using the Manchester Syntax (developed at the University of Manchester).

Because it's so useful and frequently-used, owl:hasValue – the type of restriction that "effectively turns specific instance descriptions into class descriptions"  – is "identified in the OWL standard in its own right". It is viewed "as a design pattern" and given a name: the Class-Individual Mirror pattern. It is used to describe "the relationship of an individual to a set—this is the set of all things that relate to this individual in a certain way."

Having demonstrated the application of restrictions in the design of a questionnaire, the authors go on to explore ways of ensuring steak isn't classified as a vegetarian food, and preventing a steak-eater from being described as a vegetarian, and, then, to explore 'relationship transfer'. Relationship transfer happens when "Everything related to A by property p should also be related to B but by property q".

not suitable for vegetarians

So, for instance, everyone who has bought an NUS Extra Card† will also be a student affiliated to an educational institution (or a work-based apprentice - but let's not split hairs here). Or, as in the authors' examples "'Everyone who plays for the All Star team is governed by the league's contract' and "Every work in the Collected Works of Shakespeare was written by Shakespeare'".

Finally, they describe the difference between rdfs:subClassOf and owl:equivalentClass. The former is "a simple IF/THEN relation", the latter "an IF and only IF relation". In other words, it is two IF/THEN relations: "one going each way".

And, in their summary, Dean Allemang and Jim Hendler explain the importance of restrictions. Essentially, "they can be used to model complex relationships between properties, classes, and individuals". This means that "interactions of multiple specifications can be understood and even processed automatically." And, while our brains are busy working out the possibilities that opens up, I'll finish by saying that next week I'll be blogging/thinking more about reader journeys.

I also won't make the mistake I made this week of blogging on 2 computers and accidentally overwriting the finished version by saving an earlier draft and having to rewrite. Grrrrr.

* oh, all right, it's mostly because I'm very busy at the moment, and this allows me to blog about some of the stuff I'm doing

† and if you're eligible and haven't, it's well worth it

Semantic Web for the Working Ontologist: chapter 10

I'm absurdly busy at the moment, and was therefore rather relieved that this week's chapter "SKOS—managing vocabularies with RDFS-Plus" only ran to 12 pages.

SKOS – its focus – stands for Simple Knowledge Organization System. It is

"an area of work developing specifications and standards to support the use of knowledge organization systems (KOS) such as thesauri, classification schemes, subject heading lists and taxonomies within the framework of the Semantic Web" (see http://www.w3.org/2004/02/skos/)

The authors guide us through "an example of using SKOS" - AGROVOC: the thesaurus developed by the United Nations Food and Agriculture Organization "for organizing documents about agriculture". Naturally, this needs to be multilingual, with no one language taking precedence over any other, so individual resources are identified by numbers, with a variety of labels, including a language tag (optional in Turtle strings, and drawn from XML).

Labels in SKOS are more sophisticated than in RDFS."It defines three different types of label: preferred; alternative and hidden. Each is an rdfs:subPropertyOf rdfs:label, "which provides a human readable version of the name of each resource".


For instance…

agrovoc_7030 rdfs:label "Sheep"@en
agrovoc_7030 rdfs:label "Ovin"@fr

we are all agrovoc_7030. Also NAL:38846

 

The "semantic relations" SKOS defines correspond to what the authors describe as "familiar terms" derived from thesaurus standards. These include skos:broader, skos:narrower and skos:related. skos:broader and skos:narrower are closely related – but not identical – to rdfs:superClassOf and subClassOf.

One of the best things about SKOS is the way it allows different vocabularies to be linked: including the many controlled vocabularies and thesauri that were developed before computers existed. Because it is RDF-based, every term has a URI. "This makes it possible to make statements about how a term in one vocabulary relates to a term in another", and SKOS provides skos:exactMatch, skos:narrowMatch, skos:broadMatch and skos:closeMatch, so that different people can make individual judgements about the nature of the relationships between different entities: Anyone can say Anything about Any topic.

A major facet of SKOS is its inclusion of "the notion of Concept Scheme", which Allemang and Hendler define as

"a largely informal collection of concepts, corresponding roughly to a particular thesaurus or knowledge organization system."

So, for instance where different thesauri have different identifiers for sheep like SKOS, and the US National Agricultural Library (NAL), where a sheep is NAL:38846, we can specify which thesaurus each belongs to using skos:inScheme followed by the URI for the scheme. The significance of this is that the "explicit statement of a concept scheme makes this relationship explicit and queryable with SPARQL".

Also useful in SKOS is the idea of a Top Concept. Whilst it's always possible to identify the property at the top of a property tree with a SPARQL query, it's "convenient to indicate it". There's a handy graph illustrating AGROVOC's Top Concepts on its FAQ page.

Finally, the authors explore why it is that SKOS has become so popular. They identify four major factors:

1. simplicity
2. "the ease with which a vocabulary can be transformed from other systems into SKOS"
3. the fact that, before SKOS there wasn't a standard way to represent a vocabulary in digital form
4. "translation into SKOS turns … locally unique identifiers into globally unique identifiers", making it much easier to relate disparate vocabularies to each other.

Next week - Basic Owl

Semantic Web for the Working Ontologist: chapter 9

This week we're on to "Using RDF-Plus in the wild", where the authors introduce us to two real-world applications of the principles and practices explained in chapters 1-8.

Both "are about setting up an infrastructure for a particular web community". Data,gov, the US government project to put public information online in machine-readable form and FOAF – the acronym for Friend of a Friend, which is "a machine-readable ontology describing persons, their activities and their relations to other people and objects." (quote from Wikipedia).

 The subset of US government data the authors focus in on is the list of cases "about alleged violations of Title VIII of the Fair Housing Act" filed with the Office of Fair Housing/Equal Opportunity (FHEO). The original data gives a case number, and a list of possible reasons for the complaint – each of which is marked with either a 0 or a 1, to indicate whether or not it is the basis of the complaint –  as well as the county that the omplaint is filed in/relates to. The authors take us through ways of using RDFS and SPARQL to organise and process this data to make it more meaningful and useful, enabling human beings to work out where, for instance, alleged violations of Title VIII of the Fair Housing Act cluster, and which reasons form the basis of the most cases.

FOAF – started in 2000 – "began with a simple observation"

If we are to support social networks on the Web, individuals must be able to take control of their own data, host it as they please, manage it using whatever tools they please, but still interact with other users, regardless of the choices these other users make. (p196)

This, more than Data.gov, demonstrates the adaptability of RDF, SPARQL and their associated languages, standards, frameworks, technologies – or however they should be described.

What's key is that "because Anyone can say Anything about Any topic, FOAF allows anyone to make novel statements about people, projects, and so on and to relate these statements to other statements already made."

Everything, in other words, can be connected to everything else, but by machines, and in ways that, ultimately, make sense to humans.

I think my inner hippie is showing…

My inner hippie. Yup. That's what I'm like on the inside.

Semantic Web for the Working Ontologist: chapter 8

Chapter 8 is titled RDFS-Plus. It introduces a selection of OWL – Web Ontology Language – keywords and demonstrates their use.

Clearly, OWL's originators aren't Winnie the Pooh fans, else they'd have stuck with the acronym WOL. Unless they were avoiding confusion with "Wake-on-LANan Ethernet standard that allows computers to be turned on by a network message" and a bunch of other stuff (see Wikipedia).

It felt much easier to understand most of this than I expected - but I suspect that was partly down to the assistance I had this week from Paul Rissen, Data Architect for BBC News, Paul kindly gave up a lunchtime to explain stuff to me, show me how and where the BBC are using linked data, and how he taught himself to develop ontologies. He also introduced me to two useful resources – BBC Ontologies and BBC Things which are hugely helpful for putting all this into context.

Anyway, the new functions covered in chapter 8 are…


equivalentClass
It's not unusual when federating data from different sources, to discover different URIs referring to the same thing, or class of things. Specifying that two classes are equivalent indicates that they will always have the same members. One important point the authors make here is that "when two classes are equivalent, it only means the two classes have the same members. Other properties of the classes are not shared".

equivalentProperty
This, unsurprisingly functions similarly to equivalentClass, but for properties of things, rather than classes of things. So, for example, in the authors example of library books, "borrows" is an owl:equivalentProperty of "checkedOut".

sameAs
Where equivalentClass and equivalentProperty are the ways of expressing and defining identity relationships between classes and properties of things, sameAs is for individuals. The examples given here include Shakespeare: the Shakespeare that Anne Hathaway married and who had three children is the sameAs the Shakespeare who wrote plays and sonnets. I

inverseOf
Used where one property is the inverse of another: the examples given include hasParent and hasChild and, for checking out of library books, :signedTo owl:inverseOf :signedOut. So, it specifies a mutual relationship between two properties.

TransitiveProperty
In OWL, a transitive property is one that applies throughout a chain of relationships. So, as in the instance given here, ancestors are transitive, parents are not (although parents are a subset of ancestors). "owl:TransitiveProperty is a class of properties, so a model can assert that a property is a member of the class

:P rdf:type owl:TransitiveProperty."

SymmetricProperty
"is an aspect of a single property… expressed in OWL as a Class." It applies in situations where, for instance, you need to specify that two people are married to each other, or are siblings. It applies in any case where a :isWhateverOf b, means that b :isWhateverOf a.

FunctionalProperty
"RDFS-Plus borrows the name functional to describe a property that, like a mathematical function, can only take one value for any particular individual."So, for an individual, age and National Insurance Number could each be a FunctionalProperty.

InverseFunctionalProperty
But FunctionalProperty isn't as useful as InverseFunctionalProperty, which is considered by some pwople "the most important modeling construct in RDFS-Plus, especially in situations in which a model is being used to manage data from multiple sources." It applies in a situation where "a single value of the property cannot be shared by two entities". National Insurance Number can be an InverseFunctionalProperty, but age can't. In RDFS-Plus, where two entities share the same InverseFunctionalProperty, the inference will be made not that there has been an error, but that the two entities are, in fact, the same.

Some properties – like National Insurance Number – can be both functional and inverse functional properties.

ObjectProperty and DatatypeProperty 
I struggled to understand the distinction between these two from the details provided in the book, so resorted to Googling, which led me to a forum – http://stackoverflow.com – where someone asked the
difference between the two, and the answer was "Datatype properties relate individuals to literal data (e.g., strings, numbers, datetypes, etc.) whereas object properties relate individuals to other individuals".  Which makes a lot of sense!


Next week's chapter – "Using RDFS-Plus in the wild" – looks at real world applications. So, I'm hoping that should be comprehensible!

Until then…

Semantic Web for the Working Ontologist: chapter 7

I am now much, much further into a technical book than I've ever been before in my life. That feels like an achievement: even if I don't come away from this with any more than a fragmentary grasp of all things RDF and beyond…

So – this week's chapter is concerned with RDF Schema. It is all about sets which, somehow, feels more comfortable and intuitive than all the RDF graphs, even though I've forgotten all the mathematical set-related signs (a very long time ago I did a pure maths with stats A level very badly). It explores the following questions. "Which individuals are related to one another and how? How are the properties we use to define our individuals related to other sets of individuals and, indeed to one another?"And it answers the question of how to express those relationships in a way that allows inferred triples to be constructed from asserted triples.

And "schema"? The term schema was, according to Oxford Dictionaries, coined in the 18th century. It's derived from the Greek "skhēma … [meaning] …'form, figure'", and the definitions the dictionary provides are

1. technical A representation of a plan or theory in the form of an outline or model:
2. Logic A syllogistic figure.
3. (In Kantian philosophy) a conception of what is common to all members of a class; a general or essential type or form. 

Or, in RDFS, according to Allemang and Hendler,  "The schema is information about the data." It is information about information. "The key idea of the schema in RDF", they continue, "is that it should help provide some sense of meaning to the data."

It does this "by specifying semantics using inference patterns". Which means that it expresses relationships in triples, using defined terms. So "the basic construct for specifying a set in RDFS is called an rdfs:Class. So for a subject say :FloweringPlant you'd have the predicate rdf:type and the object rdfs:Class. There's also rdfs:subClassOf, and, importantly – because it can include verbs as well as nouns – rdfs:subPropertyOf.

"In general, rdfs:subPropertyOf allows a modeler to describe a hierarchy of related properties". The more specific a property, the lower down the hierarchy it sits; the more general, the higher up. So, "whenever any property in the tree holds between two entities, so does every property above it". In other words, if entity 1 is the subproperty of entity 2 above it, it must also be a subproperty of entities 3 - n above entity 2. And we only need to assert the first relationship in a triple for the rest to be inferred.

"RDFS," say the authors, "'extends' RDF by introducing a set of distinguished resources into the language." I'm assuming that they're using "distinguished" to mean "distinct", rather than either "Very successful, authoritative, and commanding great respect" or "Dignified and noble in appearance or manner" (Oxford Dictionaries again). But what do I know?

Apparently this is an image of "Distinguished Gentleman's Ride London". Glossing over any issues with the word "gentleman" for the purposes of this caption, it's possible there may be something I don't understand about the word "distinguished".

Meanwhile, back in the book I'm supposed to be getting my head round, the authors are introducing the other key concepts for this chapter: rdfs:domain and rdfs:range. These describe a property "that determines class membership of individuals related by that property".

In the margin of p130 (for this, dear reader, is how far we have come), I've scrawled in big pencilled caps REREAD THIS, as I evidently failed to understand it first time round. This time it seems fairly clear. Essentially the use of the terms "domain" and "range" is inspired by their use in maths, where "the domain of a function is the set of values for which it is defined, and the range is the set of values it can take." In RDFS, "A property P can have an rdfs:domain and/or an rdfs:range." And the two terms provide information on how a "P"is to be used: "domain refers to the subject of any triple that uses P as its predicate, and range refers to the object of any such triple".

EDIT 28/05/2015. After reading this blog, Paul Rissen provided the following, much improved explanation for domain and range

It's also significant that there's no way in RDF to say that something isn't a member of a particular class: this means that "there is no notion of an incorrect or inconsistent inference". So modelers have to be careful in defining set relationships.

Most of the rest of this chapter is concerned with application of these concepts/terminologies, to show, for instance, how you can relate entities by using triples to define them as subsets of one another: doing this both ways ensures that an item defined as a subset of one will automatically be considered a subset of the other, or if they're related, but not hierarchically to each other, by creating another entity (or set) that sits higher up the hierarchy and that they original two entities are subsets of.

Conceptually it's comparatively easy – applied IRL situations, I imagine, requires a lot of careful thought.

Next week… RDFS-Plus. So I guess that'll be like this week, only more so…

Semantic Web for the Working Ontologist: chapter 6

This week's chapter – it's nice and short: or, at least, short) is called "RDF and inferencing".

It covers the way that data modelers can ensure that, when someone searches the web overall – or a specific site – the results include the relevant examples of the thing(s) they're searching for, even when these haven't been mentioned, by name, in the search. The example the authors use here is a search for "shirts" that should return results including "Henleys" (which, apparently, are a type of shirt. Who knew?).

What's particularly significant about the Semantic Web approach, is that it enables a data modeler to create/define data so that "the data can describe something about the way they should be used". But, more than that, "given some stated information, we can determine other, related information that we can also  consider as if it had been stated".

This is inference: the ability to model data in such ways that we are "able to add relationships into the data that constrain how the data is used".

So,

IF
?Thing1 rdfs:subClassOf ?Thing2 .
AND
?x rdf:type ?Thing1 .
THEN
?x rdf:type ?Thing2 .

In other words (or to be more accurate, in words), if Thing1 is a subset of Thing2, and x is an example of Thing1, then x must also be an example of Thing2.

We won't need to specify anywhere that that x is an example of Thing2. The query engine will infer that itself.

This is not a remotely helpful illustration, as Thing 1 is clearly not a subclass (or subset) of Thing 2, but it is what the inference quoted about made me think of…

Anyway, this is one of the uses of CONSTRUCT (see last week's blog) in SPARQL, which "provides a precise and compact way to express inference rules". All of this means that SPARQL can form "the basis for an inference language", such as SPIN – SPARQL Inferencing Notation which – according to its web page – "has become the de-facto industry standard to represent SPARQL rules and constraints on Semantic Web models.

Overall, "the strategy of basing the meaning of our terms on inferencing, provides a robust solution to understanding the meaning of novel combinations of terms". Overall, it means that any "deployment architecture" will require not merely the functionality of a Query Engine, but of something that functions as an Inference and Query Engine. Which, in other words, will work both with "triples that have been asserted" - ie those specified within any query, but also triples that are inferred from those that have been asserted (see above). Incidentally, when these relationships are represented graphically, the convention is to print asserted triples with unbroken lines, and inferred triples with broken ones.

In some instances, the querying and inferencing are done by the query engine. In other formulations, "the data are preprocessed by an inferencing engine and then queried directly" - as sometimes it's "convenient to think about inferencing and queries as separate processes". This means that inferencing can happen at different points in the storing and querying process, depending on the implementation. The decisions around this have implications: when the inferring is done early in the storing and querying processes for storage and choices of which inferred triples to retain and which to discard to keep when data sources change at. And just in time inferencing" approach – where all inferencing happens only in response to queries, "risks duplicating inference work.

And that is about that for this week. Next week we're moving on to RDF Schema. Which is obviously going to be a challenge, as I'm not sure I even understand the chapter title. Still, I've already made it to page 125, which makes this the longest relationship I've ever sustained with a technical manual…

Semantic Web for the Working Ontologist: chapter 5

Remarkably, I have managed to read my way through all 51 (okay 50-and-a-half) pages of chapter 5. I had to do it in very short bursts, as my ability to retain – or make sense of – even fairly straightforward information of this particular kind is extremely limited. I have no idea whether this is down to lack of experience and/or focused application, or something to do with the way my brain is made and functions.

Anyone care to enlighten me?

Chapter 5 is all about SPARQL, an acronym for SPARQL Protocol And RDF Query Language. Someone, somewhere made the brain-knotting decision to make the first letter of the acronym the first letter of the acronym for reasons that can only be to make it a homophone of sparkle. Because otherwise it would be called PARQL. Or xPARQL, WHERE x= the first letter of something that sounds less Escheric than SPARQL but makes more sense.

There follows 50 pages of basic SPARQL explanation and instruction, setting the scene with descriptions and illustrations of increasingly sophisticated and flexible tell-and-ask systems: from spreadsheets, via relational databases and into RDF and SPARQL, starting from the simple statement that "the basic idea behind SPARQL [is] that you can write a question that looks a lot like the data,with a question word standing in for the thing you want to know."

Most of the chapter is taken up with introducing the basic vocabulary and syntax of writing queries in SPARQL. So, readers gain an understanding of

• SELECT queries: these have 2 parts "a set of question words, and a question pattern." IN SPARQL, any word can be a question word, as long as it has a ? directly before it. This means that, in order for the question word to do its job, it needs to be defined with a triple. Essentially, "question words' = variables
• WHERE "indicates the selection pattern" and is written in what the authors call braces and I call curly brackets, because in my brain braces are what my daughter has on her teeth (I am, by-the-by, hugely impressed by the dexterity of orthodontists).
• DISTINCT filters out duplicate results, and appears after SELECT.
• FILTER which is used to define which query results will be retained, and which rejected "is a Boolean test, not a graph pattern". So, its operation is written in parentheses, rather than curly brackets. Also "you cannot reference a variable in a FILTER that hasn't already been referenced in the graph pattern" – ie the SELECT/WHERE part of the query.
• OPTIONAL according to the W3C "tries to match a graph pattern, but doesn't fail the whole query if the optional match fails" (http://www.w3.org/2009/Talks/0615-qbe/). So, as in the example Allemang and Hendler give, if you want to find out the names of actors in a film, and when they died, the query won't exclude anyone who's still alive.
• UNSAID enables you to exclude some data from the results: so, for example, if you wanted details of only the actors who were in a film and are still alive
• ASK appears at the beginning of a query, instead of SELECT and is used in instances where a yes/no answer is required.
• CONSTRUCT – which also appears instead of SELECT –  "introduces a graph pattern to be used as a template in constructing a new graph". In other words, it creates relationships between data items that might not have been previously linked.
• ORDER BY comes at the end of the graph pattern and does what you'd expect: ie allows you to specify how you would like query results ordered.
• DESC if this appears after ORDER BY, it organises data in descending order (ascending is default)
• COUNT, MIN, MAX, AVG and SUM enable data to be aggregated. They appear in parentheses, follow SELECT and are followed by the word AS "followed by a new variable, which will be bound to the aggregated value."
• GROUP BY allows data to be grouped by a specified variable: this variable "must already have been bound in the graph pattern" - ie: must have been defined with a triple.
• HAVING allows you to isolate specific results from the overall query results.
• UNION "combines two graph patterns, resulting in the set union of all bindings made by each pattern".
• SERVICE "followed by a URL for the SPARQL endpoint before a graph pattern" specifies where the results of a query are to appear. 
• GRAPH does the same sort of thing in the same sort of way, but for named graphs.

Other important things

• The order in which triples appear in a SPARQL query has no impact on the results, but can impact on the speed the results can be delivered, as it will vary the amount of data that needs to be processed. So "order triples in a query so that the fewest number of new variables are introduced in each new triple".
• SPARQL was developed for publishing to the web. "A server for the SPARQL protocol is called a SPARQL Endpoint." This "accepts queries and returns results" and "is the most web-friendly way to provide access to RDF data". It is also "identified with a URL".
• "The namespace dc stands for 'Dublin Core' a metadata standard used by many libraries worldwide"
• SPARQL has less need for subqueries than most query languages, because graph patterns "can include arbitrary connections between variables and resource identifiers". But they can still sometimes come in handy.
•  Assignments – which are "expressed as part of the SELECT clause"and aren't supported under SPARQL 1.0, but apparently will be (or are) under 1.1 – enable a query to write "the value of a variable through some computation". In other words, it assigns "a value to that variable"
• Queries can be federated: ie, an individual query can query multiple data sources.

So, having read that, could I now write a query in SPARQL. Er, no. But I might, slowly, hesitantly, and with repeated references back to this book or to the W3C SPARQL standard, be just about able to read an easy one… Which is progress.

And here are pictures of James Dean and Elizabeth Taylor who star in this chapter. No, really.

Semantic Web for the Working Ontologist: chapter 4

And… chapter 4 is concerned with Semantic Web application architecture.

It describes the different components of Semantic Web applications, and their use: the eponymous Working Ontologist needs to understand how applications are structured in order to create useful, useable, models.

The components are
RDF Parsers and Serializers
Parsers translate text written in N-Triples, Turtle or RDF/XML into "triples in teh RDF data model".
Serializers do the reverse.

Incidentally, if you parse from a text file, and then reserialise (I have switched to using "s" instead of "z" here because I'm not quoting from the book and I'm English) you won't necessarily get an identical output file…

RDF Stores
Enhanced databases: as well as storing/sorting data, they also "merge information from multiple data sources".

RDF Query Engines
Enable the retrieval of information from an RDF store "according to structured queries".

For the uninitiated (ie: me), a query language is simply a programming language designed for retrieving information from databases. And, the RDF query language that W3C is standardising is called SPARQL. Which is the subject of chapter 5. But, tantalisingly, the authors reveal that it "includes a protocol for communicating queries and results so that a query engine can act as a web service". My guess is that means it enables human beings to read the results: hopefully when I read the next chapter I'll learn if my attempt to serialise that sentence was successful or not…

What it definitely means is that the results provide "another source of data for the semantic web."


Applications
"An application has some work that it performs with the data it processes … using some programming language that accesses the RDF store via queries (processed with the RDF query engine)."

I also perform some work with the data I process. That makes me almost, but not quite, an application.

Anyway, the authors list the following "typical RDF applications":

• calendar/map integration, enabling information from several different people's diaries/"points of interest gathered from different web sites" to be displayed in one place
• annotation, allowing a variety of users to tag information with keywords that have URIs
• content indexing of resources available in various places/stores

Converters
Most RDF systems also include a converter, which allows the system to access data – like spreadsheets, relational databases and HTML – that isn't stored in a serialised form, but is readily convertible into something that can be read by a parser.

Microformats & RDFa
Microformats are ways of tagging commonly used web-page items (eg: events, business cards), so that they can be used by RDF stores. The problem with them is that they need a controlled vocabulary and a dedicated parser.

RDFa is designed to get round that issue by using "the attribute tags in HTML to embed information that can be parsed into RDF. This is good because

1. it's easier to extract the RDF data from pages marked up for this purpose
2. it allows the content author "to express the intended meaning of a web pafe inside the web page itself. This ensures that the RDF data in the document matches the intended meaning of the document itself."

And… then it's nearly the end of the chapter. But first there's an important concept to understand. Happily – assuming I've got it right – this one is fairly intuitive. It's data federation. In other words, information from a range of different sources – "spreadsheets and XML, database tables and web pages" – is converted/parsed into triples and merged, so that "all queries and inferences" work on the merged data, rather than on the original sources.

Nice to end a chapter with the sense that I actually understand something… Even though we're not in Kansas any more…

And - urk! Just noticed that chapter 5 is almost as long as chapters 1-4 put together. I may bneed to b

How reading this book makes me feel.

Semantic Web for the Working Ontologist: chapter 3

Now I'm onto "RDF—The Basis of the Semantic Web"

It's when it starts getting down to this sort of nitty-gritty stuff and I have to internalise new meanings for familiar (or semi-familiar) words that I feel in need of intellectual flotation aids. But I'm gonna dive straight in and hope to avoid a belly flop and every other variety of lousy extended metaphor.

Chapter 3 starts with an explanation of what RDF – the Resource Description Framework – is for, which is "managing distributed data", so that anyone can be able not only "to make a statement about any entity", but also to "specify any property of an entity". An "entity" is known, in this context, as a resource.

RDF is designed to enable that to happen by setting rules for how the properties of an entity are defined/expressed. These are in three parts, called a "triple" and follow the form subject – predicate – object, where the predicate is the quality linking subject and object. This framework allows for numerous ways to describe a resource/entity.

But this practice is only effective if entities have an agreed Uniform Resource Identifier (URI): "(which specifies things like server name, protocol, port number, file name etc) to locate a file (or a location in a file) on the Web". This "provides a global identification for a resource that is common across the web".

Ok - think I'm still hanging on in here. URIs tend to be long, so conventions have evolved for abbreviating them in print. The one the authors are using is called qnames.

Qnames have two parts - a "namespace" and an "identifier", (written Namespace:Identifier).
The namespace signifies what type of thing the identifier is; the identifier specifies the entity's, well, identity. Each part of each triple has its own qname, so that the different properties of a resource can be combined in different ways. So, in the RDF table the authors provide titled "Geographical Information as Qnames", one row is

geo:Scotland     geo:PartOf   geo:UK

And, in the following table, titled "Triples Referring to URIs with a Variety of Namespaces", we find entries including

lit:Shakespeare          lit:wrote          lit:KingLear
bio:AnneHathaway   bio:married     lit:Shakespeare

and

lit:Shakespeare         bio:livedIn     geo:Stratford

For these to work, there need to be a range of standardised namespaces, so these have been specified by W3C. Incidentally, it's a complete coincidence that all these references to Shakespeare are appearing in a blog published on his birthday.

The authors discuss one – rdf:type – at some length. "rdf" indicates that "type" (which translates into human English as "is an instance of") is an identifier used in RDF (resource description framework), rather than in RDFS (the RDF Schema language) or OWL (the Web Ontology Language).

I managed to follow that. But now, we're on to "higher-order relationships", where, for instance, we want to say that someone says something about something. The example the authors give is "Wikipedia says Shakespeare wrote Hamlet".

While we can, as the authors show, express the statement "Shakespeare wrote Hamlet in 1601" in three triples:

"bio:n1       bio:author                  lit:Shakespeare .
 bio:n1        bio:title                      "Hamlet" .
 bio:n1        bio:publicationDate   1601" .

saying that Wikipedia says Shakespeare wrote Hamlet requires a whole other layer of information, rendered here as

"q:n1  rdf:subject  lit:Shakespeare ;
           rdf:predicate  lit:wrote ;
           rdf:object  lit:Hamlet .

web:Wikipedia m:says q:n1 ."

The authors suggest readers notice that the "reification triple" doesn't necessarily mean that Shakespeare did write Hamlet, just that Wikipedia says he did.

What I noticed is that I am being gently introduced to some coding conventions.Things like q:n1, that are dropped in without explanation. And the space before the ".". This is explained a page or so later, during the discussion of "alternatives for serialization", including N-Triples – which refer "to resources using their fully unabbreviated URIs", making them difficult to print on paper – and Turtle: the method used in the rest of the book.

Turtle uses qnames, so before using it to express triples, each (local) qname needs to be linked to its (global) URI, using the form

"#prefix rdf: http//www.w3.org/1999/02/22-rdf-syntax-ns#"

Although I'm slightly confused, as above that is an example from an earlier illustration in the book:

"#prefix mfg:
<http://www.WorkingOntologist.com/Examples/Chapter3/Manufacturing#> (the link doesn't work, btw).

So I'm not clear whether we need the < & > as in HTML coding, or not… Anyone care to enlighten me?

Nearly at the end of the chapter - just a few more things I need to remember before I attempt chapter 4: "Semantic Web application architecture" (urk!).

1. Turtle uses contractions/abbreviations so that
a. when several triples share both subject and predicate, they can be represented economically. For example

lit:Shakespeare b:hasChild b:Susanna .
lit:Shakespeare b:hasChild b:Judith .
lit:Shakespeare b:hasChild b:Hamnet .

can be boiled down to

 lit:Shakespeare b:hasChild b:Susanna, b:Judith, b:Hamnet .

Or, to represent an ordered list (birth order, in this case)

 lit:Shakespeare b:hasChild (b:Susanna b:Judith b:Hamnet) . 

b. rdf:type is usually abbreviated to "a", so

lit:Shakespeare a lit:Playwright

rather than

lit:Shakespeare  rdf:type  lit:Playwright .

 The authors then quickly refer to RDF/XML - a method of representing RDF serialisations for the web, and also to "blank nodes", which allow for the representation of resources with no Web identity. They give the example of Shakespeare's mistress, the inspiration for sonnet 78 (at which point I got distracted and went off to read about poetry, as that sonnet was inspired by a young man – most likely Henry Wriothesley or William Herbert – not a woman). I will probably regret that by half way through chapter 4, but heigh-ho.

Anyway, "if we don't want to have an identifier for the mistress … RDF allows for a "blank node" or bnode for short" which "is indicated by putting all the triples of which it is a subject between square brackets as in

[ rdf:type bio:Woman;
        bio:livedIn  geo:England ]

Or, as it should be

 [ rdf:type bio:Man;
        bio:livedIn  geo:England ]

 And that's it for chapter 3. If I hadn't made a commitment to blog my way through this book, I'd probably have given up already…

 

 That's me, that is.

Wish me luck for chapter 4…

Semantic Web for the Working Ontologist: chapter 2

Chapter 2 is titled "Semantic modelling".

It explains that models are intellectual tools designed to "help people understand their world by forming an abstract description that hides certain details while illuminating others." In other words, the key to an effective model is working out which details to illuminate and which to conceal.

Models help with communication, explanation and prediction. They also "mediate among multiple viewpoints", by making commonalities explicit and enabling discussion about differences.


There's then a discussion of community tagging as a method of document modelling, with the caveat that as more people provide content, popular tags "saturate with a wide variety of content, making them less and less useful" for people trying to identify something specific.

According to the authors (and this is a key point):

This sort of problem is inherent in information modeling systems; since there isn't an objective description of the meaning of a symbol outside the context of the provider and consumer of the symbol, the communication power of that symbol degrades as it is used in more and more contexts. (p16)

To extrapolate, this is why Semantic Web standards require "modeling formalisms": so that there's an "objective description of the meaning of a symbol" that can exist "outside the context of the provider and consumer of the symbol".

Semantic Web standards follow a similar idea of class hierarchies "for representing commonality and variability" to Object-Oriented Programming. "High-level classes represent commonality among a large variety of entities, whereas lower-level classes represent commonality among a small, specific set of things." Which, I guess, means that lower-level classes are subsets of higher-level classes.

But what we need to add to that is the idea that "any model can be built up from contributions from multiple sources". And these multiple sources may well use different symbols to signify the same thing – or the same symbol to signify different things.

At this stage in the Semantic Web's development, it's often not possible to make a decision about which symbol representing something should be chosen as the symbol (the authors use the example of Pluto's astronomical and astrological symbols). But it should be possible to agree that each entity should be represented by only one symbol. So, in this instance "a model can provide a framework for describing what sorts of things we can say about something".

The chapter concludes with a list of Semantic Web languages from least -> most expressive: with the caveat that more expressive models are not necessarily better than less expressive models. To illustrate this, they show 3 different ways of "expressing" a water molecule, from the formula H2O, through H–––––O–––––H (showing how the components are joined) to a drawing that shows the relative sizes of the components and how they are positioned in relation to each other. Each is useful in a different situation.

The three Semantic Web modeling languages are:
RDF – the Resource Descripton Framework
RDFS – The RDF Schema Language
and
OWL

The next few chapters introduce these languages. And this, I suspect, is where I'll start to become unstuck. Usually, with technical books, I'm fine with the concepts. But when I start having to actually get to grips with the nuts & bolts of languages I turn into the dog in that Far Side cartoon:

 

Still, at least I'm not quite the cat… At least I hope I'm not… Will let you know in next week's installment…

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…