Process to reflect the facets into the ontology

Identifying properties and classes

Several of the concepts in the Device Facets list can be captured via properties in the ontology. A property in semantic relations is represented as a verb; it captures what normal people might consider a 'relationship'. A property represents the connection between a class and something that the class has or affects. They can be created by taking the something (which mortals might call a property, or a field, or a facet) and adding a verb to it: hasWidth, createsOrderID.  They can also be created as just a verb: attachesTo, isDeployedFrom. This can all be terribly confusing at first, so in this tutorial we sometimes use 'relationship' for the verb-like thing.

For example, to reflect the fact that a device has a serial number, we can explicitly define a property, say hasSerialNumber, to establish the relationship between a device and a number. The name (hasSerialNumber) is a piece of the required information to properly define a property in an ontology. A complete definition of a property also includes the corresponding domain and the range. In our example, the property would be:

Name: hasSerialNumber
Domain: System
Range: string

The previous example is a data type property; the range is chosen from a standard set of data types (which also include boolean, int, dateTime, and others). But other concepts may be better captured with object properties. An object property is similar to a data type property; the difference is that the range for the object property is a class instead of a data type. For example, the fact that a device has a manufacturer can be captured with a property hasManufacturer with the System class as its domain and the class Manufacturer as its range.

Name: hasManufacturer
Domain: System
Range: Manufacturer

So to review, a suitable property triple may be either of the form class-propertyName-datatype (for an atomic property) or class-propertyName-class (for a complex property), where domain and range are both specified as classes.

If it helps, John calls the domain class the subject of the relationship, for those of you with English grammar training, and the data type or range the object of the relationship. The relationship is generally a verb, so this seems to work.) 

Updating the ontology

As suggested above, a process to reflect the facets into the ontology is proposed as follows. (Note: parenthetical text represents possible answers for the serial number example above.)  

1. Pick an entry from the list of facets. It does not have to be at the first level. (7.a.1: Serial Number)
2. For a chosen entry, identify key entities --nouns are good candidates-- and relationships --verbs are good candidates. (Entity: Serial Number. Relationship: systems have serial numbers --implicit in this case)
3. For an identified entity, provide:   (Serial Number)
   
   1. Definition. (A unique identifying string for every individual unit, assigned by the manufacturer)
   2. Examples. (123, AF2G993C, A4022)
   3. Determine whether the entry is best described as an atomic type—a single number, or a single string—or would be better represented with a class, which in turn could be decomposed into subcategories and have other properties associated. (A serial number is atomic, and can be represented as a string)
   4. Identify significant entities and relationships associated with your entity. Each entity may be an existing class, a new class, or a new concept to capture in a property.  Each relationship also captures a potential property.  (A 'System' has a serial number)
4. For each potential relationship:
   1. Is it already included in the current ontology (diagram)? If not, perform the following steps with your potential relationship. If it is already in the current ontology, decide if these steps have been done appropriately.
   2. Determine how that relationship is associated with possible domain classes.
      1. Probably many properties will apply to System as the domain class. (true for serial number)
      2. Consider whether the property applies to only to a particular sub-class of System—does it apply to every instance of the domain class, on only to some instances? If the latter, what new type of class defines the instances to which this can be applied?  (every instance; though you might argue only hardware Systems have serial numbers)
   3. Determine how that property should be classified.
      1. If this is an atomic property, then it is likely to be a data type property. What basic data type will be the range of the property? (string)
      2. If this is not an atomic property, then it is likely to be an object property. What is the class that serves as the range of the property? (n/a)
      3. Determine the permitted cardinality for the range of the property. (1)
   4.  Propose the changes to the existing ontology based on your answers. (Add data type property hasSerialNumber with System as domain and string as range)
5. Capture any additional classes or properties identified through this process, and propose they be added either to the 'facets' list (go ahead and edit that page), or to the classes in the ontology (email Carlos and John, or the group, with this information).

Some questions and answers

(the following topics have been discussed offline -- slightly edited here)

Format for specifying changes?

Should there be a particular format to specify the changes to the ontology?

We agree the following format seemed very readable:

