semasm: semantically enhanced smart message · mms (multimedia messaging service) users also is...

1

SemaSM: Semantically enhanced Smart MessageOleksiy Khriyenko

Industrial Ontologies Group, MIT Department, University of Jyväskylä,P.O. Box 35, FIN-40014, Jyväskylä, FINLAND,

e-mail: [email protected]

Abstract Nowadays Multimedia Messaging concept facilitates new styles of communication that respond to the needs of the Mobile World, where business and personal lifestyles are changing and evolving very fast. Communication is at the heart of people’s lives. At the same time, the recent trends connected with information integration demand solid technology to provide interoperability between heterogeneous applications interacting. Applications of Semantic Web recently have shown many interesting opportunities in this domain. In this paper a Semantically Enhanced Messaging approach is presented and possibilities are analyzed for applying this approach for development of next-generation Semantic Web enabled ICT products in communication domain. Future mobile users are expected to be interested in semantic messaging and new applications built on top of semantically enhanced multimedia content. Semantic messaging provides interoperability between heterogeneous message based applications, decreases user expenses for data transmission and provides more advanced tool to access distributed information. Semantically enhanced Smart Messaging (SemaSM) supposes to be easy-to-use fun and attractive service. For other players(message content providers, service providers, access device producers and application providers) it offers a future-proof, evolutionary migration path and thus profitable business.

Index Terms:Smart Message, MMS, Interoperability, Semantic Web, Ontology, Metadata exchange, Semantic content

1. IntroductionNowadays statistics show that Multimedia Messaging Solution facilitates new styles of communication that respond to the needs of the Mobile World, where business and personal lifestyles are changing and evolving ever faster. This calls for flexible products and services that facilitate and support our new routines, and provide delightful experiences. Communication is at the heart of people’s lives. And as a result, the mobile phone is infused with rich new meaning. Now, when mobile phones become part of our way of life, impossibly to find even one user of mobile terminal who does not use the pioneer leader the path in wireless data exchange technology - SMS (Short Message Service), messaging has become so popular. And amount of MMS (Multimedia Messaging Service) users also is increased each day. MMS is one of the most recent developments in mobile messaging. Just as the traditional short message service, multimedia messaging provides automatic and immediate delivery of personal messages. Unlike the SMS however, MMS is a next-generation messaging protocol that allows mobile device users to incorporate audio, video, images and other rich content into traditional text messages, transform it into a personalized visual and audio message. MMS offers exciting functionality and full multimedia content to subscribers and an array of business opportunities to operators and service providers [1]. MMS technology offers more than just a broadening of message content. With MMS, it is not only possible to send your multimedia messages from one phone to another, but also from phone to email, and vice versa. This feature dramatically increases the possibilities of mobile communication, both for private and corporate use. Multimedia messaging reshapes the landscape of mobile communication, making it more personal, more versatile, and more expressive than ever before.

The recent trends connected with information integration demand solid technology to provide interoperability between heterogeneous applications interacting. Applications of Semantic Web in recent researches have shown many useful features for this domain. Semantic Web Activity lead by W3C provides support in standards for Semantic Web [2, 3, 4] (RDF-Schema, DAML+OIL, OWL, DAML-S). The scale of Semantic Web Activity widens attracting more and more parties.

2

Companies developing software can contribute much in integration processes providing interoperability for legacy systems that now have to be integrated. This can be done through development of software that has on the one hand software-specific interface and on the other hand standardized interface for data access. Original data in order to be available to external applications needs to be presented in some format, which those applications can process.

Making things presented in commonly understandable form is one of the goals of Semantic Web technology. Interoperability issues can be overcome if software-developer companies utilize the potential of this technology. Software systems can be adapted to produce data using common “language” provided by Semantic Web approach.

This paper introduces an extension of the MMS content to semantically enhanced message content. In the second chapter of the paper author describes the Semantically enhanced Smart Messaging Framework and main aspects within this approach. Third chapter is dedicated to the issues concerning supportive interface for semantic messaging. The last content part of the paper describes business opportunity within Semantic Messaging approach.

2. Semantically enhanced Smart Message FrameworkWe can see an always increased interest of users to information exchange. But, types of information to be sent are not limited only to text, video, audio message or images. Unfortunately now there is a lot of information which can be managed and understood just by human. An exchange of information which can be processed not just human, but also software applications is very important innovation for growing communication domain. It gives a possibility for users to manipulate applications and say what they want in an easy way via a message, and it allows software understanding of human needs. There is a lot of information people want to exchange. For example: schedule of activities (especially for a cooperative work managing or an organizing of group activities), any kind of appointments, various settings of mobile terminal’s properties (such as a profile), multimedia data and etc. Another important aspect is that the users need to exchange various kinds of information via easy, effortless mechanism of sending (creation) and receiving such Smart Messages.

