Review: Applying the Web Ontology Language to management information definitions

Jorge Vergara et al proposent d'utiliser le langage des ontologies "Web Ontology Language" OWL pour donner plus de sémantique et d'expressivité aux modèles de données.

Ils proposent d'utiliser OWL pour les raisons suivantes:

1. OWL est basé sur du RDFS et RDF
   
2. RDFS et RDF sont basés sur du XML et offrent un ensemble structuré de termes: hierarchie des classes, domaine et contraintes.
   
3. XML (eXtended Markup Language) est largement utilisé comme format d'échange, de représentation et d'interprétation d'information. L'utilisation d'XML est favorisée par l'existence d'un grand nombre d'outils et librairies qui faciliteront la validation (DTD) et le traitement des informations. En plus , XML peut être utilisé afin de représenter l'information autrement dans un scénario d'interopérabilité des protocoles d'administrations.

Jorge insiste sur le besoin d'introduire de la sémantique dans les data model existants afin d'arriver à passer de l'un à l'autre facilement. Actuellement, le passage entre 2 data models se fait par du recast autrement dit un mapping syntaxique plutôt manuel.
L'idée est de traduire les data models en OWL.
En effet, les data model actuels sont vu comme des ontologies 'light" puisqu'ils présentent entre autre un ensemble de concepts (class, attributs etc) et d'instance de concepts ainsi que des relations (sous-class, association de class etc). Cependant ces data models ne sont pas assez expressifs, pas de possibilité d'écrire des axiomes.

Or OWL est un langage d'ontologie général et lui manque quelques aspects pour pouvoir traduire les models de données en OWL. Les droits d'accès (Lecture, écriture) , les unités de mesures (Bit/seconde) ainsi que les valeurs par défaut pour les attributs. Les auteurs étendent OWL avec ces aspects tout en se basant sur du RDFS. (voir Fig, clic pour agrandir)




Conclusion:
Cet article présente une approche pour une interopérabilité entre data model tout en se basant sur OWL. Ce langage est basé sur du RDFS qui est capable de décrire un data model par des class, propriété, hiérarchie, domaine et types.
RDFS lui même est basé sur du XML ce qui facilite l'échange et le traitement d'information par des outils déjà existants.
Des extensions ont été ajoutées à OWL (en utilisant RDFS) afin d'arriver à traduire tous les aspects d'un modèle de donnée vers OWL.
Ils proposent également de formuler avec du SWRL (Semantic Web Rule Langage) des règles et des axiomes (plus de détails bientôt).

Review: Design considerations for a network of Information

In this position paper they insist on the fact that the Internet has to be reshaped and be focused on data instead of endpoints, in order to have a data centric network or network of information.
According to Jacobson [1], the first generation of the network dealt with connecting wires. The second one focused on end nodes hosting data while the third generation should refocus on what humans care the most about Information.