• + Created class CalibrationSchedule (4.c)
• + Created datatype property: System hasSerialNumber string (7.a.1) 
• + Created object property: System hasManufacturer Manufacturer
• + Created class Medium (2.a, 3.a.1)

You can use: +, *, and - to indicate addition, modification, and deletion, respectively.

I had a question about serialNumber, in this case. I got to step 3.2, and I realized there was something odd about serial number. It is odd to say the _class_ 'System' has a serial number -- it is only _instances_ of devices that actually have unique serial numbers.

Note that, by the same token, you would get a similar conclusion with, say, hasManufacturer: "it is odd to say the _class_ System has a manufacturer."

A 'class' is a set of individuals. Sometimes the set is defined by extension (ie., by explicitly enumerating the members of the set; for example: Weekday = {Monday, ..., Friday}). But a class is defined sometimes (either for convenience or necessity) by intension: we state a number of properties (and/or restrictions) for the members of the set. Our System class is an example. With our hasSerialNumber property, which has the class System as 'domain,' we are stating that, if s1 is a member of the set System, then s1 has a serial number." In summary, when you instantiate a class (eg., s2 as member of System), you would eventually also be instantiating the associated properties for that member (eg., s2 hasSerialNumber "89EE8888"). Also note that, besides the basic (domain, name, range) triple for the definition, a property can also be further qualified; for example to state that the propery is functional, which is the case with hasSerialNumber: a system can only have one serial number.

Do we do anything differently for a property that only is filled out for instances, than we do for a property that is filled out in the ontology (I think that means it is filled out for classes)? For example, if I say a deployable System may be deployed but a non-deployable system may not, now I have a property -- isDeployable -- which can filled out to determine which class of device this is.

Yes, precisely; you can have the isDeployable property (domain: System; range: boolean), and then you could also have the associated classes of System explicitly *defined* in your ontology as follows:

DeployableSystem = (System where isDeployable = true)

NonDeployableSystem = (System where isDeployable = false)

OWL offers the mechanisms for doing this kind of definitions.

Further, If deployable devices have other properties, and non-deployable devices do not have those properties, then which properties apply to the class is determined by one of its properties. How does that affect things?

You can associate them to the DeployableSystem and NonDeployableSystem (sub)classes accordingly.

System model and synonyms

A model can be expressed as a string and isn't usually decomposed into subcategories, so this should be an atomic type. Or, maybe not. In the case of the sbe-37, would it be preferable to group the 37 -IM, -IMP, -SM, -SMP, -SI, and -SIP and have them all subsets of SBE-37? We could handle this either way, and I'm not sure which will be best in the long run. Also, is there any problem using synonyms for atomic types? An SBE MicroCat is the same model as an SBE-37-SM, for example.

I concur that an atomic data type, like a string, would be appropriate to capture a model identifier in our ontology. That is:

System hasModel string

However, and somewhat related with synonyms: We don't necessarily have to capture the synonym aspect in the ontology itself at this point, mainly because we are not going to deal with instantiations, but also for the sake of an incremental development. That said, let's see. I can imagine a property hasSynonym for the corresponding relationships. This will require that Model be a class and then that hasSynonym be an *object* property:

Model hasSynonym Model
(which, BTW, would be a symmetric property as the relationship is bi-directional)

Now, since "model" is now captured as a class, then we need something to "store" the actual identifier. In this case, a hasIdentifier (atomic) property can be defined:

Model hasIdentifier string

and, finally, the hasModel property would now be an *object* property:

System hasModel Model

In some worlds, hasSynonym wouldn't be symmetric. The original concept has many synonyms, but the synonyms only have one original concept.

That's right; especially if the concept of "main identifier" is also captured explicitly.

A possible approach is as follows. The "main model identifier" concept can be captured by making the hasModel property a *functional* property (meaning that an instance of System can only have one model associated). This way, we can still make hasSynonym a symmetric property.  Note that, in principle, there is no "dominant" identifier among synonym identifiers (they all are supposed to refer to the same concept). "Dominance" (ie., "main identifier") takes place from the point of view of other entities, in this case System.