In this case, we have a need to develop an application for processing complex messages which contain many types of information. On the one hand such software (Smart Message Manager (SMM) - agent for support smart message exchange) has to support a user interface with a possibility to access a data stored on a terminal. On the other hand it has to access to the other software applications and data storage of a mobile terminal. This supporting application can be developed and imbedded by mobile terminal producers. To be able interact, exchange and understand an information they mast support common ontology ‘language’. Information resources exchanged via the Smart Message also mast be described (annotated) via a common ontology with a purpose to be processed by application. For such information resource annotation mobile terminal has to be supplied by a semantic annotation mechanism which allows user to create it.

Additional benefit comes from data annotation for software development even if there is no need to deliver information outside of origin computing system: no more needs to develop special formats of data exchange between applications, since it is already presented in common standard by means of ontology. Software can be developed in a modular, scalable manner with support of this standard (ontology). Such commitment to the shared (upper-) ontology will provide compatibility of software. Extensibility of ontology is its inherent feature. As new types of information and needs to present them appear increasingly, ontology can be extended to reflect those changes and used further as a standard.

2.1. Interoperability between heterogeneous mobile devices (applications)

The common ontology approach provides interoperability between products of different producers. The idea is based on resource adaptation approach, which was elaborated by Industrial Ontologies Group [5] during the first year of the “SmartResource Project”. The global idea is

3

adaptation of any resources to Global Understanding eNvironment (GUN). A general approach for adaptation (General Adaptation Framework GAF) was elaborated and successfully utilized in the prototypes of the resources adapters during this year of the project. Such adaptation brings with it a transformation of the specific data representation formats to common transaction format. Thus we have a need to develop the bidirectional transformation modules (adapters) to transform the content in producer’s format to the content, serialized via the context sensitive extension of the RDF standard - a Context Description Framework (elaborated by IOG), specifically via the lite version of the CDF-Schema [6] with a support of the corresponding ontologies. A CDFlogically goes from duple vision of a property description to a triple description (since each property makes a sense in certain context, which should be specified by the context tolerance range), and from triple representation of a statement to quadruple representation (statement in a context of other statements) [7].

Let’s consider for an instance a calendar entry. The calendar model contains three calendar entries (meeting, memo and anniversary), each of them has a set of facets (properties). The figure (Fig.1) shows this property belonging to the calendar entries.

Fig.1. Calendar model (property belonging to the calendar entries)

Simple hierarchy of the properties (which allow describing a calendar instance independently from a phone model) represents simple mobile calendar ontology. In addition to the property hierarchy, ontology contains a specification of the property values. The referred prototype of the phone calendar ontology is elaborated and can be found via the link [8].

Fig.2. Calendar entry instance description

In the property hierarchy we can emphasize two main supper-properties: calendarEntry(describes that subject object (phone) has some calendar entry in the form of statements container, which represent the entry’s properties) and calendarProperty (describes the abstractcalendar entry property). The meetingEntry, memoEntry, anniversaryEntry properties are subproperties of the calendarEntry property and represent the corresponding calendar entries. And in turn subject, location, startTime, endTime, startDate, endDate, alarm, repeat, synchronization, occasion and date are subproperties of calendarProperty and correspond to the

4

properties of the calendar entries. This property ontology is elaborated based on CDF-Schema in the context sensitive description framework and includes the context sensitive relations between the properties. The hierarchy of the properties values also is represented in the ontology and is headed by CalPropValue supperclass. The example of mobile calendar entry instance is shown on the figure (Fig.2). The full calendar entry description is contained in an appendix (Appendix A.).

Concerning a transformation of the message, there are two possibilities how to organize it: decentralize transformation (local transformation on the client side) and centralized transformation on the message service side (Fig.3a and Fig.3b). Concerning the decentralisedarchitecture we have a need to locate the agent with adapter on the client (mobile device) side. It is again a challenge, because we are limited with the memory and storage place (especially if we have an ontology locally with the purpose to decrease amount of the remote accesses and save a money). But from another side we do not touch the message service at all. On the other hand, following the centralized architecture, we have no changes on the client side, but we should locate all adapters with the agents on the message service side. But in both cases we do not make any challenges for end user. All these architectures and transactions are transparent for him/her.

