Application-specific intersections with schema.org record types

Greetings,

Suppose we are building a new application called GuestbookPro, and we want to store information about each person who signs the guestbook. Using the schema.org vocabulary, this would be done by using the http://schema.org/Person record type (referred to as schema:Person from now on). However, say for GuestbookPro we only care to store the person’s name and their telephone number. In that case, schema:Person is a much larger record than we actually need.

From what I can tell, any field of schema:Person may be null. To store a person’s name and telephone number we would just store the “name” and “telephone” properties of schema:Person and make the assumption that the value of any property not present is null. However, we miss the opportunity to represent or document the fact that GuestbookPro will only ever care about “name” and “telephone” in the schema:Person record. If we were going to develop a viewer for GuestbookPro, we cannot assume that only “name” and “telephone” will be present without resorting to out-of-band information, because the data is representing that a schema:Person record is being used and so any of the fields must be expected.

What would be more ideal is to specify a new record type as a subset of schema:Person. We will call this record type gbp:Person and will only have the properties “name” and “telephoneNumber”. We then specify a mapping from gbp:Person to schema:Person (which is lossless), and from schema:Person to gbp:Person (which is lossy). In general the mapping may be more complex than simply mapping property names. For example, a requirement may be to convert a date and time format. Another example is that one record type may have only one property “fullName” and another record two properties “firstName” and “lastName”. The purpose of this mapping is that gbp:Person may still be understood as a schema:Person, and a schema:Person can still be understood as a gbp:Person (with loss of data), so we do not lose the benefits of standardization and we retain the capability of defining types which best suit our applications.

I know of no mechanism like the one I describe, but I feel as though it is necessary to make schema.org practical to use, otherwise the scope of your application is poorly represented by the data. I am looking for any thoughts regarding this issue.

Thanks,
Eric