Their information models distinguish between 2 main objects:
Data Objects (DO): are the actual bit-patterns that contain the information: such as file, phone call, video, web page, a song(Beethoven's 9th symphony) etc. These data objects can be divided into "chunks" smaller pieces in order to simplify the transfer.
Information Objects (IO): holds semantic information and meta-data related to data objects, such as Beethoven's 9th symphony is an mp3 file encoded with 128kbps, IOs can be composed of other IOs or directly pointing to one or multiple DOs. An IO can represent the Eiffel tower and point to DO like pictures, a wiki page or service to buy tickets, etc.

Versioning and Revocation:
Since some information is frequently changing such as news papers. An IO can represent today's version, however the IO should adapt dynamically by binding to another DO (web page) the next day, and so on for the IO pointing to yesterday's news.
They suggest that objects invalidate themselves in order to conserve consistency. After an amount of time, objects should be recertified before it can be used. By applying this technique, they maintain consistency due to disconnected operation during information update of other replicas for example. DO can be deleted same way when no certification is given.

Security considerations:
Security in today's architecture is based on confidence (Encryption keys) of the host delivering the object, they propose to reshape security conventions so we can handle secured data instead of secured tunnels.
Integrity and authenticity is directly tied to object's names which means there would be a cryptographic relation between the name and object such as self-certifying names. However to enable off-line verification, DO must carry private keys which can be compromised. Another approach is to assign precomputed signatures to objects. It remains a research field.

Name resolution(NR):
Data objects are retrieved based on their unique identity (UID). NR starts with locating the object in the network then routing forwards the object retrieval query to its storage location and finally the DO is sent to the requesting client.
The naming resolution resolves an UID into one or more locations and should work on global and local scale by cooperating between NR systems for example. They show the side effects if ID/address split mechanism is adopted with the following example, if a laptop hosting numerous Data Objects moves its location then all Data objects location changes too. This will lead to huge number of updates in the NR system.
The NR system will be influenced by the characteristics of namespaces. They would like to adopt flat names which respects the non right of ownership and other characteristics revealed by [2].
Off course, using flat names prevents the use of hierarchical names spaces and systems like DNS.
DHT based solutions are promising since the are decentralized, scalable, self-organized and don't need central structure. However when going globally DHT uses flat names hence non hierarchical names which prevents cooperation with other systems.

Routing:
Addressable entities are still increasing and will reach millions even billions in few years with the emergence of sensor networks, Internet of things, growing data etc. They claim that routing research are not encouraging according to [3] (will be reviewed later). Hence, they ll investigate the efficiency of name based routing which integrate both resolution and retrieval paths. Name based routing will locate DO based on their ID by transforming the ID directly into a path without going through ID-address transition. Other techniques such as LLc and NodeID are to be investigated also (Soon will be reviewed).

Storage:
The information network can be implemented following two different models:

• Network based storage model where storage resources are provided by the network infrastructure, like dedicated storage servers.

• Network managed storage model where network nodes control portions of storage memory of users connected to the network. Users will be able to decide what DO goes public or be shared only with friends etc.

Search:
Search systems are expected to go far beyond text match search, such as semantic search or even search functionality based on GPS position, location positioning. For example when a picture of Eiffel tower is taken, a search mechanism will handle the identification of the monument based on GPS or other techniques and points to DO related informations such as web page, history etc.

This position paper gives many ideas and anticipations about the future Internet architecture and reveals the weakness in the current addressing system. They distinguish between DO and IO and argued that a network of information needs a scalable naming system supported by an efficient routing system.

References:
1 - V. Jacobson, M. Mosko, D. Smetters, and J. Garcia-Luna-Aceves. Content-centric networking. Whitepaper, Palo Alto Research Center, Jan. 2007.
2 - M. Walfish, H. Balakrishnan, and S. Shenker. Untangling the web from DNS. In NSDI’04: Proc. 1st Symp. on Networked Systems Design and Implementation, San Francisco, CA, USA, 2004.

Link to the article

Mobile IP

Nowadays a device might belong to a home network which means that it maintains a permanent address known as its home address and a temporary internet address assigned to it when joining another network.
This permanent unique address is used to communicate with such hosts.
When a host with a permanent address is attached to another network, the data received at the home network should be forwarded to the visited network.

There are several methods to keep track of migrating hosts such as:

• A server that keep the binding between the permanent address and temporary address. However this method has several limitations, mainly it is impossible to provide an on-line migration, transport protocols need to know about the new address in order to reestablish communication. It increase network traffic to update the mapping and caches if existed.
  

• Broadcast solution: when a host wants to send data to a migrating host, it broadcasts a query packet in a network and the migrating host reply with its temporary address. This mechanism can only be applied to small networks.

There are three well know problems involved when dealing with host migration:
[Internet draft NETLMM problem]

• Update latency: the update of the new temporary address is always necessary when a host migrate, though this update might take time if the migrating host did not notify about his mobility, network traffic, crashed routers,etc. During this time, the home network will forward received packets to an old temporary IP address until the new mapping occurs.
• Signaling overhead: when moving to another network, the migrating host notifies its home network and acquire a new address. The configuration and notification can be expensive depending on the method and the node resources (bandwidth, battery dependent etc).
• Location privacy: the change in temporary address exposes the migrating host topologically.
  

"The on-line Migration":
With the huge development of Wireless networks, a host can migrate from one network to another in a short time while still connected to other hosts. This is called "on-line" migration.
When migrating several applications need to stop and reestablish the communication with distant hosts using the new assigned address. This causes service or application interruption.

This interruption of service is encountered because in the OSI layers, the IP address is used for both host identification and routing (data delivery).
In the transport layer (TCP, UDP) the IP address is used as an identifier along with other parameters in order to uniquely address a host or a communication session.
As for the network layer, the IP address is used as a way to locate a host and deliver data.

The following paragraphs describes some solutions for the host migration.