Fig.3. (a) Decentralized transformation architecture. (b) Centralized transformation architecture

2.2. Semantically enhanced multimedia data exchange

The next provided by metadata exchange significant benefits are access to an external world of the reach multimedia data, access to the user dependent information and an expenses decreasing during a multimedia data exchange. Such approach also gives a possibility to satiate message with the multimedia content in case of deficiency of multimedia data on the sender side.This feature is realized via a multimedia content semantic annotation exchange. It allows evading of the data duplication (e.g. sending of a data, which already exists on the recipient side) and saving a storage space. Also such approach can be utilized with a purpose to send a multimedia enriched message in the absence thereof need to send exact data and with the opportunity to use the located on the recipient side data, which semantically fits to the content of the message.

The data can be divided and considered as: original (concrete) data of a sender which can not be replaced by anything else; similar data which fits to a semantic annotation of original data; and third type of the data is recipient dependent data which can be found via personal description of the subject object. The hall schema of interaction is represented in the figure (Fig.4).

5

Fig.4. Interaction model

There are tree players: a sender, a message service and a recipient. Each of them is represented by an agent and storage space. Additionally, sender and recipient can have the representatives on the service side with a storage place or without it. The storage places can contain different types of the data accordingly to figure (Fig.4). Consider a set of the use cases:

original (concrete) sender’s data transmission; abstract semantically described data transmission; recipient dependent data transmission.

Original sender’s data transmission. There is a case when sender want to send exact data (not a similar, not a semantically same data). But even now in such statement we can consider some possibilities. If sender send the strict data it does not make a sense, it does not save the money for him/her. But if sender keeps a LifeBlog (storage of the multimedia data on the service side), there are two possible models:

Sender keeps a copy of all stored on the mobile device data on the service side. Then hi/she can create a message in ordinary way, but sent message will contain just semantic annotation of the original data and will be enriched with a real multimedia data only on the service side (Fig.5a).

Sender shifts the data to the service side, but keeps the less resource required semantic annotations of the original data on a mobile phone. Thus during the message creating hi/she should use a data description module to describe the content of a message by semantic annotations. Then original data again will be added to the message on the service side and recipient will get a multimedia enriched message (Fig.5b).

Fig.5. Sender’s original data transmission: (a)-Duplication and (b)-shifting the data to the service side

The first type of transmission necessitates us to create a mechanism of automatic message content generation in the form of semantic data annotation instead of original data content. In

6

turn the second method brings a need to develop a user friendly and handy interface for message creation via semantic annotations of the contained objects. But both of them imply a resource (data) annotation presence, which can be provided with data or be created by user itself in a way of the common annotation approach with utilization of the common ontology.

Abstract semantically described data transmission. Concerning the transmission of an ”abstract data” we can say that it is a very interesting from an amusement point of view. Here we have a deal with a bit fortuitous data. During such type of a message creation sender does not make an accent on concrete data. Hi/she just want to send some fit instance of the described data class. Let’s consider for an instance some situation, when sender wants to congratulate a recipient with a birthday and would like to present a bunch of flowers. It would be any image of a bunch of flowers or video clip with a flower presenting. Sender should just make a semantic annotation of the message content: specify a type of data (image or video), data content and kind of flowers (if it is necessary). When a message with semantic annotations of the content objects comes to the message service, the appropriate data may be found in sender storage on the service side and in large service shared multimedia data storage as well. Even if there is information (on recipient service side) that appropriate data is located on the recipient mobile phone, then semantic message can be media enriched on the recipient side. It totally unloads the network traffic (Fig.6).

The sender’s and recipient’s agents on the service side may provide not just information about available media content (data), but also a lot of other kind of information as for a instance information about preferences (kind of flowers which he/she likes) of the user they represent (if such information provided by user). It gives a possibility to create not a recipient dependent message content, but message content in a context of the recipient.

Fig.6. Multimedia enriching of the semantically annotated message content

Recipient dependent data transmission. It is the most interesting case, when sender does not know or does not have specific information (data) concerning the recipient. For an instance: sender would like to congratulate his old friend with his son birth. They have not seen each other for a long time and sender does not know the name of the recipient son, because he got to know this information from another friend. And it will be much better for recipient to see in the message an image of his wife with a baby on the hands and right names in the text instead of such kind of content: “Dear Jon, I would like to congratulate you and Merry with a birth of your son”. In this case there is no other ways to create the message content then make the semantic annotations for the unknown data and expect an existence of necessary data on the recipient side (fig.7). To be sure that recipient any way will get a complete message, we have a need to specify textual analog for that annotated data which will not be found (like name in our example).

