Steve Vinoski published a very interesting article: Serendipitous reuse. He also provided additional comments in his blog. The author explores benefits of RESTful uniform interfaces based on HTTP “verbs” GET, PUT, POST and DELETE for building expansible distributed systems. He also compares RESTful approach with traditional SOA implementations based on strongly typed operation-centric interfaces.
Serendipitous reuse is one of the main goals of Subject-centric computing. In addition to uniform interfaces, Subject-centric computing promotes usage of uniform representations with basic ontological commitments (as one of the possible representations).
One of the fundamental principles of the Resource-Oriented Architecture is the support for multiple representations for the same resource. For example, if we have a RESTful service which collects information about people, GET request can return multiple representations.
Example using JSON:
{
"id": "John_Smith",
"type": "Person",
"first_name": "John",
"last_name": "Smith",
"born_in": {
"id": "Boston_MA_US",
"name": "Boston"
}
}
Example using one of the “domain specific” XML vocabularies:
<person id="John_Smith">
<first_name>John</first_name>
<last_name>Smith</last_name>
<born_in ref="Boston_MA_US">Boston</born_in>
</person>
Example using one of the “domain independent” XML vocabularies:
<object obj_id="John_Smith">
<property prop_id="first_name" prop_name="first name">John</property>
<property prop_id="last_name" prop_name="last name">Smith</property>
<property prop_id="born_in" prop_name="born in" val_ref="Boston_MA_US">
Boston
</property>
</object>
Example using HTML:
<div class="object">
<div class="data-property-value">
<div class="property">first name</div>
<div class="value">John</div>
</div>
<div class="data-property-value">
<div class="property">last name</div>
<div class="value">Smith</div>
</div>
<div class="object-property-value">
<div class="property">born in</div>
<div class="value">
<a href="/Boston_MA_US">Boston</a>
</div>
</div>
</div>
Example using text:
John Smith was born in Boston
These five formats are examples of data-centric representations without built-in ontological commitments. These formats do not define any relationship between representation and things in the “real world”. Programs which communicate using JSON, for example, do not “know” what “first_name” means. It is just a string that is used as a key in a hash table.
Creators of RESTful services typically define additional constraints and default interpretation for corresponding data-centric representations. For example, we can agree to use “id” string in JSON-based representation as an object identifier and we can publish some human readable document which describes and clarifies this agreement. But the key moment is that this agreement is not a part of JSON format.
Even if we are talking about a representation based on a domain specific XML vocabulary, semantic interpretation is outside of this vocabulary and is a part of an informal schema description (using comments or annotations).
Interestingly enough, level of usefulness is different for various representations. In case of a text, for example, computer can show text “as is”. It is also possible to do full-text indexing and to implement simple full-text search.
HTML-based representations add some structure, ability to use styles and linking between resources. Some links analysis can help to improve results of basic full-text search.
If we look at representations based on Topic Maps, situation is different. Topic Maps technology is a knowledge representation formalism and it embeds a set of ontological commitments. Topic Maps-based representations, for example, commit to such categories as topics, subject identifiers, subject locators, names, occurrences (properties) and associations between topics. There is also the commitment to two association types: “instance-type” and “subtype-supertype”. Topic Maps also support contextual assertions (using scope).
In addition, Topic Maps promote usage of Published Subject Identifiers (PSIs) as a universal mechanism for identifying “things”.
Topic Maps – based representations are optimized for information merging. For example, computers can _automatically_ merge fragments produced by different RESTful services:
Fragment 1 (based on draft of Compact Syntax for Topic Maps: CTM):
p:John_Smith
isa po:person;
- "John Smith";
- "John" @ po:first_name;
- "Smith" @ po:last_name
.
g:Boston_MA_US - "Boston"; isa geo:city.
po:born_in(p:John_Smith : po:person, g:Boston_MA_US : geo:location)
Fragment 2:
g:Paris_FR - "Paris"; isa geo:city.
po:likes(p:John_Smith : po:person, g:Paris_FR : o:object)
Result of automatic merging:
p:John_Smith
isa po:person;
- "John Smith";
- "John" @ po:first_name;
- "Smith" @ po:last_name
.
g:Boston_MA_US - "Boston"; isa geo:city.
g:Paris_FR - "Paris"; isa geo:city.
po:born_in(p:John_Smith : po:person, g:Boston_MA_US : geo:location)
po:likes(p:John_Smith : po:person, g:Paris_FR : o:object)
As any other representation formalism, Topic Maps are not ideal. But Topic Maps enthusiasts think that Topic Maps capture a “robust set” of ontological commitments which can drastically improve our ability to organize and manage information and to achieve real reuse of information with added value.