Context-driven RDF Data Replication on Mobile Devices
This is a revision of a previous submission which was accepted for publication pending only minor editorial changes. The current version has been accepted for publication. The previous version was accepted with minor revisions. The reviews of the previous revision are below, followed by the reviews of the original submission.
Solicited review by Jerome Euzenat:
The revisions did not address all my comments satisfactorily, so some remarks still holds: in particular, the narrative and the title insist on "replication" while the larger part of the paper is about the framework and the experimental results do not concern replication.
However, in spite of this comment, this is now a great paper. The work is substantial, innovative and up-to-date.
The presentation has been largely improved: the paper is far better articulated and reads very easily.
Hence, I think that the paper is ready for publication as it is.
- My main criticism is about the graph plots: it is not possible (at least on the version I printed) to see the results for μjena. I suggest to drop the grey background, to ensure that the lines are in black and that they are distinguishable.
- p1: the last years -> the past years
- p1: heat generation is rather a problem than a quality, so it is strange to put it in line with memory capacity and CPU performance
- p2: thiscontext -> this context
- p2: data,context -> data, context
- p5: combing -> combining
- p8: Berkley -> Berkeley
- p11: exemplary is an adjective, use "sample" instead
- p12: it is not clear what is the meaning of mandatory and optional in ddesc
- p17: and represents the entry-level -> and now represents the entry-level (this was not the case when it was launched)
- p18 (6.2): start by explaining that the behavior on different machines varies quite a lot but that the order between systems is preserved across machines.
- p20: parsing performances "constantly drops" with increasing graph size. I am not sure what is the meaning given to constantly drop (the x-scale is logarithmic). It would be good to have an explanation.
Reviews for the original submission:
Solicited review by Martin Raubal:
This paper presents an important and practically relevant idea regarding the handling of context on mobile devices. The paper is written and structured very clearly and the authors provide good arguments for their approach. However, the evaluation "only" focuses on computation time and ignores the evaluation of the reasoning mechanisms themselves. It would be beneficial to the paper to include more details on the reasoning mechanisms and provide a concrete example within the case study. E.g., What does the data provider concretely do in this example and how? Section 5 really just gives an overview (and it is a relatively simple example without any complexity) without providing details of what exactly happens at each stage (in terms of representation, reasoning, etc.).
Some more details:
p3, 2nd to last paragraph: For an example of dynamic interaction between context- task-, and user models for mobile devices, which is extensible and based on activity theory, see Raubal, M. and I. Panov (2009). A Formal Model for Mobile Map Adaptation. Location Based Services and TeleCartography II - From Sensor Fusion to Context Models. Selected Papers from the 5th International Symposium on LBS & TeleCartography 2008, Salzburg, Austria. G. Gartner and K. Rehrl. Berlin, Springer: 11-34.
p4, col2, 1st para: You should explain why exactly a transformation into qualitative statements is needed.
p4, 2.3: "existing descriptions ..."; "information she / he is interested in";
p5, 3rd para: "prescribed vocabulary";
p6, 3.2: "Those frameworks..."; "processing large data amounts"; "we exclusively concentrate...";
p7, just before 4.: "interested in leading...";
p8, first "- ...": "enhance the overall";
p9, footnote 26: "software sensors";
p10, 1st para: "context provider"; col2, 2nd para: How exactly is the reasoning performed?
p11: "context provider to enrich..."; you need to provide more details on the "applies reasoning rules"!; "data provider that makes...";
p12, 3rd para: "content provider"?; 5.: "mobile user depend...";
p13, 3rd para: "task"; col2, 4th para: "these data";
p14, col2, 2nd para: delete "device" after "256 MB";
p15, 3rd para: "('Triples...";
ad Conclusions: You did not really show what the users' information needs are, how are they determined in general?
Solicited review by Jerome Euzenat:
The title of the paper accurately describes its content. It proposes a
framework for replicating RDF data on mobile devices based on the
present and future context of the device and device holder. Moreover,
the context itself is represented in RDF. It justifies the need to do
so, presents some related work, describes the design of such a
system, introduces the implementation on the Android platform and
evaluates the storage requirements of other triple stores.
First, I think that the work is original and significant. So the paper
deserves to be published. The justification for replication is clear
and performing context-based replication is a good idea; doing it with
a semantic framework for context management is great. The paper itself
is a good conceptual paper: it provides an innovative design for a
class of systems that achieve context-driven RDF data replication. It
would be more convincing with an implementation of the framework that
actually works. It is not clear that this is the case. The experiment
does not help, because it does not deal with the main task of the
I have two main criticisms for the paper:
The organization could be greatly improved. Indeed, Section 2 and 3
are not particularly about replication. Replication only appears in
the end of both Sections. In Section 4, the description of the
component which implements replication is not found. It seems that the
replication strategy is left to the implementation of Data
providers. However, describing how such a strategy can be implemented
is necessary (the link between context and fetching, which kind of
reasoning can go there, what strategy is used, etc.). Given
the title of the paper and its originality, replication should be the
main guiding line of the presentation.
The second criticism is related. The experiment evaluates data
stores. It is interesting in its own right, but it has nothing to do
with replication. What I would expect, in addition, is a monitoring of
a three day use case showing that the size of the database with
replication is low relatively to the size of the database without
it. This is obvious, but this is the goal. It would also be
interesting to see this size variation, the connection attempts and
failed access at data. That would rather show the interest of
I would advise that this paper be only published once there is a link
to where to retrieve/buy the system. It will only be interesting when
semantic web application developers can use it.
Otherwise, I have only minor comments and remarks:
- "Web 2.0" is rather a marketing term as far as I am concerned. So, I
do not think it has its place in an academic paper. It is better to
tell which feature of Web 2.0 applications matters.
- the introduction starts with the assertion that mobile devices are
always connected and the whole argumentation of the paper is based on
the idea that this is not true... it may be better to mitigate the
- It would be useful to motivate the paper with an example. The first
paragraph of Section 5 could be put there with the description of what
does the user expects. In addition, Section 5 should be more
precise about what data is actually replicated.
- Section 2, rather justifies the use of semantic technologies.
- 2.1: Many definitions have been proliferated. I thinks that
proliferation entails multiplication already.
- Is "Basically... employed" really useful?
- In Section 3.2, you may have a look at the two demonstrations who
won the best demo award at ISWC 2010. They are relevant to this topic.
- The end of Section 2 and 3 should summarise what has been found from
studying the litterature: Applications would benefit from replication,
RDF mobile databases do not support replication, etc.
- It is OK that Section 4 does not commit to an implementation
target. However, it should be said earlier in the paper either what
platform is targeted or that this work is supposed to be target
- It would be worth to use also the context for deciding when the next
connection will be available (something like what IYOUIT does by
learning user patterns). Of course, this is only suggestion for
- Fig. 1: I would draw a line around those components which run on the
mobile (almost all) and those which do not. It is also strange to have
a figurative RDF graph for the context model and not for the triple
- It is a pity that Section 4 is platform independent until the last
column which introduces Android-related features. Try to keep this
- Concerning the experimentation, it seems to me that there are two
limiting factors in Android systems: RAM and ROM. The RAM is used for
running the applications while the ROM is used for storing persistent
databases (at least the SQLite databases). I would be interested to
know what is the limiting factor in this case (given that there are
devices in which the ROM is relatively small). If ROM is relevant, it
would be worth telling how much ROM is left available before starting.
- Another suggestion is to consider dumping some data sources
to external memory (SD card), instead of fully discard it and
arbitrating between these various storage available.