7

Fig.7. Message content enriched with a recipient related data

Undoubtedly the ideas mentioned above bring improvement of the existing messaging framework to some extent. Especially there is a possibility to not be limited in varied multimedia data utilization. But if we are talking about traffic decreasing and decreasing of the sender expenses for a huge amount of multimedia data transferring, then a benefit from this is not so evident. Sure, if a content of a message covers more then one MMS message (in case of transferring via an existing MMS technology), and then for sure one MMS message will be enough for a message with a semantically described content. But if there is not so much information sender wants to send, then content can be located in one MMS message. How we can resolve the situation? If we do not though the case of GPRS technology utilization, the solutions is a semantic message transferring via SMS messages. Taking into account a specific of the mobile environment we have a need to elaborate a semantic description code minimization method. It might be translator of usual semantic description to description in more compact form.In another words we have a need to elaborate a new RDF based language for a compact resource description (ontology and annotations creation) - coMpact RDF or Mobile RDF (MRDF). Via such translation modules on the sender’s and recipient’s sides content can be two directional transformed for a transferring (MRDF based content) and for a processing by already existing tools in RDF standard format.

3. Supportive interface for semantic messaging performanceFor the beginning, let’s define an example of the message we will refer over the chapter to. For example: sender congratulates his friend Jon with the Jon’s sun birth and invites his family to his new house. The result message content is represented on the figure (Fig.8). But initially, thismessage had another content, because the sender did not have some data and knowledge during acreation of the message. Just let us assume that Jon’s sun was born three weeks ago and sender do not know his name; imagine that sender do not have the picture of Jon’s family (with his wife and little sun), but it would be cool to insert this picture to the message. At the same time we can see two features in the message like an image that some how represents time and a map, which shows the way to get to the sender’s house.

I consider these two images as a new kind of multimedia data – dynamic (on-the-fly) multimedia data. Because those images are not exist images beforehand. Of course they can exist in principle, but it makes more sense if such data will be created on-the-fly by specific services. Like in our case, there are: service which creates an image with certain time representation form (clock) based on input time value, and service which create an image of the map with a path between input start and destination points. In the end in our message in addition to usual text content we have:

semantically fit multimedia data: a message mood representation in form of the image with a smile (an emotion icon);

8

recipient dependent data: the name of the recipient’s sun. Such information can be found on the recipient side and with this purpose it should be semantically annotated;

recipient dependent data: the picture of the whole recipient’s family (Jon, his wife and sun);

semantically fit / recipient dependent data: multimedia time representation in the form of “image on-the-fly” (perhaps with a recipient personalized view);

sender’s original data: the image of the new sender’s house; semantically fit / sender dependent / recipient dependent data: the map with a path

between sender’s and recipient’s houses.

Fig.8. Result message content

For this additional data we have a need to create semantic annotation during message content creation. We need such annotation for totally sender dependent (original) data even not just if real data is located on the sender’s service side (as it was mentioned before), but even if data is located on the sender’s mobile device it may to facilitate the appropriate data retrieval (if a semantic search method is assisted). Sure, the last type of data can be found and inserted by sender manually, but in this case the semantic annotation should be added to the message automatically.

3.1. Semantically annotated message content creation

A base for a semantic annotation creation is the appropriate ontologies of the domain. A semantic description technology for a semantic message content creation is the same as a content data semantic annotation technology with the only difference, that it is a description of the required resource (abstract data) as a request for semantic matching, but it is not a exist resource description. Thus the ontologies for a resource (data) semantic annotation are also a base for a semantic content creation interface.

There is a set of the ontologies required for a semantic multimedia message content annotation. And the first one is message content object ontology. Now we see that a set of the content objects is larger then a set of the multimedia objects, which we can insert to MMS

9

message (image, audio and video clips). There are already at list two additional objects like: “image on-the-fly” and unknown information (text). Keeping on the following through the list of ontologies, the ontologies for object content description are significant. For example there are such ontologies like: content type ontology (portrait, icon, logo, usual image,.. / movie, animation, news, clip,..); object ontology (objects which can be presented on the image or video); ontology of the parsons (as a part of object ontology); location ontology (places,..); action ontology (especially for video clips); and etc. We will not go to all these ontologies deeply, because there are a lot of related works on going and already done. But we concentrate more on the semantic multimedia message content ontology.

Fig.9. Semanticaly enhanced message

$$Object_01$$ Hi, Jon!!! I congratulate you and Marry with $$Object_02/name~”your son”$$

birth. $$Object_03$$ I and Kati invite you for a diner next Sunday at $$Object_04~”7 pm”$$ to our new house $$Object_05$$ The address: Mooney st. 45/2 $$Object_06$$

<?xml version='1.0' ?><!DOCTYPE rdf:RDF [ <!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY smc 'http://www.cc.jyu.fi/~olkhriye/SemaSM/ontologies/SMC_Ontology#'> <!ENTITY obj 'http://www.cc.jyu.fi/~olkhriye/SemaSM/ontologies/Obj_Ontology#'> ]><rdf:RDF xmlns:rdf="&rdf;" xmlns:rdfs="&rdfs;" xmlns:smc="&smc;" xmlns:obj="&obj;" >

<smc:Image rdf:about="#Object_01"> <smc:img_Type rdf:resource="&obj;Portrait"/> <smc:img_Content rdf:resource="#Res_01"/></smc:Image>

<smc:Person rdf:about="#Object_02"> <smc:father rdf:resource="&smc;Recipient"/></smc:Person>

<smc:Image rdf:about="#Object_03"> <smc:img_Type rdf:resource="&obj;Ordinary"/> <smc:img_Content rdf:resource="#Res_02"/> <smc:img_Content rdf:resource="#Object_02"/> <smc:img_Content rdf:resource="&smc;Recipient"/></smc:Imaget>

<smc:Image_OnTheFly rdf:about="#Object_04"> <smc:img_Type rdf:resource="&obj;Portrait"/> <smc:img_Content rdf:resource="#Res_03"/></smc:Image_OnTheFly>

<smc:Image rdf:about="#Object_05"> <smc:img_Type rdf:resource="&obj;Portrait"/> <smc:img_Content rdf:resource="#Res_04"/></smc:Image>

<smc:Image_OnTheFly rdf:about="#Object_06"> <smc:img_Type rdf:resource="&obj;Portrait"/> <smc:img_Content rdf:resource="#Res_05"/></smc:Image_OnTheFly>

</rdf:RDF>

<obj:Smile rdf:about="#Res_01"> <obj:mood rdf:resource="&obj;Excellent"/></obj:Smile>

<smc:Person rdf:about="#Res_02"> <smc:name>Marry</smc:name> <smc:husband rdf:resource="&smc;Recipient"/></smc:Person>

<obj:TimeView rdf:about="#Res_03"> <obj:hour>19</obj:hour> <obj:minute>0</obj:minute></obj:TimeView>

<obj:House rdf:about="#Res_04"> <obj:owner rdf:resource="&smc;Sender"/></obj:House>

<obj:MapWithPath rdf:about="#Res_05"> <obj:start_point rdf:resource="#Res_06"/> <obj:destination_point rdf:resource="#Res_07"/></obj:MapWithPath>

<obj:PostAddress rdf:about="#Res_06"> <obj:resident rdf:resource="&smc;Recipient"/></obj:PostAddress>

<obj:PostAddress rdf:about="#Res_07"> <obj:resident rdf:resource="&smc;Sender"/></obj:PostAddress>

Data track

Semantic track

10

Regarding the previous chapter three types of data were defined (sender’s original data, semantically fit and recipient dependent data) and should be defined in message content ontology also. Simple example (prototype) of the semantic multimedia message content ontology can be found via the link [9].

Now, when we have ontology for semantic message content annotation we should specified the message format. Below I present one of the possible structures of a message. Such structure is represented by two parts (containers): data and metadata message tracks. The data track contains a plain text with the inserts of the references to the semantic data description located in the invisible for user semantic (metadata) track. With the purpose to provide as complete as possible message content to the recipient, even in case of absence appropriate data, such insert should be supplied with a possibility to specify a text analog which will be represented for the recipient instead of unavailable data. Of course we can define any format for the insert syntactic representation, but let’s follow the format, which is shown in the message example (Fig.9), where the first part plays a role of a reference to the metadata and second part after the separator (“~”) is a text analog.

Fig.10. Message content object annotation

Semantic Track is represented by RDF document with the references to necessary ontologies and schemas (rdf, rdfs, cdfs). In current example (Fig.9) Semantic Track links to two simple prototypes of ontologies for a message Data Track content objects description. SMC_Ontology [9] contains hierarchy of the classes and properties for a message content description. Second Obj_Ontology [10] specifies the objects for content annortation. These ontologies can be reached by referred links. Besides, with a purpose to define the recipient and sender of current message,

