Academia.eduAcademia.edu

Figure 20 – uploaded by Baston Gabriela

See full PDFdownloadDownload figure
Figure 6.2: Sequence diagram for the communication with the server.

Figure 6 2: Sequence diagram for the communication with the server.

Related Figures (30)

Figure 2.1: The Semantic Web layer cake.
Figure 2.1: The Semantic Web layer cake.
Figure 2.2: RDF example represented as a graph. RDF is a data model which can be serialised in several ways. The most popular serialisation of RDF was first RDF/XML [Beckett, 2004], due to the popularity and familiarity of XML. More recently however, other serialisations, more suitable for hu- man consumption, have become preferred: N-Triples [Grant and Beckett, 2004], Turtle Beckett, 2007], and N3[Berners-Lee, 2006b]. RDFa|Adida et al., 2008] is another syntax for RDF, which allows embedding of RDF statements in HTML pages. In the following chapters of the thesis, we will use the Turtle notation in listings.
Figure 2.2: RDF example represented as a graph. RDF is a data model which can be serialised in several ways. The most popular serialisation of RDF was first RDF/XML [Beckett, 2004], due to the popularity and familiarity of XML. More recently however, other serialisations, more suitable for hu- man consumption, have become preferred: N-Triples [Grant and Beckett, 2004], Turtle Beckett, 2007], and N3[Berners-Lee, 2006b]. RDFa|Adida et al., 2008] is another syntax for RDF, which allows embedding of RDF statements in HTML pages. In the following chapters of the thesis, we will use the Turtle notation in listings.
The Semantic Desktop To accommodate some restrictions specific to describing desktop and personal data, an extension to RDF was developed. It is called NEPOMUK Representational Language (NRL)'° [Sintek et al., 2007], and is a representational ontology, thus belonging in the top level of the pyramid. It adds Named Graphs and Graph Views to RDF/S and in troduces the closed world assumption to the data. The named graphs in NRL are similar to the named graphs defined by [Carroll et al., 2005] except that they do not fo 16) low the open world assumption. NRL defines graph roles for named graphs, where es contain information about a graph’s data and how it should be handled.
The Semantic Desktop To accommodate some restrictions specific to describing desktop and personal data, an extension to RDF was developed. It is called NEPOMUK Representational Language (NRL)'° [Sintek et al., 2007], and is a representational ontology, thus belonging in the top level of the pyramid. It adds Named Graphs and Graph Views to RDF/S and in troduces the closed world assumption to the data. The named graphs in NRL are similar to the named graphs defined by [Carroll et al., 2005] except that they do not fo 16) low the open world assumption. NRL defines graph roles for named graphs, where es contain information about a graph’s data and how it should be handled.
Figure 3.2: The architecture of the NEPOMUK Java implementation.
Figure 3.2: The architecture of the NEPOMUK Java implementation.
Figure 4.1: Semantic Desktop data life-cycle. This module manages the life-cycle of the semantic data that the application handles, by enabling the transition between the phases of the life-cycle. We adapted the Abstract Data Life-Cycle Model [M6ller, 2009] to illustrate a comprehensive workflow for Semantic Desktop data, from its creation to its termination. Figure 4.1 shows the phases and transitions between them, focusing on the possible actions that the user can execute, and hence, that a semantic application could support.
Figure 4.1: Semantic Desktop data life-cycle. This module manages the life-cycle of the semantic data that the application handles, by enabling the transition between the phases of the life-cycle. We adapted the Abstract Data Life-Cycle Model [M6ller, 2009] to illustrate a comprehensive workflow for Semantic Desktop data, from its creation to its termination. Figure 4.1 shows the phases and transitions between them, focusing on the possible actions that the user can execute, and hence, that a semantic application could support.
Figure 4.2: Graph representation of the information about a note. reating and Interlinking Semantic Data on the Desktop with SemNotes 83 We later added support for rating to the interface, leaving the meaning of the rating
Figure 4.2: Graph representation of the information about a note. reating and Interlinking Semantic Data on the Desktop with SemNotes 83 We later added support for rating to the interface, leaving the meaning of the rating
Figure 4.3: SemNotes annotation suggestion and link. 56 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Figure 4.3: SemNotes annotation suggestion and link. 56 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Figure 4.4: Current version of the SemNotes user interface. 8 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Figure 4.4: Current version of the SemNotes user interface. 8 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Figure 4.5: SemNotes main window, with two notes open in-list. creating and Interlinking Semantic Data on the Desktop with SemNotes 89
Figure 4.5: SemNotes main window, with two notes open in-list. creating and Interlinking Semantic Data on the Desktop with SemNotes 89
Figure 4.6: First version of the SemNotes note editor with pop-up style annotation sugges- t1i0Nn~ 0 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Figure 4.6: First version of the SemNotes note editor with pop-up style annotation sugges- t1i0Nn~ 0 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Figure 4.7: Second version of the SemNotes note editor with a side panel to display the annotation suggestions. sreating and Interlinking Semantic Data on the Desktop with SemNotes 93
Figure 4.7: Second version of the SemNotes note editor with a side panel to display the annotation suggestions. sreating and Interlinking Semantic Data on the Desktop with SemNotes 93
Figure 4.8: Age, gender and OS distributions of participants. Twenty participants took part in the evaluation, all members of our research institute. -1 They are researchers in the field of Semantic Web, thus possibly favouring the semantic application. This bias (if it exists) would however influence only their responses in the questionnaire and not the measured values. Fourteen participants regularly use note-taking and five of them use Evernote as their preferred note-taking tool. None of the participants used Linux as their operating system. Their familiarity with one environment and one application could have influenced the measured results, in favour of Evernote.
Figure 4.8: Age, gender and OS distributions of participants. Twenty participants took part in the evaluation, all members of our research institute. -1 They are researchers in the field of Semantic Web, thus possibly favouring the semantic application. This bias (if it exists) would however influence only their responses in the questionnaire and not the measured values. Fourteen participants regularly use note-taking and five of them use Evernote as their preferred note-taking tool. None of the participants used Linux as their operating system. Their familiarity with one environment and one application could have influenced the measured results, in favour of Evernote.
Figure 4.9: Age and OS distributions of participants per gender. 6 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Figure 4.9: Age and OS distributions of participants per gender. 6 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Figure 4.10: Inter-quartile ranges for the time difference. 8 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Figure 4.10: Inter-quartile ranges for the time difference. 8 Creating and Interlinking Semantic Data on the Desktop with SemNotes
Table 4.2: Statistics for time and click differences. Results show that for the simple search task T3 the difference is positive, which uggests that it takes longer to finish the task with SemNotes. However, the difference ; not significant. For the complex search tasks that follow, T4 and T5 the difference as negative values, showing that the users spent less time on complex searches when sing SemNotes, thus supporting the claim that the use of interlinked data makes notes asier to find. Only the results for T4 are statistically significant. None of the measures f number of mouse clicks for the search tasks are statistically significant, the differences eing in average less than 1 click, with a median value of 0, -1 and +1 respectively for he tasks T3, T4 and T5. Results show that for the simple search task T3 the difference is positive, which 4.4.5 Quantitative Results
Table 4.2: Statistics for time and click differences. Results show that for the simple search task T3 the difference is positive, which uggests that it takes longer to finish the task with SemNotes. However, the difference ; not significant. For the complex search tasks that follow, T4 and T5 the difference as negative values, showing that the users spent less time on complex searches when sing SemNotes, thus supporting the claim that the use of interlinked data makes notes asier to find. Only the results for T4 are statistically significant. None of the measures f number of mouse clicks for the search tasks are statistically significant, the differences eing in average less than 1 click, with a median value of 0, -1 and +1 respectively for he tasks T3, T4 and T5. Results show that for the simple search task T3 the difference is positive, which 4.4.5 Quantitative Results
Creating and Interlinking Semantic Data on the Desktop with SemNoted.01 Figure 4.11: Which tool helped perform the tasks faster (left) and better (right).
Creating and Interlinking Semantic Data on the Desktop with SemNoted.01 Figure 4.11: Which tool helped perform the tasks faster (left) and better (right).
Do these two URIs represent instances of the same real-world object/person? Figure 5.1: The Web interface of the experiment for collecting relevance judgements. To simplify the task, we presented the two entities side by side, with all the informa- tion which was available about them in the corpora (see Figure 5.1). The desktop entity is shown on the left, and the Web entity on the right. On the Web side we included hyperlinks to the related entities, for further exploration in case the information given was not sufficient for making the decision. For convenience, on the Web side, we have separated and brought to the top the triples which partially matched any of the values from the desktop side. There were only two decisions possible: Yes or No, with a Skip option, in case of un- certainty. Once a pair was judged or skipped, another one was shown to the participant. The pairs were randomly chosen from the remaining set. To add a gamification element to the experiment, we kept count of the number of pairs judged by each participant, and displayed it on the page. We found that even such a small addition generated ad-hoc competition and made the dull task more interesting.
Do these two URIs represent instances of the same real-world object/person? Figure 5.1: The Web interface of the experiment for collecting relevance judgements. To simplify the task, we presented the two entities side by side, with all the informa- tion which was available about them in the corpora (see Figure 5.1). The desktop entity is shown on the left, and the Web entity on the right. On the Web side we included hyperlinks to the related entities, for further exploration in case the information given was not sufficient for making the decision. For convenience, on the Web side, we have separated and brought to the top the triples which partially matched any of the values from the desktop side. There were only two decisions possible: Yes or No, with a Skip option, in case of un- certainty. Once a pair was judged or skipped, another one was shown to the participant. The pairs were randomly chosen from the remaining set. To add a gamification element to the experiment, we kept count of the number of pairs judged by each participant, and displayed it on the page. We found that even such a small addition generated ad-hoc competition and made the dull task more interesting.
Table 5.1: Inter-annotator agreement measures 18 Bridging the Gap between the Semantic Desktop and the Web of Data lower than the average, while for publications it is visibly higher. We believe the differ- ence is caused by the fact that the data about publications is generated and curated by experts in the field — even more so, as the publications were largely from the domain of Semantic Web — while the music data comes from much more heterogeneous sources.
Table 5.1: Inter-annotator agreement measures 18 Bridging the Gap between the Semantic Desktop and the Web of Data lower than the average, while for publications it is visibly higher. We believe the differ- ence is caused by the fact that the data about publications is generated and curated by experts in the field — even more so, as the publications were largely from the domain of Semantic Web — while the music data comes from much more heterogeneous sources.
Table 5.2: Evaluation results for albums, when varying configuration parameters.
Table 5.2: Evaluation results for albums, when varying configuration parameters.
Table 5.3: Evaluation results for people, when varying configuration parameters. he lowest performance on the albums corpus. This can be explained by the fact that he Web resources returned by the query module for albums are mostly e-commerce rroducts, which are not defined as a type of interest, and therefore are rejected by the natching module. However, some of the annotators have considered that the corre- ponding candidates are indeed the same as the album, while some have disagreed — his is reflected in the agreement measure, as for the albums we have the lowest value or Fleiss’s k. Whether or not such candidates should have been kept by the system is ypen to discussion and left for future work.
Table 5.3: Evaluation results for people, when varying configuration parameters. he lowest performance on the albums corpus. This can be explained by the fact that he Web resources returned by the query module for albums are mostly e-commerce rroducts, which are not defined as a type of interest, and therefore are rejected by the natching module. However, some of the annotators have considered that the corre- ponding candidates are indeed the same as the album, while some have disagreed — his is reflected in the agreement measure, as for the albums we have the lowest value or Fleiss’s k. Whether or not such candidates should have been kept by the system is ypen to discussion and left for future work.
Table 5.4: Evaluation results for publications, when varying configuration parameters does not get significant advantage and it seems that using SM prevails. In Table 5.3, we can observe that the baseline, the WP and the MVP parameters are each able to match good candidates with high precision at P@1, with WP providing slightly better MAP and NDCG. However, the system does not get significant advantage by combining them. The SM parameter alone provides slightly lower precision at P@1 but significantly better MAP and NDCG. By combining the three parameters, the system does not get significant advantage and it seems that using SM prevails. In Table 5.4, the baseline provides good results from the start for publications. The system is not able to return any candidates when MVP alone is activated. However, when WP and MVP are combined, the system achieves much better results (in term of MAP and NDCG) than the baseline or than the WP parameter alone. When the system combines SM with the two previous ones, the system achieves a lower MAP and NDCG but an improved precision with a larger cut-off rank. While on the two previous types of entities, the SM parameter seemed to be the most important matching feature, this corpus shows that the WP and MVP are important matching features in certain cases.
Table 5.4: Evaluation results for publications, when varying configuration parameters does not get significant advantage and it seems that using SM prevails. In Table 5.3, we can observe that the baseline, the WP and the MVP parameters are each able to match good candidates with high precision at P@1, with WP providing slightly better MAP and NDCG. However, the system does not get significant advantage by combining them. The SM parameter alone provides slightly lower precision at P@1 but significantly better MAP and NDCG. By combining the three parameters, the system does not get significant advantage and it seems that using SM prevails. In Table 5.4, the baseline provides good results from the start for publications. The system is not able to return any candidates when MVP alone is activated. However, when WP and MVP are combined, the system achieves much better results (in term of MAP and NDCG) than the baseline or than the WP parameter alone. When the system combines SM with the two previous ones, the system achieves a lower MAP and NDCG but an improved precision with a larger cut-off rank. While on the two previous types of entities, the SM parameter seemed to be the most important matching feature, this corpus shows that the WP and MVP are important matching features in certain cases.
Table 5.5: Time performance (milliseconds). To determine the performance, we measured the time spent on each step of the algorithm. We note that these results come from a prototype implementation, still to be subject to technical optimisations. Table 5.5 shows the average times overall, and for each resource type separately, when all three parameters (SM, WP, MVP) are active. We find only small variations in the measurements when the parameter values are changed. We do not consider the time spent on retrieving data from Sindice, as this depends on external factors, like network speed and server availability. factors, like network speed and server availability.
Table 5.5: Time performance (milliseconds). To determine the performance, we measured the time spent on each step of the algorithm. We note that these results come from a prototype implementation, still to be subject to technical optimisations. Table 5.5 shows the average times overall, and for each resource type separately, when all three parameters (SM, WP, MVP) are active. We find only small variations in the measurements when the parameter values are changed. We do not consider the time spent on retrieving data from Sindice, as this depends on external factors, like network speed and server availability. factors, like network speed and server availability.
Figure 5.2: Interpolated precision at recall cut-off points. 5.5.4 Performance
Figure 5.2: Interpolated precision at recall cut-off points. 5.5.4 Performance
Figure 6.1: Overview of the semantic publishing system. Transforming Semantic Notes into Semantic Blog Posts 6.4.1 Ontologies
Figure 6.1: Overview of the semantic publishing system. Transforming Semantic Notes into Semantic Blog Posts 6.4.1 Ontologies
Table 6.1: Sample of the mapping between classes. SIOC is probably the most widely used vocabulary for interlinking social media within the Web of Data. There are already many tools for creating and using SIOC data Bojars et al., 2008]. This is why we chose to represent the pimo:Notes as sioc:Posts when they are published online with our system. The rest of the desktop resources are also transformed into concepts from the vocabularies listed above (see Table 6.1), the mappings being published at http://rdfs.org/sioc/nepomuk. The note’s properties, like title, creation and last modification time, are translated to the appropriate Dublin
Table 6.1: Sample of the mapping between classes. SIOC is probably the most widely used vocabulary for interlinking social media within the Web of Data. There are already many tools for creating and using SIOC data Bojars et al., 2008]. This is why we chose to represent the pimo:Notes as sioc:Posts when they are published online with our system. The rest of the desktop resources are also transformed into concepts from the vocabularies listed above (see Table 6.1), the mappings being published at http://rdfs.org/sioc/nepomuk. The note’s properties, like title, creation and last modification time, are translated to the appropriate Dublin
Figure 7.1: User interface to keyphrase extraction in SemNotes. The text of personal notes can be small, thus adding difficulty to the extraction task. Schutz, 2008] details the way this challenge is tackled in the service. In SemNotes, the service can be called through the menu, and once the note is parsed the relevant terms found are presented to the user as tag suggestions. Figure 7.1, taken from [Schutz, 2008], shows a screenshot of the interface in an older version of SemNotes. If the user accepts any of the suggestions, they become tag resources and are stored in Nepomuk in the usual way.
Figure 7.1: User interface to keyphrase extraction in SemNotes. The text of personal notes can be small, thus adding difficulty to the extraction task. Schutz, 2008] details the way this challenge is tackled in the service. In SemNotes, the service can be called through the menu, and once the note is parsed the relevant terms found are presented to the user as tag suggestions. Figure 7.1, taken from [Schutz, 2008], shows a screenshot of the interface in an older version of SemNotes. If the user accepts any of the suggestions, they become tag resources and are stored in Nepomuk in the usual way.
presented. An important aspect of Konduit is directly tied to the fact that all inputs and out puts are RDF graphs. As a result, any workflow can itself become a component, meaning that workflows can be built recursively. In this way, it is possible to create specia 1sec components, which we call black boxes, based on the combination of other compo. nents. The blackboxes are added to the existing library for reuse. An examp saved workflows and blackboxes is shown in Figure 7.2. The workflow is taken € oOo Tor http://smile.deri.ie/konduit/discography, where an entire example use case i Se Leer | Figure 7.2: The entire discography generator workflow. http://smile.deri.ie/konduit/discography, where an entire example use case is
presented. An important aspect of Konduit is directly tied to the fact that all inputs and out puts are RDF graphs. As a result, any workflow can itself become a component, meaning that workflows can be built recursively. In this way, it is possible to create specia 1sec components, which we call black boxes, based on the combination of other compo. nents. The blackboxes are added to the existing library for reuse. An examp saved workflows and blackboxes is shown in Figure 7.2. The workflow is taken € oOo Tor http://smile.deri.ie/konduit/discography, where an entire example use case i Se Leer | Figure 7.2: The entire discography generator workflow. http://smile.deri.ie/konduit/discography, where an entire example use case is
SemNotes evaluation — Questionnaire
SemNotes evaluation — Questionnaire
Related topics:
Computer SciencePersonal Information ManagementLinked DataSemantic ComputingSemantic AnalyticsNote Taking
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved