Defining Address Book Classes Using OWL Syntax

Before making a unified query across two address books, a user must first define a class named “Contact” for sharing common attributes. From a semantics perspective, this class is inherited to GContact (Gmail Contact) and TContact (ThunderBird Contact).

class Contact(Model):

partOfName='' partOfAddress=''

#owl:InverseFunctionalProperty Contact_email email=''

phoneNumber=''

#Contact_officePhoneNumber rdfs:subClassOf Contact_phoneNumber officePhoneNumber=''

#Contact_homePhoneNumber rdfs:subClassOf Contact_phoneNumber homePhoneNumber=''

#Contact_mobilePhoneNumber rdfs:subClassOf Contact_phoneNumber mobilePhoneNumber=''

#Contact_faxPhoneNumber rdfs:subClassOf Contact_phoneNumber faxPhoneNumber=''

According to the MVC design model, Contact class belongs to the Model data class, therefore class Contact(Model) is declared as representing a Contact inherited to the Model class.

The presentation meaning of the “partOfName” attribute is a contact person's name, which contains a surname/middle name/full name/nickname, etc. Here we allow partOfName to represent a full name or any name segment. If the semantics of any other attribute are inherited to partOfName, the attribute is used to identify one contact person’s name string.

In Python, the pound sign (#) designates a comment. Since SOF syntax is embedded in comments, any instance of ‘owl:’ or ‘rdfs:’ included in a comment means the statement is SOF-specific. For example,

‘#owl:InverseFunctionalProperty Contact_email’ utilizes OWL syntax to modify its semantics, meaning that

Contact_email string values must be unique. This should not occur in cases where two different Contact objects have the same email attribute value. In situations where they have the same email string, the proposed SOF system identifies conflicting Contact objects and notifies programmers, who can apply various strategies to resolve the illegal semantics. OWL statements are helpful for programmers in terms of applying rich syntaxes to limit relationships between model objects.

E-mail attribute names differ across various applications. Examples in address book software programs include Email, email, mail, Mail, emailAddress, and EmailAddress—all with identical semantics. In order to display all attribute values for all emails across heterogeneous address books, all E-mail-related attributes must be inherited to Contact_email.

The next topic is the process through which GContact is inherited to well-defined Contact attributes.

#GContact rdfs:subClassOf Contact class GContact(Model):

#GContact_name rdfs:subClassOf Contact_partOfName name=''

#GContact_email rdfs:subClassOf Contact_email email=''

#GContact_phone rdfs:subClassOf Contact_officePhoneNumber #GContact_phone rdfs:subClassOf Contact_homePhoneNumber phone=''

#GContact_mobile rdfs:subClassOf Contact_mobilePhoneNumber mobile=''

#GContact_fax rdfs:subClassOf Contact_faxPhoneNumber

company='' title=''

#GContact_address rdfs:subClassOf Contact_partOfAddress address=''

The representative meaning of “#GContact rdfs:subClassOf Contact” is that the GContact class is semantically inherited to the Contact class, therefore if any object query commands are used to query all Contact model objects, the GContact object inherited to the Contact class will remain within the scope of the queried targets. In a later section we will show that TContact is also semantically inherited to Contact. Accordingly, when developers want to query model objects from two different address books (e.g., Gmail or ThunderBird), SOF automatically recognizes that both GContact and TContact objects must be involved within the query scope if Contact class is the target being queried. In this manner, the goal of querying heterogeneous address books can be easily accomplished.

According to the comment line “#GContact_name rdfs:subClassOf Contact_partOfName,” the name attribute in the GContact class is semantically inherited to the partOfName attribute of the Contact class. Thus, if developers specify the string value of the Contact_partOfName attribute that is being queried at a later time, the SOF system will also automatically query the string value of the GContact_name attribute.

GContact_phone refers to a multiple inheritance relationship. The attribute represented by GContact_phone can be a business or residence telephone. Since RDF syntax supports multiple inheritance relationships, SOF still allows for semantic multiple inheritance descriptions for classes or attributes. This is true even if the programming language (e.g., Java) does not support multiple inheritance relationships. Using GContact_phone as an example, regardless of whether a developer chooses Contact_officePhoneNumber or Contact_homePhoneNumber as a query target at a later time, SOF will always automatically query GContact_phone attributes.

The next example shows how TContact is semantically inherited to Contact:

#TContact rdfs:subClassOf Contact class TContact(Model):

#TContact_mail rdfs:subClassOf Contact_email mail=''

#TContact_givenName rdfs:subClassOf Contact_partOfName givenName=''

#TContact_sn rdfs:subClassOf Contact_partOfName sn='' #first name

#TContact_cn rdfs:subClassOf Contact_partOfName cn='' #full name

#TContact_telephone rdfs:subClassOf Contact_officePhoneNumber telephone=''

#TContact_homePhone rdfs:subClassOf Contact_homePhoneNumber homePhone=''

#TContact_fax rdfs:subClassOf Contact_faxPhoneNumber fax=''

#TContact_mobile rdfs:subClassOf Contact_mobilePhoneNumber mobile=''

#TContact_homeStreet rdfs:subClassOf Contact_partOfAddress homeStreet=''

#TContact_mozillaHLocality rdfs:subClassOf Contact_partOfAddress mozillaHLocality=''

mozillaHState=''

#TContact_mozillaHPostal rdfs:subClassOf Contact_partOfAddress mozillaHPostal=''

#TContact_mozillaHCountry rdfs:subClassOf Contact_partOfAddress mozillaHCountry=''

#TContact_street rdfs:subClassOf Contact_partOfAddress street='' #street of company

#TContact_l rdfs:subClassOf Contact_partOfAddress l='' #locality name of company

#TContact_postalCode rdfs:subClassOf Contact_partOfAddress postalCode='' #postal code of company

#TContact_c rdfs:subClassOf Contact_partOfAddress c='' #country name of company

The TContact and GContact classes are both semantically inherited to the Contact class. Many engineers know that this class is more complex than GContact from their experiences with various attributes pertaining to TContact—especially those referenced to addresses. No distinction exists between home and business addresses or among country, county, or street attributes. GContact only adopts an address attribute to represent all possible address strings. In TContact, nine attributes are referenced to address, all of them semantically inherited to Contact_partOfAddress.