11

SMC_Ontology contains two instances of smc:Person class (smc:Recipient and smc:Sender). Additionally to classes which describe the message multimedia objects, SMC_Ontology contains smc:Text class for a semantic annotation of the text information. For an instance, “Object_02” describes a name of the recipient son in current example. But, since “Object_02” is an instance of the class smc:Person, we should specify a property (“Object_02/name”) which returns a text value of the semantically matched resource.

As was mentioned, ontology is a base for user annotation interface. It means that an interface should be adaptive. I consider adaptation not just from user personalization point of view, but from ontology personalization point of view. It should be universal interface with a possibility to utilize connected ontology. Such interface should be realized in handy and user friendly form, and provide as simple as possible data annotation way for user. Ontology visualization is big challenge especially in case of mobile terminals with a small screen size. The illustration on the next figure (Fig.10) shows one of the possible user interfaces for semantic description of the multimedia object (“image on-the-fly” with time representation) from our message example.

In the same time with a user creation of the message Data Track, the Semantic Track is automatically created by a message creation application. In current message creation interface we have a list representation of the ontology nodes of the same level, and supervisor questionnaire form presentation of the properties. Of course we will have troubles during surfing through the lists of nodes in huge ontology. To make it easily a search bar may be used for fast search of appropriate node. But, to perform such approach each ontology node (class) should be supplied with a set of synonyms. Another feature of the user personalization approach that can be utilized is putting the list in order with an accent on more often used by user nodes. Also such techniques can be applied for properties representation. There are a lot of approaches to make user ontology surfing more natural and easy for heterogeneous users, and one of such approaches that called Ontology Personalization [11] also can be utilized.

3.2. Semantic personalization of a message content representation

Some of personalization issues were considered already in the previous sub-chapter. There were interface personalization issues which concern ontology representation and surfing through it methods. But there is one more personalization aspect which concerns a content representation. In our example we have two objects called “Image On-The-Fly”. And one of them is time representation object (image, which visualizes time in “Clock Dial” style). There are a lot ofvisualization styles for time, temperature, any kind of diagrams presentation. And what style is the best in certain case if users have personal preferences from the visualization point of view?Thus, the possibilities to specify style of representation for the content and to describe personal user content representation preferences make a sense.

Regarding to the context concept of context dependent resource description, elaborated in Context Description Framework [7], object representation style can be considered as a context of contained in the message object. In the same time with a preferences specification in user profile, services (creators of an On-The-Fly Images) also should provide specification of the representation attributes (styles) in own profile. It helps with a search of an appropriate service. The figure (Fig.11) shows message object description statement with a presentation style in the context.

Such additional specification of the object can be added not just by sender during a message creation, but also by agent on the service side after the corresponding recipient’s information will be retrieved.

12

Fig.11. Object representation style as a context of the object

4. Business opportunity within Semantic MessagingMultimedia Messaging Service is a killer messaging service over 2.5/3rd Generation networks, which will bring revolutionary changes to enterprises and consumers. There are a lot of activities that are aimed at improving of MMS utilization. Accordingly to IBM China Research Laboratory[1], which has devoted to develop on MMS platform to help enterprise to deliver fantastic MMS-based services, MMS will make a significant impact on our personal and working lives. The mobile community has great hopes that MMS will prove to be the next important development and play a key role in halting the decline in ARPU (Average Revenue Per User). Mobile network operators are keen to introduce MMS as the flagship service on 2.5 or 3rd generation networks. Research analysts forecast that by the end of 2007 all new handsets sold in Western Europe will be equipped for MMS.

At the same time, Semantically Enhanced Messaging approach can be applied for development of next-generation Semantic Web enabled ICT products in communication domain.There is already fast growing trend of activities, which promote and show the benefit from content semantic annotation. Users are expected to be interested in semantic messaging and new applications built on top of semantically enhanced multimedia content. Semantic messaging decreases user expenses for data transmission and opens new possibility to access to the reach world of the information (data) in the case of lack own one. Then new business opportunities will be opened for multimedia content providers (multimedia creators, TV channels and etc.) as well as for service providers (internet and mobile operators), media access device producers (digitaldevice producers) and of course for application providers (as usual when new technology appears).

13

Thus, for consumers, Semantically enhanced Smart Messaging (SemaSM) as an intersection of these two fast growing approaches, delivers easy-to-use fun and utility. For other players it offers a future-proof, evolutionary migration path and thus profitable business (Fig.12).

Fig.12. Messaging migration path

5. ConclusionsIn this paper a new messaging approach have been proposed, which lies on an intersection of the fast growing MMS messaging and Semantic Web approaches. It was shown that Ontology-based information description and semantic track added to the message open new possibilities not justfor transferring and processing heterogeneous message content, but also for fully-fledgedoperation over information when direct access to the information is restricted. Providing annotated data is one of the first steps in building complex, flexible mobile communication environment. To support theoretical research author have provided examples and elaborated necessary ontologies. Another significant issue is a challenge of supportive interface for a semantic messaging. For consumers, messaging with semantically enhanced content and semantic-based interfaces delivers easy-to-use fun and utility. From the other side for message content providers, service providers, access device producers and application providers it offers a future-proof, evolutionary migration path and thus profitable business. The issues that are under research in the paper conform much to the growing market of communication and managing architectures. The developed concepts might be applicable for development of next-generation Semantic Web enabled ICT products in communication domain.

14

Appendix A. - The calendar entry description<?xml version='1.0' ?><!DOCTYPE rdf:RDF [ <!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY cdfs 'http://www.cc.jyu.fi/~olkhriye/csdf/0.1/cdfs#'>

<!ENTITY ontoCalendar 'http://www.cc.jyu.fi/~olkhriye/SemaSM/MobileCalendar/ontologies/CalendarOntology#'>

<!ENTITY calInst 'http://www.cc.jyu.fi/~olkhriye/SemaSM/MobileCalendar/instances/CalendarEntryInstance#'> ]><rdf:RDF xmlns:rdf="&rdf;" xmlns:rdfs="&rdfs;" xmlns:cdfs="&cdfs;" xmlns:ontoCalendar="&ontoCalendar;" xmlns:calInst="&calInst;" > <ontoCalendar:Phone rdf:about="&calInst;iPhone_1">

<rdfs:isDefinedBy rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/>

<rdfs:comment>Instance of the ontoCalendar:Phone class</rdfs:comment><rdfs:label>iPhone_1</rdfs:label>

</ontoCalendar:Phone>

<cdfs:Statement rdf:about="&calInst;iStatement_Meeting_1"><rdfs:isDefinedBy

rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:comment>Instance of the meeting statement</rdfs:comment><rdfs:label>iStatement_Meeting_1</rdfs:label><rdfs:subject rdf:resource="&calInst;iPhone_1"/><cdfs:predicate rdf:resource="&ontoCalendar;meetingEntry"/><rdfs:object rdf:resource="&calInst;iContainer_Meeting_1"/><cdfs:trueInContext rdf:resource="&calInst;iContContainer_Meeting_1"/>

</cdfs:Statement>

<cdfs:Container rdf:about="&calInst;iContainer_Meeting_1"><rdfs:isDefinedBy

rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:label>iContainer_Meeting_1</rdfs:label><cdfs:member rdf:resource="&calInst;iStatement1_Meeting_1"/><cdfs:member rdf:resource="&calInst;iStatement2_Meeting_1"/><cdfs:member rdf:resource="&calInst;iStatement3_Meeting_1"/><cdfs:member rdf:resource="&calInst;iStatement4_Meeting_1"/><cdfs:member rdf:resource="&calInst;iStatement5_Meeting_1"/>

</cdfs:ContextContainer>

<cdfs:ContextContainer rdf:about="&calInst;iContContainer_Meeting_1"><rdfs:isDefinedBy

rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:label>iContContainer_Meeting_1</rdfs:label><cdfs:member rdf:resource="&calInst;iContStatement_Meeting_1"/>


<cdfs:Statement rdf:about="&calInst;iContStatement_Meeting_1"><rdfs:isDefinedBy

rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:comment>Instance of the contextual statement</rdfs:comment><rdfs:label>iContStatement_Meeting_1</rdfs:label><rdfs:subject rdf:resource="&calInst;iPhone_1"/><cdfs:predicate rdf:resource="&ontoCalendar;calendarProperty"/><cdfs:trueInContext rdf:resource="&calInst;iContContainer_CalProp_1"/>

</cdfs:Statement>

<cdfs:ContextContainer rdf:about="&calInst;iContContainer_CalProp_1"><rdfs:isDefinedBy

rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:label>iContContainer_CalProp_1</rdfs:label><cdfs:member rdf:resource="&calInst;iStatement_Meeting_1"/>


<cdfs:Statement rdf:about="&calInst;iStatement1_Meeting_1"><rdfs:isDefinedBy

rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:comment>Instance of the calendar property statement</rdfs:comment><rdfs:label>iStatement1_Meeting_1</rdfs:label><rdfs:subject rdf:resource="&calInst;iPhone_1"/><cdfs:predicate rdf:resource="&ontoCalendar;subject"/><rdfs:object>Project Meeting</rdfs:object><cdfs:trueInContext rdf:resource="&calInst;iContContainer_Statement1_Meeting_1"/>

</cdfs:Statement>

15

<cdfs:ContextContainer rdf:about="&calInst;iContContainer_Statement1_Meeting_1"><rdfs:isDefinedBy

rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:label>iContContainer_Statement1_Meeting_1</rdfs:label><cdfs:member rdf:resource="&calInst;iStatement_Meeting_1"/>



rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:comment>Instance of the calendar property statement</rdfs:comment><rdfs:label>iStatement2_Meeting_1</rdfs:label><rdfs:subject rdf:resource="&calInst;iPhone_1"/><cdfs:predicate rdf:resource="&ontoCalendar;location"/><rdfs:object>University. Meeting room.</rdfs:object><cdfs:trueInContext rdf:resource="&calInst;iContContainer_Statement2_Meeting_1"/>

</cdfs:Statement>





rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:comment>Instance of the calendar property statement</rdfs:comment><rdfs:label>iStatement3_Meeting_1</rdfs:label><rdfs:subject rdf:resource="&calInst;iPhone_1"/><cdfs:predicate rdf:resource="&ontoCalendar;alarm"/><rdfs:object rdf:resource="&ontoCalendar;On"/><cdfs:trueInContext rdf:resource="&calInst;iContContainer_Statement3_Meeting_1"/>

</cdfs:Statement>





rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:comment>Instance of the calendar property statement</rdfs:comment><rdfs:label>iStatement4_Meeting_1</rdfs:label><rdfs:subject rdf:resource="&calInst;iPhone_1"/><cdfs:predicate rdf:resource="&ontoCalendar;repeat"/><rdfs:object rdf:resource="&ontoCalendar;Daily"/><cdfs:trueInContext rdf:resource="&calInst;iContContainer_Statement4_Meeting_1"/>

</cdfs:Statement>





rdf:resource="http://www.cc.jyu.fi/~olkhriye/MobileCalendar/instances/CalendarEntryInstance#"/><rdfs:comment>Instance of the calendar property statement</rdfs:comment><rdfs:label>iStatement5_Meeting_1</rdfs:label><rdfs:subject rdf:resource="&calInst;iPhone_1"/><cdfs:predicate rdf:resource="&ontoCalendar;synchronization"/><rdfs:object rdf:resource="&ontoCalendar;Private"/><cdfs:trueInContext rdf:resource="&calInst;iContContainer_Statement5_Meeting_1"/>

</cdfs:Statement>




</rdf:RDF>

16

References

[1] IBM China Research Laboratory, URL:http://www.research.ibm.com/beijing/updates/mms.html

[2] Semantic Web, URL: http://www.w3.org/2001/sw/.[3] @Semantics S.R.L., URL: http://www.asemantics.com/. [4] “OWL-S: Semantic Markup for Web-Services”, The OWL Services Coalition, December

2003, URL: http://www.daml.org/services/owl-s/1.0/owl-s.html.[5] Site of „Industrial Ontologies Group“, URL: http://www.cs.jyu.fi/ai/OntoGroup/ [6] CDF-Schema Lite, URL: http://www.cc.jyu.fi/~olkhriye/cdfs/0.1/cdfs.rdfs [7] Context Description Framework, URL: http://www.cc.jyu.fi/~olkhriye/cdf/[8] A set of classes and properties which are represent prototype ontology for mobile phone

calendar description, URL:http://www.cc.jyu.fi/~olkhriye/SemaSM/MobileCalendar/ontologies/CalendarOntology.rdf

[9] Semantic Multimedia message content ontology, URL:http://www.cc.jyu.fi/~olkhriye/SemaSM/ontologies/SMC_Ontology.rdf

[10] Object ontology for message content objects description, URL:http://www.cc.jyu.fi/~olkhriye/SemaSM/ontologies/Obj_Ontology.rdf

[11] Khriyenko O., Terziyan V., “OntoSmartResource: An Industrial Resource Generation in Semantic Web”, In: Proceedings of the 2nd IEEE International Conference on Industrial Informatics (INDIN’04), Berlin, Germany, 24-26 June 2004.

semasm: semantically enhanced smart message · mms (multimedia messaging service) users also is...

Documents