diff options
| author | Sebastian Trueg <trueg@kde.org> | 2009-11-30 19:16:03 +0000 |
|---|---|---|
| committer | Sebastian Trueg <trueg@kde.org> | 2009-11-30 19:16:03 +0000 |
| commit | 97ed16d3dc30e537baf7a2984c8fff3535dfc32e (patch) | |
| tree | 287d99810798324d308cec50dde553f9e98ab69c | |
| parent | 12cec34c5c50eb50fe551b725eaa36d62f3b0239 (diff) | |
Moved the docs out of the ontologies tree for two reasons: 1. we do not use them yet and 2. I will add a svn:external to kdesupport and nobody wants to download the tons of MBs that are the docs.
65 files changed, 1 insertions, 31371 deletions
diff --git a/CMakeLists.txt b/CMakeLists.txt index 11081dc..b9946ad 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -7,7 +7,7 @@ project(shared-desktop-ontologies) # set the version to be used by SharedDesktopOntologiesConfig.cmake # =============================================================================================== set(SHAREDDESKTOPONTOLOGIES_VERSION_MAJOR 0) -set(SHAREDDESKTOPONTOLOGIES_VERSION_MINOR 2) +set(SHAREDDESKTOPONTOLOGIES_VERSION_MINOR 3) set(SHAREDDESKTOPONTOLOGIES_VERSION "${SHAREDDESKTOPONTOLOGIES_VERSION_MAJOR}.${SHAREDDESKTOPONTOLOGIES_VERSION_MINOR}") diff --git a/nao/doc/nao-header.html b/nao/doc/nao-header.html deleted file mode 100644 index d4694cc..0000000 --- a/nao/doc/nao-header.html +++ /dev/null @@ -1,3466 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html style="direction: ltr;" xmlns="http://www.w3.org/1999/xhtml" lang="en-us"> -<head> - - - - - - - - - - - - <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> - - - - - - - - - - - - <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" /> - - - - - - - - - - - - - - - - - - <title>NEPOMUK Annotation Ontology (NAO)</title> - <meta content="Simon Scerri" name="author" /> - - - - - - - - - - - - <meta content="Specifications for the NEPOMUK Annotation Ontology, including Graph Metadata Vocabulary" name="description" /> -</head> - - -<body> - - - - - - -<div class="head"> -<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img src="nepomuk1.png" /></a><a href="http://nepomuk.semanticdesktop.org/"><img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /></a></div> - - - - - - -<h1>NEPOMUK Annotation Ontology Specification</h1> - - - - - - -<big style="color: rgb(0, 90, 156);">Task-Force Ontologies</big> -<dl> - - - - - - - <dt>Latest Version:</dt> - - - - - - - <dd><a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nao">http://www.semanticdesktop.org/ontologies/nao</a></dd> - - - - - - - <dt></dt> - - - - - - - <dt>This Version:</dt> - - - - - - - <dd><a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nao">http://www.semanticdesktop.org/ontologies/2007/08/15/nao</a></dd> - - - - - - -</dl> - - - - - - -<dl> - - - - - - - <dt>Authors:</dt> - - - - - - - <dd>Simon Scerri, DERI/NUIG, <a href="mailto:simon.scerri@deri.org">simon.scerri@deri.org</a></dd> - - - - - - - <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd> - - - - - - - <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.uni-kl.de">elst@dfki.uni-kl.de</a></dd> - - - - - - - <dd>Siegfried Handschuh, DERI/NUIG, <a href="siegfried.handschuh@deri.org">siegfried.handschuh@deri.org</a></dd> - - - - - - -</dl> - - - - - - -<span style="font-weight: bold;">Editor:</span> <br /> - - - - - - -<div style="margin-left: 40px;">Simon Scerri, DERI/NUIG, <a href="mailto:simon.scerri@deri.org">simon.scerri@deri.org</a> -</div> - - - - - - -<dl> - - - - - - - <dt>Contributors:</dt> - - - - - - - <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd> - - - - - - - <dd>Max Völkel, FZI, <a href="mailto:voelkel@fzi.de">voelkel@fzi.de</a></dd> - - - - - - - <dd>Sebastian Trüg, EDGE-IT, <span class="wikiexternallink"><a href="mailto:strueg@mandriva.com">strueg@mandriva.com</a></span></dd> - - - - - - - <dd>Knud Möller, DERI/NUIG, <a href="mailto:knud.moeller@deri.org">knud.moeller@deri.org</a></dd> - - - - - - - <dd>Julien Gaugaz, L3S, <a href="mailto:gaugaz@l3s.de">gaugaz@l3s.de</a> </dd> - - - - - - - <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a> <br /> - - - - - - - </dd> - - - - - - -</dl> - - - - - - -<dl> - - - - - - - <dt><span style="font-weight: bold;">Ontology:</span></dt> - - - - - - - <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nao/nao_data.rdfs">NAO -(Data Graph Only)</a></dd> - - - - - - - <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nao/nao_metadata.rdfs">NAO -(Metadata Graph Only)</a></dd> - - - - - - - <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nao/nao.trig">NAO -(Graph Set)</a><span class="wikiexternallink"></span></dd> - - - - - - -</dl> - - - - - - -<dl> - - - - - - - <dd></dd> - - - - - - -</dl> - - - - - - -</div> - - - - - - -<p class="copyright"> Copyright © 2007 <a href="http://nepomuk.semanticdesktop.org/">NEPOMUK Consortium</a><sup>®</sup> -This work is made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a> -</p> - - - - - - -<hr /> -<h2><a class="mozTocH2" name="mozTocId474323"></a>Abstract</h2> - - - - - - -<p style="text-align: justify;">The annotation ontology -provides -vocabulary that enables users to attach custom descriptions, -identifiers, tags and ratings to resources on their desktop. Via other -properties, the user is also able to make generic relationships between -related resources explicit. Some relationships between resources are -too general to be included at the domain ontology level. Instead, these -properties are also defined in the annotation ontology. Given the -high-level status of this ontology, these propreties can be -used -to link any related resources on the user's desktop, as well -as -provide custom human-readable textual annotations.</p> - - - - - - -<h2><a class="mozTocH2" name="mozTocId596458"></a>Status -of this document</h2> - - - - - - -<div id="sotd"> -<p style="text-align: justify;"> This document arose from -the work of the Task-Force ontologies within the [<a href="http://nepomuk.semanticdesktop.org/">NEPOMUK Project</a>]. -It presents the specifications for the first version of the NAO -vocabulary. The ontology is still being tested, which means that the -ontology and this specification document are prone to -change. The -document itself is pending a review by the general NEPOMUK consortium, -upon which it might be promoted from a draft to an official form. -Subsequent versions of NAO might mean that the specification documents -of the later versions render this document obsolete, with respect to -the version of NAO in use, but not with respect to this version. </p> - - - - - - -</div> - - - - - - -<div class="toc"> -<h2 id="contents"><a class="mozTocH2" name="mozTocId577732"></a>Contents</h2> - - - - - - -</div> - - - - - - -<div> -<ul id="mozToc"> - - - - -<!--mozToc h2 1 h3 2 h4 3 h5 4--><li><a href="#mozTocId474323">Abstract</a></li> - - - - - <li><a href="#mozTocId596458">Status -of this document</a></li> - - - - - <li><a href="#mozTocId577732">Contents</a></li> - - - - - <li><a href="#mozTocId738538">1. Introduction</a></li> - - - - - <li><a href="#mozTocId127057">2. Generic -Annotation Vocabulary</a> - - - - - <ul> - - - - - <li><a href="#mozTocId775195">2.1. -Basic Annotation</a> - - - - - <ul> - - - - - <li><a href="#mozTocId991277">2.1.1. nao:annotation - - </a></li> - - - - - <li><a href="#mozTocId95916">2.1.2. rdfs:label - - </a></li> - - - - - <li><a href="#mozTocId231785">2.1.3. rdfs:comment - - </a></li> - - - - - <li><a href="#mozTocId827817">2.1.4. nao:hasSymbol - - </a></li> - - - - - <li><a href="#mozTocId309849">2.1.5. nao:rating - - </a></li> - - - - - <li><a href="#mozTocId802441">2.1.6. nao:identifier - - </a></li> - - - - - <li><a href="#mozTocId554293">2.1.7. nao:Symbol - - </a></li> - - - - - <li><a href="#mozTocId323566">2.1.8. nao:Tag - - </a></li> - - - - - <li><a href="#mozTocId540464">2.1.9. nao:Party - - </a></li> - - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId187157">2.2. More -Specific Annotation</a> - - - - - <ul> - - - - - <li><a href="#mozTocId17438">2.2.1. nao:isRelated - - </a></li> - - - - - <li><a href="#mozTocId953268">2.2.2. nao:hasTopic - - </a></li> - - - - - <li><a href="#mozTocId682683">2.2.3. nao:isTopicOf - - </a></li> - - - - - <li><a href="#mozTocId292538">2.2.4. nao:hasTag</a></li> - - - - - <li><a href="#mozTocId891981">2.2.5. -nao:isTagFor</a></li> - - - - - <li><a href="#mozTocId460510">2.2.6. nao:prefLabel - - </a></li> - - - - - <li><a href="#mozTocId337732">2.2.7. nao:altLabel - - </a></li> - - - - - <li><a href="#mozTocId418437">2.2.8. -nao:pluralPrefLabel - - </a></li> - - - - - <li><a href="#mozTocId541375">2.2.9. nao:prefSymbol - - </a></li> - - - - - <li><a href="#mozTocId27440">2.2.10. nao:altSymbol</a></li> - - - - - <li><a href="#mozTocId845316">2.2.11. -nao:description - - </a></li> - - - - - <li><a href="#mozTocId591601">2.2.12. -nao:personalIdentifier - - </a></li> - - - - - <li><a href="#mozTocId4771">2.2.13. -nao:numericRating</a></li> - - - - - <li><a href="#mozTocId430224">2.2.14. nao:creator</a></li> - - - - - <li><a href="#mozTocId321643">2.2.15. -nao:contributor</a></li> - - - - - <li><a href="#mozTocId287675">2.2.16. nao:modified</a></li> - - - - - <li><a href="#mozTocId288437">2.2.17. nao:created</a></li> - - - - - <li><a href="#mozTocId412121">2.2.18. -nao:lastModified</a></li> - - - - - <li><a href="#mozTocId601106">2.2.19. -nao:score</a></li> - - - - - <li><a href="#mozTocId105820">2.2.20. -nao:scoreParameter</a></li> - - - - - <li><a href="#mozTocId400559">2.2.21. -nao:FreeDesktopIcon</a></li> - - - - - <li><a href="#mozTocId232585">2.2.22. -nao:iconName</a></li> - - - - - <li><a href="#mozTocId880189">2.2.23. -nao:hasSubResource</a></li> - - - - - <li><a href="#mozTocId693750">2.2.24. -nao:hasSuperResource</a></li> - - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId620976">2.3. -Tagging as Annotation - - </a></li> - - - - - <li><a href="#mozTocId873837">2.4. -Generic Annotation Example</a></li> - - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId836701">3. Graph -Metadata Vocabulary</a> - - - - - <ul> - - - - - <li><a href="#mozTocId215877">3.1 -General Graph Metadata</a> - - - - - <ul> - - - - - <li><a href="#mozTocId925972">3.1.4. -nao:hasDefaultNamespace</a></li> - - - - - <li><a href="#mozTocId505129">3.1.5. -nao:hasDefaultNamespaceAbbreviation</a></li> - - - - - <li><a href="#mozTocId297228">3.1.6. -nao:engineeringTool - - </a></li> - - - - - <li><a href="#mozTocId652689">3.1.7. nao:version</a></li> - - - - - <li><a href="#mozTocId642918">3.1.8. nao:status</a></li> - - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId370287">3.2. Document -Graph Metadata</a> - - - - - <ul> - - - - - <li><a href="#mozTocId89753">3.3.1. -nao:serializationLanguage</a></li> - - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId785190">3.3. Graph -Metadata Example</a></li> - - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId760420">References</a></li> - - - - - <li><a href="#mozTocId78171">Appendix -A. NAO Vocabulary Summary - - </a> - - - - - <ul> - - - - - <li><a href="#mozTocId177728">A1: -Ontology Classes Description</a></li> - - - - - <li><a href="#mozTocId918756">A2: -Ontology Properties Description</a></li> - - - - - - - - - </ul> - - - - - </li> - - - - -</ul> - - - - - - -<hr style="width: 100%; height: 2px;" /> -<h1>NAO Vocabulary Specification</h1> - - - - - - -<p style="text-align: justify;">This document presents the -specifications for the NEPOMUK Annotation Ontology, a vocabulary for -resource annotation that is based on the NEPOMUK Representational -Language [<a href="#References">NRL SPECIFICATION</a>]. -The ontology is available for general and individual use and -is independent of the domain for which it was initially designed for, -namely the [<a href="http://nepomuk.semanticdesktop.org/">NEPOMUK -Social Semantic Desktop</a>] initiative. The -NEPOMUK in -the ontology name (NAO) has been -retained only for historic purposes. </p> - - - - - - -<p style="text-align: justify;">The document is -structured as follows. -Section 1 provides an insight of what we consider to be annotation -within the context of NRL and the social semantic desktop. Section 2 -introduces vocabulary for generic annotation, i.e. general annotation -of resources, with a particular emphasis on how conventional tagging -can also be represented using this ontology. Section 3 introduces -vocabulary that supports annotation for graphs, or graph metadata. -Given the important role that named graphs have in NRL, -annotation for graphs is also consideted part of this -ontology. Finallya summary of all the NAO -vocabulary elements is given in [ <a href="#Appendix_A._NAO_Vocabulary_Summary">Appendix A</a>]. -</p> - - - - - - -<h2><a class="mozTocH2" name="mozTocId738538"></a><a name="1._Introduction"></a>1. Introduction</h2> - - - - - - -<div style="text-align: justify;"> -<p>The meaning of the term annotation is highly contextual. -Depending -on the context, anything or nothing can be considered as annotation -within a data set (or named graph). On the social semantic -desktop, the average user is frequently seen creating representations -of objects on their desktop, while the more experienced user is also -frequently creating representations of concepts and their -relationships. Sharing and creating relationships between all -these resources across multiple desktops is what makes a user's desktop -social and semantic. Within this context, we consider annotation to be -anything that goes further than creating resources and -defining -their elementary relationships. A user can create an instance of a -'Person', and provide values for all the elementary properties that an -instance of 'Person' can have. The user can then go one step ahead and -annotate the resources with more information, of a textual (e.g. custom -human-readable descriptions) or non-textual (e.g. links to related -resources) -nature. In a typical scenario there may be a -number of domain-centric properties for the classes 'Person' (e.g. -name, address, knows etc.) and 'Document' (e.g. author, title etc.). -Via vocabulary in the annotation ontology the user can provide -personalized, user-friendly labels and descriptions for a resource, as -well as other things like tags and ratings. Generic -relationships may exist between resources across multiple domains, and -making these relationships explicit would be of great benefit for the -user. For example, a user wants to state that a -'Document' is about some instance of 'Person'. This relationship is too -general to be applied at the domain -ontology level, since such a relationship may exist between -other concepts in other domains e.g. between 'Conference' and -'Technology'. Vocabulary that is able to express these generic -relationships are therefore provided by the annotation -ontology. Although this information is optional and does not reflect -the elementary nature of a 'Document', it contributes to -improved -data unification and eases user search. </p> - - - - - - -<p style="text-align: justify;">We model annotation via -properties, rather than classes, since -we -believe that annotation is a relationship and not a concept. This was -also the idea for the rdfs:label and rdfs:comment properties in the -RDFS vocabulary, which we consider as textual annotation. These -properties are in fact included in our specifications, especially since -in the context of this ontology and that of the social semantic desktop -they have a slightly different meaning. Generic annotation is -represented at its highest level with the abstract nao:annotation -property. Although it is not meant to be used, it is the superproperty -of many other annotation properties in this ontology. Vocabulary for -generic annotation is introduced in <a href="#2._Generic_Annotation_Vocabulary">Section 2</a>.</p> - - - - - - -<p style="text-align: justify;">Graph Metadata is also a -form of annotation, where instead -of annotating general resources, one annotates Named -Graphs. Therefore graph metadata properties can be modelled -under the general annotation property <a href="#2.1.1._nao:annotation">nao:annotation</a>, -where the resource being annotated is a graph role (instance -of nrl:Data) and the annotations are provided via the graph metadata -properties. The major difference is -that while generic annotation can be stored within any graph the user -is working with (e.g. the graph where the annotated resource is -defined), -metadata about a graph should always be stored outside that -graph, -in a separate special named graph that is aptly represented in NRL -by <span style="background-color: rgb(255, 255, 255);">[<a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl.html#3.2.7._nrl:GraphMetadata">nrl:GraphMetadata</a>]. -Graph Metadat Vocabulary is introduced in <a href="#3._Graph_Metadata_Vocabulary">Section 3</a>. -</span></p> - - - - - - -</div> - - - - - - -<span style="background-color: rgb(255, 255, 0);"></span> -<h2 style="text-align: justify;"><a class="mozTocH2" name="mozTocId127057"></a><a name="2._Generic_Annotation_Vocabulary"></a>2. Generic -Annotation Vocabulary</h2> - - - - - - -<p style="text-align: justify;">In this section we -introduce vocabulary that serves generic annotation, i.e., -vocabulary that models general, common relationships between things. <a href="#2.1._Basic_Annotation">Section 2.1</a> presents -the basic annotation vocabulary. All other vocabulary in the annotation -ontology will require or derive from these basic terms. <a href="#2.2._More_Specific_Annotation">Section 2.2</a> -introduces richer annotation relationships that derive from the basic -annotation properties presented in Section 2.1. In <a href="#2.3._Tagging_as_Annotation">Section 2.3</a> we -discuss how we also model tagging as a form of annotation and finally -in <a href="#2.4._Generic_Annotation_Example">Section 2.4</a> -we present a concise example of how the vocabulary presented in this -section can be employed.<br /> - - - - - - -</p> - - - - - - -<h3><a class="mozTocH3" name="mozTocId775195"></a><a name="2.1._Basic_Annotation"></a>2.1. -Basic Annotation</h3> - - - - - - -<p style="text-align: justify;">The most basic annotation -property is nao:annotation, which simply defines a -descriptive -property for a resource. Given that an annotation's nature can be -textual or non-textual (i.e. semantic annotation pointing to -a resource), the range of this abstract high-level property is left -undefined. Specific subproperties -can have richer semantics (e.g. symmetric properties), but in order to -abstract over all annotation properties, no such semantics are defined -for <a href="#2.1.1._nao:annotation">nao:annotation</a>. </p> - - - - - - -<p style="text-align: justify;">rdfs:label and -rdfs:comment are also (indirectly) considered as part of our annotation -ontology, as they provide textual annotations for a resource. Although -we do not define them as being subproperties of -nao:annotation, we also include them in these specifications, in order -to define their meaning in the context of the social semantic -desktop. </p> - - - - - - -<p style="text-align: justify;">These and other annotation -properties and required classes are specified below. The annotation -properties defined in this section are also illustrated in <a href="#Fig_1">Fig.1</a>.<br /> - - - - - - -</p> - - - - - - -<div style="text-align: center;"><img src="basic.png" alt="basic" style="width: 425px; height: 173px;" /><br /> - - - - - - -<a name="Fig_1"></a> -Figure1. Basic annotation properties<br /> - - - - - - -</div> - - - - - - -<h4><a class="mozTocH4" name="mozTocId991277"></a><a name="2.1.1._nao:annotation"></a>2.1.1. nao:annotation<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">An abstract property -representing a -general annotation for a resource. Given its abstract nature -and its undefined range, this property is not meant to be used directly.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId95916"></a><a name="2.1.2._rdfs:label"></a>2.1.2. rdfs:label<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">We consider this RDFS -property as part of our annotation -ontology, since it provides a textual annotation which relates a -resource to -a literal. In the context of the social semantic desktop this property -provides technical labels for a resource, i.e, a -non-user -customizable label that is not meant to be seen by the user. -User-customizable labels are possible via the use of our own -sub-properties <a href="#2.2.6._nao:prefLabel">nao:prefLabel</a> -and <a href="#2.2.7._nao:altLabel">nao:altLabel</a>.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId231785"></a><a name="2.1.3._rdfs:comment"></a>2.1.3. rdfs:comment<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">This RDFS property is also -considered as part of our -annotation ontology, -since it provides a textual annotation which relates a resource to -a literal. -In the context of the social semantic desktop, this property -provides technical descriptions for a -resource. Non-technical, custom user descriptions can be -provided by our own subproperty, <a href="#2.2.11._nao:description">nao:description</a>.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId827817"></a><a name="2.1.4._nao:hasSymbol"></a>2.1.4. nao:hasSymbol<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">A resource can be -annotated with an instance of <a href="#2.1.7._nao:Symbol">nao:Symbol</a> -via -subproperties of this abstract property, <a href="#2.2.9._nao:prefSymbol">nao:prefSymbol</a> and <a href="#2.2.10._nao:altSymbol">nao:altSymbol</a>.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId309849"></a><a name="2.1.5._nao:rating"></a>2.1.5. nao:rating<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">Users can rate a resource -via subproperties of this property, -which is not meant to be used directly. Specific subproperties can -extend it and be used to rate resources, e.g. an audio file. -The range of this property is undefined. Numeric ratings can be -assigned via <a href="#2.2.13._nao:numericRating">nao:numericRating</a> -(maximum cardinality 1). -If other kinds of ratings are needed, this property can -arbitrarily and easily extend be extended (e.g. with a property that -has as range a class for which a number of instances can be enumerated).</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId802441"></a><a name="2.1.6._nao:identifier"></a>2.1.6. nao:identifier<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">This property enables -further types of identifiers for a -resource, apart from its standard URI. The property itself -is not meant to be directly used since it is an abstract property and -does not have a defined range. The annotation ontology -provides a subproperty for this property, <a href="#2.2.12._nao:personalIdentifier">nao:personalIdentifier</a>. - Although this property is not applied any form of -restriction, all its subproperties, including <a href="#2.2.12._nao:personalIdentifier">nao:personalIdentifier</a>, -are meant to be inverse functional. <span style="font-weight: bold;"></span></p> - - - - - - -<div style="text-align: center;"> -<div style="text-align: left;"> -<h4><a class="mozTocH4" name="mozTocId554293"></a><a name="2.1.7._nao:Symbol"></a>2.1.7. nao:Symbol<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">This -class represents a symbol, which can be an icon -or an image for example, that is used to annotate a resource. -Resources can be annotated with a standard graphical symbol via the -subproperties of <a href="#2.1.4._nao:hasSymbol">nao:hasSymbol</a>, <a href="#2.2.9._nao:prefSymbol">nao:prefSymbol</a> and <a href="#2.2.10._nao:altSymbol">nao:altSymbol</a>. Any -such graphical symbol that is in this way used to annotate a resource -automatically becomes an instance of this class.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId323566"></a><a name="2.1.8._nao:Tag"></a>2.1.8. <span style="background-color: rgb(255, 255, 0);"></span>nao:Tag<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">This class is useful for -modelling conventional tagging practices. The user can tag resources in -conventional ways, automatically creating an instance of this tag, -which is then related to the annotated resource via the <a href="#2.2.4._nao:hasTag">nao:hasTag</a> property. For -more on tagging as annotation see <a href="#2.3._Tagging_as_Annotation">Section 2.3</a>.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId540464"></a><a name="2.1.9._nao:Party"></a>2.1.9. nao:Party<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;"><span style="background-color: rgb(255, 255, 255);">Annotations -are provided by an individual or a group of individuals. Some -annotations are contained in a separate named graph whose role is to -provide annotations about another named graph (e.g. graph metadata for -a graph, See <a href="#3._Graph_Metadata_Vocabulary">Graph -Metadata Vocabulary</a>). In such cases it is useful to -state the contributor(s) for the set of annotations. This -class -is provided to represent a party who created such a set of annotations, -where a party can be either one individual or a group of individuals -(e.g. an organization). Once a user or an group provides these -annotations, they automatically become an instance of this -class. </span></p> - - - - - - -</div> - - - - - - -</div> - - - - - - -<h3><a class="mozTocH3" name="mozTocId187157"></a><a name="2.2._More_Specific_Annotation"></a>2.2. More -Specific Annotation</h3> - - - - - - -<p style="text-align: justify;">The Annotation Ontology -provides more specific vocabulary that -extends the description power of the basic annotation vocabulary -presented in -the previous section. Vocabulary in this category consists -solely of properties which extend properties given in <a href="#2.1._Basic_Annotation">Section 2.1</a>. An -overview of these properties is illustrated in <a href="#Fig_2">Fig.2</a>. The -specifications for this vocabulary are given below. </p> - - - - - - -<span style="font-weight: bold;"></span> -<div style="text-align: center;"><img style="width: 664px; height: 271px;" alt="lower level properties" src="lowerLevel.png" /><br /> - - - - - - -<a name="Fig_2"></a> -Figure 2. More specific annotation properties<br /> - - - - - - -</div> - - - - - - -<h4><a class="mozTocH4" name="mozTocId17438"></a><a name="2.2.1._nao:isRelated"></a>2.2.1. nao:isRelated<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">This property defines a -symmetric relation between any two resources. A subproperty of -<a href="#2.1.1._nao:annotation">nao:annotation</a>, -one can use this property to annotate a resource with pointers -to related resources. For example, a blog entry for an event -may -be linked to an image of the same event via this property. In -order for this property to be used legally, the relationship must be -symmetric. </p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId953268"></a><a name="2.2.2._nao:hasTopic"></a>2.2.2. nao:hasTopic<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">A subproperty of <a href="#2.2.1._nao:isRelated">nao:isRelated</a>, -this property does not inherit its symmetric nature. It further defines -the relationship given by its superproperty, stating that a resource is -about some concept. Instead, this vocabulary provides an inverse -property for this property, <a href="#2.2.3._nao:isTopicOf">nao:isTopicOf</a>.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId682683"></a><a name="2.2.3._nao:isTopicOf"></a>2.2.3. nao:isTopicOf<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">This property is also a -subproperty of <a href="#2.2.1._nao:isRelated">nao:isRelated</a> -and is the inverse property of <a href="#2.2.2._nao:hasTopic">nao:hasTopic</a>. -It is used to create a relationship between two resources, where the -subject resource is said to be the topic of the object. It is -not -a symmetric property.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId292538"></a><a name="2.2.4._nao:hasTag"></a>2.2.4. nao:hasTag</h4> - - - - - - -<p style="text-align: justify;">Used to model conventional -tagging practices, this property annotates a resource with a tag, -represented by an instance of <a href="#2.1.8._nao:Tag">nao:Tag</a>. -For -more on tagging as annotation see <a href="#2.3._Tagging_as_Annotation">Section 2.3</a>.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId891981"></a><a name="2.2.5._nao:isTagFor"></a>2.2.5. -nao:isTagFor</h4> - - - - - - -<p style="text-align: justify;">This property is the -inverse of <a href="#2.2.4._nao:hasTag">nao:hasTag</a>. -It links an instance of <a href="#2.1.8._nao:Tag">nao:Tag</a> -to resources that are tagged with it. For more on tagging as annotation -see <a href="#2.3._Tagging_as_Annotation">Section 2.3</a>.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId460510"></a><a name="2.2.6._nao:prefLabel"></a>2.2.6. nao:prefLabel<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">This property is one of -two provided by this ontology to handle -custom user labels. Alternative -labels can be provided via <a href="#2.2.7._nao:altLabel">nao:altLabel</a>. -Both properties are subproperties of <a href="#2.1.2._rdfs:label">rdfs:labe</a>l -and expect a -literal as value. Given that the domain of this property is -rdfs:Resource, it is not applied -any cardinality restrictions. Where required, such -properties -can be defined by extending this property via appropriate -subproperties. However, it is intended that at most one -value per (natural) language is defined via this property and -that at most one literal without any -defined language exists. Other usages, although legal, are considered -invalid NAO data and are strongly discouraged as -they may generate errors.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId337732"></a><a name="2.2.7._nao:altLabel"></a>2.2.7. nao:altLabel<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">Via this property a user -can provide further custom labels for -resources on their desktop, alongside the required, unique value given -by <a href="#2.2.6._nao:prefLabel">nao:prefLabel</a>. Both -properties are subproperties of <a href="#2.1.2._rdfs:label">rdfs:labe</a>l -and expect a literal as value.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId418437"></a><a name="2.2.8._nao:pluralPrefLabel"></a>2.2.8. -nao:pluralPrefLabel<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">This property supplements <a href="#2.2.6._nao:prefLabel">nao:prefLabel</a> -to provide plural forms for custom user resource labels. In particular -it is useful to refer to multiple instances of a calss. It is also a -subproperty of <a href="#2.1.2._rdfs:label">rdfs:labe</a>l -and expects a -literal as value. No cardinality restrictions are -imposed. -</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId541375"></a><a name="2.2.9._nao:prefSymbol"></a>2.2.9. nao:prefSymbol<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">A subproperty of <a href="#2.1.4._nao:hasSymbol">nao:hasSymbol</a>, this -property specifies a preferred symbol for resource annotation, given by -an instance of <a href="#2.1.7._nao:Symbol">nao:Symbol</a>. -Resources can be -annotated with alternative symbols via nao:altSymbol. </p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId27440"></a><a name="2.2.10._nao:altSymbol"></a>2.2.10. nao:altSymbol</h4> - - - - - - -<p style="text-align: justify;">This property is used to -annotate a resource with alternative symbols, given by instances -of <a href="#2.1.7._nao:Symbol">nao:Symbol</a>, -alongside the preferred symbol that is linked via <a href="#2.2.9._nao:prefSymbol">nao:prefSymbol</a>. It -is a subproperty of <a href="#2.1.4._nao:hasSymbol">nao:hasSymbol</a>.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId845316"></a><a name="2.2.11._nao:description"></a>2.2.11. -nao:description<br /> - - - - - - -</h4> - - - - - - -<p style="text-align: justify;">A subproperty of <a href="#2.1.3._rdfs:comment">rdfs:comment</a>, the -purpose of this property is similar to <a href="#2.2.6._nao:prefLabel">nao:prefLabel</a> and <a href="#2.2.7._nao:altLabel">nao:altLabel</a>. However -this property is also a subproperty of <a href="#2.1.1._nao:annotation">nao:annotation</a>. -Whereas -in the context of the social semantic desktop the textual annotation -provided via <a href="#2.1.3._rdfs:comment">rdfs:comment</a> -is meant for technical users, the textual annotation here -is aimed -at average users and is meant to be used to define custom descriptions -of resources on their desktop. The maximum cardinality is 1, and the -property expects a literal value.<br /> - - - - - - -</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId591601"></a><a name="2.2.12._nao:personalIdentifier"></a>2.2.12. -nao:personalIdentifier<br /> - - - - - - -</h4> - - - - - - -<p>This property should be used to provide alternative values -that identify a -resource -alongside the default URI. A subproperty of the abstract <a href="#2.1.6._nao:identifier">nao:identifier</a>, -the range of this property is a literal. The property is inverse -functional, which effectively means that personal identifiers for -resources should be unique, and two resources cannot have the same -personal identifier.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId4771"></a><a name="2.2.13._nao:numericRating"></a>2.2.13. -nao:numericRating</h4> - - - - - - -<p>This property extends <a href="#2.1.5._nao:rating">nao:rating</a>, -to restrict the range to an XSD float datatype. Values must be between -'1' and '10' whereas a value of '0' is interpreted as not -set. Furthermore, -resources can only be given at most one numeric rating, thus the -maximum cardinality is 1. </p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId430224"></a><a name="2.2.14._nao:creator"></a>2.2.14. nao:creator</h4> - - - - - - -<div style="text-align: justify;"> -<p>Via this property the creator/s of a resource can be -specified graph. The creator -can be a an individual or a group as represented by an instance of the -<a href="#2.1.9._nao:Party">nao:Party</a> -class. </p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId321643"></a><a name="2.2.15._nao:contributor"></a>2.2.15. -nao:contributor</h4> - - - - - - -<p>This property -refers to additional contributors for a resource and is -otherwise similar to <a href="#2.2.14._nao:creator">nao:creator</a>.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId287675"></a><a name="2.2.16._nao:modified"></a>2.2.16. nao:modified</h4> - - - - - - -<p>Represents the modification date/time [<a href="http://www.w3.org/TR/xmlschema-2/#dateTime">xsd:dateTime</a>] -for a resource. More of an abstract class, its subproperties <a href="#2.2.17._nao:created">nao:created</a> and <a href="#2.2.18._nao:lastModified">nao:lastModified</a> -prove to be more useful.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId288437"></a><a name="2.2.17._nao:created"></a>2.2.17. nao:created</h4> - - - - - - -<p>Via this property the creation date/time for a resource can be -defined. A subproperty of nao:modified, the expected value is of -type [<a href="http://www.w3.org/TR/xmlschema-2/#dateTime">xsd:dateTime</a>] -and a typical value is of the form -"2007-08-15T23:59:55.329Z". The maximum cardinality for this property -is set to 1.</p> - - - - - - -</div> - - - - - - -<h4><a class="mozTocH4" name="mozTocId412121"></a><a name="2.2.18._nao:lastModified"></a>2.2.18. -nao:lastModified</h4> - - - - - - -<div style="text-align: justify;"> -<p>This property defines the date/time when a resource was most -recently modified. It is a subproperty of <a href="#2.2.16._nao:modified">nao:modified</a>. The -maximum cardinality -for this property is also set to 1.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId601106"></a><a name="2.2.19._nao:score"></a>2.2.19. -nao:score</h4> - - - - - - -<div style="text-align: justify;"> - - -<p>This property refers to an authorative score for an item -(resource), valued between [0, 1]. A score is a weight of a -resource compared to all other resources, and it is computed via a -mathematical combination of score -parameters e.g. nao:numericRating, -nao:lastModified as well external parameters. For this purpose, -parameters -that go into the score need to be marked as being sub-properties of <a href="#2.2.20._nao:scoreParameter">nao:scoreParameter</a>. Allowed values -for this property are of the [<a href="http://www.w3.org/TR/xmlschema-2/#float">xsd:float</a>] -datatype.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId105820"></a><a name="2.2.20._nao:scoreParameter"></a>2.2.20. -nao:scoreParameter</h4> - - - - - - -<p>Multiple score parameters -(e.g. nao:numericRating, -nao:lastModified) can be input to a mathematical -algorithm that -computes an overall <a href="#2.2.19._nao:score">nao:score</a> -for a resource. The score parameters in question need to be -defined as a subproperty of this property - thus effectively -nao:scoreParamter is a marker property. Ranking algorithms -will compute the values of multiple subproperties of scoreParameter and -then compute the nao:score based on a mathematical combination of score -parameters. The allowed range is a float number. The exact algorithm is -open to implementations. Allowed values for this property are -of the [<a href="http://www.w3.org/TR/xmlschema-2/#float">xsd:float</a>] -datatype.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId400559"></a><a name="2.2.21._nao:FreeDesktopIcon"></a>2.2.21. -nao:FreeDesktopIcon</h4> - - - - - - -<p>This class represents a desktop icon as defined -in the <a href="http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">FreeDesktop -Icon Naming standard</a> and it is a subclass of <a href="#2.1.7._nao:Symbol">nao:Symbol</a>. <a href="#2.2.22._nao:iconName">nao:iconName</a> is a -required property referring to the name of the icon.</p> - - - - - - -<h4><a class="mozTocH4" name="mozTocId232585"></a><a name="2.2.22._nao:iconName"></a>2.2.22. -nao:iconName</h4> - - - - - - -<p>Values of this property contain the FreeDesktop standard icon -name (literal) as -defined in the <a href="http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">FreeDesktop -Naming Specification</a>. The use of the property is required for -every instance of <a href="#2.2.21._nao:FreeDesktopIcon">nao:FreeDesktopIcon</a> -since its minimum cardinality is set to 1.</p> - - - - -<h4><a class="mozTocH4" name="mozTocId880189"></a><a name="2.2.23._nao:hasSubResource"></a>2.2.23. -nao:hasSubResource</h4> - - - - - - -<p>This property defines a super-sub relationship between two instances -of rdfs:Resource - whereby one resource can be treated as dependent on -another. Thus if a resource is deleted or removed from a system, all -its subresources can also be automatically removed, unless they have -other superresources still existant on the system. This property is the -inverse property of <a href="#2.2.24._nao:hasSuperResource">nao:hasSuperResource</a>. This property is transitive in nature. -</p> - - - - -<h4><a class="mozTocH4" name="mozTocId693750"></a><a name="2.2.24._nao:hasSuperResource"></a>2.2.24. -nao:hasSuperResource</h4> - - - - - - -<p>This property is the inverse of <a href="#2.2.23._nao:hasSubResource">nao:hasSubResource</a>. -It defines a dependency relationship between two resources such that, -when the superresource is removed from a system, the defined -subresources should also be removed unless they are also subresources -of other remaining superresources. This property is transitive in -nature.<span style="text-decoration: underline;"></span><br /> - - - - -</p> - - - - -<p> - -</p> - - - - - - -</div> - - - - - - -</div> - - - - - - -<h3><a class="mozTocH3" name="mozTocId620976"></a><a name="2.3._Tagging_as_Annotation"></a>2.3. -Tagging as Annotation<br /> - - - - - - -</h3> - - - - - - -<p style="text-align: justify;">Given tagging is a popular -Web 2.0 -concept which we want to adopt and retain in our semantic approach to -data modelling, in this section we provide an example of how semantic -tagging can be performed using our annotation ontology. <a href="#Fig_3">Fig.3</a> shows how -nao:Tag can -be used as a special case of the nao:annotation relation given in -<a href="#Fig_2">Fig.2</a>. The unique -default name given by the user when creating a -tag is defined by <a href="#2.2.6._nao:prefLabel">nao:prefLabel</a>. -Other custom names for the tag can be defined using <a href="#2.2.7._nao:altLabel">nao:altLabel</a> while a -custom user description can be provided via <a href="#2.2.11._nao:description">nao:description</a>. A -custom default icon or image can be attached to the tag via <a href="#2.2.9._nao:prefSymbol">nao:prefSymbol</a>, -making the icon in question an instance of <a href="#2.1.7._nao:Symbol">nao:Symbol</a>. -This icon, like any other resource, can also be annotated. The newly -created tag is then linked to the resource being tagged (or annotated) -via <a href="#2.2.4._nao:hasTag">nao:hasTag</a>. An -automatic inverse relationship is created to link the new tag with the -resource via <a href="#2.2.5._nao:isTagFor">nao:isTagFor</a>.<br /> - - - - - - -</p> - - - - - - -<div style="text-align: center;"><img style="width: 533px; height: 174px;" alt="tag class" src="tagClass.png" /><br /> - - - - - - -<a name="Fig_3"></a> -Figure 3. Modelling conventional tagging<span style="font-weight: bold;"></span></div> - - - - - - -<br /> - - - - - - -<h3><a class="mozTocH3" name="mozTocId873837"></a><a name="2.4._Generic_Annotation_Example"></a>2.4. -Generic Annotation Example</h3> - - - - - - -<div style="text-align: justify;"> -<p>A person wants to annotate a file of type -image/photo on their personal desktop. The photo depicts a friend, -Claudia, drinking coffee in the -SAP offices. The user states that the photo 'is related' (via -nao:isRelated - a symmetric property) to the following resources:</p> - - - - - - -<ul> - - - - - - - <li>[1] a resource representing Claudia on the user's desktop -(ex:Claudia) </li> - - - - - - - <li>[2] a resource representing the organisation SAP on the -user's desktop (ex:SAP)</li> - - - - - - -</ul> - - - - - - -Furthermore, the user states that the photo 'is about' (via -nao:hasTopic) the following resources: -<ul> - - - - - - - <li>[3] a concept from a Work ontology defining a colleague at -work (work:Colleague)</li> - - - - - - - <li>[4] a concept from a Work ontology defining a -working office (work:Office)</li> - - - - - - -</ul> - - - - - - -[5] The user defines a custom personal identifier for the photo, -'ClaudiaOffice20070815'.<br /> - - - - - - -[6] Finally, the user also tags the photo with an instance of nao:Tag -they create:<br /> - - - - - - -<ul> - - - - - - - <li>[7],[8] The user labels the new tag 'Work', with the -alternative labels 'SAP' and 'WorkPlace'.</li> - - - - - - - <li>[9],[10] The user also selects an icon for the new tag that -they -find on their desktop, and creates a custom description for the new tag.</li> - - - - - - -</ul> - - - - - - -<p>The resulting statements are generated and stored -within a -named graph 'ex:i1'. Apart from the obvious statements, -note the -following automatically generated statements </p> - - - - - - -<ul> - - - - - - - <li>[11] Since nao:hasTag has the inverse property -nao:isTagFor, the -newly generated tag is also related to the tagged resource via this -inverse property.<br /> - - - - - - - </li> - - - - - - - <li>[12] The icon used as a symbol for the tag (ex:WorkIcon) is -now also an instance of nao:Symbol.</li> - - - - - - - <li>Since nao:isRelated is symmetric the resources related to -the -photo via this property (ex:SAP and ex:Claudia) are themselves defined -as related to the photo.</li> - - - - - - -</ul> - - - - - - -<p> </p> - - - - - - -</div> - - - - - - -<br /> - - - - - - -<table style="text-align: left; font-family: monospace; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - - - <tbody> - - - - - - - <tr> - - - - - - - <td><span style="font-family: monospace;"> - ex:i1 {</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[1] ex:DSCF001 </span><span style="font-family: monospace;">nao:isRelated ex:Claudia ,</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[2] - - - - - ex:SAP ;</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[3] - - nao:hasTopic work:Colleague ,</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[4] - - - - work:Office ;<br /> - - - - - - - </span><span style="font-family: monospace;">[5] - - nao:personalIdentifier "ClaudiaOffice20070815" ;</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[6] - nao:hasTag -ex:Work .</span><br style="font-family: monospace;" /> - - - - - - - <br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;"> - -ex:Work a nao:Tag ;</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[7] - - nao:prefLabel "Work" ;</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[8] - nao:altLabel -"WorkPlace" ,</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;"> - - - "SAP" ;</span><span style="font-family: monospace;"><br /> - - - - - - -[9] - </span><span style="font-family: monospace;">nao:hasSymbol ex:WorkIcon ;</span><span style="font-family: monospace;"> </span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[10] - </span><span style="font-family: monospace;"></span><span style="font-family: monospace;">nao:description "Represents -all about my work, workplace, workmates -etc" ;</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[11] - nao:isTagFor ex:DSCF001 .</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;"> - </span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[12] -ex:WorkIcon a nao:Symbol . </span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;"> - </span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[13] ex:SAP -nao:isRelated ex:DSCF001 .</span><br style="font-family: monospace;" /> - - - - - - - <br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[14] -ex:Claudia nao:isRelated ex:DSCF001 . }</span> </td> - - - - - - - </tr> - - - - - - - - - - - - </tbody> -</table> - - - - - - -<br /> - - - - - - -<h2><a class="mozTocH2" name="mozTocId836701"></a><a name="3._Graph_Metadata_Vocabulary"></a>3. Graph -Metadata Vocabulary</h2> - - - - - - -<div style="text-align: center;"> -<div style="text-align: justify;"> -<p>In this section we -provide the -description and specifications for the subpart of the annotation -ontology dealing with Graph Metadata. Graph metadata -is a form of annotation where the subject of the annotations -are -named graphs, as specified in [<a href="#References">NRL -SPECIFICATION</a>]. -Given the important and central role that named graphs have in the NRL -concept, this graph metadata, or graph annotation, vocabulary is -considered to be part of the -annotation ontology, and the properties are subproperties -of nao:annotation. </p> - - - - - - -<p>NRL already provides vocabulary -that is -used to define essential graph metadata [See <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl.html#3.2._Graph_Roles_Vocabulary">Graph -Roles Vocabulary</a>], -including graph role speficiation and whether the graph is a document -graph (see <a href="#Fig_4">Fig.4.</a>), whether -a graph is updatable or otherwise (via <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl/#mozTocId379929">nrl:updatable</a>) -and specification of the declarative -semantics for a graph (via <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl/#mozTocId737534">nrl:hasSemantics</a>).</p> - - - - - - -<p>Generic annotation vocabulary given in this ontology is also -applicable to named graphs (which are in fact special cases of a -resource). In particular, <a href="#2.2.14._nao:creator">nao:creator</a>, -<a href="#2.2.15._nao:contributor">nao:contributor</a>, -<a href="#2.2.17._nao:created">nao:created </a>and <a href="#2.2.18._nao:lastModified">nao:lastModified</a> -are of special relevance when it comes to providing metadata for a -named graph. The vocabulary provided in this section enables additional -graph annotations to those provided by NRL and by the NAO generic -annotation vocabulary. An example that makes full use of all the -relevant vocabulary is given in <a href="#3.3._Graph_Metadata_Example">Section 3.3</a>.<br /> - - - - - - -</p> - - - - - - -<p> -In -contrast to vocabularies like the Ontology Metadata Vocabulary [<a href="#References">OMV REPORT</a>], -which was a major source of inspiration for this vocabulary, our -vocabulary -is applicable to all Graph Roles as defined in NRL (<a href="#Fig_4">Fig.4.</a>), -and not -just ontologies. The majority of graph metadata properties thus have -nrl:Data as their domain. Other properties apply specifically -to nrl:DocumentGraph (documents that encode -named graphs). <span style="background-color: rgb(255, 255, 255);"></span></p> - - - - - - -<span style="background-color: rgb(255, 255, 255);"></span></div> - - - - - - -<div style="text-align: center;"><img style="width: 602px; height: 349px;" alt="roles" src="NamedGraphs.png" /><br /> - - - - - - -</div> - - - - - - -<div style="text-align: center;"><a name="Fig_4"></a> -Figure 4. Graph Roles Hierarchy</div> - - - - - - -<br /> - - - - - - -<div style="text-align: justify;"> -<p>While generic annotation -for a resource is usually stored within the graph where the resource is -defined, -metadata about a graph is stored outside that graph, in a -separate but associated metadata graph. <span style="background-color: rgb(255, 255, 255);">These special -graphs -are marked using the [<a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl.html#3.2.7._nrl:GraphMetadata">nrl:GraphMetadata</a>] -role, also shown in <a href="#Fig_4">Fig.4.</a> and -linked to their respective graphs via [<a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl.html#3.2.8._nrl:graphMetadataFor">nrl:graphMetadataFor</a>]. -The unique metadata graph that defines the non-subjective attributes -(graph role, semantics, -namespace, etc) for a graph is instead linked to that graph -via [<a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl.html#3.2.9._nrl:coreGraphMetadataFor">nrl:coreGraphMetadataFor</a>].</span></p> - - - - - - -</div> - - - - - - -<h3><a class="mozTocH3" name="mozTocId215877"></a><a name="3.1_General_Graph_Metadata_Vocabulary"></a>3.1 -General Graph Metadata</h3> - - - - - - -<div style="text-align: justify;"> -<p>The following vocabulary -applies to -all NRL Graph Roles. Although some of them appear to be -ontology-specific, -properties which apply to e.g. both -nrl:InstanceBase and nrl:Ontology are listed here, since their common -superclass is nrl:Data. Given that graph metadata is considered to be a -special case of annotation, most of the vocabulary consists of -subproperties of nao:annotation. These properties are depicted -in -<a href="#Fig_5">Fig.5.</a> and described -individually in the following subsections. -Although the use of none of these properties is compulsory, their use -is recommended as a best practice.</p> - - - - - - -</div> - - - - - - -<br /> - - - - - - -<div style="text-align: center;"><img style="width: 706px; height: 264px;" alt="Data Properties" src="DataProperties.png" /><br /> - - - - - - -<br /> - - - - - - -<a name="Fig_5"></a> -Figure 5. General Graph Metadata properties<br /> - - - - - - -</div> - - - - - - -<br /> - - - - - - -<h4><a class="mozTocH4" name="mozTocId925972"></a><a name="3.1.4._nao:hasDefaultNamespace"></a>3.1.4. -nao:hasDefaultNamespace</h4> - - - - - - -<div style="text-align: justify;">This property -explicitally defines the default namespace for a -named graph. The value for this property should therefore be a valid -URI ending with the '#' sign.<br /> - - - - - - -</div> - - - - - - -<h4><a class="mozTocH4" name="mozTocId505129"></a><a name="3.1.5._nao:hasDefaultNamespaceAbbreviation"></a>3.1.5. -nao:hasDefaultNamespaceAbbreviation</h4> - - - - - - -<div style="text-align: justify;">A default namespace -abbreviation for a named graph can be defined via the use of this -property. This prevents a scenario where different random -abbreviations are generated from different applications for the same -graph.<br /> - - - - - - -</div> - - - - - - -<h4><a class="mozTocH4" name="mozTocId297228"></a><a name="3.1.6._nao:engineeringTool"></a>3.1.6. -nao:engineeringTool<br /> - - - - - - -</h4> - - - - - - -<div style="text-align: justify;">Graphs that are -generated via a specific graph engineering tool can make use of this -property. -The value is a string stating the name of the editing tool.<br /> - - - - - - -</div> - - - - - - -<h4><a class="mozTocH4" name="mozTocId652689"></a><a name="3.1.7._nao:version"></a>3.1.7. nao:version</h4> - - - - - - -<div style="text-align: justify;">This property specifies -version -information for the graph role and is particularly useful -for tracking, -comparing and -merging data. Legal values for this property are of the [<a href="http://www.w3.org/TR/xmlschema-2/#float">xsd:float</a>] -datatype. A graph can have at most one version, hence the -maximum cardinality is 1. -</div> - - - - - - -<h4><a class="mozTocH4" name="mozTocId642918"></a><a name="3.1.8._nao:status"></a>3.1.8. nao:status</h4> - - - - - - -<div style="text-align: justify;">Tracking -information for the contents of a graph can be specified via this -property. Typical values, of type string, -include "Stable", "Unstable" and "Testing". -</div> - - - - - - -<br /> - - - - - - -<h3><a class="mozTocH3" name="mozTocId370287"></a><a name="3.2._Document_Graph_Metadata"></a>3.2. Document -Graph Metadata</h3> - - - - - - -<div style="text-align: justify;"> -A special class in the NRL specifications, [<a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl.html#3.1.2._nrl:DocumentGraph">nrl:DocumentGraph</a>], -is defined to mark graphs that are completely represented within a -document which can be accessed via a URL, which effectively also -becomes the name of the graph. The following property, also shown in -<a href="Fig_6">Fig.6.</a>, applies only to -instances of such graphs.<br /> - - - - - - -</div> - - - - - - -<br /> - - - - - - -<div style="text-align: center;"><img style="width: 476px; height: 84px;" alt="Document Graph" src="DocumentGraph.png" /><br /> - - - - - - -<a name="Fig_6"></a> -Figure 6. Graph Metadata for Graphs encoded in documents<br /> - - - - - - -</div> - - - - - - -<h4><a class="mozTocH4" name="mozTocId89753"></a><a name="3.3.1._nao:serializationLanguage"></a>3.3.1. -nao:serializationLanguage</h4> - - - - - - -<div style="text-align: justify;"> -This property states the graph serialization -language for the document, e.g. XML/RDFS, RDFS/N3, TriG etc.<br /> - - - - - - -</div> - - - - - - -<br /> - - - - - - -<h3><a class="mozTocH2" name="mozTocId785190"></a><a name="3.3._Graph_Metadata_Example"></a>3.3. Graph -Metadata Example</h3> - - - - - - -<div style="text-align: justify;"> -<p>The following example demonstrates the use and best practice -for the Graph Metadata Vocabulary given in this section.</p> - - - - - - -</div> - - - - - - -<div style="text-align: justify;">[1] In this example we -assume that a named graph with the role of an ontology exists and is -given by ex:o1.<br /> - - - - - - -[2] Graph metadata for this ontology is provided by the metadata graph -ex:o1_metadata. This graph consists of annotations for the -ontology stored in graph ex:o1. These annotations are defined using the -graph metadata vocabulary specified in this document. <br /> - - - - - - -[3],[4] The metadata graph includes first and foremost a description -about itself, stating that it is indeed a named graph with a -nrl:GraphMetadata role. It is further stated that this is the core -graph -metadata that defines the core properties for the graph -ex:o1, via <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl.html#3.2.9._nrl:coreGraphMetadataFor">nrl:coreGraphMetadataFor</a>.<br /> - - - - - - -[5] Metadata for the actual graph being described is then provided. -This metadata includes the following:<br /> - - - - - - -<ul> - - - - - - - <li>[6] The creator of the ontology is defined to be ex:SAP, -with two -separate contributors being ex:Dirk and ex:Claudia. This automatically -generates the statement <span style="background-color: rgb(255, 255, 255);">(usually not -within this -graph)</span> that ex:SAP, ex:Dirk -and ex:Claudia are annotators and therefore instances of nao:Party.</li> - - - - - - - <li>[7] The ontology is defined to be 'Stable' at version 1.2. -The last modified time is also represented.</li> - - - - - - - <li>[8] A static, standard namespace and namespace -abbreviation are defined.</li> - - - - - - - <li>[9] The graph is said to be non-updatable, meaning that if -the -ontology needs to be changed, a new version needs to be generated while -leaving the original unchanged. See <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl.html#3.2.14._nrl:updatable">nrl:updatable</a>.</li> - - - - - - -</ul> - - - - - - -</div> - - - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - - - <tbody> - - - - - - - <tr> - - - - - - - <td><span style="font-family: monospace;">[1] </span><span style="font-family: monospace;">ex:o1 {<br /> - - - - - - - # Work Ontology -provided in this named graph<br /> - - - - - - - </span><span style="font-family: monospace;"> - </span><span style="font-family: monospace;"> }<br /> - - - - - - - <br /> - - - - - - - </span><span style="font-family: monospace;">[2] -ex:o1/metadata { </span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[3] - </span><span style="font-family: monospace;">ex:o1/metadata -a nrl:GraphMetadata ;<br /> - - - - - - -[4] - nrl:coreGraphMetadataFor -ex:o1 .</span><span style="font-family: monospace;"> } </span><span style="font-family: monospace;"> <br /> - - - - - - - <br /> - - - - - - -[5] </span><span style="font-family: monospace;">ex:o1 a -nrl:Ontology ;</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;">[6] - - nao:creator -ex:SAP ;<br /> - - - - - - - - nao:contributor ex:Dirk ,<br /> - - - - - - - - - ex:Claudia ;<br /> - - - - - - - </span><span style="font-family: monospace;">[7] - nao:version "1.2" ;</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;"></span><span style="font-family: monospace;"> - - nao:lastModified "2007-08-15T23:59:55.329Z" .<br /> - - - - - - - </span><span style="font-family: monospace;"> - nao:status "Stable" ;<br /> - - - - - - - </span><span style="font-family: monospace;">[8] - -nao:hasNamespace "http://www.example.org/ontologies/work#" ;</span><br style="font-family: monospace;" /> - - - - - - - <span style="font-family: monospace;"> - nao:hasNamespaceAbbreviation "work" ;<br /> - - - - - - - </span><span style="font-family: monospace;">[9] - nrl:updatable "0" . }<br /> - - - - - - - </span><span style="font-family: monospace;"></span><span style="font-family: monospace;"><br /> - - - - - - - </span></td> - - - - - - - </tr> - - - - - - - - - - - - </tbody> -</table> - - - - - - -</div> - - - - - - -<h2><a class="mozTocH2" name="mozTocId760420"></a><a name="References"></a>References</h2> - - - - - - -<dl> - - - - - - - <dt>[NRL SPECIFICATIONS]</dt> - - - - - - - <dd><a href="http://www.semanticdesktop.org/ontologies/nrl">NEPOMUK Representation -Language (NRL) Vocabulary Specification</a><cite></cite>.</dd> - - - - - - - <dd>NEPOMUK., Task-Force Ontologies.</dd> - - - - - - - <dd><small style="font-family: monospace;"><a href="http://www.semanticdesktop.org/ontologies/nrl">http://www.semanticdesktop.org/ontologies/nrl</a>.</small></dd> - - - - - - -</dl> - - - - - - -<span style="font-weight: bold;">[OMV Report] -<br /> - - - - - - -</span> -<div style="margin-left: 40px;"><a href="http://ontoware.org/projects/omv/">Ontology Metadata -Vocabulary for the Semantic. Web</a>. Jens Hartmann (University -of Karlsruhe), Raul Palma (Universidad Politecnica de Madrid) and Elena -Paslaru Bontas (Free University of Berlin).<small style="font-family: monospace;"><br /> - - - - - - -<a href="http://ontoware.org/projects/omv/">http://ontoware.org/projects/omv/</a>.</small><br /> - - - - - - -<small style="font-family: monospace;"> -</small></div> - - - - - - -<dl> - - - - - - -</dl> - - - - - - -</div> diff --git a/ncal/doc/ncal-header.html b/ncal/doc/ncal-header.html deleted file mode 100644 index 9206afa..0000000 --- a/ncal/doc/ncal-header.html +++ /dev/null @@ -1,1140 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
- <title>Nepomuk Calendar Ontology (NCAL)</title>
-
-
-</head>
-
-
-<body>
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
-
-<h1>NEPOMUK Calendar Ontology</h1>
-
-<big style="color: rgb(0, 90, 156);">Task-Force Ontologies</big>
-<dl>
-
- <dt></dt>
-
- <dt>Latest Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/ncal">http://www.semanticdesktop.org/ontologies/ncal</a>
- </dd>
-
- <dt></dt>
-
- <dt>This Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2007/04/02/ncal">http://www.semanticdesktop.org/ontologies/2007/04/02/ncal</a>
- <br/>This file refers to the Revision 9 of NIE. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.</dd>
-
- <dt></dt>
-
- <dt>Authors:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
-
- <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
-
- <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.uni-kl.de">elst@dfki.uni-kl.de</a></dd>
-
- <dt></dt>
-
- <dt>Editor:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
- <dt></dt>
-
- <dt>Contributors:</dt>
-
- <dd>Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, <a href="mailto:stexx@mail.ru">stexx@mail.ru</a></dd>
-
- <dd>Christiaan Fluit, Aduna, <a href="mailto:christiaan.fluit@aduna-software.com">christiaan.fluit@aduna-software.com</a></dd>
-
-</dl>
-
-<span style="font-weight: bold;">Ontology:</span><br />
-
-<div style="margin-left: 40px;">XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/04/02/ncal/ncal_data.rdfs">NCAL
-(Data Graph Only)</a><br />
-
-XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/04/02/ncal/ncal_metadata.rdfs">NCAL
-(Metadata Graph Only)</a><br />
-
-TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/04/02/ncal/ncal.trig">NCAL
-(Graph Set)</a></div>
-
-</div>
-
-<p class="copyright"> Copyright © 2007 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>®</sup>
-The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
-</p>
-
-<hr />
-<h2>Abstract</h2>
-
-<p style="text-align: justify;"> The NEPOMUK Calendaring
-Ontology intends to provide vocabulary for describing calendaring data
-(events, tasks, journal entries) which is an important part of the body
-of information usually stored on a desktop. It is an adaptation of the
-ICALTZD ontology created by the W3C <a href="http://www.w3.org/2002/12/cal/"> RDF Calendar Task
-Force</a> of the <a href="http://www.w3.org/2001/sw/interest/">
-Semantic Web Interest Group</a> in the <a href="http://www.w3.org/2001/sw/"> Semantic Web Activity</a>.
-This document describes the reasons behind the adaptation, the changes
-performed, as well as an overview of the classes and properties of the
-NCAL ontology.
-</p>
-
-<h2> Status of this document</h2>
-
-<div id="sotd">
-<p style="text-align: justify;"> This document arose from
-the work of the Task-Force ontologies within the <a href="http://nepomuk.semanticdesktop.org">NEPOMUK project</a>.
-This document is a DRAFT made available by the Nepomuk Consortium for
-discussion only. This document is a work in progress and may be
-updated, replaced, or rendered obsolete by other documents at any time.
-</p>
-
-<p style="text-align: justify;"> This document is a part
-in a set of seven documents, which together comprise the complete
-specification of the Nepomuk Information Element Ontology
-Framework. These are: <a href="http://www.semanticdesktop.org/ontologies/nie">NIE</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nfo">NFO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nco">NCO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nmo">NMO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/ncal">NCAL</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nexif">NEXIF</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nid3">NID3</a>.
-</p>
-
-</div>
-
-<div class="toc">
-<h2 id="contents">Contents</h2>
-
-<blockquote> <a href="#sec-introduction">1.
-Introduction</a><br />
-
- <blockquote> <a href="#sec-history">1.1 Previous
-work</a><br />
-
- </blockquote>
-
- <a href="#sec-drawbacks">2. Drawbacks of the ICALTZD
-ontology</a><br />
-
- <blockquote> <a href="#sec-underspecification">2.1
-Underspecification</a><br />
-
- <blockquote> <a href="#sec-propertyvaluesandparams">2.1.1
-Property values and parameters</a><br />
-
- <a href="#sec-domainscalendarproperties">2.1.2
-Domains of calendar properties</a><br />
-
- <a href="#sec-missingtypes">2.1.3 Missing Entity
-Types</a><br />
-
- <a href="#sec-nolimitedvocabulary">2.1.4 No limited
-vocabulary</a><br />
-
- <a href="#sec-vaguecomponentproperty">2.1.5 Vague
-semantics of the component property</a><br />
-
- </blockquote>
-
- <a href="#sec-errors">2.2 Errors</a><br />
-
- <a href="#sec-rangesdatatypeproperties">2.3 Ranges of
-datatype properties</a><br />
-
- <a href="#sec-unacceptabledecisions">2.4 Design
-decisions unacceptable in Nepomuk</a><br />
-
- <blockquote> <a href="#sec-owl">2.4.1 OWL</a><br />
-
- <a href="#sec-tzd">2.4.2 Timezones as datatypes</a><br />
-
- </blockquote>
-
- <a href="#sec-alignmentnco">2.5 Alignment with contact
-ontology</a><br />
-
- </blockquote>
-
- <a href="#sec-ncaldevelopment">3. NCAL Development
-process</a><br />
-
- <a href="#sec-differences">4. Differences between NCAL
-and ICALTZD</a><br />
-
- <blockquote> <a href="#sec-timezones">4.1
-Timezones</a><br />
-
- <a href="#sec-nco">4.2 Alignment with NCO</a><br />
-
- <a href="#sec-unionclasses">4.3 Union Classes</a><br />
-
- </blockquote>
-
- <a href="#sec-knownlimitations">5. Known limitations of
-NCAL</a><br />
-
- <a href="#sec-futureversions">6. Future versions</a><br />
-
- <a href="#sec-examples">7. Examples</a><br />
-
-</blockquote>
-
-</div>
-
-<div>
-<a name="sec-introduction"></a>
-<h2><a name="sec-introduction">1. Introduction</a></h2>
-
-<p style="text-align: justify;"><a name="sec-introduction"> Nepomuk Calendar Ontology (NCAL)
-has been designed to describe various entries
-usually found in calendars. These include events, tasks (todo's) and
-journal
-entries. It is an adaptation of the well known iCalendar specification
-published
-in 2002 as RFC 2445 [</a><a href="#ref-rfc2445">RFC2445</a>].
-This section begins with an outline of the
-previous attempts in adapting RFC 2445 to RDF. It gives an account of
-the issues
-with existing ICAL ontologies that make them unusable within Nepomuk.
-Following
-subsections describe the process adopted for the creation of NCAL and
-it's
-result - the classes and properties of the ontology. Proposed solutions
-to
-problems found in existing ICAL ontologies are presented. At the end, a
-list of
-known limitations of NCAL is given, followed by ideas for future work
-on
-improving NCAL.</p>
-
-<p style="text-align: justify;">
-The following sections make use of the vocabulary specified in RFC
-2445. The
-reader is advised to get acquainted with it before continuing reading.
-A nice
-outline of the structure of iCalendar specification can be found in
-[<a href="#ref-timblical">TIMBLICAL</a>].
-</p>
-
-<a name="sec-history">
-</a>
-<h3><a name="sec-history">1.1 Previous work</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-history">The need for a common vocabulary for
-describing calendaring information in RDF
-has been recognized early within the </a><a href="http://www.w3.org/2001/sw/interest/">W3C RDF Interest
-Group</a>. Organized activity
-has been started on 9th of October 2002 at the SWAD-Europe Workshop on
-the
-Semantic web and Calendaring in Bristol, UK. The report from this
-workshop
-[<a href="#ref-swad37">SWAD37</a>] mentions earlier
-attempts by Tim Berners-Lee
-([<a href="#ref-timblical">TIMBLICAL</a>]), Arick
-and Miller ([<a href="ref-hybridical">HYBRIDICAL</a>])
-and Dan Connoly
-([<a href="#ref-anotherical">ANOTHERICAL</a>],[<a href="#ref-palmical">PALMICAL</a>]).</p>
-
-<p style="text-align: justify;">
-Work continued through a series of meetings. Numerous discussions were
-held
-using the www-rdf-calendar@w3.org mailing list. The archive is
-available at <a href="http://lists.w3.org/Archives/Public/www-rdf-calendar/">here</a>
-and
-the #rdfig channel on the Freenode IRC network. Logs of these
-discussions are available <a href="http://chatlogs.planetrdf.com/rdfig/">here</a>.</p>
-
-<p style="text-align: justify;">
-After three years of research the group has produced two ontologies in
-OWL and a
-W3C Interest Group Note ([<a href="#ref-icalnote">ICALNOTE</a>])
-describing the design decisions that
-have been made. The first ontology, hosted under
-<a href="http://www.w3.org/2002/12/cal/ical">http://www.w3.org/2002/12/cal/ical</a>
-is more popular, semantic web
-enthusiasts try to publish their calendars with this vocabulary, even
-though the
-creators themselves have abandoned it in favour of a newer one, hosted
-under <a href="http://www.w3.org/2002/12/cal/icaltzd">http://www.w3.org/2002/12/cal/icaltzd</a>.
-The main difference between
-these two lies in treatment of timezones. Many entities in the
-iCalendar data
-model contain various dates and times. They are usually accompanied by
-a
-timezone that should serve as a context to interpret them. The older
-ontology
-represents this fact with a 'tzid' property more in-line with the
-original
-representation. The newer one uses a controversial approach of
-representing the
-timezones as datatypes for literals.</p>
-
-<p style="text-align: justify;">
-In the rest of this section the older ontology will be referred to as
-ICAL
-ontology, whereas the newer one will be called the ICALTZD ontology to
-avoid
-confusion. TZD stands for ``TimeZones as Datatypes''. Whenever concrete
-properties from the ICAL ontology are referred, they will be given with
-the
-'ical' prefix (e.g. ical:attendee). ICALTZD properties will use the
-'icaltzd'
-prefix (e.g. icaltzd:component).
-</p>
-
-</div>
-
-<div>
-<a name="sec-drawbacks"></a>
-<h2><a name="sec-drawbacks">2. Drawbacks of the
-ICALTZD ontology</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-drawbacks">ICALTZD ontology is newer and
-better developed. Therefore it was chosen to serve
-as a the model for NCAL. Numerous drawbacks have been identified in it
-though.
-This section gives an account of them. It is intended to provide
-justification
-for the decision not to use ICALTZD directly.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-drawbacks">Most of the deficiencies of
-ICALTZD have been caused by the automatic process of
-its creation. It is automatically generated from the text of the RFC
-itself
-using a combination of a python script and an XSLT transformation.
-(Refer to
-[</a><a href="#ref-icalnote">ICALNOTE</a>] for
-details). This process overlooks many details that cannot be
-extracted with a simple analysis of the structure of the document. They
-would
-require deeper understanding of the text itself, which is certainly
-beyond the
-capabilities of such simple tools. Following subsections explain four
-kinds of
-problems encountered when trying to use ICALTZD within Nepomuk:
-underspecification, bugs,
-superfluous elements and pieces of design that certainly cannot be
-considered
-errors in themselves but are nevertheless against the <a href="http://www.semanticdesktop.org/ontologies/nie#sec-basicdecisions">guidelines
-for NIE</a>.
-</p>
-
-<a name="sec-underspecification">
-</a>
-<h3><a name="sec-underspecification">2.1
-Underspecification</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-underspecification">ICALTZD is
-underspecified. There are many places, where certain structural
-information is not explicitly stated within the ontology. The user
-needs to be
-aware of the 'conventions' adopted by the authors. </a></p>
-
-<a name="sec-propertyvaluesandparams">
-</a>
-<h4><a name="sec-propertyvaluesandparams">2.1.1
-Property values and parameters</a></h4>
-
-<p style="text-align: justify;">
-<a name="sec-propertyvaluesandparams">RFC 2445 specifies a
-generic model where each calendar property can be adorned
-with any number of parameters. Some properties (e.g. UID) don't accept
-any
-parameters. These can easily be modelled in RDF. Their ranges can be
-set to
-appropriate XML Schema datatypes. Other properties (e.g. Attendee)
-accept a
-number of parameters. They cannot be easily modelled in RDF because
-literals
-cannot serve as subjects of RDF triples. An intermediary node is
-necessary.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-propertyvaluesandparams">Using intermediary
-nodes to express property values poses two problems. The
-first one being the type of that node. ICALTZD uses untyped blank nodes
-for this
-purpose. This is against the recomendations for using property domains
-and
-ranges within Nepomuk Representational Language (See [</a><a href="#ref-nrlspec">NRLSPEC</a>] sec. 2.3.1).
-The Closed-World assumption adopted in NRL implies that domains and
-ranges are
-constrains that must be met. Untyped resources cannot be related in NRL.</p>
-
-<p style="text-align: justify;">
-Whenever such intermediary blank nodes are used as property values, the
-ICALTZD
-ontology doesn't specify the ranges of those properties at all. (e.g.
-in
-icaltzd:attach, icaltzd:dtend, icaltzd:dtstart, icaltzd:due,
-icaltzd:duration,
-icaltzd:exdate, icaltzd:exdate, icaltzd:rdate, icaltzd:recurrenceId,
-icaltzd:trigger, icaltzd:tzurl, icaltzd:url). It is worth noting that
-in some
-cases the ICALTZD ontology simplifies the model defined in RFC 2445 and
-discards
-some parameters. This happens for instance in 8 properties that use
-parameters
-for alternate representation (ALTREP) and language (LANGUAGE) namely:
-icaltzd:comment, icaltzd:description, icaltzd:location,
-icaltzd:resources, icaltzd:summary and icaltzd:contact. These
-simplifications are not documented anywhere.
-They can only be learned by observing the example files provided with
-the
-ontology.</p>
-
-<p style="text-align: justify;">
-An attempt has been made to develop a utility that would convert raw
-iCalendar
-files to an RDF representation conforming to the ICALTZD ontology. It
-was
-developed as an element of the <a href="http://aperture.sourceforge.net">Aperture
-Framework</a>. Due to the
-underspecification of properties the developers had to document the
-conventions
-by themselves. Each property has been characterised with following
-attributes:</p>
-
-<ul style="text-align: justify;">
-
- <li> Possible parameters (according to the RFC 2445).
-Information if those
-parameters are allowed in the RDF representation or not, which is the
-case if
-the model has been simplified.</li>
-
- <li> Information if a property points to a literal value (in
-which case all
-parameters specified in RFC 2445 are discarded) or to an untyped blank
-node.</li>
-
- <li> URI of the property. </li>
-
- <li> URI of a property used to link the intermediary blank node
-with the actual
-value of the property.</li>
-
-</ul>
-
-<p style="text-align: justify;">
-The last of those four characteristics is especially important since it
-constitutes the second of those two problems mentioned above. RFC 2445
-allows
-for a property to have multiple value types. The actual type is
-indicated by a
-special parameter (VALUE). It is difficult to model this behavior in a
-general
-case. ICALTZD makes no attempt to formalize it and forces to user to
-learn the
-conventions expressed in examples.</p>
-
-<p style="text-align: justify;">
-Property parameters are modelled in ICALTZD as rdf properties with no
-domains
-and ranges specified at all. Because of that each parameter can just as
-well be
-applied to any property. The same applies to parameters of recurrence
-rules
-(RRULE and EXRULE property values). Their usage must be learned from
-the RFC
-2445 or from the example files. The ontology itself contains too little
-information.
-</p>
-
-<a name="sec-domainscalendarproperties">
-</a>
-<h4><a name="sec-domainscalendarproperties">2.1.2
-Domains of calendar properties</a></h4>
-
-<p style="text-align: justify;">
-<a name="sec-domainscalendarproperties">RFC 2445 specifies
-four properties that apply directly to the central Vcalendar
-object. These are icaltzd: prodid, icaltzd: calscale, icaltzd: method
-and
-icaltzd: version. They don't have their domain specified at all.
-</a></p>
-
-<a name="sec-missingtypes">
-</a>
-<h4><a name="sec-missingtypes">2.1.3 Missing Entity
-Types</a></h4>
-
-<p style="text-align: justify;">
-<a name="sec-missingtypes">As said before many properties
-that accept parameters deserve to have a special
-classes as their ranges. From these four deserve to be mentioned
-separately.
-They are different from other structured values because they are
-described with
-their own vocabulary i.e. not with 'normal' ical parameters as defined
-in sec.
-4.2 of RFC 2445.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-missingtypes">RFC 2445 defines the concept of
-a timezone observance. Each timezone can have
-two observances - daylight and standard. This models a common practice
-to use
-different time in the winter and in the summer. Properties responsible
-for this
-in the ICALTZD ontology are icaltzd:daylight and icaltzd:standard. They
-don't
-have their ranges specified, even though RFC 2445 treats them as
-separate
-subcomponents within the timezone component. They are marked with a
-separate
-pair of BEGIN and END constructs. The ontology makes no provision for
-it being a
-separate class.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-missingtypes">A similar situation occurs with
-recurrence rules i.e. values of RRULE and EXRULE
-properties. They define patterns for the repetition of a calendar
-event. ICALTZD
-doesn't mention them specifically. They are expressed as untyped blank
-nodes.
-Recurrence rule properties are attached to untyped blank nodes.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-missingtypes">There are also two properties
-that don't accept any parameters, but their values
-are structured. That is a comma separated value of the GEO property,
-which
-signifies coordinates of a point, and a semicolon-separated value of
-the
-REQUEST-STATUS property.
-</a></p>
-
-<a name="sec-nolimitedvocabulary">
-</a>
-<h4><a name="sec-nolimitedvocabulary">2.1.4 No
-limited vocabulary</a></h4>
-
-<p style="text-align: justify;">
-<a name="sec-nolimitedvocabulary">Many properties and
-parameters defined in RFC 2445 (e.g. CLASS, STATUS, TRANSP,
-PARTSTAT, RELTYPE etc.) have a limited set of values. This is not
-expressed in
-the ICALTZD ontology. The user needs to learn those acceptable values
-by him- or
-herself in order to generate RDF that can be exported to a valid
-iCalendar file.
-</a></p>
-
-<a name="sec-vaguecomponentproperty">
-</a>
-<h4><a name="sec-vaguecomponentproperty">2.1.5 Vague
-semantics of the component property</a></h4>
-
-<p style="text-align: justify;">
-<a name="sec-vaguecomponentproperty">ICALTZD defines an
-icaltzd: component property to link the calendar with the
-components it contains. It is also used to link the events with their
-alarms but
-even though Timezone Observances also have their own BEGIN and END
-constructs,
-the icaltzd:component property is not used there. These usage patterns
-have been
-extracted from the example files provided by the authors of the ICALTZD
-ontology. The ontology itself doesn't define any domain or range for
-the
-icaltzd:component property.
-</a></p>
-
-<a name="sec-errors">
-</a>
-<h3><a name="sec-errors">2.2 Errors</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-errors">Two problems have been identified
-when working with the ICALTZD ontology. The
-first one concerns the domain of the icaltzd:rrule property. It is
-defined as an
-anonymous owl union class.
-</a></p>
-
-<pre><a name="sec-errors"><rdf:Description rdf:ID="rrule"><br /> <rdfs:domain><br /> <owl:Class rdf:nodeID="DomainOf_rrule"><br /> ....<br /> </owl:Class><br /> <rdfs:domain><br /> ...<br /></rdf:Description><br /></a></pre>
-
-<p style="text-align: justify;">
-<a name="sec-errors">We see that the nodeID construct has
-been used. This means an identifier of a
-blank node. This might not have been the intention of the author though
-since
-two other properties icaltzd:recurrenceId and icaltzd:exdate refer to
-it, but
-they do it wrong.
-</a></p>
-
-<pre><a name="sec-errors"><rdf:Description rdf:ID="recurrenceId"><br /> <rdfs:domain><br /> <owl:Class rdf:about="#DomainOf_rrule"/><br /> </rdfs:domain><br /></rdf:Description><br /></a></pre>
-
-<p style="text-align: justify;">
-<a name="sec-errors">This construct refers to an URI, not
-to a blank node. The </a><a href="http://www.w3.org/RDF/Validator">W3C RDF
-validator</a> interprets the first
-example as:
-</p>
-
-<pre>subject: http://www.w3.org/2002/12/cal/icaltzd#rrule<br />predicate: http://www.w3.org/2000/01/rdf-schema#domain<br />object: genid:UDomainOf_rrule<br /></pre>
-
-<p style="text-align: justify;">
-Whereas the second example is interpreted as:
-</p>
-
-<pre>subject: http://www.w3.org/2002/12/cal/icaltzd#recurrenceId<br />predicate: http://www.w3.org/2000/01/rdf-schema#domain<br />object: http://www.w3.org/2002/12/cal/icaltzd#DomainOf_rrule<br /></pre>
-
-<p style="text-align: justify;">
-Which is clearly not the same.
-</p>
-
-<p style="text-align: justify;">
-The second problem with ICALTZD are multiply defined ID's. The W3C RDF
-Validator
-finds 53 redefinitions of a previously defined identifiers. This fact
-has caused
-problems when working with the RIO 1.0 RDF Parser. It could potentially
-cause
-problems with other tools, even though semantically it makes no
-difference if a
-statement occurs once or multiple times within an RDF document.</p>
-
-<p style="text-align: justify;">
-There are also repetitions in OWL unions that describe the domains of
-properties.
-</p>
-
-<a name="sec-rangesdatatypeproperties">
-</a>
-<h3><a name="sec-rangesdatatypeproperties">2.3
-Ranges of datatype properties</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-rangesdatatypeproperties">An attempt has been
-made to model the datatypes of literals that serve as
-property values. A set of datatypes has been defined. These include
-icaltzd:
-Value_DATE-TIME, icaltzd: Value_CAL-ADDRESS, icaltzd: Value_PERIOD,
-icaltzd:
-Value_RECUR etc. They have been defined as rdfs: Datatype but there are
-no
-additional characteristics of them. In most cases they can safely be
-expressed
-with either xml schema datatypes or special-purpose classes. It is
-worth noting
-that the datatype for dates and times is defined twice: as icaltzd:
-Value_DATE-TIME and icaltzd: dateTime.
-</a></p>
-
-<a name="sec-unacceptabledecisions">
-</a>
-<h3><a name="sec-unacceptabledecisions">2.4 Design
-decisions unacceptable in Nepomuk</a></h3>
-
-<a name="sec-owl">
-</a>
-<h4><a name="sec-owl">2.4.1 OWL</a></h4>
-
-<p style="text-align: justify;">
-<a name="sec-owl">The most important fact, that inhibits
-the usability of ICALTZD within Nepomuk
-is that it is expressed in OWL. This violates the guideline expressed </a><a href="http://www.semanticdesktop.org/ontologies/nie#sec-nrl">here</a>.
-Even though OWL
-classes and properties could theoretically be
-interpreted as RDFS constructs, ICALTZD makes use of OWL unions, which
-have no
-equivalent in RDFS.
-</p>
-
-<a name="sec-tzd">
-</a>
-<h4><a name="sec-tzd">2.4.2 Timezones as datatypes</a></h4>
-
-<p style="text-align: justify;">
-<a name="sec-tzd">A second design decision that may be
-considered controversial is the
-timezones-as-datatypes idea. Whenever point in time is referenced it is
-described with a date, time and a timezone. The first two parts can be
-expressed
-with a single literal, formatted according to the XML Schema 'dateTime'
-format.
-The timezone though is expressed as the datatype of that literal.
-Example files
-provided with the ICALTZD ontology contain many entries similar to the
-following
-one:
-</a></p>
-
-<pre><a name="sec-tzd"><Vevent rdf:about="#D4F0202E-2F2F-11D7-A96C-000393161A98"><br /> <summary>#rdfig calendar meeting</summary><br /> <tstart <br /> rdf:datatype="http://www.w3.org/2002/12/cal/tzd/Europe/London#tz"><br /> 2003-02-05T17:00:00<br /> </dtstart><br /> <dtend<br /> rdf:datatype="http://www.w3.org/2002/12/cal/tzd/Europe/London#tz"><br /> 2003-02-05T18:00:00<br /> </dtend><br /> <description><br /> Email www-rdf-calendar@w3.org with agenda suggestions.<br /> </description><br /></Vevent><br /></a></pre>
-
-<p style="text-align: justify;">
-<a name="sec-tzd">As you can see the values dtstart and
-dtend properties have their timezones
-expressed as URIs. This approach has following disadvantages:</a></p>
-
-<ul>
-
- <li style="text-align: justify;"><a name="sec-tzd">It
-relies on the timezone database provided by the
-authors.Available </a><a href="http://www.w3.org/2002/12/cal/tzd/">here</a>.
-This
-database was created by converting the well-known <a href="http://www.twinsun.com/tz/tz-link.htm">Olson timezone
-database</a> to RDF. This
-assumption works as long as the timezone identifiers used in in
-iCalendar files
-can easily be translated into URIs from that database. This is often
-the case,
-but there are no constraints specified in the RFC 2445 to reinforce
-that claim.
-The timezone identifiers are plain strings. The specification states
-that they
-should refer to timezone definitions that within the same file. RFC
-2445 doesn't
-mention any centralised timezone database. There are perfectly correct
-iCalendar
-files that use timezone identifiers that cannot be easily (that is by
-simple
-string operations) mapped to those from the Olson database.</li>
-
- <li style="text-align: justify;"> Instances of
-icaltzd:Vtimezone gathered in the timezone database are not
-instances of rdfs:Datatype. Using them as datatypes is dubious from the
-semantic
-point of view.</li>
-
- <li style="text-align: justify;"> This approach makes it
-impossible to specify the datatype in the ontology
-itself. The user must learn to use this convention from other sources.</li>
-
-</ul>
-
-<a name="sec-alignmentnco">
-</a>
-<h3><a name="sec-alignmentnco">2.5 Alignment with
-contact ontology</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-alignmentnco">Tight integration between
-ontologies has been identified as one of the core
-requirements for NIE (see </a><a href="http://www.semanticdesktop.org/ontologies/nie#sec-integration">here</a>).
-ICALTZD
-makes no
-references to any specific ontology that would make it possible to link
-calendar
-events with actual contact information about attendees and organizers.
-</p>
-
-<a name="sec-ncaldevelopment">
-</a>
-<h2><a name="sec-ncaldevelopment">3. NCAL
-Development process</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-ncaldevelopment">Issues outlined in the
-previous section led to a decision to create a new
-calendaring ontology for Nepomuk. The main goal was to solve the
-problems
-described above while retaining compatibility with Nepomuk guidelines.
-</a></p>
-
-<a name="sec-ncaldevelopment">Development of NCAL began
-with the ICALTZD ontology. A Java program has been
-written that transformed it into RDFS and performed some basic
-transformations.
-These transformations included:
-</a>
-<ul style="text-align: justify;">
-
- <a name="sec-ncaldevelopment"> <li> Solving the
-problem with the domain of rrule property. See </li>
-
- </a><a href="#sec-errors">here</a> <li>
-Adding the TimezoneObservance class and including it in domains of
-appropriated properties.</li>
-
- <li> Removing the cardinality restrictions from class
-definitions.</li>
-
- <li> Converting the owl unions to appropriate superclasses and
-adding the rdfs:subClassOf links.</li>
-
- <li> Changing OWL classes and properties into RDFS classes and
-properties.</li>
-
- <li> Converting all property ranges to XML Schema datatypes</li>
-
- <li> Creating the RecurrenceRule class, adding it as a range of
-icaltzd:rrule and icaltzd:exrule properties. Setting the domain of all
-recurrence rule parameters appropriately.</li>
-
- <li> Setting the domain of all four Vcalendar properties
-correctly.</li>
-
-</ul>
-
-<p style="text-align: justify;">
-It became clear that some properties require special classes as their
-ranges.
-They would provide explicit hooks to attach the property parameters. In
-order to
-get an overview of the needs the definitions of properties in RFC 2445
-have been
-examined carefully. A table has been created with basic information
-about each
-property. It had following columns:</p>
-
-<ul style="text-align: justify;">
-
- <li> Name of the property.</li>
-
- <li> Domain of the property.</li>
-
- <li> Default type of the property value.</li>
-
- <li> Additional possible types of the property value (does the
-property accept the VALUE parameter).</li>
-
- <li> Does the value accept the timezone identifier parameter?</li>
-
- <li> Other parameters (apart from VALUE and TZID).</li>
-
- <li> Possible values. (If the property has a limited set of
-possible values).</li>
-
- <li> Multiplicity. Whenever the RFC mentioned the fact that a
-property can be specified multiple times (or only once), or that it can
-have many comma-separated values - this fact was recorded.</li>
-
- <li> Other important information.</li>
-
-</ul>
-
-<p style="text-align: justify;">
-This table quickly visualised the actual relations between properties
-and
-parameters. It enabled us to divide the ical properties into six
-groups.
-For each group an approach to represent it in RDF has been chosen.</p>
-
-<ul>
-
- <li style="text-align: justify;"> Properties that accept
-the ALTREP and LANGUAGE parameters. It has been
-decided that creating a separate class just to have means to express
-the
-alternate representation would not be an elegant solution. Therefore
-for each
-property that can accept the ALTREP parameter (i.e. COMMENT,
-DESCRIPTION,
-LOCATION, RESOURCES, SUMMARY and CONTACT) a new 'altRep' property has
-been
-introduced (i.e. <a href="#commentAltRep">ncal:commentAltRep</a>,
- <a href="#descriptionAltRep">ncal:descriptionAltRep</a>,
-etc.). The LANGUAGE
-parameter has been removed from the ontology altogether. The user can
-express
-the same with language literals available in RDF.</li>
-
- <li style="text-align: justify;"> Properties that accept
-no parameters, but have a limited set of values.
-This included CLASS, STATUS, TRANSP and ACTION. For each a separate
-class has
-been introduced. For each of those classes a set of instances has been
-created
-to represent the possible values of each property.</li>
-
- <li style="text-align: justify;"> Properties that don't
-accept and don't have any restrictions on the set of
-possible values. This was the simplest case. The ranges of those
-properties have
-been set to an appropriate XML Schema datatype. (Apart from RRULE and
-EXRULE,
-which refer to a RecurrenceRule).</li>
-
- <li style="text-align: justify;"> Properties that refer
-to a Universal Coordinated Time point. (COMPLETED,
-CREATED, DTSTAMP, LAST-MODIFIED). Their ranges have been set to the
-dateTime
-datatype defined in the XML Schema Definition.</li>
-
- <li style="text-align: justify;"> Properties that refer
-to a time point in a concrete timezone (DTEND, DUE,
-DTSTART, EXDATE, RDATE). The problem of representing the timezone has
-been
-solved with the NcalDateTime class. Its properties enable it to be used
-whenever
-a DATE-TIME or DATE value is needed. It also provides three ways to
-express the
-timezone - a reference to a <a href="#Timezone">ncal:Timezone</a>
-instance or a simple string.</li>
-
- <li style="text-align: justify;"> Properties that
-require separate solutions. These included RECURRENCE-ID,
-TRIGGER, FREEBUSY, ATTENDEE, ORGANIZER, ATTACH, GEO, RELATED-TO. For
-each of
-those a separate class has been created and added to the range of the
-property
-and to the domain of appropriate parameters.</li>
-
-</ul>
-
-<a name="sec-differences">
-</a>
-<h2><a name="sec-differences">4. Differences between
-NCAL and ICALTZD</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-differences">The overall structure of NCAL is
-in most respects similar to ICALTZD, which is
-thoroughly described in [</a><a href="#ref-icalnote">ICALNOTE</a>].
-NCAL only tries to clarify certain underspecified
-points, as outlined in the sections above. Following paragraphs
-describe two
-important changes that break the continuity with ICALTZD.
-</p>
-
-<a name="sec-timezones">
-</a>
-<h3><a name="sec-timezones">4.1 Timezones</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-timezones">As already mentioned, NCAL
-introduces the NcalDateTime
-class (see </a><a href="#NcalDateTime">ncal:NcalDateTime</a>).
-It's
-purpose is to provide a more elegant way to link the time values with
-their
-timezones. It can also represent plain dates, which models the fact
-that
-four properties have two possible value types: date and date-time. It
-allows for
-a clean link between the time value and the timezone (expressed with
-the
-<a href="#ncalTimezone">ncal:ncalTimezone</a>).
-Since RFC states that each icalendar document MUST contain exact
-definitions of
-all timezones used, it can safely be assumed that all time values can
-refer to
-those definitions.
-</p>
-
-<a name="sec-nco">
-</a>
-<h3><a name="sec-nco">4.2 Alignment with NCO</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-nco">According to the guidelines for NIE (see
-sec.
-</a><a href="http://www.semanticdesktop.org/ontologies/nie#sec-integration">here</a>),
-it is desirable to promote integration between
-ontologies. That's why ranges of two properties (namely: <a href="#attendee">ncal:attendee</a>
-and <a href="#organizer">ncal:organizer</a> have
-been equiped with links
-to the <a href="http://www.semanticdesktop.org/ontologies/nco#Contact">nco:Contact</a>
-class from the Nepomuk Contact Ontology. This will facilitate
-integration between addressbooks and calendars.
-</p>
-
-<a name="sec-unionclasses">
-</a>
-<h3><a name="sec-unionclasses">4.3 Union Classes</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-unionclasses">ICALTZD used OWL unions to
-define domains of many properties. They don't have
-their equivalents in NRL, so another solution has been adopted. Each
-union
-is now represented as a separate class with whose name has been
-generated by
-concatenating the names of classes that comprise the union. (such as
-UnionOfEventFreebusy).</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-unionclasses">The reader may now feel the
-urge to give more "meaningful" (semantic) names to the
-union classes. It is difficult. The semantic meaning of a union class
-is defined by the
-properties that have it as a domain, and it was not possible for us to
-find a
-name for the Union classes based on the properies, as they are too
-diverse.
-</a></p>
-
-<a name="sec-knownlimitations">
-</a>
-<h2><a name="sec-knownlimitations">5. Known
-limitations of NCAL</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-knownlimitations">Nepomuk Calendaring
-Ontology doesn't capture the whole complexity of the data
-model defined by RFC 2445. Following limitations have been identified.
-</a></p>
-
-<ul style="text-align: justify;">
-
- <li><a name="sec-knownlimitations"> Usually in
-places where a limited set of values is referred to, one of
-those values is considered default. NCAL doesn't distinguish between
-default and
-non-default values. </a></li>
-
- <li><a name="sec-knownlimitations"> If a parameter
-or a property has multiple sets of acceptable values
-depending on the context - this information is lost. For example the
-STATUS
-property can have different values depending on whether it has been
-applied to a
-Event, a Todo or a Journal instance. NCAL makes no such distinctions.
-All
-possible values are represented as instances of the same class.</a></li>
-
- <li><a name="sec-knownlimitations"> Sets of
-acceptable parameters can also differ between various classes in
-the domain of a property (e.g. attendee of an alarm cannot have any
-parameters).
-NCAL doesn't capture this.</a></li>
-
- <li><a name="sec-knownlimitations"> No cardinality
-constraints have been specified, neither direct (properties
-MUST be specified) nor conditional (properties that cannot be specified
-simultaneously)</a></li>
-
- <li><a name="sec-knownlimitations"> Extension
-tokens have been altogether ignored </a></li>
-
-</ul>
-
-<a name="sec-futureversions">
-</a>
-<h2><a name="sec-futureversions">6. Future versions</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-futureversions">A major revision of NCAL is
-expected when the RFC 2445 is obsoleted by a new
-document currently in preparation in the </a><a href="http://tools.ietf.org/wg/calsify/">Working Group for
-Calendaring and
-Scheduling Standards Simplification (CALSIFY)</a> within the
-Internet Engineering
-Task Force.
-</p>
-
-</div>
-
-<div>
-<a name="sec-examples"></a>
-<h2><a name="sec-examples">7. Examples</a></h2>
-
-Example files that show how to use the expressive power of the ontology will be
-published here in near future.
-
-</div>
-
-<div>
-<h2>References</h2>
-
-<dl>
-
- <dt><a name="ref-icalnote">[ICALNOTE] </a></dt>
-
- <dd><cite><a href="http://www.w3.org/TR/rdfcal/">Rdf
-calendar - an application of the resource description framework to
-icalendar datal</a></cite>, Dan Connolly and Libby Miller,
-W3C Interest Group Note 29 September 2005 http://www.w3.org/TR/rdfcal/</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-hybridical">[HYBRIDICAL] </a></dt>
-
- <dd><cite><a href="http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf">Hybrid
-ical rdf schema</a></cite>, Michael Arick and Libby
-Miller
-http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-timblical">[TIMBLICAL] </a></dt>
-
- <dd><cite><a href="http://www.w3.org/2000/01/foo">A
-quick look at icalendar</a></cite>, Tim Berners-Lee
-http://www.w3.org/2000/01/foo</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-anotherical">[ANOTHERICAL] </a></dt>
-
- <dd><cite><a href="http://www.w3.org/2000/10/swap/pim/ical.rdf"> Another
-icalendar model</a></cite>, Dan Connoly
-http://www.w3.org/2000/10/swap/pim/ical.rdf</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-palmical">[PALMICAL] </a></dt>
-
- <dd><cite><a href="http://www.w3.org/2000/08/palm56/datebook"> Palm
-datebook</a></cite>, Dan Connoly
-http://www.w3.org/2000/08/palm56/datebook</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-rfc2426">[RFC2445] </a></dt>
-
- <dd><cite><a href="http://www.ietf.org/rfc/rfc2445.txt">Internet
-calendaring and scheduling core objects specification</a></cite>,
-Frank Dawson and Derik Stenerson http://www.ietf.org/rfc/rfc2445.txt</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-swad37">[SWAD37] </a></dt>
-
- <dd><cite><a href="http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_2/">Swad-europe
-deliverable 3.7: Developer workshop report 2 - semantic web
-calendaring</a></cite>, Libby Miller
-http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_2/</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-nrlspec">[NRLSPEC] </a></dt>
-
- <dd><cite><a href="http://www.semanticdesktop.org/ontologies/nrl">Nepomuk
-Representational Language (NRL) Vocabulary Specification.</a></cite>, Nepomuk Task-Force Ontologies,
-http://www.semanticdesktop.org/ontologies/nrl</dd>
-
-</dl>
-
-</div>
diff --git a/nco/doc/nco-header.html b/nco/doc/nco-header.html deleted file mode 100644 index 83e6a61..0000000 --- a/nco/doc/nco-header.html +++ /dev/null @@ -1,364 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
- <title>Nepomuk Contact Ontology (NCO)</title>
-
-
-</head>
-
-
-<body>
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK" src="nepomuk.png" /> </a> </div>
-
-<h1>NEPOMUK Contact Ontology</h1>
-
-<big style="color: rgb(0, 90, 156);">Task-Force Ontologies</big>
-<dl>
-
- <dt></dt>
-
- <dt>Latest Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/nco">http://www.semanticdesktop.org/ontologies/nco</a>
- </dd>
-
- <dt></dt>
-
- <dt>This Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nco">http://www.semanticdesktop.org/ontologies/2007/03/22/nco</a>
- <br/>This file refers to the Revision 9 of NIE. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.</dd>
-
- <dt></dt>
-
- <dt>Authors:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
-
- <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
-
- <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.uni-kl.de">elst@dfki.uni-kl.de</a></dd>
-
-</dl>
-
-<dl>
-
- <dt>Editor:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
-</dl>
-
-<dl>
-
- <dt>Contributors:</dt>
-
- <dd>Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, <a href="mailto:stexx@mail.ru">stexx@mail.ru</a></dd>
-
- <dd>Christiaan Fluit, Aduna, <a href="mailto:christiaan.fluit@aduna-software.com">christiaan.fluit@aduna-software.com</a></dd>
-
- <dt><span style="font-weight: bold;"></span></dt>
-
- <dt><span style="font-weight: bold;">Ontology:</span></dt>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nco/nco_data.rdfs">NCO
-(Data Graph Only)</a></dd>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nco/nco_metadata.rdfs">NCO
-(Metadata Graph Only)</a></dd>
-
- <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nco/nco.trig">NCO
-(Graph Set)</a></dd>
-
-</dl>
-
-</div>
-
-<p class="copyright"> Copyright © 2007 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>®</sup>
-The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
-</p>
-
-<hr />
-<h2>Abstract</h2>
-
-<p style="text-align: justify;"> NEPOMUK Contact Ontology
-describes contact information, common in many places on the desktop. It
-evolved from the VCARD specification (<a href="http://www.ietf.org/rfc/rfc2426.txt">RFC 2426</a>)
-and has been inspired by the <a href="http://www.w3.org/TR/vcard-rdf">Vcard Ontology</a>
-by Renato Ianella. The scope of NCO is much broader though. This
-document gives an overview of the classes, properties and intended use
-cases of the NCO ontology.
-</p>
-
-<h2> Status of this document</h2>
-
-<div id="sotd">
-<p style="text-align: justify;"> This document arose from
-the work of the Task-Force ontologies within the <a href="http://nepomuk.semanticdesktop.org">NEPOMUK project</a>.
-This document is a DRAFT made available by the Nepomuk Consortium for
-discussion only. This document is a work in progress and may be
-updated, replaced, or rendered obsolete by other documents at any time.</p>
-
-<p style="text-align: justify;"> This document is a part
-in a set of seven documents, which together comprise the complete
-specification of the Nepomuk Information Element Ontology Framework.
-These are: <a href="http://www.semanticdesktop.org/ontologies/nie">NIE</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nfo">NFO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nco">NCO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nmo">NMO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/ncal">NCAL</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nexif">NEXIF</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nid3">NID3</a>.
-</p>
-
-</div>
-
-<div class="toc">
-<h2 id="contents">Contents</h2>
-
-<blockquote> <a href="#sec-intro">1. Introduction</a><br />
-
- <a href="#sec-scope">2. Scope</a><br />
-
- <a href="#sec-description">3. Description of classes and
-properties</a><br />
-
- <a href="#intro">4. Usage</a><br />
-
- <a href="#sec-examples">5. Examples</a><br />
-
-</blockquote>
-
-</div>
-
-<div>
-<h2 id="sec-intro">1. Introduction</h2>
-
-<p style="text-align: justify;">
-The purpose of the Nepomuk Contact Ontology (NCO) is to describe
-contact information. It is one of the core elements of every Personal
-Information Management system and Nepomuk is no exception. Origins of
-this ontology can be traced back to VCARD specification published in [<a href="#ref-rfc2426">RFC2426</a>]. The first attempt to
-convert RFC 2426 to RDF was made by Renato Ianella and published in a
-W3C working group note [<a href="#ref-vcardrdf">VCARDRDF</a>].
-This ontology doesn't meet Nepomuk requirements though. Most of the
-properties don't have their domains and ranges set. It uses certain
-modelling techniques that result in untyped blank nodes. Those few
-range constraints that have been set are violated
-in the examples provided with the specification document. </p>
-
-<p style="text-align: justify;">
-All of this led to a decision to create a new ontology. This
-opportunity has been used to fill in the missing domain and range
-constraints and to expand the ontology with the concepts of Roles and
-arbitrary contact media. It came at a cost of reduced compatibility
-with the VCARD specification. The goal was to allow for lossless import
-of vCard data. Exporting vCard files might require discarding some
-information, since NCO is more expressive.
-</p>
-
-</div>
-
-<div>
-<a name="sec-scope"></a>
-<h2><a name="sec-scope">2. Scope</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-scope">The meaning of the term 'Contact' in
-NCO is quite wide. It is every piece of data that identifies an entity
-or provides means to communicate with it. This definition has two
-aspects - identification and communication. NCO covers both of them.<br />
-
-</a></p>
-
-<div style="text-align: center;"><a name="sec-scope"><img style="width: 512px; height: 366px;" alt="NCO Scope" src="scopeOfNco.png" /></a></div>
-
-<p style="text-align: justify;">
-<a name="sec-scope">A very high level diagram of the scope
-of NCO is outlined in the figure above. It has two axes: content and
-complexity. The vertical one refers to the various kinds of entities
-mentioned in the definition of a Contact. They include people and
-organizations but in a general case anything that can be contacted, can
-be represented by an instance of the Contact class. This generality is
-justified by
-the fact, that in many cases automatic agents can be contacted with
-various means.
-Many companies operate automatic IVR systems the users may call to
-obtain information or place orders. Emails are sent by various software
-systems to notify the recipient of some event. In all of these cases, a
-user might want to reprent such entities on a contact list, even though
-they are neither people, nor organizations.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-scope">The horizontal axis represents the
-broad spectrum of use cases for this ontology. The left end is intended
-to cover simple bits of information about contacts. Such information is
-usually found in various places on a desktop. Recipients of emails,
-authors of documents, attendees of calendar events. All of
-these small pieces of data refer to Contacts, even though they are not
-parts of a typical addressbook or a Contact list.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-scope">The rightmost end of the horizontal
-axis represents cases where a Contact refers
-to an entry in an Addressbook. There are numerous applications that
-allow the user to manage a list of contacts. They usually store many
-pieces of data. In many cases a single person appears in various roles,
-as a private person and as an employee of a company or an organization.
-These roles are usually connected with their own addresses (private and
-business), telephone numbers, email addresses etc. Cases when a person
-is affiliated with multiple organizations make the matters even more
-complicated. NCO tries to provide means to express this role-based
-approach.
-</a></p>
-
-</div>
-
-<div>
-<a name="sec-description"></a>
-<h2><a name="sec-description">3. Description of
-classes and properties</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-description">The most important classes are
-outlined in the Figure below.</a></p>
-
-<p style="text-align: center;"><a name="sec-description"></a><img style="width: 476px; height: 326px;" alt="NCO Classes" src="ncoMainClassDiagram.png" />
-</p>
-
-<p style="text-align: justify;">
-<a href="#Contact">Contact</a> is the core class of
-NCO. It provides various properties for the purpose of identifying an
-entity. They include mostly names, either as one string - (<a href="#fullname">fullname</a> or split into
-constituent parts - <a href="#nameFamily">nameFamily</a>,
-<a href="#nameGiven">nameGiven</a> etc).</p>
-
-<p style="text-align: justify;">
-The communication information is expressed with subclasses of the <a href="#ContactMedium">ContactMedium</a>
-class. They provide various means of communication. An entire hierarchy
-of various ContactMedia has been presented. Available subclasses
-include: <a href="#PostalAddress">PostalAddress</a>,
-<a href="#PhoneNumber">PhoneNumber</a>, <a href="#EmailAddress">EmailAddress</a>, and <a href="#IMAccoung">IMAccount</a>. Each medium is
-equipped with specific properties. For instance the PostalAddress can
-be split into various parts, an IMAccount has
-an <a href="#imID">instant messaging identifier</a>,
-a <a href="#imStatus">status</a> and a status
-message <a href="#imStatusMessage">status message</a>.
-</p>
-
-<p style="text-align: justify;">
-A single <a href="#Contact">Contact</a> has one
-default role (expressed by the fact that the Contact class is a
-subclass of <a href="#Role">Role</a>. This makes it
-easier to use Contacts in places where little information is available
-(leftmost end of the complexity axis). When contacts are extracted from
-places where they are described in more detail (rightmost end of the
-complexity axis) the distinction between multiple roles can be
-expressed. NCO provides means to describe contact information to a
-person (<a href="#PersonContact">PersonContact</a>
-class that is affiliated (<a href="#Affiliation">Affiliation</a>)
-with multiple Organizations (<a href="#OrganizationContact">OrganizationContact</a>).
-</p>
-
-</div>
-
-<div>
-<a name="sec-usage"></a>
-<h2><a name="sec-usage">4. Usage</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-usage">As already mentioned the definition of
-a Contact is intentionally broad. NCO is intended to cover a wide array
-of use cases. The most obvious one is description
-of entries found in addressbooks. There are many applications that work
-with such data. The list includes, but is certainly not limited to
-email clients, calendaring applications, standalone addressbook
-applications and online social services (like </a><a href="http://www.orkut.com">Orkut</a> or <a href="http://www.linkedin.com">LinkedIn</a>).</p>
-
-<p style="text-align: justify;">
-Addressbook entries are not the only way to use NCO. Instances of the
-Contact class may come up in many other places, as senders and
-receivers of emails, as meeting attendees, as fileOwners etc. It is
-considered a best practice to use an
-instance of the Contact class wherever some contactable entity is
-referenced, even when the point where this reference is made contains
-little other information. See the list of properties that have <a href="#Contact">Contact</a> as their domain for ideas.</p>
-
-<p style="text-align: justify;">
-The NCO is a good example of the trend towards <a href="http://www.semanticdesktop.org/ontologies/nie#sec-integration">ontology
-integration</a>.
-To illustrate the effect of it let's consider a contact disambiguation
-tool. It would browse all instances of the class Contact and aggregate
-those that refer to one Person (by email address or various forms of
-name). Such a tool wouldn't need to be aware of all properties in all
-ontologies that even though they have a plain String as their range -
-actually indicate a name of a person. If we left the names and email
-addresses as plain string values of specialized properties - it would
-become much more difficult to assign them to appropriate people
-automatically.
-</p>
-
-</div>
-
-<div>
-<a name="sec-examples"></a>
-<h2><a name="sec-examples">5. Examples</a></h2>
-
-<ul>
- <li>
- <b><a href="examples/nco-contact.ttl">nco-contact.ttl</a></b><br />
- A simple NCO Contact. It represents an individual, with some contact media
- affiliated with an organization. His work address and telephone is also
- expressed.
- </li>
- <li>
- <b><a href="examples/nco-key.ttl">nco-key.ttl</a></b><br />
- Demonstrates how to attach information about public keys. NCO doesn't have
- any particular vocabulary for elements of public keys. A key is treated as
- an attachment file. Future NIE extensions may add more expressive vocabulary
- for this.
- </li>
- <li>
- <b><a href="examples/nco-photossounds.ttl">nco-photossounds.ttl</a></b><br />
- Demonstrates how to attach information about photos and sounds to a contact.
- They are also expressed as attachments, but NIE provides vocabulary that can
- be used to interpret those attachments as InformationElements of a concrete
- type.
- </li>
-</ul>
-
-</div>
-
-<div>
-<h2>References</h2>
-
-<dl>
-
- <dt><a name="ref-vcardrdf"></a>[VCARDRDF]</dt>
-
- <dd><cite><a href="http://www.w3.org/TR/vcard-rdf">Representing
-vcard objects in rdf/xml</a></cite>, Renato
-Ianella, W3C Note 22 February 2001 http://www.w3.org/TR/vcard-rdf</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-rfc2426"></a>[RFC2426]</dt>
-
- <dd><cite><a href="http://www.ietf.org/rfc/rfc2426.txt">vcard
-mime directory profile</a></cite>, Frank Dawson and
-Tim Howes http://www.ietf.org/rfc/rfc2426.txt</dd>
-
-</dl>
-
-</div>
diff --git a/nco/doc/ncoMainClassDiagram.png b/nco/doc/ncoMainClassDiagram.png Binary files differdeleted file mode 100644 index ff0997b..0000000 --- a/nco/doc/ncoMainClassDiagram.png +++ /dev/null diff --git a/nco/doc/scopeOfNco.png b/nco/doc/scopeOfNco.png Binary files differdeleted file mode 100644 index 0efbc27..0000000 --- a/nco/doc/scopeOfNco.png +++ /dev/null diff --git a/nexif/doc/nexif-header.html b/nexif/doc/nexif-header.html deleted file mode 100644 index c5035b7..0000000 --- a/nexif/doc/nexif-header.html +++ /dev/null @@ -1,200 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
- <title>Nepomuk EXIF Ontology (NEXIF)</title>
-
-
-</head>
-
-
-<body>
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
-
-<h1>NEPOMUK EXIF Ontology</h1>
-
-<big style="color: rgb(0, 90, 156);">Task-Force Ontologies<br />
-
-<br />
-
-</big>
-<dl>
-
- <dt>Latest Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/nexif">http://www.semanticdesktop.org/ontologies/nexif</a>
- </dd>
-
- <dt></dt>
-
- <dt>This Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2007/05/10/nexif">http://www.semanticdesktop.org/ontologies/2007/05/10/nexif</a>
- <br/>This file refers to the Revision 9 of NIE. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.
- </dd>
-
-</dl>
-
-<dl>
-
- <dt>Authors:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
-
- <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
-
- <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.uni-kl.de">elst@dfki.uni-kl.de</a></dd>
-
-</dl>
-
-<dl>
-
- <dt>Editor:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
-</dl>
-
-<dl>
-
- <dt>Contributors:</dt>
-
- <dd>Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, <a href="mailto:stexx@mail.ru">stexx@mail.ru</a></dd>
-
- <dd>Christiaan Fluit, Aduna, <a href="mailto:christiaan.fluit@aduna-software.com">christiaan.fluit@aduna-software.com</a></dd>
-
- <dt></dt>
-
- <dt><span style="font-weight: bold;">Ontology:</span></dt>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/05/10/nexif/nexif_data.rdfs">NEXIF
-(Data Graph Only)</a></dd>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/05/10/nexif/nexif_metadata.rdfs">NEXIF
-(Metadata Graph Only)</a></dd>
-
- <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/05/10/nexif/nexif.trig">NEXIF
-(Graph Set)</a></dd>
-
-</dl>
-
-<dl>
-
-</dl>
-
-</div>
-
-<p class="copyright"> Copyright © 2007 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>®</sup>
-The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
-</p>
-
-<hr />
-<h2>Abstract</h2>
-
-<p style="text-align: justify;"> EXIF is a common standard
-of basic image metadata used in digital cameras and in image management
-software. Masahide Kanzaki created an <a href="http://www.kanzaki.com/ns/exif">ontology</a>
-that allows the EXIF metadata to be expressed in RDF. NEXIF is a simple
-adaptation of the Kanzaki's ontology to fit it into the NEPOMUK
-Information Element Framework. This document gives an overview of
-NEXIF, its classes and properties.
-</p>
-
-<h2> Status of this document</h2>
-
-<div id="sotd">
-<p style="text-align: justify;"> This document arose from
-the work of the Task-Force ontologies within the <a href="http://nepomuk.semanticdesktop.org">NEPOMUK project</a>.
-This document is a DRAFT made available by the Nepomuk Consortium for
-discussion only. This document is a work in progress and may be
-updated, replaced, or rendered obsolete by other documents at any time.</p>
-
-<p style="text-align: justify;"> This document is a part
-in a set of seven documents, which together comprise the complete
-specification of the Nepomuk Information Element Ontology
-Framework. These are: <a href="http://www.semanticdesktop.org/ontologies/nie">NIE</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nfo">NFO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nco">NCO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nmo">NMO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/ncal">NCAL</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nexif">NEXIF</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nid3">NID3</a>.
-</p>
-
-</div>
-
-<div>
-<h2 id="intro">Ontology description</h2>
-
-<p style="text-align: justify;">Exchangeable Image Format
-(EXIF) is a specification of image metadata vocabulary
-published by the Japan Electronics and Information Technology
-Industries Association [<a href="#ref-exifspec">EXIFSPEC</a>].
-It has gained wide acceptance within the digital photography community.
-Most of today's digital cameras annotate the pictures with EXIF
-annotations.</p>
-
-<p style="text-align: justify;">
-An Exif description is to a large extent a set of name/value pairs.
-Exif descriptions have little structural information, apart from simple
-part-of relationships. Therefore adapting it to RDF is quite
-straightforward. This has been expertly done by Masahide Kanzaki [<a href="#ref-exifrdf">EXIFRDF</a>]. His ontology
-meticulously recreates all properties defined in the specification
-document as rdf properties. They don't have their domains and ranges
-specified though. Therefore, during the adaptation of Kanzaki ontology
-to the Nepomuk Representational Language the domains and ranges have
-been added.</p>
-
-<p style="text-align: justify;">
-The Nepomuk Exif Ontology (NEXIF) has been linked with two other
-ontologies. The first link allows for easy annotation of image files
-with exif properties. It has been realized with the <a href="#Photo">nexif:Photo</a>
-class, which is a subclass of <a href="http://www.semanticdesktop.org/ontologies/http://www.semanticdesktop.org/ontologies/nfo#Image">nfo:Image</a>.
-</p>
-
-</div>
-
-<div>
-<a name="sec-examples"></a>
-<h2><a name="sec-examples">Examples</a></h2>
-
-Example files that show how to use the expressive power of the ontology will be
-published here in near future.
-
-</div>
-
-<div>
-<h2>References</h2>
-
-<dl>
-
- <dt><a name="ref-exifspec"></a>[EXIFSPEC]</dt>
-
- <dd><cite><a href="http://exif.org/Exif2-2.PDF">Exchangeable
-Image Format for digital still cameras: Exif Version 2.2.</a></cite>,
-JEITA Technical Standardization Committee on AV & IT Storage
-Systems and Equipment. Standard of Japan Electronics and Information
-Technology Industries Association: JEITA CP-3451. Japan, April 2002.
-http://exif.org/Exif2-2.PDF</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-exifrdf"></a>[EXIFRDF]</dt>
-
- <dd><cite><a href="http://www.kanzaki.com/ns/exif">Exif
-data description vocabulary</a></cite>, Masahide
-Kanzaki http://www.kanzaki.com/ns/exif</dd>
-
-</dl>
-
-</div>
\ No newline at end of file diff --git a/nfo/doc/nfo-header.html b/nfo/doc/nfo-header.html deleted file mode 100644 index 33f05e2..0000000 --- a/nfo/doc/nfo-header.html +++ /dev/null @@ -1,218 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
- <title>Nepomuk File Ontology (NFO)</title>
-
-
-</head>
-
-
-<body>
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
-
-<h1>NEPOMUK File Ontology</h1>
-
-<big style="color: rgb(0, 90, 156);">Task-Force Ontologies</big>
-<dl>
-
- <dt></dt>
-
- <dt>Latest Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/nfo">http://www.semanticdesktop.org/ontologies/nfo</a></dd>
-
- <dt></dt>
-
- <dt>This Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nfo">http://www.semanticdesktop.org/ontologies/2007/03/22/nfo</a>
- <br/>This file refers to the Revision 9 of NIE. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.</dd>
-
- <dt></dt>
-
- <dt>Authors:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
-
- <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
-
- <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.uni-kl.de">elst@dfki.uni-kl.de</a></dd>
-
-</dl>
-
-<dl>
-
- <dt>Editor:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
-</dl>
-
-<dl>
-
- <dt>Contributors:</dt>
-
- <dd>Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, <a href="mailto:stexx@mail.ru">stexx@mail.ru</a></dd>
-
- <dd>Christiaan Fluit, Aduna, <a href="mailto:christiaan.fluit@aduna-software.com">christiaan.fluit@aduna-software.com</a></dd>
-
-</dl>
-
-<dl>
-
- <dt><span style="font-weight: bold;">Ontology:</span></dt>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nfo/nfo_data.rdfs">NFO
-(Data Graph Only)</a></dd>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nfo/nfo_metadata.rdfs">NFO
-(Metadata Graph Only)</a></dd>
-
- <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nfo/nfo.trig">NFO
-(Graph Set)</a></dd>
-
-</dl>
-
-</div>
-
-<p class="copyright"> Copyright © 2007 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>®</sup>
-The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
-</p>
-
-<hr />
-<h2>Abstract</h2>
-
-<p style="text-align: justify;"> NEPOMUK File Ontology
-(NFO) intends to provide vocabulary to express information extracted
-from various sources. They include files, pieces of sotware and remote
-hosts. This document gives an overview of NFO and describes its classes
-and properties.
-</p>
-
-<h2> Status of this document</h2>
-
-<div id="sotd">
-<p style="text-align: justify;"> This document arose from
-the work of the Task-Force ontologies within the <a href="http://nepomuk.semanticdesktop.org">NEPOMUK project</a>.
-This document is a DRAFT made available by the Nepomuk Consortium for
-discussion only. This document is a work in progress and may be
-updated, replaced, or rendered obsolete by other documents at any time.
-</p>
-
-<p style="text-align: justify;"> This document is a part
-in a set of seven documents, which together comprise the complete
-specification of the Nepomuk Information Element Ontology Framework.
-These are: <a href="http://www.semanticdesktop.org/ontologies/nie">NIE</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nfo">NFO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nco">NCO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nmo">NMO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/ncal">NCAL</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nexif">NEXIF</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nid3">NID3</a>.
-</p>
-
-</div>
-
-<div>
-<h2 id="intro">Introduction</h2>
-
-<p style="text-align: justify;"> Nepomuk File Ontology
-(NFO) is one of the fundamental parts of NIE. It deals with files and
-other desktop resources. Files are understood as sequences of bytes
-stored in a Filesystem or on a Network. It provides subclasses both of
-a DataObject and an InformationElement. A basic hierarchy of
-FileDataObject subclasses is provided. It includes a 'normal'
-FileDataObject, that usually resides on a typical filesystem, but also
-allows for other kinds of
-files - those embedded in, or attached to other data items, as well as
-deleted and stored in a trash folder. This hierarchy is by no means
-complete. More complete taxonomies, that either add additional
-FileDataObject subclasses or extend ones provided in this ontology may
-appear in future.
-</p>
-
-</div>
-
-<div>
-<h2>FileDataObject</h2>
-
-<p style="text-align: justify;">
-The cornerstone of the NFO is the <a href="#FileDataObject">FileDataObject</a>
-class. It represents files - finite sequences of bytes available from
-some durable storage medium. This definition explicitly exludes streams
-(which are potentially infinite) but includes web documents and other
-resources resolvable via a URL. As mentioned before there are various
-types of files. They are reflected in the hierarchy of subclasses of
-the File class. This
-hierarchy is expected to grow when users add new types of files
-relevant to their work.
-</p>
-
-</div>
-
-<div>
-<h2>Folders and Compressed files</h2>
-
-<p style="text-align: justify;">
-Each file on a hard disk is usually contained within a folder or a
-directory (the naming depends on the Operating System). They are
-represented by the <a href="#Folder">Folder</a>
-class. The containment relation can be expressed with the <a href="#belongsToContainer">belongsToContainer</a>
-property. Note that a Folder is an interpretation. It may be applied to
-a <a href="#FileDataObject">FileDataObject </a>
-(representing a folder on a disk), but it can also be applied to an <a href="#ArchiveItem">ArchiveItem</a>
-(representing a folder inside an archive), or to a <a href="#MailboxDataObject">MailboxDataObject</a>
-(representing a mail folder on an IMAP server).
-</p>
-
-<p style="text-align: justify;">
-Compressed Files are expressed with an Archive class. It is also an
-interpretation that may be applied to any piece of data. An important
-thing to note is that Nepomuk strives for data integration. It
-shouldn't make much difference if a file is within a normal folder or
-within an archive. That's why no special case is made for the <a href="#fileUrl">fileUrl</a> property for files in
-compressed archives. In both cases a file should be accessible with a
-URL. In case of stand-alone files this is simple. Unfortunately there
-are no standards defining the way to construct URL's for files inside
-compressed archives. We encourage applications to use conventions
-established by the <a href="http://jakarta.apache.org/commons/vfs/filesystems.html">Apache
-Virtual File System project.</a> For cases when no URL can be
-constructed for a file (e.g. a picture inside an archive attached to an
-event in an outlook calendar) the entire containment tree needs to be
-examined to find ways for accessing a file.
-</p>
-
-</div>
-
-<div>
-<h2>Remote Resources</h2>
-
-<p style="text-align: justify;">
-NFO includes basic vocabulary to describe remote resources. Its notion
-of a <a href="#FileDataObject">FileDataObject</a>
-is universal. The fileUrl property can just as well be set to a http://
-address. To facilitate processing a <a href="#RemoteDataObject">RemoteDataObject</a>
-class has been introduced. Its purpose is to have a 'semantic' way of
-expressing the fact that an instance of a FileDataObject class actually
-refers to a remote resource. Otherwise the applications would have to
-check manually if the url begins with http://. </p>
-
-</div>
-
-<div>
-<a name="sec-examples"></a>
-<h2><a name="sec-examples">Examples</a></h2>
-
-Example files that show how to use the expressive power of the ontology will be
-published here in near future.
-
-</div>
diff --git a/nid3/doc/nid3-header.html b/nid3/doc/nid3-header.html deleted file mode 100644 index 2ea942d..0000000 --- a/nid3/doc/nid3-header.html +++ /dev/null @@ -1,208 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
-
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-
-
-
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
-
-
- <title>Nepomuk ID3 Ontology (NID3)</title>
-</head>
-
-
-<body>
-
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
-
-
-<h1>NEPOMUK ID3 Ontology</h1>
-
-
-<big style="color: rgb(0, 90, 156);">Task-Force Ontologies</big>
-<dl>
-
-
- <dt></dt>
-
-
- <dt></dt>
-
-
- <dt>Latest Version:</dt>
-
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/nid3">http://www.semanticdesktop.org/ontologies/nid3</a>
- </dd>
-
-
- <dt></dt>
-
-
- <dt>This Version:</dt>
-
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2007/05/10/nid3#">http://www.semanticdesktop.org/ontologies/2007/05/10/nid3</a>
- <br/>This file refers to the Revision 9 of NIE. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.</dd>
-
-
- <dt></dt>
-
-
- <dt>Authors:</dt>
-
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
-
-
- <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
-
-
- <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.uni-kl.de">elst@dfki.uni-kl.de</a></dd>
-
-
-</dl>
-
-
-<dl>
-
-
- <dt>Editor:</dt>
-
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
-
-</dl>
-
-
-<dl>
-
-
- <dt>Contributors:</dt>
-
-
- <dd>Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, <a href="mailto:stexx@mail.ru">stexx@mail.ru</a></dd>
-
-
- <dd>Christiaan Fluit, Aduna, <a href="mailto:christiaan.fluit@aduna-software.com">christiaan.fluit@aduna-software.com</a></dd>
-
-
- <dt><span style="font-weight: bold;"></span></dt>
-
-
- <dt><span style="font-weight: bold;">Ontology:</span></dt>
-
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/05/10/nid3/nid3_data.rdfs">NID3
-(Data Graph Only)</a></dd>
-
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/05/10/nid3/nid3_metadata.rdfs">NID3
-(Metadata Graph Only)</a></dd>
-
-
- <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/05/10/nid3/nid3.trig">NID3
-(Graph Set)</a></dd>
-
-
- <dt></dt>
-
-
-</dl>
-
-
-</div>
-
-
-<p class="copyright"> Copyright © 2007 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>®</sup>
-The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
-</p>
-
-
-<hr />
-<h2>Abstract</h2>
-
-
-<p style="text-align: justify;"> ID3 is a common standard
-for audio metadata. It has become widespread with the profusion of MP3
-files. The NEPOMUK ID3 ontology (NID3) makes it possible to express ID3
-information in RDF, thus bringing it within reach of RDF-enabled
-application. This document gives an overview of NID3 and describes its
-classes and properties.
-</p>
-
-
-<h2> Status of this document</h2>
-
-
-<div id="sotd">
-<p style="text-align: justify;"> This document arose from
-the work of the Task-Force ontologies within the <a href="http://nepomuk.semanticdesktop.org">NEPOMUK project</a>.
-This document is a DRAFT made available by the Nepomuk Consortium for
-discussion only. This document is a work in progress and may be
-updated, replaced, or rendered obsolete by other documents at any time.
-</p>
-
-
-<p style="text-align: justify;"> This document is a part
-in a set of seven documents, which together comprise the complete
-specification of the Nepomuk Information Element Ontology
-Framework. These are: <a href="http://www.semanticdesktop.org/ontologies/nie">NIE</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nfo">NFO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nco">NCO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nmo">NMO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/ncal">NCAL</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nexif">NEXIF</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nid3">NID3</a>.
-</p>
-
-
-</div>
-
-
-<div>
-<h2 id="intro">Ontology description</h2>
-
-
-<p style="text-align: justify;">
-ID3 is a popular standard of audio metadata. It has gained popularity
-with the profusion of MP3 files, but it's not limited to the MP3
-format. The authors of the Nepomuk ID3 Ontology (NID3) haven't found
-any previous attempts at converting the ID3 specifications to RDF. NID3
-has been created from scratch as an exact adaptation of the <a href="http://www.id3.org/id3v2.3.0">ID3 v. 2.3.0 Standard
-Document</a>. It covers all ID3v2 frames defined in section 4 of
-the standard document with the exception of subsections: 4.6, 4.7, 4.8.
-Subsections from 4.12 to 4.28 inclusive aren't covered either.</p>
-
-
-<p style="text-align: justify;">
-The NID3 properties have been carefully aligned with <a href="http://www.semanticdesktop.org/ontologies/nco">NCO</a>
-(mainly <a href="http://www.semanticdesktop.org/ontologies/nco#creator">nco:creator</a>
-and
-<a href="http://www.semanticdesktop.org/ontologies/nco#contributor">nco:contributor</a>)
-and Dublin Core (e.g. <a href="http://www.dublincore.org/documents/dces/#rights">dc:rights</a>).
-Refer to the documentation for details.
-</p>
-
-
-</div>
-
-<div>
-<a name="sec-examples"></a>
-<h2><a name="sec-examples">Examples</a></h2>
-
-Example files that show how to use the expressive power of the ontology will be
-published here in near future.
-
-</div>
\ No newline at end of file diff --git a/nie/doc/bigPicture.png b/nie/doc/bigPicture.png Binary files differdeleted file mode 100644 index 5a78662..0000000 --- a/nie/doc/bigPicture.png +++ /dev/null diff --git a/nie/doc/exampleMailAttachment.png b/nie/doc/exampleMailAttachment.png Binary files differdeleted file mode 100644 index 60a65e5..0000000 --- a/nie/doc/exampleMailAttachment.png +++ /dev/null diff --git a/nie/doc/interpretation-containment.png b/nie/doc/interpretation-containment.png Binary files differdeleted file mode 100644 index 1361314..0000000 --- a/nie/doc/interpretation-containment.png +++ /dev/null diff --git a/nie/doc/nepomukUniverse.png b/nie/doc/nepomukUniverse.png Binary files differdeleted file mode 100644 index f2f9b28..0000000 --- a/nie/doc/nepomukUniverse.png +++ /dev/null diff --git a/nie/doc/nie-header.html b/nie/doc/nie-header.html deleted file mode 100644 index 2403711..0000000 --- a/nie/doc/nie-header.html +++ /dev/null @@ -1,987 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
- <title>Nepomuk Information Element Ontology (NIE)</title>
-
-
-</head>
-
-
-<body>
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
-
-<h1>NEPOMUK Information Element Ontology</h1>
-
-<big style="color: rgb(0, 90, 156);">Task-Force Ontologies<br />
-
-</big>
-<dl>
-
- <dt>Latest Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/nie">http://www.semanticdesktop.org/ontologies/nie</a>
-
- <dt></dt>
-
- <dt>This Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2007/01/19/nie">http://www.semanticdesktop.org/ontologies/2007/01/19/nie</a>
- <br/>This file refers to the Revision 9 of NIE. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.</dd>
-
- <dt></dt>
-
- <dt>Authors:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
-
- <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
-
- <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.uni-kl.de">elst@dfki.uni-kl.de</a></dd>
-
- <dt></dt>
-
- <dt>Editor:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
- <dd></dd>
-
- <dt>Contributors:</dt>
-
- <dd>Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, <a href="mailto:stexx@mail.ru">stexx@mail.ru</a></dd>
-
- <dd>Christiaan Fluit, Aduna, <a href="mailto:christiaan.fluit@aduna-software.com">christiaan.fluit@aduna-software.com</a></dd>
-
-</dl>
-
-<dl>
-
- <dt><span style="font-weight: bold;">Ontology:</span></dt>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/01/19/nie/nie_data.rdfs">NIE
-(Data Graph Only)</a></dd>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/01/19/nie/nie_metadata.rdfs">NIE
-(Metadata Graph Only)</a></dd>
-
- <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/01/19/nie/nie.trig">NIE
-(Graph Set)</a></dd>
-
-</dl>
-
-</div>
-
-<p class="copyright"> Copyright © 2007 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>®</sup>
-This work is made available under the terms of NEPOMUK <a href="http://nepomuk.semanticdesktop.org/LICENSE.txt">software
-license</a>
-</p>
-
-<hr />
-<h2>Abstract</h2>
-
-<p style="text-align: justify;"> The NEPOMUK Information
-Element Framework is an attempt to provide unified vocabulary for
-describing native resources available on the desktop. This document
-presents the high-level overview of the entire framework, its
-motivations and design decisions, as well as classes and properties
-that comprise the core part of the framework - the NEPOMUK Information
-Element Ontology itself.
-</p>
-
-<h2> Status of this document</h2>
-
-<div id="sotd">
-<p style="text-align: justify;"> This document arose from
-the work of the Task-Force ontologies within the <a href="http://nepomuk.semanticdesktop.org">NEPOMUK project</a>.
-This document is a DRAFT made available by the NEPOMUK Consortium for
-discussion only. This document is a work in progress and may be
-updated, replaced, or rendered obsolete by other documents at any time.</p>
-
-<p style="text-align: justify;"> This document is a part
-in a set of seven documents, which together comprise the complete
-specification of the NEPOMUK Information Element Ontology Framework.
-These are: <a href="http://www.semanticdesktop.org/ontologies/nie">NIE</a>, <a href="http://www.semanticdesktop.org/ontologies/nfo">NFO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nco">NCO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nmo">NMO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/ncal">NCAL</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nexif">NEXIF</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nid3">NID3</a>.
-</p>
-
-</div>
-
-<div class="toc">
-<h2 id="contents">Contents</h2>
-
-<blockquote> <a href="#sec-introduction">1.
-Introduction</a><br />
-
- <a href="#sec-background">2. Background</a><br />
-
- <a href="#sec-nepomukontologies">3. Overview of the
-NEPOMUK ontology architecture</a><br />
-
- <a href="#sec-basicdecisions">4. Basic design decisions</a>
- <blockquote> <a href="#sec-nrl">4.1 Use NEPOMUK
-Representational Language</a><br />
-
- <a href="#sec-usefullness">4.2 Make NIE usefull for
-the Semantic Desktop</a>
- <blockquote> <a href="#sec-unification">4.2.1
-Unification of ontologies</a><br />
-
- <a href="#sec-integration">4.2.2 Integration of
-ontologies</a> </blockquote>
-
- <a href="#sec-scope">4.3 Don't go beyond the intended
-scope of NIE</a><br />
-
- <a href="#sec-migration">4.4 Allow for easy migration
-and conform to the standards</a> </blockquote>
-
- <a href="#sec-overview">5. High-level overview of the
-entire NIE Framework</a><br />
-
- <a href="#sec-niedescription">6. Description of the NIE
-Ontology</a>
- <blockquote> <a href="#sec-dataobjects">6.1 Data
-Objects</a><br />
-
- <a href="#sec-informationelements">6.2 Information
-Elements</a><br />
-
- <a href="#sec-datasources">6.3 Data Sources</a> </blockquote>
-
- <a href="#sec-guidelines">7. Guidelines for extending NIE</a> <br />
- <a href="#sec-examples">8. Examples</a>
-</blockquote>
-
-</div>
-
-<div>
-<a name="sec-introduction"></a>
-<h2><a name="sec-introduction">1. Introduction</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-introduction">Since the dawn of the Semantic
-Web much effort has been exercised to bring its power to the desktop.
-One of the most important parts of this aim is to leverage
-existing information sources and make them accessible to 'semantic'
-systems. This information is contained within various structures
-maintained by the operating system and a multitude of existing 'legacy'
-applications. These structures include files, messages, documents,
-pictures, calendar entries and contacts in addressbooks. Ludger van
-Elst coined the term `native structures' to
-describe them and 'native resources' for the pieces of information they
-contain.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-introduction">A successful Semantic Desktop
-system cannot deny the existence of native structures. Dealing with
-them is an issue that needs to be tackled on every attempt to realize
-the Semantic Desktop vision. What follows is an account of the approach
-adopted within the NEPOMUK Social Semantic Desktop project, followed by
-the specification of the NEPOMUK Information Element Framework (NIE),
-vocabulary developed to express native structures in RDF.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-introduction">Note that the abbreviation NIE
-may refer to the NIE Framework as a whole or to the NIE Ontology - the
-core part of the framework. In most cases the former meaning is used,
-unless explicitly stated otherwise.
-</a></p>
-
-</div>
-
-<div>
-<a name="sec-background"></a>
-<h2><a name="sec-background">2. Background</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-background">The problem is a difficult one
-given the multitude of applications and data formats. Previous semantic
-desktop projects (e.g. </a><a href="http://haystack.lcs.mit.edu/">Haystack</a> or <a href="http://www.gnowsis.org/">Gnowsis</a>) had to
-develop their solutions. Some attempts at standardization have been
-made (<a href="http://www.adobe.com/products/xmp/">Adobe
-XMP</a> or <a href="http://freedesktop.org/wiki/XesamAbout">Freedesktop.org
-XESAM</a>) but a definite standard hasn't emerged yet.</p>
-
-<p style="text-align: justify;">
-Apart from large metadata description frameworks there exists a
-considerable number of smaller single-purpose ontologies aimed at
-specific types of resources
-(e.g. <a href="http://www.w3.org/2002/12/cal/ical">ICAL</a>
-or <a href="http://www.w3.org/TR/vcard-rdf">VCARD</a>).
-A broad array of utilities has been developed for extracting RDF
-metadata from desktop sources (see <a href="http://simile.mit.edu/wiki/RDFizers">RDFizers website</a>,
-for an overview).</p>
-
-<p style="text-align: justify;">
-Various problems have been identified with those ontologies. They are
-expressed in many languages, often aren't as detailed as one would
-like, sometimes contain
-outright bugs. NEPOMUK Information Element Framework is an attempt to
-build upon
-that experience, to provide unified vocabulary to describe typical
-native resources that may be of interest to the user. These resources
-are intended to serve as raw data for other semantic applications. They
-can be browsed, searched,
-annotated and linked with each other. It is hoped that this framework
-will help to achieve the critical mass of raw RDF data that will ignite
-rapid development of applications which will bring actual value to the
-user and make everyday work
-easier and more productive.</p>
-
-<p style="text-align: justify;">
-The open source community has recently started a widespread
-standardization activity under the name of <a href="http://freedesktop.org/wiki/XesamAbout">XESAM Project</a>.
-It gathers together developers from many important desktop search
-projects like <a href="http://strigi.sourceforge.net/">Strigi</a>,
-<a href="http://beagle-project.org/">Gnome Beagle</a>,
-<a href="http://www.gnome.org/projects/tracker/">Gnome
-Tracker</a>, <a href="http://pinot.berlios.de">Pinot</a>
-and <a href="http://www.lesbonscomptes.com/recoll/">Recol</a>.
-The NEPOMUK project has been involved in this effort. NIE has
-benefitted much from the insight of XESAM developers (most notably
-Evgeny Egorochkin). Even though the ontologies themselves are kept
-separate, due
-to certain differences in requirements, NIE strived to maximize
-interoperability
-with XESAM and provide direct equivalents of XESAM classes an
-properties wherever possible.
-</p>
-
-</div>
-
-<div>
-<a name="sec-nepomukontologies"></a>
-<h2><a name="sec-nepomukontologies">3. Overview of
-the NEPOMUK ontology architecture</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-nepomukontologies">In order to justify the
-design decisions that were made when creating NIE, a short introduction
-on the ontology architecture of NEPOMUK is necessary. It can be
-conceptually divided in two tiers.
-</a></p>
-
-<div style="text-align: center;"><a name="sec-nepomukontologies">
-<img style="width: 464px; height: 403px;" alt="NEPOMUK Universe" src="nepomukUniverse.png" /></a></div>
-
-<p style="text-align: justify;">
-<a name="sec-nepomukontologies">The lower one is the data
-tier. It stores the native data extracted from various
-data sources on the desktop. These include filesystems, mailboxes,
-calendars, and addressbooks. They are usually maintained
-by external applications, that are not part of NEPOMUK by themselves.
-The user still uses Kontact or MS Outlook for contacts and events,
-OpenOffice or Word for writing documents etc. The upper ontology layer
-is composed of concepts and instances that make up the Personal
-Information Model. They represent more abstract entities. </a></p>
-
-<p style="text-align: justify;"><a name="sec-nepomukontologies">Native resources are extracted,
-converted to
-RDF and made available for Semantic Web software agents. An approach is
-to store
-converted RDF in a repository, making it queryable. Another approach is
-to adapt datasources dynamically, using virtual RDF graphs
-but in general, extraction and storing RDF in a queryable index is the
-common approach, also used by the other desktop search engines.</a></p>
-
-<p style="text-align: justify;"><a name="sec-nepomukontologies">Data represented in NIE has
-three roles. First, NIE data is intended to be generated by an
-extraction process.
-Second, RDF-based systems can create NIE structures natively, without
-building
-on existing applications. Third, data expressed in NIE can be imported
-back to native applications. The ontology is therefore a mediator
-between semantic and
-native applications. </a></p>
-
-<p style="text-align: justify;"><a name="sec-nepomukontologies">These roles explain some
-of the design decisions outlined below. They are a
-direct result of the following assumptions about the NEPOMUK
-architecture:</a></p>
-
-<ul style="text-align: justify;">
-
- <a name="sec-nepomukontologies"> <li>The 'PIMO'
-layer can much more easily work with native resources if they are
-expressed
-in a single language (see </li>
-
- </a><a href="#sec-nrl">here</a>), using
-limited vocabulary
-(see <a href="#unification">here</a>), where
-similar entities are always
-expressed in the same way with the same vocabulary elements (see <a href="#integration">here</a>). <li>The task of
-dealing with dynamic nature of the native resources can be more easily
-tackled
-when it is divided into two subtasks :
- <ul>
-
- <li>synchronizing the 'real-life' with the data repository,
-that doesn't contain abstract concepts</li>
-
- <li>synchronizing the data repository with the abstract
-concepts in the personal information model</li>
-
- </ul>
-
-These subtasks can be assigned to different components that only need
-limited
-knowledge to perform them and can thus be much simpler.</li>
-
-</ul>
-
-<p style="text-align: justify;">
-The authors of this document believe that these assumptions would also
-hold for
-other semantic desktop systems.<a name="sec-basicdecisions"></a></p>
-
-</div>
-
-<div>
-<h2><a name="sec-basicdecisions">4. Basic design
-decisions</a></h2>
-
-<p style="text-align: justify;"><a name="sec-basicdecisions">Requirements stated above led to
-certain guidelines for the ontology design.
-The following sections
-contain a brief outline of them. This is by no means a sound and
-complete set of
-axioms that are always correct, but a set of factors that were taken
-into
-account. They are given in their perceived order of importance.
-Developers of
-ontologies that will extend NIE to describe new kinds of data are
-strongly
-encouraged to be consistent with them.</a></p>
-
-<a name="sec-nrl">
-</a>
-<h3><a name="sec-nrl">4.1 Use NEPOMUK
-Representational Language</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-nrl">NIE is expressed in the NEPOMUK
-Representational Language as defined in the
-recently published specification (</a><a href="#ref-nrlspec">[NRLSPEC]</a>).
-This
-means, that whenever some existing ontologies are to be reused, they
-need to
-be adapted to NRL. Author's experience suggests that such an adaptation
-would usually entail following steps:</p>
-
-<ol style="text-align: justify;">
-
- <li> Remove language constructs that are not present in RDFS.
-Some of them have
-their NRL equivalents (like FunctionalProperty or TransitiveProperty in
-OWL or
-Protege ontologies). Others don't (e.g. OWL unions or Protege
-overriding
-properties). If a construct has a NRL equivalent - it may be
-substituted. If
-not, then the information may be expressed in the, rdfs:comment or in
-the
-documentation.</li>
-
- <li> Create a new namespace for the new ontology, to
-distinguish between the original
-one and the new representation in NRL. </li>
-
- <li> Let all properties
-have concrete domains and ranges. Bring the ontology to a state where
-the data
-that conforms to it doesn't need to have any untyped nodes.</li>
-
- <li> Provide links with the original ontology (e.g. via
-rdfs:subClassOf or
-rdfs:subPropertyOf relationships) if possible.</li>
-
- <li>Examine the ontology for possibilities of alignment with
-existing NIE ontologies, in accordance with the <a href="#sec-integration">integration</a>
-guidelines.</li>
-
-</ol>
-
-<p style="text-align: justify;">
-This decision is fundamental in its nature. It could be interpreted as
-being
-against the spirit of reuse, pervasive in the Semantic Web community.
-It brings
-many benefits though. They include:</p>
-
-<ol>
-
- <li style="text-align: justify;"> Easier consistency
-checking. There are differences between semantics
-of various ontology languages. Some of them don't specify any
-constraints.
-(e.g. RDF/S domains and ranges aren't interpreted as constraints that
-have to be met, but as rules that entail facts. [<a href="#ref-rdfsemantics">RDFSEMANTICS</a>]) Apart from
-that many well-established ontologies (like Dublin Core [<a href="#ref-dcspec">DCSPEC</a>], Kanzaki EXIF [<a href="#ref-exifrdf">EXIFRDF</a>] or important parts of
-ICAL [<a href="ref-icalrdf">ICALRDF</a>] don't have
-the
-domains and ranges specified at all, so there is nothing to check.</li>
-
- <li style="text-align: justify;"> Simpler inference. An
-inferencer would have to reason
-over data that uses vocabulary from many ontologies in many languages. </li>
-
- <li style="text-align: justify;"> Explicit connections
-between ontologies. The application developer would need to be aware of
-the fact
-that an instance of a class from one ontology, might also be annotated
-with
-properties from some other ontology. This is important information,
-that is not
-expressed in the ontology itself. </li>
-
- <li style="text-align: justify;"> Unified ontology
-universe. Since the Personal Information Model would definitely be
-expressed in NRL
-- leaving the raw data described in its 'original' vocabulary would
-split the
-'NEPOMUK universe' into two parts - one consistent, well checked, where
-inference is efficient and well-implemented - the part in NRL, and the
-chaotic,
-unchecked part in all possible languages.</li>
-
- <li style="text-align: justify;"> Easier data
-integration. Algorithms would need to have knowledge of multiple
-languages and
-differences in their semantics. Using single language removes this
-burden and
-paves the way for further benefits - described in the next section. </li>
-
-</ol>
-
-<a name="sec-usefullness">
-</a>
-<h3><a name="sec-usefullness">4.2 Make NIE usefull
-for the Semantic Desktop</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-usefullness">The main goal of the Semantic
-Desktop is to aid the user in his/her everyday
-tasks. In order to achieve this goal - the user wants to have a uniform
-view of
-all his/her data, where application boundaries are not important. This
-requirement is a very important one. It implies that wherever data with
-similar
-'meaning' is stored or processed - it needs to be described using the
-same
-vocabulary. Having multiple disparate vocabularies for dealing with
-similar
-entities would make the task of data integration much more difficult.
-In the
-previous section we mentioned that differences between representational
-languages are to be avoided. Here we fortify that claim by saying that
-overlap
-between multiple ontologies in the same domain is also unadvisable.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-usefullness">This statement has two practical
-consequences. They are outlined below.
-</a></p>
-
-<a name="sec-unification">
-</a>
-<h4><a name="sec-unification">4.2.1 Unification of
-ontologies</a></h4>
-
-<p style="text-align: justify;">
-<a name="sec-unification">In domains where there are many
-competing 'de facto standard' ontologies - for
-NIE either one of them is chosen (and adapted - see </a><a href="#ref-nrl">sec. 4.1</a>) or both are
-merged into a third one, with incosistencies resolved. It is definitely
-not the
-purpose of NEPOMUK to deny existence of publicly available ontologies.
-NEPOMUK
-wants to provide a platform that would simplify the development of
-semantically-enabled applications. To achieve this goal NEPOMUK aims to
-alleviate the burden of learning and supporting multiple vocabularies.</p>
-
-<p style="text-align: justify;">
-If the user needs to integrate data expressed in the vocabulary of some
-other
-ontology into the NEPOMUK knowledge base it needs to be transformed
-into NRL and
-aligned with other NEPOMUK ontologies. This will enable NEPOMUK
-applications to process it easily. Maintaining a single import/export
-utility is
-much less costly than having all applications support all vocabularies.
-In a
-domain where many applications need to work with many vocabularies,
-there is an
-entire matrix of combinations that need to be supported. A unified
-approach
-encouraged by NEPOMUK aims to reduce this complexity from quadratic to
-linear.</p>
-
-<p style="text-align: justify;">
-NEPOMUK doesn't aim to substitute existing data with their RDF
-counterparts. The
-complexity of existing and future data formats makes round-trip 1 to 1
-transformation between RDF and the native format nearly impossible.
-There were
-attempts at creating vocabularies that would express all complexities
-of a
-non-rdf data format. (e.g. [<a href="ref-icalrdf">ICALRDF</a>],
-or [<a href="ref-vcardrdf">VCARDRDF</a>]). Even
-if they succeeded in achieving high level of conformance, they didn't
-explore
-real benefits of RDF, like common datatypes and URI references.
-Ontologies that
-resulted from these attempts have deficiencies that inhibit their
-usefullness
-within social semantic desktop context.
-</p>
-
-<a name="sec-integration">
-</a>
-<h4><a name="sec-integration">4.2.2 Integration of
-ontologies</a></h4>
-
-<p style="text-align: justify;">
-<a name="sec-integration">Tight integration between
-ontologies is needed. Some data formats contain
-references to entities that fall beyond their intended scope, but are
-nevertheless important. Examples might include references to contacts
-in emails
-(to, from, cc, bcc fields), calendar events (attendee, rsvp) or text
-documents
-(author, reviewer). These references are mostly incomplete. (a 'to'
-field in an
-email usually contains only the address, sometimes a name).
-Nevertheless it is
-better for these occurences to be described as instances of classes
-from a
-specialized ontology (even though these instances might hardly contain
-more that
-one or two fields) than leave them as plain string values.</a></p>
-
-<p style="text-align: justify;">
-<a name="sec-integration">Having such incomplete instances
-facilitates ontology alignment. It is
-comparatively easy to create and algorithm that browses all instances
-of a given
-class and implements some similarity measure to detect duplicates in
-order to
-link them with a unique instance of some higher-level concept. If those
-instances were expressed with plain strings, the problem would become
-more
-difficult.
-</a></p>
-
-<a name="sec-scope">
-</a>
-<h3><a name="sec-scope">4.3 Don't go beyond the
-intended scope of NIE</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-scope">NIE contains concepts that are
-directly related to native resources available on
-a local desktop or in the network. These are mostly files or can be
-mapped to
-parts of files. (like calendar entries are parts of a calendar file,
-contacts
-are part of an addressbook file etc.) It doesn't contain abstract
-concepts that
-don't have their direct representations as sequences of bytes (like
-'Person',
-'Project', 'Publication', 'Job' etc.) These are delegated to other
-ontologies.
-It is the task of appropriate tools to map between the 'raw' data and
-those
-'high-level' concepts.
-</a></p>
-
-<a name="sec-migration">
-</a>
-<h3><a name="sec-migration">4.4 Allow for easy
-migration and conform to the standards</a></h3>
-
-<p style="text-align: justify;">
-<a name="sec-migration">The most immediate goal of NIE is
-to replace ontologies currently used by
-Aperture, Beagle++ and Strigi. That's why NIE is designed with easy
-migration in
-mind, wherever it didn't clash with above objectives. Moreover existing
-standards are to be observed. This means widespread norms, usually
-issued by
-official standardization bodies like World Wide Web Consortium (W3C
-Recommendations), Internet Engineering Task Force (RFC Documents),
-International
-Organization for Standardization etc. Specific attention is given to
-the
-standardization effort undertaken by the open source community in the
-XESAM
-Project (eXtEnsible Search And Metadata Specification).
-</a></p>
-
-</div>
-
-<div>
-<a name="sec-overview"></a>
-<h2><a name="sec-overview">5. High-level overview of
-the NIE Framework</a></h2>
-
-<div style="text-align: center;"><a name="sec-overview">
-<img style="width: 851px; height: 1220px;" alt="High-Level Overview" src="bigPicture.png" /></a></div>
-
-</div>
-
-<div>
-<a name="sec-niedescription"></a>
-<h2><a name="sec-niedescription">6. Description of
-the NIE Ontology</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-niedescription">The core of the NEPOMUK
-Information Element Ontology and the entire NIE Framework
-revolves around the concepts of </a><a href="#DataObject">DataObject</a>
-and <a href="#InformationElement">InformationElement</a>.
-They express
-the representation and content of a piece of data. Their specialized
-subclasses can
-be used to classify a wide array of desktop resources and express them
-in RDF.
-</p>
-
-<a name="sec-dataobjects">
-</a>
-<h3><a name="sec-dataobjects">6.1 DataObjects</a></h3>
-
-<p style="text-align: justify;">
-<a href="#DataObject">DataObjects</a> represent
-physical entities that contain data. They are extracted from
-filesystems,
-archives, contact lists, mailboxes etc. The representation itself is
-usually not
-interesting to the user. In order for a piece of data to be actually
-understood,
-it needs to be interpreted as an appropriate type of an
-InformationElement. Such
-an interpretation makes it possible to inspect the content of a <a href="#DataObject">DataObject</a>
-correctly, and possibly divide it into parts - new <a href="#DataObject">DataObjects</a> which can have
-their
-own interpretations. This process is iterative and continues as long as
-needed.</p>
-
-<p style="text-align: justify;">
-All
-resources on the desktop are basically related to each other with two
-most
-fundamental types of relations: interpretation and containment.</p>
-
-<p style="text-align: center;"><img style="width: 488px; height: 478px;" alt="Interpretation/Containment" src="interpretation-containment.png" /> </p>
-
-<p style="text-align: justify;">
-<a href="#DataObject">DataObject</a> represents a
-native entity the user works with. The usage of the term
-'native' is important. It means that a <a href="#DataObject">DataObject</a>
-can usually be directly mapped
-to a sequence of bytes. Examples include a file, a set of files or a
-part of a
-file. The granularity depends on the user. <a href="#DataObject">DataObject</a>
-is atomic in the sense, that in order to
-distinguish any more data objects within, it has to be interpreted
-first.</p>
-
-<p style="text-align: justify;">
-The detailed list of <a href="#DataObject">DataObject</a>
-subclasses is subject to extension. It is
-envisioned that future applications will define their own <a href="#DataObject">DataObject</a> subclasses
-in their own ontologies. The NEPOMUK Information Element Ontology
-defines only
-the most generic properties deemed applicable to all <a href="#DataObject">DataObjects</a>. More specific
-information is to be expressed using vocabularies extending NIE.
-</p>
-
-<a name="sec-informationelements">
-</a>
-<h3><a name="sec-informationelements">6.2
-Information Elements</a></h3>
-
-<p style="text-align: justify;">
-<a href="#InformationElement">InformationElement</a>
-is a piece of information stored within a data object. Content-specific
-properties are defined as
-properties of an <a href="#InformationElement">InformationElement</a>.
-It is separate from the <a href="#DataObject">DataObject</a>
-in order
-to make the interpretation independent of the representation. Research
-has shown
-that this flexibility is necessary to create a framework flexible
-enough to
-accomodate for the complexity of data structures present on the
-desktop. For
-example let's consider a mailbox. It is usually stored in a file (this
-is
-expressed as a FileDataObject interpreted as a Mailbox). An IMAP
-mailbox though is
-stored on a remote server, but from the interpretation point of view it
-doesn't
-differ from a file mailbox (in NIE this is expressed as a
-RemoteHostAddress
-interpreted as a Mailbox). Another representation may be a software
-service
-available through some interprocess communication mechanism (as is the
-case of
-the Outlook mailbox available via a COM interface). In NIE this is
-expressed
-as a SoftwareService interpreted as a mailbox). We have three
-completely
-different representations (file, remote host, software service) with an
-identical interpretation (Mailbox).</p>
-
-<p style="text-align: justify;">
-For a more thorough example see figure below. We see
-an in-file mailbox, containing an email, which contains an attachment.
-Notice
-that entities appearing on the right side can also appear at different
-levels.
-Apart from the already mentioned mailbox, there are other
-possibilities. A
-partition may be interpreted as a filesystem, but also a file
-containing an
-image of a DVD can be interpreted as a filesystem. A <a href="http://www.semanticdesktop.org/ontologies/nmo#MailboxDataObject">MailboxDataObject</a>
-can be
-interpreted as a <a href="http://www.semanticdesktop.org/ontologies/nmo#Message">Message</a>,
-but an .eml file too. The same applies to <a href="http://www.semanticdesktop.org/ontologies/nco#Contact">Contacts</a>.
-We
-may have a single .vcf file containing a single VCARD, which is
-interpreted as a
-<a href="http://www.semanticdesktop.org/ontologies/nco#Contact">Contact</a>,
-but an email
-<a href="http://www.semanticdesktop.org/ontologies/nfo#Attachment">Attachment</a>,
-or a <a href="http://www.semanticdesktop.org/ontologies/nfo#RemoteDataObject">RemoteDataObject</a>
-may have the same
-interpretation.</p>
-
-<div style="text-align: center;"><img style="width: 403px; height: 348px;" alt="Mail Attachment Example" src="exampleMailAttachment.png" />
-</div>
-
-<p style="text-align: justify;">
-This approach gives a uniform overview of data regardless of how it's
-represented.
-</p>
-
-<a name="sec-datasources">
-</a>
-<h3><a name="sec-datasources">6.3 Data Sources</a></h3>
-
-<p style="text-align: justify;">
-<a href="#DataObject">DataObject</a> instances don't
-just come out of thin air. They are usually extracted
-from some data source. These are represented by instances of a <a href="#DataSource">DataSource</a> class. Each instance
-represents a native application or system,
-that manages information. A <a href="#DataSource">DataSource</a>
-instance aggregates information required
-by the data extraction component to gain access to the source. In the
-case of a
-<a href="http://www.semanticdesktop.org/ontologies/nfo#Filesystem">Filesystem</a>,
-this
-may be a path, for a <a href="http://www.semanticdesktop.org/ontologies/nmo#Mailbox">Mailbox</a>
-this may be the hostname, login and password etc.</p>
-
-<p style="text-align: justify;">
-Various subclasses of a <a href="#DataSource">DataSource</a>
-are envisioned. They may include filesystems data sources,
-calendar data sources, website data sources etc. The exact choice of
-types and properties
-is considered specific to a particular rdf extraction application. Data
-extraction applications are encouraged
-to provide their own data source ontologies. Such an ontology should
-contain
-data source types supported by the application coupled with properties
-necessary
-to gain access to them.</p>
-
-<p style="text-align: justify;">
-It is important to notice that certain entities (such as a mailbox or a
-filesystem)
-may appear both as a DataSource and as an InformationElement. They
-should not
-be confused though. They are completely different classes with
-completely different
-meaning. DataSource is an entity for which an rdf extraction framework
-of choice
-has an adapter for. DataObjects are extracted from it, either
-automatically when
-they appear (with some kind of monitoring process) or manually at the
-wish of the user.</p>
-
-<p style="text-align: justify;">
-The choice of subclasses of a DataSource depends specifically
-on the capabilities of the chosen rdf extraction framework. Some
-frameworks prefer to
-use an integrated approach (like the 'personal information space' from
-Beagle) where the Desktop is treated as a whole, and no specific data
-sources are distinguished.
-Other (like Aperture), work with a specific set of data source types
-(e.g.
-FilesystemDataSource, IMAPDataSource, IcalDataSource etc.). In the
-Aperture example
-a Filesystem instance is extracted from a FilesystemDataSource, just as
-all files.</p>
-
-<p style="text-align: justify;">
-The provenance of a DataObject is represented by the <a href="#dataSource">dataSource</a> property. In many
-usage scenarios it is important to keep track of
-the provenance of each data object. This information is useful for a
-number of
-reasons.</p>
-
-<ul style="text-align: justify;">
-
- <li>It augments the value of the information contained within
-the object itself. </li>
-
- <li>It could be used to open a resource in it's native
-application for editing.</li>
-
- <li>If a user wishes to remove a data source from the system,
-or stop monitoring it, the dataSource
-property can be used to identify resources that have been extracted
-from this
-data source, so that they can also be removed.</li>
-
-</ul>
-
-<p style="text-align: justify;">
-Note that this approach itself allows for an arbitrary hierarchy of
-data objects. It
-makes the structure of the extracted data independent of the
-capabilities of a particular extraction framework. It can
-be used by all-encompassing semantic desktop systems, as well as
-smaller libraries specialized in a single type of data
-source. The former would probably begin with some high-level concept
-such as
-<a href="http://www.semanticdesktop.org/ontologies/nfo#HardDiskPartition">HardDiskPartition</a>
-or a <a href="http://www.semanticdesktop.org/ontologies/nfo#SoftwareItem">SoftwareItem</a>
-interpreted as an <a href="http://www.semanticdesktop.org/ontologies/nfo#OperatingSystem">OperatingSystem</a>
-and build a containment tree to the very bottom. The latter could
-begin their work somewhere in the middle (e.g. an mbox file crawler)
-and proceed
-as deep as they like.
-</p>
-
-</div>
-
-<div>
-<a name="sec-guidelines"></a>
-<h2><a name="sec-guidelines">7. Guidelines for
-extending NIE</a></h2>
-
-<p style="text-align: justify;">
-<a name="sec-guidelines">As said before, The NIE Ontology
-is intended to serve as a foundation for a
-broad framework. Extensions are to be added to accomodate for various
-types of
-DataObjects and InformationElements. Each extension is a separate
-ontology,
-housed within a separate namespace. It should accept the assumptions
-outlined in
-section </a><a href="sec-basicdecisions">'Basic
-decisions'</a> - be expressed in NRL and try not to extend
-beyond native desktop resources. A NIE extension can define its own
-types of
-Data entities (subclasses of <a href="#DataObject">DataObject</a>)
-and their interpretations (subclasses
-of <a href="#InformationElement">InformationElement</a>)
-or simply augment vocabulary provided elsewhere. The
-developers are encouraged to reuse classes and properties already
-defined in NIE (as stated <a href="#sec-integration">above</a>)
-or provide specializations for them
-(subclasses and subproperties).
-</p>
-
-</div>
-
-<div>
-<a name="sec-examples"></a>
-<h2><a name="sec-examples">8. Examples</a></h2>
-
-Example files that show how to use the expressive power of the ontology will be
-published here in near future.
-
-</div>
-
-<div>
-<h2>References</h2>
-
-<dl>
-
- <dt><a name="ref-nrlspec"></a>[NRLSPEC]</dt>
-
- <dd><cite><a href="http://www.semanticdesktop.org/ontologies/nrl">NEPOMUK
-Representational Language (NRL) Vocabulary Specification.</a></cite>, NEPOMUK Task-Force Ontologies,
-http://www.semanticdesktop.org/ontologies/nrl</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-rdfsemantics"></a>[RDFSEMANTICS]</dt>
-
- <dd><cite><a href="http://www.w3.org/TR/rdf-mt/">RDF
-Semantics</a></cite>, Patrick Hayes, W3C Recommendation
-http://www.w3.org/TR/rdf-mt/</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-dcspec"></a>[DCSPEC]</dt>
-
- <dd><cite><a href="http://www.dublincore.org/documents/dces/"> Dublin
-core metadata element set, version 1.1</a></cite>, DCMI
-Recommendation http://www.dublincore.org/documents/dces/</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-icalrdf"></a>[ICALRDF]</dt>
-
- <dd><cite><a href="http://www.w3.org/TR/rdfcal/">Rdf
-calendar - an application of the resource description framework to
-icalendar data</a></cite>, Dan Connolly and Libby Miller,
-W3C Interest Group Note 29 September 2005 http://www.w3.org/TR/rdfcal/</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-vcardrdf"></a>[VCARDRDF]</dt>
-
- <dd><cite><a href="http://www.w3.org/TR/vcard-rdf">Representing
-vcard objects in rdf/xml</a></cite>, Renato
-Ianella, W3C Note 22 February 2001 http://www.w3.org/TR/vcard-rdf</dd>
-
-</dl>
-
-<dl>
-
- <dt><a name="ref-exifrdf"></a>[EXIFRDF]</dt>
-
- <dd><cite><a href="http://www.kanzaki.com/ns/exif">Exif
-data description vocabulary</a></cite>, Masahide
-Kanzaki http://www.kanzaki.com/ns/exif</dd>
-
-</dl>
-
-</div>
diff --git a/nmo/doc/nmo-header.html b/nmo/doc/nmo-header.html deleted file mode 100644 index 66f6564..0000000 --- a/nmo/doc/nmo-header.html +++ /dev/null @@ -1,192 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
- <title>Nepomuk Message Ontology (NMO)</title>
-
-
-</head>
-
-
-<body>
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
-
-<h1>NEPOMUK Message Ontology</h1>
-
-<big style="color: rgb(0, 90, 156);">Task-Force Ontologies<br />
-
-</big>
-<dl>
-
- <dt>Latest Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/nmo">http://www.semanticdesktop.org/ontologies/nmo</a>
- </dd>
-
- <dt></dt>
-
- <dt>This Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo">http://www.semanticdesktop.org/ontologies/2007/03/22/nmo</a>
- <br/>This file refers to the Revision 9 of NIE. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.</dd>
-
- <dt></dt>
-
- <dt>Authors:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
-
- <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
-
- <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.uni-kl.de">elst@dfki.uni-kl.de</a></dd>
-
- <dt></dt>
-
- <dt>Editor:</dt>
-
- <dd>Antoni Mylka, DFKI, <a href="mailto:antoni.mylka@dfki.de">antoni.mylka@dfki.de</a></dd>
-
- <dt></dt>
-
- <dt>Contributors:</dt>
-
- <dd>Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, <a href="mailto:stexx@mail.ru">stexx@mail.ru</a></dd>
-
- <dd>Christiaan Fluit, Aduna, <a href="mailto:christiaan.fluit@aduna-software.com">christiaan.fluit@aduna-software.com</a></dd>
-
- <dt><span style="font-weight: bold;"></span></dt>
-
- <dt><span style="font-weight: bold;">Ontology:</span></dt>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo/nmo_data.rdfs">NMO
-(Data Graph Only)</a></dd>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo/nmo_metadata.rdfs">NMO
-(Metadata Graph Only)</a></dd>
-
- <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/03/22/nmo/nmo.trig">NMO
-(Graph Set)</a></dd>
-
-</dl>
-
-</div>
-
-<p class="copyright"> Copyright © 2007 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>®</sup>
-The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
-</p>
-
-<hr />
-<h2>Abstract</h2>
-
-<p style="text-align: justify;"> NEPOMUK Message Ontology
-extends the NEPOMUK Information Element framework into the domain of
-messages. Kinds of messages covered by NMO include Emails and instant
-messages. This document gives an overview of NMO and describes its
-classes and properties.
-</p>
-
-<h2> Status of this document</h2>
-
-<div id="sotd">
-<p style="text-align: justify;"> This document arose from
-the work of the Task-Force ontologies within the <a href="http://nepomuk.semanticdesktop.org">NEPOMUK project</a>.
-This document is a DRAFT made available by the Nepomuk Consortium for
-discussion only. This document is a work in progress and may be
-updated, replaced, or rendered obsolete by other documents at any time.
-</p>
-
-<p style="text-align: justify;"> This document is a part
-in a set of seven documents, which together comprise the complete
-specification of the Nepomuk Information Element Ontology Framework.
-These are: <a href="http://www.semanticdesktop.org/ontologies/nie">NIE</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nfo">NFO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nco">NCO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nmo">NMO</a>,
-<a href="http://www.semanticdesktop.org/ontologies/ncal">NCAL</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nexif">NEXIF</a>,
-<a href="http://www.semanticdesktop.org/ontologies/nid3">NID3</a>.</p>
-
-</div>
-
-<div>
-<h2 id="intro">Introduction</h2>
-
-<p style="text-align: justify;"> Messages - the domain of
-the Nepomuk Message Ontology (NMO) form a large part of
-the body of data available on a desktop. The user sends them, receives
-them, forwards them to other users, stores them and recalls them when
-they are needed. They are almost never self contained, always refering
-to something - to events, people, organizations, projects, activities,
-anything the user might be interested in. The purpose of NMO is to
-bring messages to the world of ontologies so that these links can be
-made explicit.
-</p>
-
-<h2>The Concept of a Message</h2>
-
-<p style="text-align: justify;">
-The concept of a message in everyday english is broad. The
-Thesaurus.com website
-lists 'message' under 36 different meanings. NMO had to limit itself to
-a familiar domain of electronic communication. In NMO a message is a
-finite sequence of bytes containing arbitrary information exchanged
-between a sender and at least one receiver. Notice the difference
-between definitions of a Message and a File - the presence of at least
-one sender and receiver, and the absence of the requirement about
-durability. Of course it doesn't exclude the possibility of a file
-interpreted as a message (e.g. a .eml file).</p>
-
-<p style="text-align: justify;">
-Even with these limitations, a taxonomy of messages can be defined.
-Subconcepts may include an Email, a message sent with an instant
-messaging application, an SMS, a voice message, a forum private message
-etc.</p>
-
-<p style="text-align: justify;">
-A message can have multiple receivers. It can be sent to multiple
-Contacts. A mailing list is treated as one contact, since the message
-itself is sent to one email address. The fact that it is forwarded to
-other people is not expressed in the byte sequence that comprises the
-message and therefore falls beyond the scope of NIE. Blog posts and
-forum posts are not considered Messages in the NMO sense. This
-statement may seem arbitrary at first. In the case of a forum post, the
-actual Message according to the NMO definition (and the overall notion
-of nie:DataObject) is the HTTP packet generated by the browser and
-received by the Web Server. It is usually hardly relevant for a typical
-user. There are other ontologies, better suited towards description of
-blogs and forums, most notably <a href="http://sioc-project.org/ontology">SIOC</a>.
-</p>
-
-</div>
-
-<div>
-<h2>Description of a Message</h2>
-
-<p style="text-align: justify;">
-The most important information about each Message is the sender,
-receiver and the dates. NMO provides properties to express this
-information. The choice of those properties has been inspired by header
-fields found in emails, but they are definitely applicable to other
-kinds of messages too. The nmo:references property
-(\ref{nmo:references}) can be used to express relations in dialogues.
-It would link an answer with the message it refers to.
-</p>
-
-</div>
-
-<div>
-<a name="sec-examples"></a>
-<h2><a name="sec-examples">Examples</a></h2>
-
-Example files that show how to use the expressive power of the ontology will be
-published here in near future.
-
-</div>
\ No newline at end of file diff --git a/nrl/doc/nrl-header.html b/nrl/doc/nrl-header.html deleted file mode 100644 index 6d9f543..0000000 --- a/nrl/doc/nrl-header.html +++ /dev/null @@ -1,11143 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html style="direction: ltr;" xmlns="http://www.w3.org/1999/xhtml" lang="en-us"> -<head> - - - - - - - - <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> - - - - - - - - <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" /> - - - - - - - - - - - - <title>NEPOMUK Representational Language (NRL)</title> - <meta content="Simon Scerri" name="author" /> - - - - - - - - <meta content="Specifications for the NEPOMUK Representational Language" name="description" /> -</head> - - -<body style="width: 900px; color: rgb(0, 0, 0);" alink="#ee0000" link="#0000ee" vlink="#551a8b"> - - - - -<div class="head"> -<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> </a><a href="http://nepomuk.semanticdesktop.org"><img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /></a><br /> - - - - -<h1>Nepomuk Representational Language Specification</h1> - - - - -<big style="color: rgb(0, 90, 156);">Task-Force Ontologies</big> -</div> - - - - -<dl> - - - - - <dt>Latest Version:</dt> - - - - - <dd><a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl">http://www.semanticdesktop.org/ontologies/nrl</a></dd> - - - - - <dt></dt> - - - - - <dt>This Version:</dt> - - - - - <dd><a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl">http://www.semanticdesktop.org/ontologies/2007/08/15/nrl</a></dd> - - - - -</dl> - - - - -<dl> - - - - - <dt>Authors:</dt> - - - - - <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd> - - - - - <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.uni-kl.de">elst@dfki.uni-kl.de</a></dd> - - - - - <dd>Simon Scerri, DERI/NUIG, <a href="mailto:simon.scerri@deri.org">simon.scerri@deri.org</a></dd> - - - - - <dd>Siegfried Handschuh, DERI/NUIG, <a href="../htmlinformal/siegfried.handschuh@deri.org">siegfried.handschuh@deri.org</a></dd> - - - - - <dt></dt> - - - - - <dt>Editor:</dt> - - - - - <dd>Simon Scerri, DERI/NUIG, <a href="mailto:simon.scerri@deri.org">simon.scerri@deri.org</a></dd> - - - - - <dt></dt> - - - - - <dt>Contributors:</dt> - - - - - <dd>Julien Gaugaz, L3S, <a href="mailto:gaugaz@l3s.de">gaugaz@l3s.de</a> </dd> - - - - - <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd> - - - - - <dd>Max Völkel, FZI, <a href="mailto:voelkel@fzi.de">voelkel@fzi.de</a><br /> - - - - - </dd> - - - - -</dl> - - - - -<dl> - - - - - <dt><span style="font-weight: bold;">Ontology:</span></dt> - - - - - <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl/nrl_data.rdfs">NRL -(Data Graph Only)</a></dd> - - - - - <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl/nrl_metadata.rdfs">NRL -(Metadata Graph Only)</a></dd> - - - - - <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/08/15/nrl/nrl.trig">NRL -(Graph Set)</a></dd> - - - - -</dl> - - - - -</div> - - - - -<p class="copyright">Copyright © 2007 <a href="http://nepomuk.semanticdesktop.org/">Nepomuk Consortium</a><sup>®</sup> -This work is made available under the terms of Nepomuk <a href="LICENSE.txt">software license</a> -</p> - - - - -<hr /> -<h2><a class="mozTocH2" name="mozTocId48135"></a><a name="Abstract"></a>Abstract</h2> - - - - -<p style="text-align: justify; background-color: rgb(255, 255, 255);">NRL -was designed for knowledge representation in NEPOMUK Social Semantic -Desktop applications. While being built on top of the Resource -Description Framework (RDF) and the associated RDF Schema (RDFS), it -addresses several limitations of current Semantic Web languages, -especially with respect to modularization and costumization. These -questions seem to be important not only in Semantic Desktop scenarios -but also on the general Semantic Web. NRL tackles these questions by -including support for two main additional concepts: <a href="#3._NRL_Named_Graph_Extensions">Named Graphs</a> -and <a href="#4._Graph_Views_Extensions">Graph Views</a>. -Named graphs help coping with the heterogeneity of knowledge models and -ontologies, esp. multiple knowledge modules with potentially different -interpretations. The view concept allows for the tailoring of -ontologies towards different needs in various exploiting applications. -This view concept provides also the basic mechanism to impose different -semantics on thesame syntactical structure. <br /> - - - - -</p> - - - - -<p style="text-align: justify; background-color: rgb(255, 255, 255);"> -</p> - - - - -<h2 style="background-color: rgb(255, 255, 255);"><a class="mozTocH2" name="mozTocId695723"></a><a name="Status_of_this_document"></a>Status -of this document</h2> - - - - -<div style="background-color: rgb(255, 255, 51);" id="sotd"> -<p style="text-align: justify; background-color: rgb(255, 255, 255);"><span style="background-color: rgb(255, 255, 255);"> This document -arose from -the work of the Task-Force ontologies within the </span><a style="background-color: rgb(255, 255, 255);" href="http://nepomuk.semanticdesktop.org">Nepomuk project</a><span style="background-color: rgb(255, 255, 255);">. -It presents the specifications for the second version of the NRL -vocabulary. The document has been promoted from a draft form to this -official form upon reviewing by the general NEPOMUK consortium. -Subsequent versions of NRL might mean that the specification documents -of the later versions render this document obsolete, with respect to -the version of NRL in use, but not with respect to this versio</span>n.</p> - - - - -</div> - - - - -<div class="toc"> -<h2 id="contents"><a class="mozTocH2" name="mozTocId537771"></a><a name="Contents"></a>Contents<span style="text-decoration: underline;"></span><span style="text-decoration: underline;"></span><br /> - - - - -</h2> - - - - -<ul id="mozToc"> - - - - -<!--mozToc h2 1 h3 2 h4 3 h5 4--><li><a href="#mozTocId48135">Abstract</a></li> - - - - - <li><a href="#mozTocId695723">Status -of this document</a></li> - - - - - <li><a href="#mozTocId537771">Contents </a></li> - - - - - <li><a href="#mozTocId131741">1. -Introduction</a> - - - - <ul> - - - - - <li><a href="#mozTocId401341">1.1 -Requirements</a></li> - - - - - <li><a href="#mozTocId545385">1.2 -RDF/S and NRL -Compatibility</a></li> - - - - - <li><a href="#mozTocId290714">1.3 -Naming</a></li> - - - - - <li><a href="#mozTocId950739">1.4 -Persistence</a></li> - - - - - <li><a href="#mozTocId607548">1.5 -Social Semantic Desktop Ontologies</a></li> - - - - - <li><a href="#mozTocId976485">1.6 External -Ontology -Synchronisation</a></li> - - - - - <li><a href="#mozTocId561958">1.7 -NRL and Closed World Vs. Open World Assumptions</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId154049">2. -Representing Domain Knowledge: RDF(S) and NRL Extensions to RDF(S)</a> - - - - <ul> - - - - - <li><a href="#mozTocId866477">2.1 -Resource Description -Framework -(RDF) Elements</a> - - - - <ul> - - - - - <li><a href="#mozTocId302034">2.1.1 -Classes</a></li> - - - - - <li><a href="#mozTocId861838">2.1.2 -Properties</a></li> - - - - - <li><a href="#mozTocId355985">2.1.3 -Other -Vocabulary</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId794884">2.2. -RDF Schema (RDFS) -Elements</a> - - - - <ul> - - - - - <li><a href="#mozTocId679335">2.2.1 Classes</a></li> - - - - - <li><a href="#mozTocId295955">2.2.2 -Properties</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId589481">2.3. -Recommendations for and -against the use of RDF/S elements</a> - - - - <ul> - - - - - <li><a href="#mozTocId522073">2.3.1 -rdfs:domain, rdfs:range</a></li> - - - - - <li><a href="#mozTocId332366">2.3.2 -Blank Nodes</a></li> - - - - - <li><a href="#mozTocId397156">2.3.3 -Collections -and Containers</a></li> - - - - - <li><a href="#mozTocId220340">2.3.4 -rdfs:isDefinedBy</a></li> - - - - - <li><a href="#mozTocId361071">2.3.5 -Reification</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId932814">2.4. -Constraint Extensions</a> - - - - <ul> - - - - - <li><a href="#mozTocId770989">2.4.1. -nrl:TransitiveProperty</a></li> - - - - - <li><a href="#mozTocId779070">2.4.2. -nrl:SymmetricProperty</a></li> - - - - - <li><a href="#mozTocId832124">2.4.3. -nrl:AsymmetricProperty</a></li> - - - - - <li><a href="#mozTocId890283">2.4.4. -nrl:ReflexiveProperty</a></li> - - - - - <li><a href="#mozTocId687239">2.4.5. -nrl:FunctionalProperty</a></li> - - - - - <li><a href="#mozTocId86301">2.4.6. -nrl:InverseFunctionalProperty</a></li> - - - - - <li><a href="#mozTocId97363">2.4.7. -nrl:cardinality</a></li> - - - - - <li><a href="#mozTocId435982">2.4.8. -nrl:minCardinality</a></li> - - - - - <li><a href="#mozTocId297991">2.4.9. -nrl:maxCardinality</a></li> - - - - - <li><a href="#mozTocId72221">2.4.10. -nrl:inverseProperty</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId929002">3. -Handling -Multiple Models: NRL Named Graph Extensions</a> - - - - <ul> - - - - - <li><a href="#mozTocId549245">3.1. -Graph Core Vocabulary</a> - - - - <ul> - - - - - <li><a href="#mozTocId991762">3.1.1. -nrl:Graph</a></li> - - - - - <li><a href="#mozTocId246095">3.1.2. -nrl:DocumentGraph</a></li> - - - - - <li><a href="#mozTocId178125">3.1.3. -nrl:subGraphOf</a></li> - - - - - <li><a href="#mozTocId972506">3.1.4. -nrl:superGraphOf</a></li> - - - - - <li><a href="#mozTocId503632">3.1.5. -nrl:equivalentGraph</a></li> - - - - - <li><a href="#mozTocId858885">3.1.6. -nrl:imports</a></li> - - - - - <li><a href="#mozTocId337127">3.1.7. -nrl:DefaultGraph</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId787923">3.2. -Graph -Roles Vocabulary </a> - - - - <ul> - - - - - <li><a href="#mozTocId792849">3.2.1. -nrl:Data</a></li> - - - - - <li><a href="#mozTocId420122">3.2.2. -nrl:Schema</a></li> - - - - - <li><a href="#mozTocId196061">3.2.3. -nrl:InstanceBase</a></li> - - - - - <li><a href="#mozTocId287595">3.2.4. -nrl:Ontology</a></li> - - - - - <li><a href="#mozTocId372280">3.2.5. -nrl:KnowledgeBase</a></li> - - - - - <li><a href="#mozTocId379616">3.2.6. -nrl:Configuration</a></li> - - - - - <li><a href="#mozTocId781665">3.2.7. -nrl:GraphMetadata</a></li> - - - - - <li><a href="#mozTocId159397">3.2.8. -nrl:graphMetadataFor</a></li> - - - - - <li><a href="#mozTocId728175">3.2.9. -nrl:coreGraphMetadataFor</a></li> - - - - - <li><a href="#mozTocId465236">3.2.10. -nrl:Semantics</a></li> - - - - - <li><a href="#mozTocId737534">3.2.11. -nrl:hasSemantics</a></li> - - - - - <li><a href="#mozTocId331701">3.2.12. -nrl:semanticsDefinedBy</a></li> - - - - - <li><a href="#mozTocId704028">3.2.13. -nrl:semanticsLabel</a></li> - - - - - <li><a href="#mozTocId379929">3.2.14. -nrl:updatable</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId54895">3. -Named Graph Example</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId172834">4. Imposing -Semantics on and Tailoring of Graphs: NRL Graph Views Extensions</a> - - - - <ul> - - - - - <li><a href="#mozTocId238972">4.1. Views -Core Vocabulary</a> - - - - <ul> - - - - - <li><a href="#mozTocId304281">4.1.1. -nrl:GraphView </a></li> - - - - - <li><a href="#mozTocId595657">4.1.2. -nrl:viewOn</a></li> - - - - - <li><a href="#mozTocId124884">4.1.3. -nrl:hasSpecification </a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId648959">4.2. -Views Specification Vocabulary</a> - - - - <ul> - - - - - <li><a href="#mozTocId925367">4.2.1. -nrl:ViewSpecification</a></li> - - - - - <li><a href="#mozTocId162918">4.2.2. -nrl:realizes</a></li> - - - - - <li><a href="#mozTocId266518">4.2.3. -nrl:RuleViewSpecification </a></li> - - - - - <li><a href="#mozTocId718088">4.2.4. -nrl:ruleLanguage</a></li> - - - - - <li><a href="#mozTocId518283">4.2.5. -nrl:rule</a></li> - - - - - <li><a href="#mozTocId968780">4.2.6. -nrl:ExternalViewSpecification </a></li> - - - - - <li><a href="#mozTocId745751">4.2.7. -nrl:externalRealizer</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId227803">4.3 -Graph Views Example</a></li> - - - - - - - - </ul> - - - - - </li> - - - - - <li><a href="#mozTocId943672">5. -Deprecated Elements</a></li> - - - - - <li><a href="#mozTocId225357">6. NRL -Semantics</a></li> - - - - - <li><a href="#mozTocId501171">References </a></li> - - - - - <li><a href="#mozTocId193273">Appendix -A. NRL Vocabulary Summary</a> - - - - <ul> - - - - - <li><a href="#mozTocId292715">A1: -Ontology Classes Description</a></li> - - - - - <li><a href="#mozTocId612656">A2: -Ontology Properties Description </a></li> - - - - - - - - </ul> - - - - - </li> - - - - -</ul> - - - - -<hr style="width: 100%; height: 2px;" /> -<h1>NRL Vocabulary Specification</h1> - - - - -<p style="text-align: justify;">This -document presents the -NEPOMUK -Representational Language (NRL), a language built on top of -RDF/S. The language is available for global use and -is independent of the domain for which it was initially designed for, -namely the [<a href="http://nepomuk.semanticdesktop.org/">NEPOMUK -Social Semantic Desktop</a>] initiative. The -NEPOMUK in -the language name (NRL) has been -retained only for historic purposes. Information regarding other -NEPOMUK ontologies can be found in [<a href="#1.5_Semantic_Desktop_Ontologies">Section -1.5</a>]. </p> - - - - -<p style="text-align: justify;">The -document stucture is as -follows. [<a href="#1._Introduction">Section 1</a>] gives -an insight -on the motivation for this work, the approaches taken, some resulting -assumptions and the specificatin of general naming and persistance -policies. [<a href="#2._Imported_Vocabulary_Elements">Section -2</a>] -gives an overview of the imported RDF/S vocabulary elements, -some of which have been restricted, and the NRL <span style="font-style: italic;">Constraint Extensions</span> -to -RDF/S. <span style="font-style: italic;"></span></p> - - - - -<p style="text-align: justify;"><span style="font-style: italic;">Named -Graph Extensions </span>[<a href="#3._NRL_Named_Graph_Extensions">Section -3</a>] gives an overview <span style="font-style: italic;"></span>of -the NRL -vocabulary to model the handling of multiple models, while <span style="font-style: italic;">Graph -View Extensions</span> -[<a href="#4._Graph_Views_Extensions">Section -4</a>] presents the vocabulary available to tailor and impose -semantics on named graphs.</p> - - - - -<p style="text-align: justify;">[<a href="#5._Deprecated_Elements">Section 5</a>] -is dedicated to deprecated elements whereas [<a href="#6._NRL_Semantics">Section -6</a>] -defines -the formal semantics of NRL (to be completed). A summary of all the NRL -vocabulary elements is given in [<a href="#Appendix_A._NRL_Vocabulary_Summary">Appendix A</a>].</p> - - - - -<h2><a class="mozTocH2" name="mozTocId131741"></a><a name="1._Introduction"></a>1. -Introduction</h2> - - - - -<span style="font-weight: bold;"></span> -<p style="text-align: justify;"><span style="font-weight: normal;"></span><span style="background-color: rgb(255, 255, 255);">NRL -is based on a number of key concepts, some of which -are -identical to concepts defined in earlier work. Other concepts -are -fundamentally the same to ones in existant work, but differ slightly in -definition, while some concepts are a fresh approach to data -representation. The key concepts are <span style="font-style: italic;">RDF -triple</span>, <span style="font-style: italic;">Named -Graph</span> -and <span style="font-style: italic;">Graph Views</span> and -they are introduced in this section.</span></p> - - - - -<p style="text-align: justify;"><span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);">The basic -concept is the <span style="font-style: italic;">RDF -triple</span> and the definition is fundamentally similar to the -one given in [</span><a style="background-color: rgb(255, 255, 255);" href="#References">RDF -Specification - CONCEPTS</a><span style="background-color: rgb(255, 255, 255);">] where a -triple consists of three components:</span></p> - - - - -<ul style="text-align: justify;"> - - - - - <li><span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);"></span>a -subject - in the form of a URI Reference</li> - - - - - <li>a predicate - in the form of a URI Reference</li> - - - - - <li>an object - in the form of either a URI Reference or a -literal</li> - - - - -</ul> - - - - -<div style="text-align: justify;"><span style="background-color: rgb(255, 255, 255);">where -the predicate denotes the relationship between the subject and the -object. The only difference is that in NRL it is not expected -that -a blank node manifests itself as either a subject or an object -of -a triple [See <a href="#2.3.2_Blank_Nodes">Recommendation2.3.2</a>]. -</span><span style="background-color: rgb(255, 255, 255);"></span><br /> - - - - -<span style="background-color: rgb(255, 255, 255);"></span></div> - - - - -<p style="text-align: justify;"><span style="background-color: rgb(255, 255, 255);">An <span style="font-style: italic;">RDF Graph</span> -consists of a set of triples. The definition is similar to -the one given in [</span><a style="background-color: rgb(255, 255, 255);" href="#References">RDF -Specification - -CONCEPTS</a><span style="background-color: rgb(255, 255, 255);">].</span><span style="background-color: rgb(255, 255, 255);"> A </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">Named -Graph </span><span style="background-color: rgb(255, 255, 255);">is -an RDF Graph identified by a name. In NRL, all RDF triples -must be assigned -to at least one named graph. Triples that are not, are automatically -assigned to a special named graph, the [<a href="#3.1.7._nrl:DefaultGraph">nrl:DefaultGraph</a>]. -Therefore, NRL -data handling is usually defined in terms of named graphs rather than -RDF triples. The formal definition for a named graph is the same as -that -given in [</span><a style="background-color: rgb(255, 255, 255);" href="#References">NAMED -GRAPHS</a><span style="background-color: rgb(255, 255, 255);">] -but excludes the open-world assumption [See <a href="#1.7_NRL_and_Closed_World_Vs._Open_World">Section 1.7</a>]. -Named graphs differ in content and purpose, -and for this reason <span style="font-style: italic;">Graph -Roles </span>have -been introduced, representing general roles like simple data, ontology, -knowledge base, plus other less generic roles. Graph roles carry <span style="font-style: italic;">Declarative Semantics</span>, -which means that their semantics are implicit and have not necessarily -been realized (in the form of inferred triples). A more elaborate -definition, syntax -specification and example section for named graphs is given in -</span><span style="font-style: italic; background-color: rgb(255, 255, 255);">Named -Graph Extensions </span><span style="background-color: rgb(255, 255, 255);">[</span><a style="background-color: rgb(255, 255, 255);" href="#3._NRL_Named_Graph_Extensions">Section -3</a><span style="background-color: rgb(255, 255, 255);">].</span></p> - - - - -<p style="text-align: justify;"><span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);">A named graph -consists of the corresponding triple set as is, and retrieving -RDF triples from a named graph, will simply return the enumerated -triples -in the set. However </span><span style="background-color: rgb(255, 255, 255);">it -is frequently required to work with graphs having realized -semantics in -the form of entailment triples, according to some declared -semantics. Additionaly, it is sometimes required to work with -more -abstract, simplified forms of a graph. In general, it is useful to work -with various interpretations of a named graph in different situations.</span><span style="background-color: rgb(255, 255, 255);"> -However, in order to preserve the integrity and consistency of named -graphs, an original named graph should be independent of -its interpretations. To model -this, one can -define arbitrary views which realize different -interpretations for an established named graph. We call these -interpretations </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">Graph -Views </span><span style="background-color: rgb(255, 255, 255);">and -they -are formally defined in </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">Graph -Views Extensions </span><span style="background-color: rgb(255, 255, 255);">[</span><a style="background-color: rgb(255, 255, 255);" href="#4._Graph_Views_Extensions">Section -4</a><span style="background-color: rgb(255, 255, 255);">]. -Graph views are themselves named -graphs, so it -is possible for a view to be applied on top of another graph -view. <span style="font-style: italic;">View -Specifications</span> define how a view </span>is -to be computed and they can refer either to a set of rules in some rule -language, or to an external application. Some view specifications -realize the <span style="font-style: italic;">Procedural -Semantics</span> of a graph, and the result is a <span style="font-style: italic;">Semantic View</span>, -having both declarative and procedural semantics. <span style="background-color: rgb(255, 255, 255);">Conceptually, -a graph <span style="font-style: italic;">g</span> </span><span style="background-color: rgb(255, 255, 255);">can be given a -semantics by applying a semantic realizing view</span><span style="font-style: italic; background-color: rgb(255, 255, 255);"> v</span><span style="background-color: rgb(255, 255, 255);">,</span><span style="font-style: italic; background-color: rgb(255, 255, 255);"> -</span><span style="background-color: rgb(255, 255, 255);">which -is linked to some semantic specifications. Practically, if the -semantics specifications are those for NRL, and these state that some -of the applied semantics </span><span style="background-color: rgb(255, 255, 255);">are -transitive (e.g. rdfs:subClass) this would imply that <span style="font-style: italic;">v</span></span><span style="font-style: italic; background-color: rgb(255, 255, 255);"> -</span><span style="background-color: rgb(255, 255, 255);">will -be the extension of </span><span style="background-color: rgb(255, 255, 255); font-style: italic;">g</span><span style="background-color: rgb(255, 255, 255);"> with the -inferred triples generated by performing the transitive closure.</span></p> - - - - -<p style="text-align: justify;"><span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);"></span> -<span style="background-color: rgb(255, 255, 255);">The -following -figure </span><span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);">presents the -important aspects of the NRL language, including the key concepts just -described and their relationships. The -diagram is partitioned in the (abstract) -syntax on which it is defined (right), and the formal semantics (left) -to which it is linked to. </span><span style="background-color: rgb(255, 255, 255);">The -NRL domain is depicted by the grey shaded part. Notice that NRL is not -limited to the syntax partition, since it includes NRL formal semantics -defined in [<a href="#6._NRL_Semantics">Section -6</a>]. </span><span style="background-color: rgb(255, 255, 255);">The -NRL syntax -is -composed of a base langugage and a schema language. The base -language refers to the specification of the key concepts in -the -language, including named graphs, graph roles and graph views -while </span><span style="background-color: rgb(255, 255, 255);">t</span><span style="background-color: rgb(255, 255, 255);">he schema -language (NRL Schema) provides the means to define schemas (especially -information models and ontologies). </span><span style="background-color: rgb(255, 255, 255);">The semantics -partition mainly distinguishes between abstract declarative semantics, -and realized procedural semantics.</span><br /> - - - - -</p> - - - - -<div style="text-align: center;"> -<div style="text-align: justify; margin-left: 40px;"> -<div style="text-align: center;"><img style="width: 547px; height: 330px;" alt="Overview of NRL: AbstractSyntax, Concepts and Semantics" src="NRLoverview.png" /><br /> - - - - -</div> - - - - -<div style="text-align: center;"><a name="Fig1"></a>Figure -1: Overview of NRL - -Abstract Syntax, Concepts and Semantics<br /> - - - - -</div> - - - - -<br /> - - - - -</div> - - - - -<div style="text-align: justify;"> -<p>The syntax schema consists of the NRL Schema, which is based -on an -extended RDFS (RDFS'). The syntax base presents the key -concepts of NRL as a set abstraction. Named graphs, consisting of RDF -Triples, are the most general set (red) since both graph roles and -graph views are special kinds of named graphs. Graph Roles (yellow) are -tied to declarative semantics that they assume (e.g. an ontology using -elements from RDF/S). Graph Views (green) are tied to view -specifications which execute the view's realization. The -intersection between graph roles and graph views refers to semantic -views. These special views realize the declarative semantics of the -graph role they are interpreting (e.g. by extending an ontology that -uses <span style="font-style: italic;">rdfs:subClassOf</span> -by its transitive closure as defined in RDF/S Semantics). Thus, as -shown on the left hand side of the figure, semantic view specifications -carry the realized procedural semantics for a view, which are -linked to the abstract declarative semantics of a language.<span style="background-color: rgb(255, 255, 255);"><br /> - - - - -</span></p> - - - - -</div> - - - - -<div style="text-align: justify;"> -<p><span style="background-color: rgb(255, 255, 255);"><a href="#Fig2">Figure 2</a></span><span style="background-color: rgb(255, 255, 255);"> shows how the -theoritical basis of NRL can be -applied in practice to handle RDF data. Data handling includes -creation, merging, interpretation and presentation of RDF data. It -presents the dataflow for some typical NRL data and how the various -concepts introduced earlier can be effectively used to model RDF data -and use it in different scenarios in a sound but intuitive way. The -example sections for the Named Graph extensions [<a href="#3.3._Named_Graph_Example">Section 3.3</a>] and -the Graph Views extensions [<a href="#4.3_Graph_Views_Example">Section -4.3</a>] present examples that model the dataflow in this figure -in TriG syntax </span>[<a href="#References">TRIG</a>]. -TriG is a straight-forward -extension of Turtle -[<a href="#References">TURTLE</a>]. Turtle itself -is an extension of N-Triples [<a href="#References">N-TRIPLES</a>] -which carefully takes the most useful and appropriate things added from -Notation3 -[<a href="#References">NOTATION3</a>] -while keeping it in the RDF model. TriG is a plain text -format created for serializing NGs and RDF Datasets.<br /> - - - - -</p> - - - - -</div> - - - - -<div style="text-align: justify;"> -<p><span style="background-color: rgb(255, 255, 255);">The -dataflow is based on four existing named graphs, two having the -role of [<a href="#3.2.4._nrl:Ontology">nrl:Ontology</a>] -(ontologies </span><span style="background-color: rgb(255, 255, 255);"><span style="font-style: italic;">O</span><small style="font-style: italic;"><small><small>1</small></small></small> -and <span style="font-style: italic;">O</span><small style="font-style: italic;"><small><small>2</small></small></small></span><span style="background-color: rgb(255, 255, 255);">) and the -other two that of [<a href="#3.2.3._nrl:InstanceBase">nrl:InstanceBase</a>] -(instance bases </span><span style="background-color: rgb(255, 255, 255);"><span style="font-style: italic;">I</span><small style="font-style: italic;"><small><small>1</small></small></small> -and <span style="font-style: italic;">I</span><small style="font-style: italic;"><small><small>2</small></small></small></span><span style="background-color: rgb(255, 255, 255);">). A new named -graph, <span style="font-style: italic;">O</span>, -is also defined as having the role of </span><span style="background-color: rgb(255, 255, 255);">[<a href="#3.2.4._nrl:Ontology">nrl:Ontology</a>]</span><span style="background-color: rgb(255, 255, 255);"> and by using -the property [<a href="#3.1.6._nrl:imports">nrl:imports</a>] -it is defined as being the supergraph of both </span><span style="background-color: rgb(255, 255, 255);"><span style="font-style: italic;">O</span><small style="font-style: italic;"><small><small>1</small></small></small> -and <span style="font-style: italic;">O</span><small style="font-style: italic;"><small><small>2</small></small></small></span><span style="background-color: rgb(255, 255, 255);">. This -constitutes an ontology merge for <span style="font-style: italic;">O</span></span><span style="background-color: rgb(255, 255, 255);"><span style="font-style: italic;"></span><small style="font-style: italic;"><small><small>1</small></small></small> -and <span style="font-style: italic;">O</span><small style="font-style: italic;"><small><small>2</small></small></small></span><span style="background-color: rgb(255, 255, 255);"> into <span style="font-style: italic;">O</span>.</span><span style="background-color: rgb(255, 255, 255);"></span> -Similarly, a new named graph, <span style="font-style: italic;">KB</span>, -is defined to have the role of [<a href="#3.2.5._nrl:KnowledgeBase">nrl:KnowledgeBase</a>] -and is defined as the supergraph of <span style="font-style: italic;">O</span>, <span style="font-style: italic;">I</span><small style="font-style: italic;"><small>1</small></small> -and <span style="font-style: italic;">I</span><small style="font-style: italic;"><small>2</small></small>. -Therefore,<span style="font-style: italic;"> KB </span>consists -of all RDF triples in <span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);"><span style="font-style: italic;">O</span><small style="font-style: italic;"><small><small>1</small></small></small>, -<span style="font-style: italic;">O</span><small style="font-style: italic;"><small><small>2</small></small></small></span>, -<span style="font-style: italic;">I</span><small style="font-style: italic;"><small>1</small></small> -and<span style="font-style: italic;"> I</span><small><small><span style="font-style: italic;">2</span><big><big>. -</big></big></small></small></p> - - - - -</div> - - - - -<img style="width: 552px; height: 339px;" alt="NRL Dataflow" src="dataflow.png" /><br /> - - - - -<br /> - - - - -<a name="Fig2"></a>Figure 2: NRL Dataflow diagram<br /> - - - - -<div style="text-align: left;"> -<div style="text-align: justify; margin-left: 0px; width: 900px;"> -<p><small><small><big><big>An -RDF programmer would like to work with an extension of <span style="font-style: italic;">KB</span> that includes -also the realized semantics that <span style="font-style: italic;">KB</span> -is implicitly carrying. To generate this extension, or view, the RDF -programmer can define an instance of [<a href="#4.2.1._nrl:ViewSpecification">nrl:ViewSpecification</a>] -that computes and returns -the procedural semantics for <span style="font-style: italic;">KB</span>. -</big></big></small></small><big><span style="background-color: rgb(255, 255, 255);"></span></big>The -view specification uses a rule language of choice that provides a -number of rules, one of which computes the transitive closure of <span style="font-style: italic;">rdfs:subClassOf</span>, as -defined in the RDFS semantics, for a set of RDF triples. Executing the -chosen rules over the triples in <span style="font-style: italic;">KB</span> -result in a semantic view <span style="font-style: italic;">RDFS(KB)</span> -consisting of the RDF triples in <span style="font-style: italic;">KB</span> -plus the generated entailment triples.</p> - - - - -<p>Next, the RDF programmer needs to present some of -this -extended data to an average user in a simplified way. In particular, -the user would at some point like to see the class hierarchy present in -<span style="font-style: italic;">RDFS(KB)</span>. -The RDF programmer can create external view specifications, in the form -of applications which take a named graph as input (a set of -RDF triples), and return the desired RDF triples as output. In -this case, an external view specification, <span style="font-style: italic;">E<small><small>1</small></small></span>, -is created and designed to select and return the triples defining the -class hierarchy within an input named graph. The view generated by this -application, <span style="font-style: italic;">E<small><small>1</small></small>(RDFS(KB)), -</span>which is basically another named graph, is -the data required for presentation to the user. It is worth to -note, that at this stage, all the seven named graphs that this last view<span style="font-style: italic;"> </span>is generated upon -are still intact and they have not been modified by any of the -operations. </p> - - - - -<h3><a class="mozTocH3" name="mozTocId401341"></a><a name="1.1_Requirements"></a>1.1 -Requirements</h3> - - - - -<p style="text-align: justify;">In this section we -specify the original identified requirements for a -Representational Language (excluding requirements that are -domain-dependent) and whether their fulfillment was successful or -otherwise.</p> - - - - -<p style="text-align: justify;">The following -requirements have been satisfied:</p> - - - - -<ul> - - - - - <li>Tool support for inferencing, interpretation, -manipulation and storage.</li> - - - - - <li>NRL should allow for validation of ontologies.</li> - - - - - <li>Basic subClassOf, type, and inverseProperty inference has -to be computable efficiently.</li> - - - - - <li>Domain and Range properties must be adhered to and -verified. [See domain and range usage <a href="#2.3._Recommendations">restrictions</a>]</li> - - - - - <li>Properties must support cardinality requirements. [See <a href="#2.4.7._nrl:cardinality"> nrl:cardinalty</a>, <a href="#2.4.8._nrl:minCardinality">nrl:minCardinalty</a> -and <a href="#2.4.9._nrl:maxCardinality">nrl:maxCardinality</a>]</li> - - - - - <li>Representation of ontology models. [See -graph role <a style="background-color: rgb(255, 255, 255);" href="#3.2.4._nrl:Ontology">nrl:Ontology</a>]</li> - - - - - <li>Ontology imports must be possible. Ontology management -must -be provided. [See named graph property [<a style="background-color: rgb(255, 255, 255);" href="#3.1.6._nrl:imports">nrl:imports</a>]</li> - - - - - <li>Support for Quads/Named Graphs to record provenance. [See <a href="#3._NRL_Named_Graph_Extensions">Named -Graph -Extensions</a>]</li> - - - - -</ul> - - - - -<p style="text-align: justify;">The following -requirements are no longer in the scope of the -NRL but in that of lower-level ontologies:</p> - - - - -<ul> - - - - - <li>The language must differentiate between concepts and -web-resources. [See <a href="#5._Deprecated_Elements">nrl:Thing</a> -and <a href="#5._Deprecated_Elements">nrl:ResourceManifestation</a>]</li> - - - - - <li>Meta-modeling needs to be supported. [See <a href="#5._Deprecated_Elements">nrl:NRLClass</a> -and <a href="#5._Deprecated_Elements">nrl:NRLProperty</a>]</li> - - - - - <li>Support for alternative labels (thesauri helpers) -alongside -labels is required. [See alternative labels property <a href="#5._Deprecated_Elements">nrl:altLabel</a>]</li> - - - - - <li>n-ary relations should be supported. [See <a href="#5._Deprecated_Elements"> -nrl:relationProperty</a>]</li> - - - - - <li>It must provide some basic semantic relations. [See <a href="#5._Deprecated_Elements">nrl:partOf</a>, <a href="#5._Deprecated_Elements">nrl:hasTopic</a> -and <a href="#5._Deprecated_Elements"> -nrl:relationProperty</a>]</li> - - - - - <li>Typing on reifications and contexts.</li> - - - - -</ul> - - - - -<p style="text-align: justify;">The following -requirements have not been satisfied:</p> - - - - -<ul> - - - - - <li>Support for imprecise/fuzzy/probabilistic -representations.</li> - - - - -</ul> - - - - -<p><span style="font-style: italic; font-weight: bold;">Note</span><span style="font-weight: bold;">:</span> -The -fulfillment of this requirement will be postponed until -a non-imprecise version of NRL is stable.</p> - - - - -<p>The following -requirement has been retracted:</p> - - - - -<ul> - - - - - <li>Typing on container -contents. Containers are to be -avoided -altogether. [See Recommendation <a href="#2.3.3_Grouping_resources">2.3.3</a>]</li> - - - - -</ul> - - - - -<h3><a class="mozTocH3" name="mozTocId545385"></a><a name="1.2_RDFS_and_NRL_Compatibility"></a>1.2 -RDF/S and NRL -Compatibility</h3> - - - - -<p style="text-align: justify;">This specification -provides some recommendations as to the use -of some RDF/S elements or constructs [<a href="#2.3">2.3</a>]. -It must be noted that if these recommendations are not followed, this -still results in <i>legal</i> RDF/S data and therefore <i>legal</i> -NRL data. However this does not imply that such data would be <i>valid</i> -NRL data. Although such data would conform to the RDF/S specifications, -correct manipulation of invalid NRL data is not guaranteed if the -recommendations are not followed. This also applies to RDF/S data that -is imported -in an NRL context (e.g. RDF/S data imported on one's semantic desktop). -In a more technical sense, legal NRL would be processed without -generating errors, but only valid NRL would be processed without -generating warnings. </p> - - - - -<p style="background-color: rgb(255, 255, 255); text-align: justify;"><span style="background-color: rgb(255, 255, 255);">Since -NRL is based on the Named Graph paradigm [See </span><a style="background-color: rgb(255, 255, 255);" href="#3._NRL_Named_Graph_Extensions">Named -Graph Extensions</a><span style="background-color: rgb(255, 255, 255);">], NRL -data cannot be directly represented with plain RDF/S since NG's are an -extension </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">on -top</span><span style="background-color: rgb(255, 255, 255);"> -of RDF/S. Therefore NRL with named graphs is not backward -compatible -to RDF/S. It is compatible however with Named Graphs -as specified in [</span><a style="background-color: rgb(255, 255, 255);" href="#References">SPARQL-QUERY</a><span style="background-color: rgb(255, 255, 255);">].</span><br /> - - - - -</p> - - - - -<h3><a class="mozTocH3" name="mozTocId290714"></a><a name="1.3_Naming"></a>1.3 -Naming</h3> - - - - -<p style="text-align: justify;">The URI for the NRL -Vocabulary is <a href="http://www.semanticdesktop.org/ontologies/nrl#">http://www.semanticdesktop.org/ontologies/yyyy/mm/dd/nrl#</a> -subject -to the date of the latest stable version.</p> - - - - -<p style="text-align: justify;">The URI for an element -in the vocabulary is constructed by -appending a fragment identifier to the above URI. A fragment identifier -for a class always starts with an uppercase letter while in the case of -properties it starts with a lowercase letter. In the case of class -identifiers consisting of multiple words, the leading character of each -word will be an uppercase letter. In case of property identifiers -consisting of multiple words, the leading character of each word will -be an uppercase letter, except for the first word which as specified -should be in lowercase.</p> - - - - -<i>Examples<br /> - - - - -<br /> - - - - -</i> -<table style="text-align: left; width: 100%; height: 83px;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;">http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#Class</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#ExampleClass</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#property</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#exampleProperty</span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -<h3><a class="mozTocH3" name="mozTocId950739"></a><a name="1.4_Persistence"></a>1.4 -Persistence</h3> - - - - -<p>The NRL Vocabulary specification defined here and any -previous -or later versions, plus the NRL ontology itself [<a href="http://nepomuk.org/ontologies/nrl">http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#</a>] -will be provided as persistent resources.</p> - - - - -<h3><a class="mozTocH3" name="mozTocId607548"></a><a name="1.5_Social_Semantic_Desktop_Ontologies"></a>1.5 -Social Semantic Desktop Ontologies</h3> - - - - -<p style="text-align: justify;">Ontologies are -structured in various layers or levels, with -the rationale that those at higher levels are more stable and thus -change less often than those at lower levels. Usually, one -distinguishes representational ontologies, upper-level ontologies, -mid-level ontologies, and domain ontologies.</p> - - - - -<p style="text-align: justify;">The NRL is a -representational ontology and although it is -domain independent it was designed to fulfil requirement for the -NEPOMUK Social Semantic Desktop initiative. Representational ontologies -define -the vocabulary with which other ontologies are represented. Other -examples of such representational ontologies are RDF/S and OWL. The -relationship of a representational ontology to other ontologies is -quite different from the relationship between the other ontologies -themselves. While upper-level ontologies generalize mid-level -ontologies, which in turn generalize domain ontologies, all these -ontologies can be seen as <i class="italic">instances</i> -of the -representational ontology.</p> - - - - -<p style="text-align: justify;">The specification of -various other ontologies is in the -pipeline for the Social Semantic Desktop project. In particular, -the -following (upper-level) ontologies are being discussed:</p> - - - - -<ul> - - - - - <li>Information Element -Ontology [<a href="http://www.semanticdesktop.org/ontologies/nie">NIE</a>] -- to handle physical -resource (e.g. documents, web pages, files etc.)</li> - - - - - <li>Annotation Ontology -[<a href="http://www.semanticdesktop.org/ontologies/nao">NAO</a>] - -to handle general -annotation (e.g. Data annotation, Linking abstract -to physical resources) as well as graph -annotation (e.g. Data -authorship. etc.)</li> - - - - - <li>Personal Information Modelling Ontology [PIMO] - to model -things and relationships on the user's desktop.</li> - - - - -</ul> - - - - -<h3><a class="mozTocH3" name="mozTocId976485"></a><a name="1.6_External_Ontology_Synchronisation"></a>1.6 External -Ontology -Synchronisation</h3> - - - - -<p>The ontologies resulting -from the Social Semantic Desktop project -are -partly inspired by existing elements in external ontologies. -As a result some elements are very -similar to elements in existing languages like OWL <a href="#References">[OWL Overview]</a> and OMV <a href="#References">[OMV Documentation]</a>. -Also, some RDF/S elements do not fulfil the requirements for the -project's ontologies and therefore problems arise from these two -scenarios. When requiring elements that already exist in some other -standard ontology, but do not exactly conform to our requirements, -there are the following three outlined options:</p> - - - - -<ol> - - - - - <li>Re-define semantics for use within NEPOMUK ontologies.</li> - - - - -</ol> - - - - -This creates major problem when it comes to heterogeneity -issues. One cannot redefine an element if it already has a defined -semantics, because when encountering such an element, it would not -be -possible to decide in which context to interpret it. Restrictions are a -more subtle form of redefinition. In this case, any restrictions placed -on the use of existing elements will result in the possibility of -having Legal but Invalid data in the NEPOMUK ontologies context. See -further discussions in [<a href="#1.2">1.2</a>] -in -the case of NRL. -<ol style="text-align: justify;"> - - - - - <li value="2">Re-create new elements with required -semantics and ignore the existing ones.</li> - - - - -</ol> - - - - -<div style="text-align: justify;"> -This goes against the idea of ontologies and the Semantic -Web in general, that is, to have a shared conceptualisation, promote -the re-use of ontologies and discourage the re-creation of data. -<ol style="text-align: justify;"> - - - - - <li value="3">Re-create new elements with required -semantics and provide a mapping between them and the existing elements.</li> - - - - -</ol> - - - - -</div> - - - - -<div style="text-align: justify;"> -This option is a variant of the previous option, where -although new elements are re-created, the relation between the new and -the existent elements is modelled using mappings. Examples of these -mappings are subclass, hyponym, meronym. Although in this case, new -elements satisfying the requirements are created, the existent elements -are not ignored and therefore the shared conceptualisation ideology is -respected. -<p style="text-align: justify; width: 900px;">In the -NEPOMUK -ontologies, option three is the standard -best practice when existent elements with different semantics are -required. When requiring restriction on the use of elements, option one -is sufficient since it does not violate the predefined semantics. -However in this case the statement in [<a href="#1.2">1.2</a>] -should be noted. The mapping constructs required for option three will -be defined over time and therefore, although theoritically the -agreed-upon option is three, in practice option two is currently being -implemented.</p> - - - - -</div> - - - - -<h3><a class="mozTocH3" name="mozTocId561958"></a><a name="1.7_NRL_and_Closed_World_Vs._Open_World"></a>1.7 -NRL and Closed World Vs. Open World Assumptions</h3> - - - - -<div style="width: 909px;"> -<div style="text-align: justify; width: 900px;"> -<div style="text-align: justify;"> -<p style="width: 900px;">The open-world -assumption (OWA) presumes that its knowledge of the -world is incomplete and that this lack of knowledge does not imply -falsity. On the other hand, the closed-world assumption (CWA) presumes -that what is not currently known to be true, is false. Whereas the OWA -states that everything that is not known is undefined, the CWA implies -that everything we don't know is false. </p> - - - - -</div> - - - - -<p>This assumption has a big impact on direct and indirect -knowledge -generated through RDF data. This difference is demonstrated through the -following example which is based on <a href="#3._NRL_Named_Graph_Extensions">Named -Graphs</a> -and -<a href="http://www.wiwiss.fu-berlin.de/suhl/bizer/TriG/">TriG</a> -[TRIG]. We will consider the implications of importing the given three -graphs <span style="font-style: italic;">g1</span>, -<span style="font-style: italic;">g2</span> and <span style="font-style: italic;">g3</span> into an external -graph <span style="font-style: italic;">g</span>.</p> - - - - -<table style="text-align: left; width: 100%; height: 463px;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;">@prefix -nrl: -<http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> -.</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> @prefix dom: -<http://www.example.org/ontology/domainOntology#> . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> @prefix ex: -<http://www.example.org/vocabulary#> .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> @prefix ex2: -<http://www.example.org/vocabulary#> .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> @prefix : -<http://www.example.org/vocabulary#> .</span><br /> - - - - - <br /> - - - - - <span style="font-family: monospace;">[1] :g1 {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - dom:Person rdf:type rdfs:Class .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - dom:Man rdf:type rdfs:Class ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - rdfs:subClassOf -dom:Person .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - dom:Woman rdf:type rdfs:Class ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - rdf:subClassOf -dom:Person .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - dom:hasFather rdf:type rdf:Property ,</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - - nrl:FunctionalProperty ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdfs:domain rdf:Person ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdfs:range rdf:Man . }</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] :g2 { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:Peter rdf:type dom:Man .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:Jill rdf:type dom:Person ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - dom:hasFather -ex:Peter . }</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] :g3 { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex2:Jack rdf:type dom:Man .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:Jill dom:hasFather ex2:Jack . } </span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -</div> - - - - -</div> - - - - -<div style="width: 909px;"> -<br /> - - - - -[1] The first -graph consists of an ontology and presents -three classes and a property. The classes are <span style="font-style: italic;">dom:Person</span> and its -two subclasses <span style="font-style: italic;">dom:Woman</span> -and <span style="font-style: italic;">dom:Man</span>. -The property <span style="font-style: italic;">dom:hasFather </span>is -a <a href="#2.4.5._nrl:FunctionalProperty">nrl:FunctionalProperty</a> -applicable to class <span style="font-style: italic;">dom:Person -</span>and taking as values instances of <span style="font-style: italic;">dom:Man</span>.<br /> - - - - -<br /> - - - - -</div> - - - - -<div style="width: 909px;"> -[2] The second named graph is an instance base consisting of -two -instances, <span style="font-style: italic;">Peter </span>as -a <span style="font-style: italic;">dom:Man </span>and <span style="font-style: italic;">Jill</span> as a <span style="font-style: italic;">dom:Person</span>. In -addition, the <span style="font-style: italic;">dom:hasFather</span> -relation between <span style="font-style: italic;">Jill </span>and<span style="font-style: italic;"> Peter</span> says that <span style="font-style: italic;">Peter</span> is <span style="font-style: italic;">Jill</span>'s father. -</div> - - - - -<div style="width: 909px;"> -<span style="font-style: italic;">Question</span>: -Is <span style="font-style: italic;">Jill</span> a <span style="font-style: italic;">dom:Woman</span>?<span style="font-style: italic;"></span> -<br /> - - - - -<span style="font-style: italic;">OWA</span>: -Unknown - It is only known that <span style="font-style: italic;">Jill</span> -is a <span style="font-style: italic;">dom:Person</span>. -OWA cannot determine whether the statement is true or false. -</div> - - - - -<div style="text-align: justify;"> -<span style="font-style: italic;">CWA</span>: -No - <span style="font-style: italic;">Jill </span>is -nowhere -defined to be a <span style="font-style: italic;">dom:Woman</span>. -Therefore the statement is false. -<br /> - - - - -<br /> - - - - -<span style="font-style: italic;">Question</span>: -Is <span style="font-style: italic;">Peter</span> a -<span style="font-style: italic;">dom:Person</span>? -<br /> - - - - -<span style="font-style: italic;">OWA</span>: -Yes - -Peter is a <span style="font-style: italic;">dom:Man</span>, -and this is a subclass of <span style="font-style: italic;">dom:Person</span>. -<br /> - - - - -<span style="font-style: italic;">CWA</span>: -Yes - -Peter is a <span style="font-style: italic;">dom:Man</span>, -and this is a subclass of <span style="font-style: italic;">dom:Person</span>.<br /> - - - - -<br /> - - - - -[3] -The -third graph is also an instance base and presents another instance, <span style="font-style: italic;">Jack </span>as a <span style="font-style: italic;">dom:Man</span>. The same <span style="font-style: italic;">Jill </span>defined in -graph two, is said to have <span style="font-style: italic;">Jack</span> -as her father<span style="font-style: italic;">.</span><br /> - - - - -<span style="font-style: italic;"></span><span style="font-style: italic;"></span><br /> - - - - -Since <span style="font-style: italic;">dom:hasFather </span>is -a functional property, <span style="font-style: italic;">Jill -</span>can have only one person related to her by that property. -<span style="font-style: italic;"></span><br /> - - - - -<span style="font-style: italic;">OWA</span>: -It -results that <span style="font-style: italic;">Jack</span> -and <span style="font-style: italic;">Peter</span> -are the same person. This statement is implicitly added to the -data. -<span style="font-style: italic;"></span><br /> - - - - -<span style="font-style: italic;">CWA</span>: -There -is conflicting data in g2 and g3. An error is generated. -<p>The RDF -language itself assumes an open-world and so does -the definition for Named Graphs in <span style="background-color: rgb(255, 255, 51);"><span style="background-color: rgb(255, 255, 255);">[</span></span><a style="background-color: rgb(255, 255, 255);" href="#References">NAMED -GRAPHS</a><span style="background-color: rgb(255, 255, 255);">]. -There is a difference of opinion on what approach is best for handling -RDF data. While OWA is more flexible, and more likely to -generate -new statements based on ones that already exist in the models, its -non-monotonic nature hinders computability and largely increases -the -complexity of RDF data. On the other hand, while CWA is much more prone -to generate errors, it is totally deterministic and one can always -compute whether any statement under the assumption is true or false.</span></p> - - - - -<p><span style="background-color: rgb(255, 255, 255);"></span>Although -it is sometimes more realistic to apply OWA, the correctness -of this approach is not guaranteed. In the given example, it might -makes sense to leave the possibility open for the statement <span style="font-style: italic;">Jill is a woman</span> to -be true. However it might not make sense to assume that the fact <span style="font-style: italic;">Jack is Peter</span> is -intentional. Under CWA, the truth of the statements is subject to -explicitally stating them.</p> - - - - -<p>For this reason, NRL does not assume an <span style="font-style: italic;">Open World View</span> -and although NRL imposes no semantics on basic -graphs, NRL -semantics are CWA. Semantics are imposed on graphs through Graph Views -and Semantic Views as -introduced in [<a href="#4._Graph_Views_Extensions">Section -4</a>]. Therefore <span style="font-style: italic;">Open -World Views</span> -can be realized as well by applying an OWA view to a -named -graph. On the Semantic Desktop in particular we assume closed-world -semantics -as it focuses mainly on personal data. While most people find it -difficult to understand the logical meaning and potential inferences -statements of the open-world assumption, the closed-world assumption is -easier to understand for an average desktop user. </p> - - - - -</div> - - - - -<div style="width: 909px;"> -<h2><a class="mozTocH2" name="mozTocId154049"></a><a name="2._Representing_Domain_Knowledge:_RDFS"></a>2. -Representing Domain Knowledge: RDF(S) and NRL Extensions to RDF(S)</h2> - - - - -<p style="text-align: justify; width: 900px;">The NRL -Vocabulary is an -application of the [<a href="#References">Resource -Description Framework</a>] (RDF) and the associated [<a href="#References">RDF -Schema</a>] (RDFS). The NRL vocabulary -therefore implicitly includes elements from the RDF/RDFS vocabularies. -Consequently the specifications for RDF [<a href="#References">RDF -Specification</a>] and RDFS should be regarded as part of this -specification document. However, the NRL vocabulary defines some <a href="#2.3._Recommendations"> -recommendations</a> on the use of RDF/RDFS elements. When using -RDF/S constructs within the NRL context, these recommendations need -to be respected if the generated data is to be valid NRL data (see -discussion in [<a href="#1.2">1.2</a>] -regarding -valid and legal NRL). In practice this means that when RDF/S constructs -are used together with NRL elements (or any of their instances) one -should strictly abide by the RDF/S specifications and any -recommendations stated in this document.<br /> - - - - -<br /> - - - - -The rest of Section 2 is divided as follows. Summary tables of the -imported RDF/RDFS elements are provided, followed by specifications of -any restrictions or recommendations placed when importing into NRL.</p> - - - - -<h3><a class="mozTocH3" name="mozTocId866477"></a><a name="2.1_Resource_Description_Framework_RDF"></a>2.1 -Resource Description -Framework -(RDF) Elements</h3> - - - - -<p style="text-align: justify; width: 900px;">The -following are the -elements defined in RDF and implicitly -forming part of the NRL. Their summary tables are categorized into -Classes, Properties and other elements. The class summary table states -the class name and the class’s parent class. The property -summary table states the property name and the applicable domain and -range. The other elements table states the element name and the element -type. The tables also denote whether the elements have been imported as -is, or if extensions or restrictions apply when used in the NEPOMUK -context. These extensions and restrictions are specified in [<a href="#2.3._Recommendations">2.3</a>]</p> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId302034"></a><a name="2.1.1_Classes"></a>2.1.1 -Classes</h4> - - - - -<table style="width: 100%;" id="table27" border="1"> - - - - - <tbody> - - - - - <tr> - - - - - <td style="width: 199px;"><i>Class</i></td> - - - - - <td style="width: 521px;"><i>Superclass</i></td> - - - - - <td style="width: 183px;"><i>Notes</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 199px;">rdf:Property</td> - - - - - <td style="width: 521px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 199px;">rdf:Statement</td> - - - - - <td style="width: 521px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 199px;">rdf:XMLLiteral*</td> - - - - - <td style="width: 521px;">rdfs:Literal</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 199px;">rdf:Bag</td> - - - - - <td style="width: 521px;">rdfs:Container</td> - - - - - <td style="width: 183px;"><a href="#2.3.3_Grouping_resources">Yes</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 199px;">rdf:Seq</td> - - - - - <td style="width: 521px;">rdfs:Container</td> - - - - - <td style="width: 183px;"><a href="#2.3.3_Grouping_resources">Yes</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 199px;">rdf:Alt</td> - - - - - <td style="width: 521px;">rdfs:Container</td> - - - - - <td style="width: 183px;"><a href="#2.3.3_Grouping_resources">Yes</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 199px;">rdf:List</td> - - - - - <td style="width: 521px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<p>*rdf:XMLLiteral is also an instance of rdfs:Datatype (see <a href="#2.1.3_Other_Vocabulary"> -Other Vocabulary</a>)</p> - - - - -<h4><a class="mozTocH4" name="mozTocId861838"></a><a name="2.1.2_Properties"></a>2.1.2 -Properties</h4> - - - - -<table style="width: 100%;" id="table28" border="1"> - - - - - <tbody> - - - - - <tr> - - - - - <td style="width: 193px;"><i>Property</i></td> - - - - - <td style="width: 241px;"><i>Domain</i></td> - - - - - <td style="width: 273px;"><i>Range</i></td> - - - - - <td style="width: 183px;"><i>Notes</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 193px;">rdf:type</td> - - - - - <td style="width: 241px;">rdfs:Resource</td> - - - - - <td style="width: 273px;">rdfs:Class</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 193px;">rdf:subject</td> - - - - - <td style="width: 241px;">rdf:Statement</td> - - - - - <td style="width: 273px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 193px;">rdf:predicate</td> - - - - - <td style="width: 241px;">rdf:Statement</td> - - - - - <td style="width: 273px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 193px;">rdf:object</td> - - - - - <td style="width: 241px;">rdf:Statement</td> - - - - - <td style="width: 273px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 193px;">rdf:value</td> - - - - - <td style="width: 241px;">rdfs:Resource</td> - - - - - <td style="width: 273px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 193px;">rdf:first</td> - - - - - <td style="width: 241px;">rdf:List</td> - - - - - <td style="width: 273px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 193px;">rdf:rest</td> - - - - - <td style="width: 241px;">rdf:List</td> - - - - - <td style="width: 273px;">rdf:List</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<h4><a class="mozTocH4" name="mozTocId355985"></a><a name="2.1.3_Other_Vocabulary"></a>2.1.3 -Other -Vocabulary</h4> - - - - -<table style="width: 100%;" id="table29" border="1"> - - - - - <tbody> - - - - - <tr> - - - - - <td style="width: 193px;"><i>Name</i></td> - - - - - <td style="width: 519px;"><i>Type</i></td> - - - - - <td style="width: 184px;"><i>Notes</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 193px;">rdf:nil</td> - - - - - <td style="width: 519px;">rdfs:List</td> - - - - - <td style="width: 184px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 193px;">rdf:XMLLiteral</td> - - - - - <td style="width: 519px;">rdfs:Datatype</td> - - - - - <td style="width: 184px;">No</td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<h3><a class="mozTocH3" name="mozTocId794884"></a><a name="2.2._RDF_Schema_RDFS_Elements"></a>2.2. -RDF Schema (RDFS) -Elements</h3> - - - - -<p style="text-align: justify;">The following are the -elements defined in RDFS and -implicitly -forming part of the NRL. Their summary tables are categorized into -Classes and Properties. The class summary table states the class name -and the class’s parent class. The property summary table -states the property name and the applicable domain and range. The -tables also denote whether the elements have been imported as is, or if -extensions apply when used in the NRL context. These extensions are -specified in [<a href="#2.3._Recommendations">2.3</a>]</p> - - - - -<h4><a class="mozTocH4" name="mozTocId679335"></a><a name="2.2.1_Classes"></a>2.2.1 Classes</h4> - - - - -<table style="width: 100%;" id="table30" border="1"> - - - - - <tbody> - - - - - <tr> - - - - - <td style="width: 253px;"><i>Class</i></td> - - - - - <td style="width: 460px;"><i>Superclass</i></td> - - - - - <td style="width: 183px;"><i>Notes</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 253px;">rdfs:Resource</td> - - - - - <td style="width: 460px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 253px;">rdfs:Class</td> - - - - - <td style="width: 460px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 253px;">rdfs:Datatype</td> - - - - - <td style="width: 460px;">rdfs:Class</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 253px;">rdfs:Container</td> - - - - - <td style="width: 460px;">rdfs:Resource</td> - - - - - <td style="width: 183px;"><a href="#2.3.3_Grouping_resources">Yes</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 253px;">rdfs:Literal</td> - - - - - <td style="width: 460px;">rdfs:Resource</td> - - - - - <td style="width: 183px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 253px;">rdfs:ContainerMembershipProperty</td> - - - - - <td style="width: 460px;">rdf:Property</td> - - - - - <td style="width: 183px;"><a href="#2.3.3_Grouping_resources">Yes</a></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<h4><a class="mozTocH4" name="mozTocId295955"></a><a name="2.2.2_Properties"></a>2.2.2 -Properties</h4> - - - - -<table style="width: 100%;" id="table31" border="1"> - - - - - <tbody> - - - - - <tr> - - - - - <td style="width: 312px;"><i>Property</i></td> - - - - - <td style="width: 326px;"><i>Domain</i></td> - - - - - <td style="width: 258px;"><i>Range</i></td> - - - - - <td style="width: 250px;"><i>Notes</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 312px;">rdfs:domain</td> - - - - - <td style="width: 326px;">rdf:Property</td> - - - - - <td style="width: 258px;">rdfs:Class</td> - - - - - <td style="width: 250px;"><a href="#2.3.1_rdfs:domain_rdfs:range">Yes</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 312px;">rdfs:range</td> - - - - - <td style="width: 326px;">rdf:Property</td> - - - - - <td style="width: 258px;">rdfs:Class</td> - - - - - <td style="width: 250px;"><a href="#2.3.1_rdfs:domain_rdfs:range">Yes</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 312px;">rdfs:subClassOf</td> - - - - - <td style="width: 326px;">rdfs:Class</td> - - - - - <td style="width: 258px;">rdfs:Class</td> - - - - - <td style="width: 250px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 312px;">rdfs:subPropertyOf</td> - - - - - <td style="width: 326px;">rdf:Property</td> - - - - - <td style="width: 258px;">rdf:Property</td> - - - - - <td style="width: 250px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 312px;">rdfs:member</td> - - - - - <td style="width: 326px;">rdfs:Resource</td> - - - - - <td style="width: 258px;">rdfs:Resource</td> - - - - - <td style="width: 250px;"><a href="#2.3.3_Grouping_resources">Yes</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 312px;">rdfs:isDefinedBy*</td> - - - - - <td style="width: 326px;">rdfs:Resource</td> - - - - - <td style="width: 258px;">rdfs:Resource</td> - - - - - <td style="width: 250px;"><a href="#2.3.4_rdfs:isDefinedBy">Yes</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 312px;" height="24">rdfs:label</td> - - - - - <td style="width: 326px;" height="24">rdfs:Resource</td> - - - - - <td style="width: 258px;" height="24">rdfs:Literal</td> - - - - - <td style="width: 250px;" height="24">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 312px;">rdfs:comment</td> - - - - - <td style="width: 326px;">rdfs:Resource</td> - - - - - <td style="width: 258px;">rdfs:Literal</td> - - - - - <td style="width: 250px;">No</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 312px;">rdfs:seeAlso</td> - - - - - <td style="width: 326px;">rdfs:Resource</td> - - - - - <td style="width: 258px;">rdfs:Resource</td> - - - - - <td style="width: 250px;">No</td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<p>*rdfs:isDefinedBy is a sub property of rdfs:seeAlso</p> - - - - -</div> - - - - -<h3><a class="mozTocH3" name="mozTocId589481"></a><a name="2.3._Recommendations_for_and_against_the"></a>2.3. -Recommendations for and -against the use of RDF/S elements</h3> - - - - -<p>As discussed earlier [<a href="#1.2">Section -1.2</a>] although -any legal RDF is also legal NRL, it is not necessarily valid NRL. In -order for NRL to be valid, these recommendations must be strictly -adhered to.</p> - - - - -<h4><a class="mozTocH4" name="mozTocId522073"></a><a name="2.3.1_rdfs:domain_rdfs:range"></a>2.3.1 -rdfs:domain, rdfs:range</h4> - - - - -<p style="text-align: justify;"><big><span style="font-size: 12pt;">The -fact that NRL does not assume open-world has an -impact on the way some constructs should be used. This is especially -true for -the rdfs:domain and the rdfs:range elements. In an open-world scenario, -when -using a property to relate two resources, one is implicitly casting the -type of -those resources to the types specified in the property’s -domain and range -definition. In other words the use of a property evokes additional -implicit -statements about the types of the objects being related, even if these -types -are different than the types that have been predefined for the objects, -if at -all. In a closed-world scenario as on the semantic -desktop this is not possible since in order to -relate -two resources, their types must fit the expected domain and range in -the first -place. This also means that untyped resources cannot be related. -Failure to do -so will generate legal yet invalid NRL data on the semantic desktop. -This recommendation has a -major bearing -on the validity of logical inference mechanisms in place within NRL and -therefore must be strictly adhered to.</span></big><br /> - - - - -</p> - - - - -<span style="font-style: italic;"><span style="font-weight: bold;">Recommendation: </span></span><i>The -domain and range constraints for -properties must be strictly adhered to. Untyped resources cannot be -related -through a property, since the types of the related resources must -explicitly -satisfy the constraints set by rdfs:domain and rdfs:range given NRL is -not OWA.<br /> - - - - -</i><br /> - - - - -<i>Examples</i> -<p style="text-align: justify;">In these examples and -the ones that follow throughout the -document, we use the example namespace for user-generated data <span style="font-family: monospace;">http://mydesktop.org/mydesktop#</span>. -The example namespace abbreviation can be defined as follows. To -improve the readability of examples, the user namespace abbreviation is -sometimes excluded. In these cases, the elements are given in italics.</p> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;"> @prefix -rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> @prefix -rdfs: <http://www.w3.org/2000/01/rdf-schema#> .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> @prefix -nrl: -<http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> -.</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> @prefix -voc: <http://www.semanticdesktop.org/ontology/desktop#> .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> @prefix -desktop: <http://mydesktop.org/mydesktop#> .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> ...</span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -[1] Within the Ontology <span style="font-style: italic;">Desktop</span> -the -property voc:depicts is assigned a domain of voc:ImageFile and a range -of voc:Person.<br /> - - - - -<br /> - - - - -[2] desktop:Myself is defined as an instance of voc:Person.<br /> - - - - -<br /> - - - - -[3] desktop:MyFriend is defined as an instance of voc:Friend.<br /> - - - - -<br /> - - - - -[4] desktop:PassportPhoto is defined as an instance of voc:ImageFile. -It is related to desktop:Myself through the voc:depicts property. This -is valid usage of the rdfs:domain and -rdfs:range as defined in [1] and is valid NRL data, since the types of -both resources being related have been stated and they fit the domain -and range constraints.<br /> - - - - -<br /> - - - - -[5] -desktop:Friend20060613 is defined -as an instance of voc:ImageFile. It is related to desktop:MyFriend -through the voc:depicts property. It is nowhere stated that the class -voc:Friend is a subclass of voc:Person. This is legal, but not -valid usage of the rdfs:domain and -rdfs:range as defined in [1]. Given the closed-world -assumption, -it cannot be determined whether the statement 'desktop:MyFriend is -voc:Person' is true. Note that if voc:Friend was defined as a -subclass of voc:Person, the statement would become true -and -therefore the NRL data would be both legal and valid.<br /> - - - - -<br style="font-family: monospace;" /> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;">[1] -:o1 {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - voc:depicts rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:domain voc:ImageFile ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range voc:Person ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdfs:subClassOf voc:Person . }</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - :ib1 { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] -desktop:Myself rdf:type voc:Person . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] -desktop:MyFriend rdf:type voc:Friend . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[4] -desktop:PassportPhoto rdf:type voc:ImageFile ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - voc:depicts -desktop:Myself .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[5] -desktop:Friend20060613 rdf:type voc:ImageFile ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - - voc:depicts desktop:MyFriend . } </span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -<h4><a class="mozTocH4" name="mozTocId332366"></a><a name="2.3.2_Blank_Nodes"></a>2.3.2 -Blank Nodes</h4> - - - - -<p style="text-align: justify;">The use of blank nodes -in conjunction with NRL elements and -their instances is strongly discouraged. Blank nodes are semantically -difficult to handle and as a result it is difficult to implement them -correctly. </p> - - - - -<div style="text-align: justify;"><i><span style="font-weight: bold;">Recommendation:</span> The -use of blank nodes is strongly -discouraged. Data containing blank nodes is legal but not valid NRL -data.<br /> - - - - -</i> -<h4><a class="mozTocH4" name="mozTocId397156"></a><a name="2.3.3_Grouping_resources"></a>2.3.3 -Collections -and Containers</h4> - - - - -<p>Container classes are -deprecated because the semantics of -containers are not clear and they are also difficult to handle. The -sole use of either containers or collections is sufficient to model -grouped resources. Since the semantics of collections are clearer, the -use of containers is discouraged in favour of collections.</p> - - - - -<ol> - - - - - <li>rdf:Bag is a -container class whose use is discouraged.</li> - - - - - <li>rdf:Alt is a -container class whose use is discouraged.</li> - - - - - <li style="text-align: justify;">rdf:Seq is a -container class whose use is discouraged.</li> - - - - - <li style="text-align: justify;">rdfs:Container is the -superclass of rdf:Bag, rdf:Alt and -rdf:Seq, and is not applicable to any other RDF/S or NRL element.</li> - - - - - <li style="text-align: justify;">rdfs:ContainerMembershipProperty -is used to indicate the -membership of rdf:Bag, rdf:Alt and rdf:Seq, and is not applicable to -any other RDF/S or NRL element.</li> - - - - - <li style="text-align: justify;">rdfs:member is a -super property of the container -membership -properties, and is not applicable to any other RDF/S or NRL element.</li> - - - - -</ol> - - - - -<span style="font-weight: bold; font-style: italic;">Recommendation:</span><span style="font-style: italic;"> -The use elements numbered [1] -through -[6] is strongly discouraged. <br /> - - - - -</span> -<p>Although the use of -container classes and properties is -discouraged, resources can still be grouped using [<a href="http://www.w3.org/TR/rdf-schema/#ch_collectionvocab">RDFS -Collections</a>] constructs.</p> - - - - -</div> - - - - -<ol> - - - - - <li>rdf:List is a class that can be used to build -descriptions -of collections. A collection typically is composed of one or more lists.</li> - - - - - <li>rdf:first is a property that relates a list to its first -element.</li> - - - - - <li>rdf:rest is a property that relates a list to the rest of -the elements excluding the first element. The rest of the elements are -in the form of another list.</li> - - - - - <li>rdf:nil is a property that can be used to create an empty -list. This is usually the last list in a collection.</li> - - - - -</ol> - - - - -<i><span style="font-weight: bold;">Recommendation:</span> -The combined use of elements -numbered -[1] through [4] is encouraged as an alternative to container elements<br /> - - - - -</i> -<h4><a class="mozTocH4" name="mozTocId220340"></a><a name="2.3.4_rdfs:isDefinedBy"></a>2.3.4 -rdfs:isDefinedBy</h4> - - - - -<p style="text-align: justify;">The semantics of this -element is unclear and therefore it is -discouraged. The definition vaguely -allows the use of this property to relate any two resources.</p> - - - - -<i><span style="font-weight: bold;">Recommendation:</span> -The use of rdfs:isDefinedBy is -strongly discouraged. Data containing statements using this property is -legal but not valid NRL data.</i> -<h4><a class="mozTocH4" name="mozTocId361071"></a><a name="2.3.5_Reification"></a>2.3.5 -Reification</h4> - - - - -<p style="background-color: rgb(255, 255, 255);">The -named -graphs paradigm provides all -the functionality required to be able to state things about other -statements. Consequently, the idea of reification within the NRL -context is redundant. </p> - - - - -<span style="background-color: rgb(255, 255, 255);"></span><span style="font-style: italic; background-color: rgb(255, 255, 255);"><span style="font-weight: bold;">Recommendation:</span> -The use of reification is strongly discouraged.</span><span style="background-color: rgb(255, 255, 255);"> -</span><br /> - - - - -<h3><a class="mozTocH3" name="mozTocId932814"></a><a name="2.4._Constraint_Extensions"></a>2.4. -Constraint Extensions</h3> - - - - -<p>This -section -presents extensions used to make statements -about constraints on the use of properties in NRL data. These -extensions provide further functionalities to the basic -constraints provided by RDFS, namely [<a href="http://www.w3.org/TR/rdf-schema/#ch_domain">rdfs:domain</a>] -and [<a href="http://www.w3.org/TR/rdf-schema/#ch_range">rdfs:range</a>]. -The latter two constraints place a limitation on the class -type of the resources that a property can relate (<span style="font-style: italic;">class type</span> <span style="font-style: italic;">constraints</span>).<span style="font-style: italic;"> </span>The NRL -constraint extensions in turn place a limitation on the amount -of values that a property can take (<span style="font-style: italic;">range -cardinality constraints</span>) and on actual pairs of -resources that the property should or should -not, through inference, relate (<span style="font-style: italic;">resource -relation constraints</span>). -These three categories are -summarized in [<a href="#Table_1">Table 1</a>]. -Similarly -to RDFS, NRL provides a mechanism for describing these constraints, but -does -not say whether or how an application must process the constraint -information. In particular, in the Social Semantic Desktop scenario, -different applications -will use -the -constraints in different ways. NRL Validators will be expected to check -for errors, -interactive editors to suggest legal values, and reasoners to -perform inference and inconsistency checks.</p> - - - - -<table style="text-align: left; width: 100%; height: 228px;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td style="font-style: italic; width: 220px;">Class -Type -Constraints</td> - - - - - <th colspan="1" rowspan="8" style="width: 87px;"></th> - - - - - <td style="font-style: italic; width: 231px;">Range -Cardinality -Constraints</td> - - - - - <td colspan="1" rowspan="8" style="width: 94px;"></td> - - - - - <td style="font-style: italic; width: 244px;">Resource -Relation Constraints</td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 220px;">rdfs:domain</td> - - - - - <td style="width: 231px;"><a href="#2.4.7._nrl:cardinality">nrl:cardinality</a></td> - - - - - <td style="width: 244px;"><a href="#2.4.1._nrl:TransitiveProperty">nrl:TransitiveProperty</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 220px;">rdfs:range</td> - - - - - <td style="width: 231px;"><a href="#2.4.8._nrl:minCardinality">nrl:minCardinality</a></td> - - - - - <td style="width: 244px;"><a href="#2.4.2._nrl:SymmetricProperty">nrl:SymmetricProperty</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 220px;"><br /> - - - - - </td> - - - - - <td style="width: 231px;"><a href="#2.4.9._nrl:maxCardinality">nrl:maxCardinality</a></td> - - - - - <td style="width: 244px;"><a href="#2.4.3._nrl:AsymmetricProperty">nrl:AsymmetricProperty</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 220px;"><br /> - - - - - </td> - - - - - <td style="width: 231px;"><br /> - - - - - </td> - - - - - <td style="width: 244px;"><a href="#2.4.4._nrl:ReflexiveProperty">nrl:ReflexiveProperty</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 220px;"><br /> - - - - - </td> - - - - - <td style="width: 231px;"><br /> - - - - - </td> - - - - - <td style="width: 244px;"><a href="#2.4.10._nrl:inverseProperty">nrl:inverseProperty</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 220px;"><br /> - - - - - </td> - - - - - <td style="width: 231px;"><br /> - - - - - </td> - - - - - <td style="width: 244px;"><a href="#2.4.5._nrl:FunctionalProperty">nrl:FunctionalProperty</a></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 220px;"><br /> - - - - - </td> - - - - - <td style="width: 231px;"><br /> - - - - - </td> - - - - - <td style="width: 244px;"><a href="#2.4.6._nrl:InverseFunctionalProperty">nrl:InverseFunctionalProperty</a></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<div style="margin-left: 40px; text-align: center;"><a name="Table_1"></a>Table -1: NRL Constraints </div> - - - - -<div style="text-align: justify;"> -<p>It -should be noted, that the -recommendation given for the RDFS constraints in [<a href="#2.3.1_rdfs:domain_rdfs:range">2.3.1.</a>] -is extended to the NRL constraint extensions. <span style="font-size: 12pt;">Given -a possible closed-world view, in order to -generate valid NRL data a user (human or machine) should check, prior -to using -a property, whether the resources are indeed valid candidates which -satisfy the -constraints.</span></p> - - - - -<p>The following are the classes ([<a href="#2.4.1._nrl:TransitiveProperty">2.4.1.</a>] -- [<a href="#2.4.6._nrl:InverseFunctionalProperty">2.4.6.</a>]) -and properties ([<a href="#2.4.7._nrl:cardinality">2.4.7.</a>] -- [<a href="#2.4.10._nrl:inverseProperty">2.4.10.</a>]) -provided in NRL as -constraint extensions to RDF/S. </p> - - - - -<h4><a class="mozTocH4" name="mozTocId770989"></a><a name="2.4.1._nrl:TransitiveProperty"></a>2.4.1. -nrl:TransitiveProperty</h4> - - - - -</div> - - - - -<p style="text-align: justify;">Properties -may be defined -to -be transitive. If a transitive -property relates resource X to resource Y as well as Y to resource Z, -then it follows that the property also relates X to Z. Semantic views -can realize these declarative semantics by generating -entailment -triples. This class is similar -to [<a href="http://www.w3.org/TR/owl-ref/#TransitiveProperty-def">owl:TransitiveProperty</a>].</p> - - - - -<span style="font-style: italic; font-weight: bold;">Note:</span> -Transitive properties and their superproperties should -not be assigned a maximum cardinality restriction of one. This would -contradict the fact that the resource X described above can be -transitively related to both Y and Z. -<br /> - - - - -<br /> - - - - -<span style="font-style: italic; font-weight: bold;">Note:</span> -Transitive properties should not be defined as [<a href="#2.4.5._nrl:FunctionalProperty">nrl:FunctionalProperty</a>] -properties. If a -transitive functional property relates X to Y, then X cannot be related -to other resources by that same property. Thus transitivity cannot -hold. <br /> - - - - -<br /> - - - - -<span style="font-style: italic; font-weight: bold;">Note:</span> -Transitive properties should not be defined as [<a href="#2.4.6._nrl:InverseFunctionalProperty">nrl:InverseFunctionalProperty</a>] -properties. If a -transitive inverse functional property relates X to Y, then Y cannot be -related to other resources by that same property. Thus transitivity -cannot hold. -<br /> - - - - -<i><br /> - - - - -Example</i> -<br /> - - - - -<br /> - - - - -[1] -voc:containsFolder -is defined as an instance of -rdf:Property, applicable to instances of voc:Folder and taking -instances of voc:Folder as a values. voc:containsFolder is also -defined to be an instance of [<a href="#2.4.1._nrl:TransitiveProperty">nrl:TransitiveProperty</a>]. -<br /> - - - - -<br /> - - - - -[2] -desktop:MyPapers is -defined to be an instance of class voc:Folder. Another voc:Folder, -desktop:PublishedPapers is -related to desktop:MyPapers by the transitive property -voc:containsFolder. -<br /> - - - - -<br /> - - - - -[3] -desktop:PublishedPapers -is defined to be an instance of -class voc:Folder. Another voc:Folder, desktop:ShortPapers is -related to desktop:PublishedPapers by the transitive property -voc:containsFolder. -<br /> - - - - -<p>Since <i>containsFolder</i> -is a transitive -property, a reasoner can easily deduce that since <i>MyPapers - -containsFolder - PublishedPapers</i> and <i>PublishedPapers -- containsFolder - ShortPapers</i>, then <i>MyPapers - -containsFolder - ShortPapers</i> as well.</p> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;"> - :o1 {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - voc:containsFolder rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:domain -voc:Folder ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range -voc:Folder ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[1] - - rdf:type nrl:TransitiveProperty . }</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - :ib1 { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - desktop:MyPapers rdf:type voc:Folder ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] - - voc:containsFolder desktop:PublishedPapers .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] -desktop:PublishedPapers rdf:type voc:Folder ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - - voc:containsFolder desktop:ShortPapers . }</span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -<h4><a class="mozTocH4" name="mozTocId779070"></a><a name="2.4.2._nrl:SymmetricProperty"></a>2.4.2. -nrl:SymmetricProperty</h4> - - - - -<p>Properties can be defined -to -be symmetric. If a symmetric -property relates resource X to resource Y, then it follows that Y is -related to X by the same property. Examples follow [<a href="#2.4.4._nrl:ReflexiveProperty">5.1.4.</a>]. This -class is similar to [<a href="http://www.w3.org/TR/owl-ref/#SymmetricProperty-def">owl:SymmetricProperty</a>].</p> - - - - -<h4><a class="mozTocH4" name="mozTocId832124"></a><a name="2.4.3._nrl:AsymmetricProperty"></a>2.4.3. -nrl:AsymmetricProperty</h4> - - - - -<p>Properties can also be -defined to be asymmetric. Then if -asymmetric property relates X to Y, then Y cannot be related to X by -the same property.</p> - - - - -<h4><a class="mozTocH4" name="mozTocId890283"></a><a name="2.4.4._nrl:ReflexiveProperty"></a>2.4.4. -nrl:ReflexiveProperty</h4> - - - - -<p style="text-align: justify;">Properties -can be defined -to -be reflexive. This would -restrict -the use of this property to relate a resource to itself. Hence, -reflexive properties can only relate resource X to itself.</p> - - - - -<i>Examples</i> -<br /> - - - - -<br /> - - - - -[1] -voc:relatedTopic -is -defined as an instance of -rdf:Property, applicable to instances of <span style="font-family: monospace;">voc</span>:Folder and -taking -instances of voc:Folder as values.<i> relatedTopic</i> -is defined to be an instance of [<a href="#2.4.2._nrl:SymmetricProperty">nrl:SymmetricProperty</a>]. -<br /> - - - - -<br /> - - - - -[2] -voc:hasTopic -is -defined as an instance of -rdf:Property, applicable to instances of <span style="font-family: monospace;">voc</span>:Folder and -taking -instances of voc:Topic as values.<i> hasTopic</i> -is defined to be an instance of [<a href="#2.4.3._nrl:AsymmetricProperty">nrl:AsymmetricProperty</a>]. -<br /> - - - - -<br /> - - - - -[3] -desktop:Publications -is -defined to be an instance of -class voc:Topic. Another voc:Topic, desktop:Research is defined to be -a voc:relatedTopic of desktop:Publications. -<br /> - - - - -Since <i>relatedTopic</i> -is a symmetric -property, it can be inferred that <i>Publications</i> is a -<i>relatedTopic</i> of <i>Research</i>. -<br /> - - - - -<br /> - - - - -[4] -desktop:PublishedPapers -is defined to be an instance of -class voc:Folder. desktop:PublishedPapers is also stated to have -topic desktop:Publications. -<p style="text-align: justify;">Since <i>hasTopic</i> -is an asymmetric -property, -a reasoner would know that it is not possible to say that the<i> </i>topic -<i>Publications</i> has as topic the<i> </i>folder<i> -PublishedPapers</i>.</p> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td> <span style="font-family: monospace;"> :o1 {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - voc:relatedTopic rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:domain voc:Topic ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range voc:Topic ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[1] - - rdf:type nrl:SymmetricProperty . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - voc:hasTopic rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:domain voc:Folder ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range voc:Topic ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] - - rdf:type nrl:AsymmetricProperty . }</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - :ib1 { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] -desktop:Publications rdf:type voc:Topic ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - -voc:relatedTopic desktop:Research .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[4] -desktop:PublishedPapers rdf:type voc:Folder ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - -voc:hasTopic desktop:Publications . }</span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -<h4><a class="mozTocH4" name="mozTocId687239"></a><a name="2.4.5._nrl:FunctionalProperty"></a>2.4.5. -nrl:FunctionalProperty</h4> - - - - -<p style="text-align: justify;">Properties -can be defined -to -be functional. This translates -into the property having a minimum cardinality of zero and a maximum -cardinality of one <span style="font-style: italic;">for -each</span> unique resource that is applied as its domain. -Therefore, if a functional property relates -resource X to resource Y, then it means that X cannot be forward -related to other resources by that same property. In simpler words, the -value of such a property for resource X, if stated, is unique. Example -follows [<a href="#2.4.6._nrl:InverseFunctionalProperty">3.1.13</a>]. This -class is similar to [<a href="http://www.w3.org/TR/owl-ref/#FunctionalProperty-def">owl:FunctionalProperty</a>].</p> - - - - -<h4><a class="mozTocH4" name="mozTocId86301"></a><a name="2.4.6._nrl:InverseFunctionalProperty"></a>2.4.6. -nrl:InverseFunctionalProperty</h4> - - - - -<p>A property can also be -defined to be inverse functional. -Such -a property implies that the inverse of the property is functional. This -does not automatically mean that an inverse property of the property in -question is actually defined using [<a href="#2.4.10._nrl:inverseProperty">nrl:inverseProperty</a>]. -This translates -into the property having a minimum cardinality of zero and a maximum -cardinality of one <span style="font-style: italic;">for -each</span> unique resource that is applied as its range. -Therefore, if such a property relates resource X to resource -Y, then it means that Y cannot be backward related to other resources -using that same property. In other words, if Y is defined as the -property value for one resource, then it cannot be defined as the -property value for another resource. This class is similar -to [<a href="http://www.w3.org/TR/owl-ref/#InverseFunctionalProperty-def">owl:InverseFunctionalProperty</a>].</p> - - - - -<i>Examples</i><br /> - - - - -<br /> - - - - -[1] -voc:user is -defined -as an instance of rdf:Property, -applicable to instances of voc:Desktop and taking instances of -voc:Person as a values. desktop:user is defined to be an instance -of [<a href="#2.4.5._nrl:FunctionalProperty">nrl:FunctionalProperty</a>]. -<br /> - - - - -<br /> - - - - -[2] -voc:email is -defined -as an instance of rdf:Property, -applicable to instances of voc:Person and taking string datatypes -as values. voc:email is defined to be an instance of -[<a href="#2.4.6._nrl:InverseFunctionalProperty">nrl:InverseFunctionalProperty</a>]. -<br /> - - - - -<br /> - - - - -[3] -desktop:MyPersonalDesktop is defined to be an instance -of -class voc:Desktop. It is related to <i>Person</i> -desktop:MyUserName by the property voc:user. -<p style="text-align: justify;">Since <i>user</i> -is a functional property, it -can be concluded that this instance of <i>Desktop</i> has -only that unique particular instance of <i>Person</i> as <i>user</i>. -No other instances of <i>Person</i> can be defined as the <i>user</i> -of this <i>Desktop</i>. Under the closed-world -assumption this would generate warning over conflicting -data. </p> - - - - -[4] -desktop:MyUserName is -defined to be an instance of class voc:Person with a voc:email value of -<i>user.name@host.com.</i> -<p style="text-align: justify;">Since <i>email</i> -is an inverse -functional property, it follows that <i>user.name@host.com -</i>cannot belong to other instances of <i>Person</i>. Doing -so might result in conflicting data due to NRL's closed-world -assumption.</p> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;"> - :o1 {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - voc:user rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - -rdf:domain voc:Desktop ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range voc:Person ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[1] - rdf:type -nrl:FunctionalProperty . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - voc:email rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:domain voc:Person ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range -<http://www.w3.org/2001/XMLSchema#string> ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] - - rdf:type nrl:InverseFunctionalProperty . }</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - :ib1 { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] -desktop:MyPersonalDesktop rdf:type voc:Desktop ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - - voc:user desktop:MyUsername .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[4] -desktop:MyUserName rdf:type voc:Person ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - voc:email -"user.name@host.com" . }</span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -<h4><a class="mozTocH4" name="mozTocId97363"></a><a name="2.4.7._nrl:cardinality"></a>2.4.7. -nrl:cardinality</h4> - - - - -This property is a -cardinality restriction property. It -can -be -applied to instances of rdf:Property to specify a constraint on the -number <span style="font-style: italic;">n</span> -of values that the property can have <span style="font-style: italic;">for -each</span> unique -resource that is applied as its domain. The value -allowed for this property is a nonNegativeInteger data value from the -XML Schema datatypes. This states that instances of the restricted -property must have exactly <span style="font-style: italic;">n</span> -semantically distinct values. In order to -correctly use the NRL vocabulary, this restriction must be always -strictly respected. This property is similar to [<a href="http://www.w3.org/TR/owl-ref/#cardinality-def">owl:cardinality</a>].<br /> - - - - -<h4><a class="mozTocH4" name="mozTocId435982"></a><a name="2.4.8._nrl:minCardinality"></a>2.4.8. -nrl:minCardinality</h4> - - - - -<p>This property is a -cardinality restriction property. It -can -be -applied to instances of rdf:Property to specify a constraint on the -minimum number <span style="font-style: italic;">n</span> -of values that the property can have for each unique resource -it is applied as its domain. The -value allowed for this property is a nonNegativeInteger data value from -the XML Schema datatypes. This states that instances of the restricted -property must have at least <span style="font-style: italic;">n</span> -(<span style="font-style: italic;">n</span> or more) -semantically distinct values. -In particular, properties with a minimum cardinality of one must have -at least one value to be semantically valid. Properties whose minimum -cardinality constraint is not defined have a default minimum -cardinality of zero. In order to correctly use the NRL vocabulary, this -restriction must be always strictly respected. This property is similar -to the Protégé minimum cardinality property -constraints and to [<a href="http://www.w3.org/TR/owl-ref/#minCardinality-def">owl:minCardinality</a>].</p> - - - - -<h4><a class="mozTocH4" name="mozTocId297991"></a><a name="2.4.9._nrl:maxCardinality"></a>2.4.9. -nrl:maxCardinality</h4> - - - - -<p>This property is a -cardinality restriction property. It -can -be -applied to instances of rdf:Property to specify a constraint on the -maximum number <span style="font-style: italic;">n</span> -of values that the property can have for each unique resource it is -applied as its domain. The -value allowed for this property is a nonNegativeInteger data value from -the XML Schema datatypes. This states that instances of the restricted -property must have at most <span style="font-style: italic;">n</span> -(<span style="font-style: italic;">n</span> or less) -semantically distinct values. -In particular, a property with a maximum cardinality of zero would be -of no use since it should never contain any values. Properties -whose maximum cardinality constraint is not -defined -have a default infinite maximum cardinality. In order to correctly use -the NRL vocabulary, this restriction must be always strictly respected. -This property is similar to the Protégé maximum -cardinality property constraints and to [<a href="http://www.w3.org/TR/owl-ref/#maxCardinality-def">owl:maxCardinality</a>].</p> - - - - -Examples<br /> - - - - -<br /> - - - - -The property -desktop:contactEmail is defined as being -applicable to voc:ContactPerson and to have a value of -voc:EmailAddress. Furthermore a restriction is placed on the -minimum cardinality of the values for this property [1]. The minimum -number of values for this property is one. This means, that all <i>ContactPerson</i> -instances must be assigned at least one <i>EmailAddress</i>.<br /> - - - - -<br /> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;"> - :o1 {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - voc:contactEmail rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:domain voc:ContactPerson -;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range voc:EmailAddress ; - </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[1] - - nrl:minCardinality "1" . }</span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -This second example -demonstrates the combinatorial use of -cardinality constraints on properties. The property voc:firstName -is defined as being applicable to voc:ContactPerson and to have a -string datatype value. Two restrictions are placed on the minimum [2] -and maximum [3] cardinality of the values for this property [2]. The -value for both restrictions is set to one. This means, that all <i>ContactPerson</i> -instances must be assigned exactly one <i>firstName</i>.<br /> - - - - -<br /> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;"> - :o1 {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - voc:firstName rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:domain voc:ContactPerson ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range -<http://www.w3.org/2001/XMLSchema#string> ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] - -nrl:minCardinality "1" ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] - -nrl:maxCardinality "1" . }</span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -<h4><a class="mozTocH4" name="mozTocId72221"></a><a name="2.4.10._nrl:inverseProperty"></a>2.4.10. -nrl:inverseProperty</h4> - - - - -<p style="text-align: justify;">Properties are mainly -distinguished by their domain and -range. -Some properties are the exact inverse of each others, where the range -and domain of property A are the domain and range of property B -respectively. In order to provide efficient reasoning and query -handling, the NRL requires that such inverse functionality of two -properties is explicitly stated using the [<a href="#2.4.10._nrl:inverseProperty">nrl:inverseProperty</a>]. -Stating -that a new property B is the inverse property of predefined property A -is equivalent to stating that the range of A is the domain of B and the -domain of A is the range of B. This will help enable the logical -inference of some implicit statements from other explicit statements. -If property A and property B are defined to be inverse properties, -stating that resource X is related by property A to resource Y will -evoke the statement that resource Y is related by property B to -resource X. This property is comparable to -Protégé’s inverse property and [<a href="http://www.w3.org/TR/owl-ref/#inverseOf-def">owl:inverseOf</a>].</p> - - - - -<i>Example</i><br /> - - - - -<br /> - - - - -[1] voc:hasFile is -defined as an instance of -rdf:Property, -applicable to instances of voc:Folder and taking instances of voc:File -as a values.<br /> - - - - -<br /> - - - - -[3] voc:inFolder is -likewise defined as an instance of -rdf:Property, applicable to instances of voc:File and taking -instances of voc:Folder as values. The domain of voc:hasFile is -equivalent to the range of voc:inFolder, while the range of voc:hasFile -is equivalent to the domain of voc:inFolder.<br /> - - - - -<br /> - - - - -[2,4] This implicit -inverse relationship is explicitly -stated -in both properties.<br /> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;"> - :o1 {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ...</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[1] -voc:hasFile rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:domain voc:Folder ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range voc:File ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] - -nrl:inverseProperty voc:inFolder .</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] -voc:inFolder rdf:type rdf:Property ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:domain voc:File ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdf:range voc:Folder ; </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[4] - - nrl:inverseProperty voc:hasFile . }</span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<h2><a class="mozTocH2" name="mozTocId929002"></a><a name="3._NRL_Named_Graph_Extensions"></a>3. -Handling -Multiple Models: NRL Named Graph Extensions</h2> - - - - -<p style="background-color: rgb(255, 255, 255); text-align: justify;">In -the Social Semantic Desktop -domain we -take a Named Graphs approach to semantic data. Named Graphs [NGs] are -an extension on top of RDF, where every RDF Graph as defined -in [<a href="#References">RDF -Specification - CONCEPTS</a>] is identified by -a name. -<span class=""></span>NGs -provide useful additional functionality on top of RDF, -particulary with respect to metametadata (data about metadata), -provenance and data (in)equivalence issues. <span style="background-color: rgb(255, 255, 51);"><span style="background-color: rgb(255, 255, 255);">This approach -is based on -the work</span> <span style="background-color: rgb(255, 255, 255);">described -in [</span></span><a style="background-color: rgb(255, 255, 255);" href="#References">NAMED -GRAPHS</a><span style="background-color: rgb(255, 255, 255);">] -excluding the open-world assumption described there. However, -one -should -note that our definitions for a closed-world and open-world assumption -(See Section <a href="#1.7_NRL_and_Closed_World_Vs._Open_World">1.7</a>) -differ slightly from the ones given in [</span><a style="background-color: rgb(255, 255, 255);" href="#References">NAMED -GRAPHS</a><span style="background-color: rgb(255, 255, 255);">].</span><span style="background-color: rgb(255, 255, 51);"><span style="background-color: rgb(255, 255, 255);"> -As -previously stated NRL does not assume an open-world scenario and -although it imposes no semantics per se to the graphs the NRL -Semantics are based on a closed-world assumption.</span></span></p> - - - - -<div style="text-align: justify; background-color: rgb(255, 255, 255);"> -<p>A -named graph is a pair <span style="font-style: italic;">(n,g)</span>, -where <span style="font-style: italic;">n</span> is -a unique URI -reference denoting the assigned name for the graph <span style="font-style: italic;">g</span>. Such a mapping<span style="font-style: italic;"> -</span>fixes -the graph <span style="font-style: italic;"> -</span><span style="font-style: italic;">g</span> -corresponding -to <span style="font-style: italic;">n -</span>in -a rigid, -non-extensible way<span style="font-style: italic;">.</span> -The URI representing <span style="font-style: italic;">n</span> -can then be used from any location to refer to the -corresponding set of triples belonging to the graph <span style="font-style: italic;">g</span>. In other words, -graph names, like namespaces, should be globally unique. A graph <span style="font-style: italic;">g'</span> -consistent with a -different graph <span style="font-style: italic;">g -</span>named -<span style="font-style: italic;">n -</span>cannot -be assigned the same name <span style="font-style: italic;">n</span>. -Two -different datasets asserting graphs -<span style="font-style: italic;">g</span> and <span style="font-style: italic;">g'</span> having -the same URI for a name contradict one another. </p> - - - - -</div> - - - - -<p style="text-align: justify;">An RDF -triple can exist in a -named graph or outside any named graph. However, for consistency -reasons, all triples must be assigned to some named graph. For -this reason, NRL provides -the special named graph [<a href="#3.1.7._nrl:DefaultGraph">nrl:DefaultGraph</a>]. -Triples existing outside any named graph automatically -form part of this default graph. -This ensures backward compatibility with triples that are not -based -on named graphs. This approach gives rise to the term RDF Dataset as -defined in [<a href="#References">SPARQL-QUERY</a>]. -An RDF dataset is composed of a default graph and an unlimited number -of distinct named graphs. It is formally defined as the set <span style="font-style: italic;">{g, (n</span><sub style="font-style: italic;">1</sub><span style="font-style: italic;">, -g</span><sub style="font-style: italic;">1</sub><span style="font-style: italic;">), (n</span><sub style="font-style: italic;">2</sub><span style="font-style: italic;">, -g</span><sub style="font-style: italic;">2</sub><span style="font-style: italic;">), . . ., (n</span><sub style="font-style: italic;">n</sub><span style="font-style: italic;">, -g</span><sub style="font-style: italic;">n</sub><span style="font-style: italic;">) }</span> comprising of -the default graph <span style="font-style: italic;">g</span> -and zero or more named graphs <span style="font-style: italic;">(n,g)</span>.</p> - - - - -<p style="background-color: rgb(255, 255, 255); text-align: justify;"><span style="background-color: rgb(255, 255, 255);">NRL -distinguishes between </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">Graphs</span><span style="background-color: rgb(255, 255, 255);"> -and </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">Graph -Roles</span><span style="background-color: rgb(255, 255, 255);">, -in -order to have orthogonal modeling -primitives for defining graphs and for specifying their role. A -graph role refers to the characteristics and content of a named graph -(e.g. simple data, an ontology, a knowledge base, etc.) and how the -data is intented to be handled. </span><span style="background-color: rgb(255, 255, 255);" class=""> -The NEPOMUK Annotation Ontology (Refer to the <a href="http://www.semanticdesktop.org/ontologies/nao">NAO</a>) -includes</span><span style="background-color: rgb(255, 255, 255);" class=""> -vocabulary for</span><span style="background-color: rgb(255, 255, 255);" class=""> providing -metadata about graph roles. </span><span style="background-color: rgb(255, 255, 255);">Graph -metadata -will be -attached to these roles rather than to the graphs themselves, because -in practice it makes more sense to describe an ontology or a -knowledge base rather than an anonymous graph. Roles are more stable -than the graphs they represent, and while the graph for a particular -role might change constantly, evolution of the role itself is less -frequent. An instantiation of a -role represents a specific type of graph and the -corresponding triple set data</span><span style="font-style: italic; background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);">. One -can contain graph metadata outside or inside the graph being described. -Storing graph metadata within the graph itself implies that the graph -metadata is also describing itself, which is not something one will -always want to have. Therefore its more suitable to keep graph metadata -separate from its respective graph, and therefore outside the graph. -This means to either contain the metadata in the default -graph, or -in a dedicated named graph. Since having graph metadata about every -existing named graph in the default graph is not practical, it is more -suitable to have the graph metadata in separate named graphs. That is, -any metadata about a named graph <span style="font-style: italic;">g</span> -will be contained within a separate -metadata graph <span style="font-style: italic;">gm</span> -dedicated for <span style="font-style: italic;">g</span>. -A special graph role, [<a href="#3.2.7._nrl:GraphMetadata">nrl:GraphMetadata</a>] -is used to mark such metadata graphs.</span></p> - - - - -<p style="background-color: rgb(255, 255, 255); text-align: justify;"><span style="background-color: rgb(255, 255, 255);"> -General graph -vocabulary is defined in [</span><a style="background-color: rgb(255, 255, 255);" href="#3.1._Graph_Core_Vocabulary_">Section -3.1</a><span style="background-color: rgb(255, 255, 255);">] -while [</span><a style="background-color: rgb(255, 255, 255);" href="#3.2._Graph_Roles_Vocabulary">Section -3.2</a><span style="background-color: rgb(255, 255, 255);">] -is dedicated entirely to graph roles. </span><a style="background-color: rgb(255, 255, 255);" href="#Fig3">Figure -3</a><span style="background-color: rgb(255, 255, 255);"> -depicts the class hierearchy supporting NGs -in NRL. Graph -Roles</span><span style="font-style: italic; background-color: rgb(255, 255, 255);"> -</span><span style="background-color: rgb(255, 255, 255);">(yellow) -are defined as a subclass of the abstract role superclass nrl:Data, -itself being defined as a subclass of the general -Graph -representation -(red). A special Graph specialization (blue) is used as a -marker -class for Graphs that are represented and identified by a -document URL [See </span><a style="background-color: rgb(255, 255, 255);" href="#3.1.2._nrl:DocumentGraph">3.1.2</a>]. -</p> - - - - -<div style="text-align: center;"><img src="NamedGraphs.png" alt="" style="width: 602px; height: 349px;" /><br /> - - - - -</div> - - - - -<p style="margin-left: 40px; text-align: center;"><a name="Fig3"></a>Figure -3: NRL Named Graph class -hierarchy</p> - - - - -<h3><a class="mozTocH3" name="mozTocId549245"></a><a name="3.1._Graph_Core_Vocabulary"></a>3.1. -Graph Core Vocabulary</h3> - - - - -<p>This section specifies -the core named graph vocabulary. This -consists of top-level named graph elements which represent general -graphs. Vocabulary for representation of specific graph roles is -described in section [<a href="#3.2._Graph_Roles_Vocabulary">3.2.</a>].</p> - - - - -<h4><a class="mozTocH4" name="mozTocId991762"></a><a name="3.1.1._nrl:Graph"></a>3.1.1. -nrl:Graph</h4> - - - - -<p>This class represents -a named graph. An instance of -this class will represent a named graph as described in the -introduction of this section, where the name of the instance coincides -with the name of the graph. It should be noted that all graph role -classes described in [<a href="#3.2._Graph_Roles_Vocabulary">3.2</a>] -are subclasses of this element [See <a href="#Fig3">Figure -3</a>]. -As such, there will generally be instances of specific graph -roles -rather than this more generic graph representation. This class is -similar to [<a href="http://www.w3.org/2004/03/trix/">rdfg:Graph</a>].</p> - - - - -<h4><a class="mozTocH4" name="mozTocId246095"></a><a name="3.1.2._nrl:DocumentGraph"></a>3.1.2. -nrl:DocumentGraph</h4> - - - - -<p style="text-align: justify;">This is a marker class -that names graphs via the URL of their containing document. A graph that is completely represented by -such a -document can be defined to be an instance of this class, whereby the -document URL will become the name of that graph. </p> - - - - -<h4><a class="mozTocH4" name="mozTocId178125"></a><a name="3.1.3._nrl:subGraphOf"></a>3.1.3. -nrl:subGraphOf</h4> - - - - -<p style="text-align: justify;">Graphs -can consist of subparts of other more -general -Graphs. In -other terms, a set of triples may form a specific part of a -more -general set of triples. This property can be used to model such a -relationship between two instances of [<a href="#3.1.1">nrl:Graph</a>]. -This -property is the inverse of [<a href="#3.1.4._nrl:superGraphOf">nrl:superGraphOf</a>]. -When a graph <span style="font-style: italic;">g</span> -is defined to be a subgraph of another graph <span style="font-style: italic;">g'</span>, the latter is -understood to be the supergraph of <span style="font-style: italic;">g</span>. -This -property is similar to [<a href="http://www.w3.org/2004/03/trix/">rdfg:subGraphOf</a>]. </p> - - - - -<h4><a class="mozTocH4" name="mozTocId972506"></a><a name="3.1.4._nrl:superGraphOf"></a>3.1.4. -nrl:superGraphOf</h4> - - - - -<p>This property can be -used to state that one graph subsumes -another -graph. A supergraph will then consist of one or more subgraphs. This -property is the inverse of [<a href="#3.1.3._nrl:subGraphOf">nrl:subGraphOf</a>]. -When a graph <span style="font-style: italic;">g' -</span>is -defined to be a supergraph of another graph <span style="font-style: italic;">g</span>, the latter is -understood to be a supgraph of <span style="font-style: italic;">g'</span>. -The property [<a href="#3.1.6._nrl:imports">nrl:imports</a>] -is a subproperty of this property.</p> - - - - -<h4><a class="mozTocH4" name="mozTocId503632"></a><a name="3.1.5._nrl:equivalentGraph"></a>3.1.5. -nrl:equivalentGraph</h4> - - - - -<div style="text-align: justify;">A set -of triples can -undergo duplication at a number of separate locations. This property -can effectively be used to state that a graph that manifests -itself at more than one location under -different names -is in fact equivalent. Equivalent graphs are simultaneously -the subgraph and supergraph of each other. This property is similar -to [<a href="http://www.w3.org/2004/03/trix/">rdfg:equivalentGraph</a>].<br /> - - - - -</div> - - - - -<span class=""><span style="font-style: italic; background-color: rgb(255, 255, 255);"><br /> - - - - -<span style="font-weight: bold;">Note</span></span><span style="background-color: rgb(255, 255, 255);"><span style="font-weight: bold;">:</span> The -term equivalentGraph -is subject to the role of the graphs being related. Hence for two -graphs to be defined equivalent, they must either -have the same role, or be a superrole or subrole of each other -as depicted -in </span><a style="background-color: rgb(255, 255, 255);" href="#Fig3">Figure -3</a><span style="background-color: rgb(255, 255, 255);">. -When a -graph </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">g</span><span style="background-color: rgb(255, 255, 255);"> -having a role </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">R -</span><span style="background-color: rgb(255, 255, 255);">is -defined to be equivalent to a graph </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">g'</span><span style="background-color: rgb(255, 255, 255);"> having a -superrole </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">R'</span><span style="background-color: rgb(255, 255, 255);">, -then </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">g' -</span><span style="background-color: rgb(255, 255, 255);">is -understood to have the more specific role </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">R</span><span style="background-color: rgb(255, 255, 255);">. For example, -if -graph </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">g -</span><span style="background-color: rgb(255, 255, 255);">having -role [<a href="#3.2.4._nrl:Ontology">nrl:Ontology</a>] -is defined as equivalent to graph </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">g'</span><span style="background-color: rgb(255, 255, 255);"> having role -[<a href="#3.2.2._nrl:Schema">nrl:Schema</a>], -then -it can be said that graph </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">g'<span style="font-style: italic;"><span style="font-style: italic;"> </span></span></span><span style="background-color: rgb(255, 255, 255);">has -a role of [<a href="#3.2.4._nrl:Ontology">nrl:Ontology</a>]. -However not all graphs can be defined to be -equivalent. For example, graph </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">g</span><sub style="font-style: italic; background-color: rgb(255, 255, 255);">1</sub><span style="font-style: italic; background-color: rgb(255, 255, 255);"> -</span><span style="background-color: rgb(255, 255, 255);">having -role -[<a href="#3.2.3._nrl:InstanceBase">nrl:InstanecBase</a>] -cannot be defined as equivalent to graph </span><span style="font-style: italic; background-color: rgb(255, 255, 255);">g</span><sub style="font-style: italic; background-color: rgb(255, 255, 255);">2</sub><span style="background-color: rgb(255, 255, 255);"> if -this graph has the role </span></span><span class=""><span style="background-color: rgb(255, 255, 255);">[<a href="../../l#3.2.2._nrl:Schema">nrl:Schema</a>]</span></span><span class=""><span style="background-color: rgb(255, 255, 255);">.</span><br /> - - - - -</span><span style="font-weight: bold;"></span> -<h4><a class="mozTocH4" name="mozTocId858885"></a><a name="3.1.6._nrl:imports"></a>3.1.6. -nrl:imports</h4> - - - - -<div style="text-align: justify;"> -<p>This special subproperty -of [<a href="#3.1.4._nrl:superGraphOf">nrl:superGraphOf</a>] -models graph imports and can be used to state that an existing named -graph <span style="font-style: italic;">g'</span> -should be considered as part of graph <span style="font-style: italic;">g</span>. -This is akin to -saying that <span style="font-style: italic;">g'</span> -is a subgraph of <span style="font-style: italic;">g</span> -or inversely that <span style="font-style: italic;">g</span> -is a supergraph of <span style="font-style: italic;">g'</span>. -This property can be used to model graph role data imports. Importing a -graph into another means that all the former graph’s data, -and semantics, -will implicitly form part of the latter.<span style="font-style: italic;"></span><span style="font-style: italic;"></span> -Such modelling is transitive. If graph<span style="font-style: italic;"> -g</span> is imported into -graph <span style="font-style: italic;">g'</span>, -and <span style="font-style: italic;">g'</span> is -imported into graph <span style="font-style: italic;">g''</span>, -then <span style="font-style: italic;">g''</span> -also includes the data represented by<span style="font-style: italic;"><span style="font-style: italic;"> </span>g</span>. -Two graphs <span style="font-style: italic;">g</span> -and <span style="font-style: italic;">g'</span> -are equivalent if they import each other. When applied to the [<a href="#3.2.4._nrl:Ontology">nrl:Ontology</a>] -role this property -can be used to model ontology imports and in this case this -property is -similar to [<a href="http://www.w3.org/TR/owl-ref/#imports-def">owl:imports</a>]. -<span style="background-color: rgb(255, 255, 255);">An -incompatibility problem may arise when importing graphs with -incompatible semantics to the current graph, or combining multiple -graphs with different semantics into a new supergraph.. This -incompatibility may however be resolved via semantic views which -rectify this problem by aligning the different semantics of the graphs.</span></p> - - - - -</div> - - - - -<h4><a class="mozTocH4" name="mozTocId337127"></a><a name="3.1.7._nrl:DefaultGraph"></a>3.1.7. -nrl:DefaultGraph</h4> - - - - -<div style="text-align: justify;"> -<p>Although triples can exist inside a named graph or -outside any -named graph, for consistency reasons all triples are required to form -part of some named <span style="background-color: rgb(255, 255, 255);">graph. -This -default graph instance is provided by -NRL to serve this requirement. All triples existing outside any named -graph</span><span style="background-color: rgb(255, 255, 255);"> -(e.g. external triples unaware of NRL's named graph approach), -will be assigned to this default graph. The -DefaultGraph is disjoint from all other existing named graphs and it is -given by the intersection of the complements of all other existing -named graphs in the RDF triple space.</span></p> - - - - -</div> - - - - -<h3><a class="mozTocH3" name="mozTocId787923"></a><a name="3.2._Graph_Roles_Vocabulary"></a><span style="font-weight: bold;"></span>3.2. -Graph -Roles Vocabulary </h3> - - - - -<div style="text-align: justify;"> -<p>This section introduces -classes and properties provided in NRL that -deal with Graph Roles as described in the introduction of <a href="#3._NRL_Named_Graph_Extensions">Section 3</a> -and -depicted in <a href="#Fig3">Figure -3</a>. This vocabulary is closely tied with the Graph Metadata -Vocabulary provided in [<a href="http://www.semanticdesktop.org/ontologies/nao">NAO</a>]. -In fact they can also be considered as graph metadata vocabulary, since -the elements are in practice used within graph metadata definitions. -However, due to their essential nature they are core NRL elements. </p> - - - - -</div> - - - - -<h4><a class="mozTocH4" name="mozTocId792849"></a><a name="3.2.1._nrl:Data"></a>3.2.1. -nrl:Data</h4> - - - - -<div style="text-align: justify;"> -<p>This is an abstract -class -representing all graph roles. All graphs are assigned one of -the -roles represented by this abstract superclass. It is itself a subclass -of [<a href="#3.1.1._nrl:Graph">nrl:Graph</a>] -alongside [<a href="#4.1.1_nrl:GraphView">nrl:GraphView</a>] -and [<a href="#3.1.2._nrl:DocumentGraph">nrl:DocumentGraph</a>].</p> - - - - -<h4><a class="mozTocH4" name="mozTocId420122"></a><a name="3.2.2._nrl:Schema"></a>3.2.2. -nrl:Schema</h4> - - - - -</div> - - - - -<div style="text-align: justify;"> -<p>A -schema represents a -conceptualisation model. This class is used as a role for a graph that -represents data in the -form of a schema. It is defined as a subclass of [<a href="#3.2.1._nrl:Data">nrl:Data</a>], -and -therefore also a subclass of [<a href="#3.1.1._nrl:Graph">nrl:Graph</a>]; -and it -is a superclass of [<a href="#3.2.4._nrl:Ontology">nrl:Ontology</a>].</p> - - - - -<h4><a class="mozTocH4" name="mozTocId196061"></a><a name="3.2.3._nrl:InstanceBase"></a>3.2.3. -nrl:InstanceBase</h4> - - - - -<p>A graph may represent instances of classes -defined -using some schema (or ontology) that is represented by another separate -graph. This class provides the representation for such graphs. An -instance base is a -subclass of [<a href="#3.2.1._nrl:Data">nrl:Data</a>], -and therefore also a subclass of -[<a href="#3.1.1._nrl:Graph">nrl:Graph</a>].</p> - - - - -<h4><a class="mozTocH4" name="mozTocId287595"></a><a name="3.2.4._nrl:Ontology"></a>3.2.4. -nrl:Ontology</h4> - - - - -<p>An ontology is a more expressive type of schema describing -more complex -models which may include rule-based knowledge in addition to a -relational characterisation. This class represents such a role for a -Graph and it can also serve the -purpose of an ontology header within RDF/S documents as provided by [<a href="http://www.w3.org/TR/owl-ref/#Ontology-def">owl:Ontology</a>]. -This class is a subclass of [<a href="#3.2.2._nrl:Schema">nrl:Schema</a>] -and therefore also a subclass -of -[<a href="#3.2.1._nrl:Data">nrl:Data</a>] -and [<a href="#3.1.1._nrl:Graph">nrl:Graph</a>].</p> - - - - -<h4><a class="mozTocH4" name="mozTocId372280"></a><a name="3.2.5._nrl:KnowledgeBase"></a>3.2.5. -nrl:KnowledgeBase</h4> - - - - -<p>A graph can represent a schema (or ontology) together -with a -number of instantiations of elements in the same schema (or ontology). -Such a graph has a similar role to an instance base with the major -difference that it also represents the schema (or ontology) providing -the constructs used to define the instances. Therefore this -role can be seen as a subset of the -intersection of the [<a href="#3.2.4._nrl:Ontology">nrl:Ontology</a>] -and [<a href="#3.2.3._nrl:InstanceBase">nrl:InstanceBase</a>] -roles, and is in -fact defined as a subclass of both these roles. -</p> - - - - -</div> - - - - -<h4><a class="mozTocH4" name="mozTocId379616"></a><a name="3.2.6._nrl:Configuration"></a>3.2.6. -nrl:Configuration</h4> - - - - -<div style="text-align: justify;"> -<p>Technical -configuration -data that is -irrelevant to general semantic web data can also be -represented -within a graph, through this role. Other additional roles serving -different purposes might be added in the future. This class is a -subclass of [<a href="#3.2.1._nrl:Data">nrl:Data</a>]. -</p> - - - - -<h4><a class="mozTocH4" name="mozTocId781665"></a><a name="3.2.7._nrl:GraphMetadata"></a>3.2.7. -nrl:GraphMetadata</h4> - - - - -<p>This role is useful to mark graphs whose sole purpose is to -store -metadata about some specific graph. Data about a graph, or Graph -Metadata, is thus stored in a corresponding graph that has -this -role. -</p> - - - - -</div> - - - - -<h4><a class="mozTocH4" name="mozTocId159397"></a><a name="3.2.8._nrl:graphMetadataFor"></a><span style="background-color: rgb(255, 255, 255);">3.2.8. -nrl:graphMetadataFor</span></h4> - - - - -<div style="background-color: rgb(255, 255, 255);"> -<p>This -property binds a metadata graph to the graph being -described. A metadata graph must point to the named graph being -described therefore the minimum cardinality is set to 1. Given that in -some cases a single metadata graph can provide metadata for multiple -graphs, the maximum cardinality is undefined. </p> - - - - -</div> - - - - -<h4 style="background-color: rgb(255, 255, 255);"><a class="mozTocH4" name="mozTocId728175"></a><a style="background-color: rgb(255, 255, 255);" name="3.2.9._nrl:coreGraphMetadataFor"></a><span style="background-color: rgb(255, 255, 255);">3.2.9. -nrl:coreGraphMetadataFor</span></h4> - - - - -<div style="text-align: justify; background-color: rgb(255, 255, 255);"> -<p style="background-color: rgb(255, 255, 255);">Although -a graph can have multiple metadata graphs that describe it, -there can only be one unique core metadata graph which defines the -graph's important core properties, e.g. whether it is updatable or -otherwise and other important metadata -vocabulary. This property identifies such a core metadata graph and -points to the graph it describes. It is a subproperty of <a href="#3.2.8._nrl:graphMetadataFor">nrl:graphMetadataFor</a>.<br /> - - - - -</p> - - - - -<span style="font-style: italic;"><span style="font-weight: bold; background-color: rgb(255, 255, 255);">Note:</span><span style="background-color: rgb(255, 255, 255);"> -Sometimes the inverse link (from the subject named graph to its core -metadata graph) might be of practical use. However, in order to avoid -redundancy in the language, this direction has not been included in -NRL. For a more efficient access to a graph's metadata, specific -applications might want to establish this direction when loading graphs.</span></span> -</div> - - - - -<h4 style="background-color: rgb(255, 255, 255);"><a class="mozTocH4" name="mozTocId465236"></a><a name="3.2.10._nrl:Semantics"></a>3.2.10. -nrl:Semantics</h4> - - - - -<div style="text-align: justify;"> -<p><span style="background-color: rgb(255, 255, 255);">The -declarative semantics for a graph role can be specified by -referring to instances of this class. Such an instance will consist of -an identifier to a location where the formal semantics of the schema or -language used are specified.</span></p> - - - - -<h4><a class="mozTocH4" name="mozTocId737534"></a><span style="background-color: rgb(255, 255, 255);"></span><a name="3.2.11._nrl:hasSemantics"></a>3.2.11. -nrl:hasSemantics</h4> - - - - -<p><span style="background-color: rgb(255, 255, 255);">Graph -roles -do not automatically have any semantics, but these can be -specified through this property (declarative -semantics) with respect -to an instance of the special class [<a href="#3.2.10._nrl:Semantics">nrl:Semantics</a>]. -The semantics of a -graph role can also be realized (procedural semantics) by -instantiating a graph view with a semantic -specification over the role (See </span><a style="background-color: rgb(255, 255, 255);" href="#4._Graph_Views_Extensions">Graph Views -Extensions</a><span style="background-color: rgb(255, 255, 255);"> and <a href="#4.2.2._nrl:realizes">nrl:realizes</a>). However -this property has a declarative rather than a procedural role.</span></p> - - - - -<span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);"></span><span style="background-color: rgb(255, 255, 255);"><span style="font-style: italic; font-weight: bold;">Note:</span> -A graph role -with (virtual) declarative semantics -should never be assumed to also carry (realized) procedural -semantics. </span><br /> - - - - -</div> - - - - -<h4 style="background-color: rgb(255, 255, 255);"><a class="mozTocH4" name="mozTocId331701"></a><a name="3.2.12._nrl:semanticsDefinedBy"></a>3.2.12. -nrl:semanticsDefinedBy</h4> - - - - -<div style="text-align: justify;"> -<p><span style="background-color: rgb(255, 255, 51);"><span style="background-color: rgb(255, 255, 255);">This -property links instances of the </span></span><span style="background-color: rgb(255, 255, 255);">[<a href="../../l#3.2.10._nrl:Semantics">nrl:Semantics</a>]</span><span style="background-color: rgb(255, 255, 51);"><span style="background-color: rgb(255, 255, 255);"> class to a -URL for a document that defines the formal, non-machine-readable -semantics that the instance is representing.</span></span></p> - - - - -<span style="background-color: rgb(255, 255, 51);"></span></div> - - - - -<h4 style="background-color: rgb(255, 255, 255); text-align: justify;"><a class="mozTocH4" name="mozTocId704028"></a><a name="3.2.13._nrl:semanticsLabel"></a>3.2.13. -nrl:semanticsLabel</h4> - - - - -<div style="text-align: justify;"> -<p><span style="background-color: rgb(255, 255, 255);">This -trivial property assigns a string label to instances of the </span><span style="background-color: rgb(255, 255, 255);">[<a href="../../l#3.2.10._nrl:Semantics">nrl:Semantics</a>]</span><span style="background-color: rgb(255, 255, 255);"> -class, in order to more easily identify and refer to different -semantics.</span></p> - - - - -<p><span style="background-color: rgb(255, 255, 255);"></span></p> - - - - -<h4 style="background-color: rgb(255, 255, 255);"><a class="mozTocH4" name="mozTocId379929"></a><a name="3.2.14._nrl:updatable"></a>3.2.14. -nrl:updatable</h4> - - - - -<p style="background-color: rgb(255, 255, 255);"><span style="font-weight: normal;">A -graph role is stated as being -updatable (1) or static (0). A static graph prevents any modifications -- any modified versions of the graph must be created as a separate -graph. A non-static graph's dataset can be directly modified.</span></p> - - - - -<p><span style="background-color: rgb(255, 255, 255);"> -</span></p> - - - - -</div> - - - - -<h3><a class="mozTocH3" name="mozTocId54895"></a><a name="3._Named_Graph_Example"></a>3. -Named Graph Example</h3> - - - - -<div style="text-align: justify;"> -<p>The following example -demonstrates the use of NG extensions and is based on <a href="http://www.wiwiss.fu-berlin.de/suhl/bizer/TriG/">TriG</a> -[TRIG] as introduced in the introduction of this document. A simple -graph in TriG -named G (where g is a URI) is syntactically denoted by: -</p> - - - - -</div> - - - - -<table style="text-align: left; width: 100%; height: 32px;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td style="width: 100%;"> - - - - <div style="text-align: center; margin-left: 40px;">:G -{<span style="font-style: italic;">Triple Set</span>}<br /> - - - - - </div> - - - - - </td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<div style="margin-left: 40px;"><br /> - - - - -</div> - - - - -<p>This example and the one -that follows in [<a href="#4.3_Graph_Views_Example">Section -4.3</a>] model -the dataflow represented in <a href="#Fig2">Figure -2</a>. -This example demonstrates how one can make use of the named graph -paradigm and the syntax for named graphs presented in this -section. <br /> - - - - -</p> - - - - -<div style="text-align: justify; background-color: rgb(255, 255, 255);"><span style="font-style: italic;"></span>[1] The -example starts by defining the -required namespaces.<br /> - - - - -<br /> - - - - -[2-7] Metadata about six -different graphs is represented within four metadata graphs. <br /> - - - - -<br /> - - - - -[3] The metadata graph describing graph <span style="font-style: italic;">ex:o1</span> -given in [8] states that <span style="font-style: italic;">ex:o1</span> -is an ontology (graph with role ontology). <span style="font-style: italic;"><br /> - - - - -<br /> - - - - -</span>[4] <span style="font-style: italic;">ex:o1 </span>is -defined to have the declarative semantics defined by the instance <span style="font-style: italic;">RDFS</span>.<br /> - - - - -<br /> - - - - -[5] <span style="font-style: italic;">RDFS</span> -is an instance of -nrl:Semantics. It is labelled 'RDF/S' and its semantics are said to be -defined by 'http://www.w3.org/TR/rdf-schema#'.<br /> - - - - -<br /> - - - - -<span style="font-style: italic;"></span>[6] <span style="font-style: italic;">ex:o1_metadata </span>itself -is marked as being graph metadata.<br /> - - - - -<span style="font-style: italic;"></span><br /> - - - - -[7] <span style="font-style: italic;">ex:o2_metadata </span>says -that <span style="font-style: italic;">ex:o2</span> -is graph equivalent to <span style="font-style: italic;">http://www.domain.com/o2.rdfs. </span><br /> - - - - -<span style="font-style: italic;"></span><br /> - - - - -[8] <span style="font-style: italic;">ex:o2_metadata</span> states -also that <span style="font-style: italic;">ex:o </span>is -an ontology represented by the union of graphs <span style="font-style: italic;">ex:o1</span> and <span style="font-style: italic;">ex:o2</span>. <span style="font-style: italic;">ex:o</span> is now a -supergraph of <span style="font-style: italic;">ex:o1</span> -and <span style="font-style: italic;">ex:o2</span> -(or <span style="font-style: italic;">http://www.domain.com/o2.rdfs</span>). -Inversely the named graphs are subgraphs of <span style="font-style: italic;">ex:o</span>.<br /> - - - - -<br /> - - - - -[9] <span style="font-style: italic;">ex:ib1_metadata </span>states -that <span style="font-style: italic;">ex:ib1 </span>is -an instance base defined in [9].<br /> - - - - -<br /> - - - - -[10] <span style="font-style: italic;">ex:kb1_metadata</span> -states that <span style="font-style: italic;">ex:kb1 </span>is -a knowledge base graph represented by the union of graphs <span style="font-style: italic;">ex:o</span>,<span style="font-style: italic;"> ex:ib1 </span>and<span style="font-style: italic;"> </span><span style="font-style: italic;">http://www.anotherdomain.com/ib2.rdf</span>s. -Alternatively, through the definition of <span style="font-style: italic;">ex:o </span>[5], one can -say that <span style="font-style: italic;">ex:kb1</span> -is represented by the union of graphs <span style="font-style: italic;">ex:o1</span>, -<span style="font-style: italic;">ex:o2 </span>(or<span style="font-style: italic;"> </span><span style="font-style: italic;">http://www.domain.com/o2.rdfs</span>), -<span style="font-style: italic;">ex:ib1</span> and <span style="font-style: italic;">http://www.anotherdomain.com/ib2.rdfs</span>, -where the latter graphs are all subgraphs of <span style="font-style: italic;">ex:kb1</span>.<br /> - - - - -<br /> - - - - -<span style="font-style: italic;"> -</span>[12] The representation for graph <span style="font-style: italic;">ex:o1</span> (an ontology) -is composed of the definition of a class <span style="font-style: italic;">ex:Person</span>, a class -ex:<span style="font-style: italic;">DesktopUser</span> -which is also a subclass of <span style="font-style: italic;">ex:Person</span>, -and a symmetric property <span style="font-style: italic;">ex:knows</span> -which relates instances of <span style="font-style: italic;">ex:Person</span> -to other -instansces of <span style="font-style: italic;">ex:Person</span>.<br /> - - - - -<br /> - - - - -[12] The representation for graph <span style="font-style: italic;">ex:ib1 -</span>(an instance base) is composed of the definition of an -instance of <span style="font-style: italic;">ex:DesktopUser -</span>called <span style="font-style: italic;">ex:User1</span>, -and two instances of <span style="font-style: italic;">ex:Person</span> -called <span style="font-style: italic;">ex:Contact1</span> -and <span style="font-style: italic;">ex:Contact2</span>. -<span style="font-style: italic;">ex:Contact1</span> -'knows' <span style="font-style: italic;">ex:Contact2</span> -and <span style="font-style: italic;">ex:User1</span> -while ex:Contact2 'knows' <span style="font-style: italic;">ex:User1</span>. -However since <span style="font-style: italic;">ex:knows </span>is -a symmetric property, all three instances of <span style="font-style: italic;">ex:Person</span> (or its -subclass <span style="font-style: italic;">ex:DesktopUser</span>) -'know' each other.<br /> - - - - -<br /> - - - - -<table style="text-align: left; font-family: monospace; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;">[1] - @prefix nrl: -<http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> -.</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - @prefix ex: -<http://www.example.org/vocabulary#> .</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] - ex:o1_metadata { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] - ex:o1 a nrl:Ontology ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[4] - nrl:hasSemantics ex:RDFS .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[5] - ex:RDFS a nrl:Semantics ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - -nrl:semanticsDefinedBy "http://www.w3.org/TR/rdf-schema#" ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - -nrl:semanticsLabel "RDF/S" . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[6] - ex:o1_metadata rdf:type nrl:GraphMetadata . }</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:o2_metadata { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[7] - ex:o2 rdf:type nrl:Ontology ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - -nrl:equivalentGraph <http://www.domain.com/o2.rdfs> . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[8] - ex:o rdf:type nrl:Ontology ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - nrl:imports ex:o1 ,</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - ex:o2 . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:o2_metadata rdf:type nrl:GraphMetadata . }</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[9] - ex:ib1_metdata {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:ib1 rdf:type nrl:InstanceBase .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:ib1_metadata rdf:type nrl:GraphMetadata . }</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[10] -ex:kb1_metadata {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:kb1 rdf:type nrl:KnowledgeBase ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - nrl:imports ex:o , </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - ex:ib1 , </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - -<http://www.anotherdomain.com/ib2.rdfs> . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:kb1_metadata rdf:type nrl:GraphMetadata . }</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[11] ex:o1 { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:Person rdf:type rdfs:Class .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:DesktopUser rdf:type rdfs:Class ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - rdfs:subClassOf ex:Person .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:knows rdf:type rdf:Property ,</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - nrl:SymmetricProperty ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - rdfs:domain -ex:Person ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - rdfs:range -ex:Person . }</span><br style="font-family: monospace;" /> - - - - - <br /> - - - - - <span style="font-family: monospace;">[12] ex:ib1 { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -ex:User1 rdf:type ex:DesktopUser .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:Contact1 rdf:type ex:Person ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - ex:knows ex:User1 ,</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - -ex:Contact1 .</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -ex:Contact2 rdf:type ex:Person ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - ex:knows ex:User1 . } </span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -<p>The -RDF/S Ontology -accesible at <span style="font-style: italic;">http://www.domain.com/o2.rdfs</span> -and serialized as RDF/XML is given and described as follows.</p> - - - - -[1] Required namespaces are defined.<br /> - - - - -<br /> - - - - -[2] The [<a href="#3.2.4._nrl:Ontology">nrl:Ontology</a>] -class -can be used to define some (ontology) graph metadata about the graph -represented by this RDF/S document. Here it states that this is -a document graph having the role of an ontology. <br /> - - - - -<span style="font-style: italic; background-color: rgb(255, 255, 255);"><br /> - - - - -<span style="font-weight: bold;">Note:</span> -Although this is allowed it is not considered best practice, since in -this way, given that we state that XML/RDFS files can only encode one -graph at a time, one is effectively providing graph metadata within the -graph itself. This goes against our notion of keeping metadata about a -graph separate from the graph itself, as discussed in [<a href="#3._NRL_Named_Graph_Extensions">Section 3</a>].</span><br style="background-color: rgb(255, 255, 51);" /> - - - - -<br /> - - - - -[3] A class <span style="font-style: italic;">Desktop</span> -is defined.<br /> - - - - -<br /> - - - - -[4] A property <span style="font-style: italic;">user</span> -is defined as relating instances of <span style="font-style: italic;">Desktop -</span>to -instances of <span style="font-style: italic;">http://www.example.org/vocabulary#DesktopUser -</span>defined in <span style="font-style: italic;">ex:g1 -</span>in the example above.<br /> - - - - -<br /> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;">[1] -<rdf:RDF</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -xmlns:nrl="http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#"></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -xmlns="http://www.domain.com/o2#"></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] -<nrl:Ontology rdf:about=""></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -<rdf:type rdfs:resource="nrl#DocumentGraph"/></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -<!--Other Graph Metadata---></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -</nrl:Ontology></span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] -<rdfs:Class rdf:ID="Desktop"/> </span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[4] -<rdf:Property rdf:ID="user"></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -<rdfs:domain rdf:resource="#Desktop"/></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -<rdfs:range -rdf:resource="http://www.example.org/vocabulary#DesktopUser/> </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -</rdf:Property></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - </rdf:RDF></span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -</div> - - - - -The following is the -RDF/S instance base -serialized as RDF/XML and accessible at <span style="font-style: italic;">http://www.anotherdomain.com/ib2.rdf</span>s:<br /> - - - - -<div style="margin-left: 40px;"> -<div style="text-align: justify;"><br /> - - - - -</div> - - - - -</div> - - - - -<div style="text-align: justify;">[1] Required namespaces -are defined.<br /> - - - - -<br /> - - - - -[2] Metadata about the instance base graph represented by this RDF/S -document is defined through the use of [<a href="#3.2.3._nrl:InstanceBase">nrl:InstanceBase</a>].<br /> - - - - -<span style="font-style: italic;"><span style="background-color: rgb(255, 255, 51);"></span></span><br /> - - - - -<span style="font-style: italic; background-color: rgb(255, 255, 255);"><span style="font-weight: bold;">Note:</span> Although this -is allowed it is -not considered best practice, since in this way, given that we state -that XML/RDFS files can only encode one graph at a time, one is -effectively providing graph metadata within the graph itself. This goes -against our notion of keeping metadata about a graph separate from the -graph itself, as discussed in [<a href="#3._NRL_Named_Graph_Extensions">Section 3</a>].</span><br style="background-color: rgb(255, 255, 51);" /> - - - - -<span style="font-style: italic;"></span><br /> - - - - -<span style="font-style: italic;"></span>[3] <span style="font-style: italic;">DesktopA </span>is -defined as an instance of <span style="font-style: italic;">o2:Desktop -</span>and related to <span style="font-style: italic;">http://www.example.org/vocabulary#User1 -</span>through the <span style="font-style: italic;">o2:user</span> -property. -<br /> - - - - -<br style="font-family: monospace;" /> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td><span style="font-family: monospace;">[1] -<rdf:RDF</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -xmlns:nrl="http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#"</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -xmlns:o2="http://www.domain.com/o2#"</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -xmlns="http://www.anotherdomain.com/ib2#"></span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] -<nrl:InstanceBase rdf:about=""></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -<rdf:type rdfs:resource="nrl#DocumentGraph"/></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -<!--Other Graph Metadata---></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - </nrl:InstanceBase></span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] -<o2:Desktop rdf:ID="DesktopA"></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> -<o2:user http://www.example.org/vocabulary#User1></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - </o2:Desktop></span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - </rdf:RDF></span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -</div> - - - - -<h2><a class="mozTocH2" name="mozTocId172834"></a><a name="4._Graph_Views_Extensions"></a>4. Imposing -Semantics on and Tailoring of Graphs: NRL Graph Views<span style="background-color: rgb(255, 255, 255);"> Extensions</span></h2> - - - - -<div style="text-align: justify;"> -<p>A simple named -graph consists only of the enumerated triples in the -triple set associated with the name, and it does not inherently carry -any form of semantics. However in many situations it is desirable to -work -with an extended or restricted interpretation of a -simple syntax-only named graph. -These interpretations can be realized by applying rules which -enhance named graphs with entailment triples, or return a -restricted form of the -complete triple set. To preserve the integrity of a named graph, -interpretations of a basic named graph should -never replace the original. To model this functionality in an intuitive -way, while still separating between an original named graph and any -number of its interpretations, we introduce the concept of <span style="font-style: italic;">Graph Views</span>.</p> - - - - -<p>Graph views, -or simply views, are different interpretations for a -particular named graph. Formally, a graph view is an executable -specification of an input graph into a corresponding output graph. -Informally, they can be seen as arbitrary wrappings for a -named graph. <a href="#Fig4">Figure 4</a> -depicts -graph view support in -NRL. As can be seen in the figure, views are themselves named graphs -(subclass of <a href="#3.1.1._nrl:Graph">nrl:Graph</a>). -Therefore it is possible to have a named graph that is itself a -different interpretation, or view, of another named graph. This -modelling can be applied recurrently, yielding a view of a view (or an -interpretation of a named graph interpretation, as depicted in <a href="#Fig2">Figure 2</a>) and so on.<br /> - - - - -</p> - - - - -</div> - - - - -<div style="text-align: justify;"> -<div style="text-align: center;"> -<div style="text-align: center;"><span style="font-style: italic;"><img style="width: 555px; height: 325px;" alt="Graph Views Overview" src="GraphViews.png" /><br /> - - - - -</span><a name="Fig4"></a> -Figure 4: -Graph Views in NRL<br /> - - - - -</div> - - - - -</div> - - - - -<p>Views are -defined through <span style="font-style: italic;">View -Specifications</span> which -can execute, via a set of rules in a rule language (e.g. a -SPARQL -query over a named graph), or via an external application (e.g. an -application that performs and returns the transitive closure of -rdfs:subClassOf), the<span style="font-style: italic;"> -View Realization</span> for a particular view. As in the latter -example, view realizations can also realize the implicit -semantics of a graph according to some language -or schema (e.g. RDFS, OWL, NRL etc.). We refer to such -a view as a <span style="font-style: italic;">Semantic -View </span>and in <a href="#Fig4">Figure -4</a> -these are represented by the intersection of [<a href="#4.1.1_nrl:GraphView">nrl:GraphView</a>] -and <span style="font-style: italic;">Graph Roles</span>. -Therefore a semantic view is an instance of graph view that also -carries a particular graph role. Semantic views are also depicted in <a href="#Fig1">Figure -1</a>, and one can quite easily draw a parallel between the two -figures. One must note that the property [<a href="#4.2.2._nrl:realizes">nrl:realizes</a>] -applies -only to semantic views, since only such views realize an explicit form -of semantics. One should also note that in -contrast to graph roles which have only <span style="font-style: italic;">Declarative -Semantics</span> defined through the [<a href="#3.2.11._nrl:hasSemantics">nrl:hasSemantics</a>] -property, -semantic views also carry <span style="font-style: italic;">Procedural -Semantics</span>, -since the semantics of these graphs are always realized and not -simply assumed. </p> - - - - -</div> - - - - -<h3><a class="mozTocH3" name="mozTocId238972"></a><a name="4.1._Views_Core_Vocabulary"></a>4.1. Views -Core Vocabulary</h3> - - - - -<div style="text-align: justify;"> -<p>This section presents -the core vocabulary supporting views in NRL, -consisting of the core attributes that apply to views. The -following section is specifically dedicated to vocabulary concerning -the -specification of views.</p> - - - - -</div> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId304281"></a><a name="4.1.1_nrl:GraphView"></a>4.1.1. -nrl:GraphView </h4> - - - - -<div style="text-align: justify;"> -<p>This class represents a -view over a named graph as introduced in this -document, and is itself modeled as a -subclass of a named graph. A view is realized through a view -specification, defined by an instance of [<a href="#4.2.1._nrl:ViewSpecification">nrl:ViewSpecification</a>]. -The view is linked its view specification through the [<a href="#4.1.3_nrl:hasSpecification">nrl:hasSpecification</a>] -property whereas the named graph that the view applies to is linked by [<a href="#4.1.2_nrl:viewOn">nrl:viewOn</a>]. -An instance of this class will be a realized view over -some named graph, and it will consist of the extended or restricted set -of RDF -triples present in the original named graph. -</p> - - - - -</div> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId595657"></a><a name="4.1.2_nrl:viewOn"></a>4.1.2. -nrl:viewOn</h4> - - - - -<div style="text-align: justify;"> -<p>This property attaches a -view realisation to the respective interpreted -named graph by linking -instances of [<a href="#4.1.1_nrl:GraphView">nrl:GraphView</a>] -to respective instances of [<a href="#3.1.1._nrl:Graph">nrl:Graph</a>]. -In this way, it is always possible to determine which graph a -view is interpreting. Thus both the theoritical and the -practical separation between different interpretations of a named graph -and the original named -graph itself can be retained. As a result, it is always possible to -retrieve an original named graph, independently of how many views have -been applied over it.</p> - - - - -</div> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId124884"></a><a name="4.1.3_nrl:hasSpecification"></a>4.1.3. -nrl:hasSpecification </h4> - - - - -<p>Views are realized according to a given view specification. -This -property determines the specification for a view by linking instances -of [<a href="#4.1.1_nrl:GraphView">nrl:GraphView</a>] -to instances of [<a href="#4.2.1._nrl:ViewSpecification">nrl:ViewSpecification</a>]. -View specifications are defined through instances of [<a href="#4.2.1._nrl:ViewSpecification">nrl:ViewSpecification</a>]. -This class, its subclasses, attributes and general characteristics are -introduced and defined in the following section. </p> - - - - -<h3 style="text-align: justify;"><a class="mozTocH3" name="mozTocId648959"></a><a name="4.2._View_Specification_Vocabulary"></a>4.2. -Views Specification Vocabulary</h3> - - - - -<div style="text-align: justify;"> -<p>This section presents -the vocabulary supporting graph view -specification. These specification are essentially the instructions to -how a view is to be -realized. -</p> - - - - -</div> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId925367"></a><a name="4.2.1._nrl:ViewSpecification"></a>4.2.1. -nrl:ViewSpecification</h4> - - - - -<div style="text-align: justify;">This class represents a -view specification. Every graph view requires -an associated view specification. View specifications can take one of -two forms, modeled as the two subclasses [<a href="#4.2.3._nrl:RuleViewSpecification">nrl:RuleViewSpecification</a>] -and [<a href="#4.2.6._nrl:ExternalViewSpecification">nrl:ExternalViewSpecification</a>]. -The view specification defines the criteria for the realization of the -view. In the case of semantic views, view specifications also -state which semantics are realized through the [<a href="#4.2.2._nrl:realizes">nrl:realizes</a>] -property. -</div> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId162918"></a><a name="4.2.2._nrl:realizes"></a>4.2.2. -nrl:realizes</h4> - - - - -<div style="text-align: justify;"> -<p>This property applies -only to subset of views introduced as semantic -views (see <a href="#4._Graph_Views_Extensions">Section -4</a> -introduction). It links a semantic view to the formal specifications of -the -semantics that it realizes. In effect this states that the view should -carry the realized, procedural semantics according to the given -semantics -definition, and not simply the implicit declarative -semantics. The overlap in <a href="#Fig4">Figure4</a> -and also in<a href="#Fig4"> </a><a href="#Fig1">Figure -1</a>) -between graph roles and views refers to these semantic views which -carry both procedural (through this property) and declarative -(through [<a href="#3.2.11._nrl:hasSemantics">nrl:hasSemantics</a>]) -semantics. This property should be distinguished from the [<a href="#3.2.11._nrl:hasSemantics">nrl:hasSemantics</a>] -property since this property has only a declarative role when it comes -to specifying the semantics for a graph.</p> - - - - -<span style="font-style: italic;"><span style="font-weight: bold;">Note:</span> </span>For NRL -to be -valid, all semantic views must carry both procedural and declarative -semantics. That is, any view (which can manifest itself also as a graph -role) that is linked to some semantics by [<a href="#4.2.2._nrl:realizes">nrl:realizes</a>], -should -also be linked to the same semantics by [<a href="#3.2.11._nrl:hasSemantics">nrl:hasSemantics</a>]. -This relationship between the two properties is not symmetric and it is -perfectly valid for a -graph role (that is not a view) to have only non-realized declarative -semantics. -</div> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId266518"></a><a name="4.2.3._nrl:RuleViewSpecification"></a>4.2.3. -nrl:RuleViewSpecification </h4> - - - - -<div style="text-align: justify;">This class represents -one of the provided forms of view -specifications. Views can be specified by referring to a rule language -and a corresponding set of required rules within. The view is -subsequently realized by executing those rules, generating the -required output named graph. -The rule language and the selected rules are specified through the [<a href="#4.2.4._nrl:ruleLanguage">nrl:ruleLanguage</a>] -and [<a href="#4.2.5._nrl:rule">nrl:rule</a>] -properties, presented below.<br /> - - - - -</div> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId718088"></a><a name="4.2.4._nrl:ruleLanguage"></a>4.2.4. -nrl:ruleLanguage</h4> - - - - -<p style="text-align: justify;">This property links a rule -view specification to the name of -the rule language supporting the required rules. The -rule language is -identified via a string referring to the language name.<br /> - - - - -</p> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId518283"></a><a name="4.2.5._nrl:rule"></a>4.2.5. -nrl:rule</h4> - - - - -<p style="text-align: justify;">This property is used to -provide the actual rules -for a rule view -specification, with respect to the selected rule language. -The rules (or queries) are provided as a string.</p> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId968780"></a><a name="4.2.6._nrl:ExternalViewSpecification"></a>4.2.6. -nrl:ExternalViewSpecification </h4> - - - - -<div style="text-align: justify;"> -<p>The second type of view -specification supported by NRL refers -to an external application, service or program -(external realizer) that automatically executes and returns the -required view without the need to select any rule or -language. The word -'external' refers to the fact that the actual view -specification is not given by instances of this class, but is -predefined within the external application. External view -specifications need only -specify the location of the external realizer through the -following property.</p> - - - - -</div> - - - - -<h4 style="text-align: justify;"><a class="mozTocH4" name="mozTocId745751"></a><a name="4.2.7._nrl:externalRealizer"></a>4.2.7. -nrl:externalRealizer</h4> - - - - -<div style="text-align: justify;"> -<p>External view -specifications rely on external realizers to realize a -particular view. An identifier for the external application, service or -program is assigned to the view specification through this property in -the form of -a string.</p> - - - - -</div> - - - - -<h3 style="text-align: justify;"><a class="mozTocH3" name="mozTocId227803"></a><a name="4.3_Graph_Views_Example"></a>4.3 -Graph Views Example</h3> - - - - -<div style="text-align: justify;"> -<p>The following example is -a continuation to that given in [<a href="#3.3._Named_Graph_Example">Section -.3</a>] and -it completes the dataflow diagram presented in the introduction [<a href="#Fig2">Figure 2</a>]. It -demonstrates how the -provided syntax supporting graph views can be used effectively. The -practical applicability of the introduced views is explained in more -detail in the introduction of the document and [<a href="#Fig2">Figure -2</a>].<br /> - - - - -</p> - - - - -[1] <span style="font-style: italic;">ex:kb2_metadata </span>states -that a new graph with the role of knowledge base, <span style="font-style: italic;">ex:kb2</span>, -is a graph view over graph<span style="font-style: italic;"> -ex:kb1 </span>defined in the example earlier<span style="font-style: italic;"> </span>according to a -view specification <span style="font-style: italic;">ex:rvs</span>. <br /> - - - - -<br /> - - - - -[2] <span style="font-style: italic;">ex:rvs</span> -is the view specification required to realize <span style="font-style: italic;">ex:kb2</span>. It is a -rule view specification, and it requires executing two rules -from the SPARQL language over the graph that <span style="font-style: italic;">ex:kb2</span> is -interpreting, namely <span style="font-style: italic;">ex:kb1</span>. The -view is defined as a semantic realizing view, which semantics -are given by <span style="font-style: italic;">ex:RDFSSemantics</span>.<br /> - - - - -<br /> - - - - -[3] <span style="font-style: italic;">ex:RDFSemantics </span>refers -to a document where the formal specification of the procedural -semantics realized by the view are given. These semantics are -identified by a label, <span style="font-style: italic;">RDFS</span>.<br /> - - - - -<br /> - - - - -[4] <span style="font-style: italic;">ex:kb3_metadata</span> -states that the graph <span style="font-style: italic;">ex:kb3 -</span>having role [<a href="#3.2.5._nrl:KnowledgeBase">nrl:KnowledgeBase</a>]<span style="font-style: italic;"> -</span>is a graph view over <span style="font-style: italic;">ex:kb2 </span>according -to a view specification <span style="font-style: italic;">ex:evs</span>. <br /> - - - - -<br /> - - - - -[5] The view specification for <span style="font-style: italic;">ex:kb3</span> -is defined to consist of an external view specification. This in -practice means that no specification is given in the graph definition, -but the virtual specification is assumed to be within the external -application or service that realizes the view. In this case, <span style="font-style: italic;">GraphTaxonomyExtractor </span>will -return the required realized view as the graph <span style="font-style: italic;">ex:kb3</span>.<br /> - - - - -<br /> - - - - -<table style="text-align: left; width: 100%;" border="1" cellpadding="2" cellspacing="2"> - - - - - <tbody> - - - - - <tr> - - - - - <td> <span style="font-family: monospace;"> @prefix nrl: -<http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> -.</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - @prefix ex: -<http://www.example.org/vocabulary#> .</span><br style="font-family: monospace;" /> - - - - - <br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[1] -ex:kb2_metadata { </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:kb2 rdf:type nrl:KnowledgeBase , </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - nrl:GraphView ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - nrl:viewOn ex:kb1 -;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - nrl:hasSpecification ex:rvs . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[2] ex:rvs -rdf:type nrl:RuleViewSpecification ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - nrl:realizes -ex:RDFSSemantics ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - nrl:ruleLanguage "SPARQL" ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - nrl:rule "CONSTRUCT {?s -?rdfs:subClassOf ?v} WHERE ..." ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - nrl:rule -"CONSTRUCT {?s ?rdf:type ?v} WHERE ..." . </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[3] -ex:RDFSSemantics rdf:type nrl:Semantics ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - nrl:semanticsDefinedBy -"http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - nrl:semanticsLabel "RDFS" . }</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[4] -ex:kb3_metadata {</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - ex:kb3 rdf:type nrl:GraphView ,</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - nrl:KnowledgeBase ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - - nrl:viewOn ex:kb2 ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - nrl:hasSpecification ex:evs -. </span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;">[5] ex:evs -rdf:type nrl:ExternalViewSpecification ;</span><br style="font-family: monospace;" /> - - - - - <span style="font-family: monospace;"> - nrl:externalRealizer -"GraphTaxonomyExtractor" . } </span></td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<br /> - - - - -</div> - - - - -<h2><a class="mozTocH2" name="mozTocId943672"></a><a name="5._Deprecated_Elements"></a>5. -Deprecated Elements</h2> - - - - -<p style="text-align: justify;"> In general -there are three criteria for -excluding -elements from NRL:</p> - - - - -<ol> - - - - - <li>Elements with no clear formal semantics.</li> - - - - - <li>Elements whose complexity cannot be handled.</li> - - - - - <li>Elements that are <span style="font-style: italic;">NEPOMUK -project</span>-specific.</li> - - - - - <li>Elements that do not belong to the Representation -Language -layer but rather to lower ontology levels.</li> - - - - - <li>Elements that have become redundant after introduction of -the NRL concepts.</li> - - - - -</ol> - - - - -<p style="text-align: justify;">The following is a list -of elements which have been -excluded -from NRL. Some of these elements might be moved to other NEPOMUK -ontologies, or removed completely. Given in the table are the -reasons why they have been excluded from this ontology, alongside the -resulting actions taken.</p> - - - - -<table style="width: 100%; height: 3496px;" id="table44" border="1"> - - - - - <tbody> - - - - - <tr> - - - - - <td style="text-align: justify;" width="20%">nrl:Thing</td> - - - - - <td style="text-align: justify;" width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">The superclass of all conceptual -classes. See also [<a href="http://www.w3.org/TR/swbp-skos-core-spec/">SKOS -Concept</a>] -and [<a href="http://www.w3.org/TR/owl-guide/">OWL Thing</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">rdfs:Resource satisfies the -requirements for a top Resource representation.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Exclude.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:ResourceManifestation</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">The superclass of all files or -web -resources. See also [<a href="http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s2.2.1">RDFS -Resource</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Distinction between abstract -resource and information resource not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to upper-level -(foundational) -ontology.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:Association</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">The superclass of n-ary -relations. -See also [<a href="http://www.topicmaps.org/xtm/#desc-association">Topic -Maps Association</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to upper-level -(foundational) -ontology.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:AssociationRole</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">The superclass of relations for -N-ary associations. See also [<a href="http://www.topicmaps.org/xtm/#desc-association">Topic -Maps Association</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to upper-level -(foundational) -ontology.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:NRLClass</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">The NRL's own class to enable -specific extensions.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">No specific restrictions in this -ontology requiring an extra class representation.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to -upper-level(foundational) -ontology if required.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:NRLProperty</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">The NRL's own property to enable -specific extensions.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">No specific restrictions in this -ontology requiring an extra property representation.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to -upper-level(foundational) -ontology if required.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:DescribingProperty</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">This class defines a class -instance -to be descriptive rather than relational. Descriptive properties cannot -have an inverse. See also [<a href="http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DefiningProperties">OWL -DatatypeProperty</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Distinction between descriptive -and -relational properties not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to upper-level -(foundational) -ontology.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:RelatingProperty</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" style="width: 20%;"> </td> - - - - - <td widdth="78%">This class defines a class -instance -to be relational rather than descriptive. Only relational properties -can have an inverse. See also [<a href="http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DefiningProperties">OWL -ObjectProperty</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Distinction between descriptive -and -relational properties not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to upper-level -(foundational) -ontology.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:hasNamespace</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">Specifies the standard namespace -for -an ontology with particular attention to the hash or slash problem.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to Ontology Metadata Layer -provided semantics are clear.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:hasNamespaceAbbreviation</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">Provides a means to specify the -standard abbreviation for an ontology's namespace.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to Ontology Metadata Layer -provided semantics are clear.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:isDefinedBy</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">A standard for stating which -ontology defines a ontology element, to enable more efficient queries.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to Ontology Metadata Layer -provided semantics are clear.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:directType</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">Specifies that a type is a -direct -type and not a type resulting from transitivity.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required since the -introduction of Graph Views.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Unclear</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:directSubClass</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">Specifies a direct subclass of -some -class and not a subclass resulting from transitivity.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required since the -introduction of Graph Views.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Unclear</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:directSubProperty</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">Specifies a direct subproperty -of -some property and not a subproperty resulting from transitivity.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required since the -introduction of Graph Views.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Unclear</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:altLabel</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">The alternative labels for a -resource. A thesauri requirement in conjunction with [<a href="http://www.w3.org/TR/rdf-schema/#ch_label">rdfs:label</a>]. -See also [<a href="http://www.w3.org/TR/swbp-skos-core-spec/">skos:altLabel</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">This is an annotation property.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to annotation ontology.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:defaultValues</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">The default value/s for a -property -assigned to instances of a class. Comparable to -Protégé's defaultValues slot attribute.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to general view ontology.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:hasPart</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">This defines a resource as -having -a -subset resource. </td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">No clear formal semantics.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Exclude.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:partOf</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">This defines a resource as being -a -subset of another. </td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">No clear formal semantics.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Exclude.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:hasTopic</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">This states the topic of a -resource. -See also [<a href="http://www.w3.org/TR/swbp-skos-core-spec/">SKOS -isSubejctOf</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to annotation ontology.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:isTopicOf</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">This states the resource -attributed -to a topic. See also [<a href="http://www.w3.org/TR/swbp-skos-core-spec/">SKOS -isSubjectOf</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Not required at this level.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Move to annotation ontology.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:occurrence</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" width="20%"> </td> - - - - - <td width="78%">This points to an instance of a -specific resource. See also [<a href="http://www.topicmaps.org/xtm/#desc-occurrence">Topic -Maps Occurences</a>] and [<a href="http://www.w3.org/TR/swbp-skos-core-spec/">SKOS -hasSubject</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">No formal semantics.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">Exclude.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="20%">nrl:isOccurenceOf</td> - - - - - <td width="78%"><i>Description</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td rowspan="5" style="width: 20%;"> </td> - - - - - <td width="78%">This points to a resource -classifying this and other similar instances. See also [<a href="http://www.topicmaps.org/xtm/#desc-occurrence">Topic -Maps Occurences</a>] and [<a href="http://www.w3.org/TR/swbp-skos-core-spec/">SKOS -hasSubject</a>]</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Reason</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%">No formal semantics.</td> - - - - - </tr> - - - - - <tr> - - - - - <td width="78%"><i>Action</i></td> - - - - - </tr> - - - - - <tr> - - - - - <td style="width: 100%;">Exclude.</td> - - - - - </tr> - - - - - - - - </tbody> -</table> - - - - -<h2><a class="mozTocH2" name="mozTocId225357"></a><a name="6._NRL_Semantics"></a>6. NRL -Semantics</h2> - - - - -<span style="font-style: italic;"><span style="font-weight: bold;">Note:</span> -The -Semantics of NRL will be formally specified at a later version of the -language.</span> -<dl> - - - - -</dl> - - - - -</div> - - - - -</div> - - - - -</div> - - - - -</div> - - - - -<div> -<h2><a class="mozTocH2" name="mozTocId501171"></a><a name="References"></a>References<br /> - - - - -</h2> - - - - -</div> - - - - -<span style="font-weight: bold;">[NAMED GRAPHS]</span> -<dl> - - - - - <dd><span style="font-weight: normal;"><a href="http://www2005.org/cdrom/docs/p613.pdf">Named Graphs, -Provenance and Trust</a>, </span><span style="font-weight: normal;">J. J. Carroll, C. Bizer, P. -Hayes and P. Stickler, Proceedings of WWW2005, May 2005, -Japan. </span></dd> - - - - - <dd><small><a style="font-family: Courier New,Courier,monospace;" href="http://www.w3.org/DesignIssues/Notation3">http://www.w3.org/2004/03/trix/</a></small><small><span style="font-family: Courier New;">.</span></small><span style="font-weight: bold;"></span><br /> - - - - - </dd> - - - - -</dl> - - - - -<div> -<dl> - - - - - <dt><span style="font-weight: bold;">[NOTATION3]</span></dt> - - - - - <dd><span style="font-weight: normal;"><a href="http://www.w3.org/DesignIssues/Notation3">A readable -language for data on the Web</a>. Tim Berners-Lee, Editor.</span></dd> - - - - - <dd><small><a style="font-family: Courier New,Courier,monospace;" href="http://www.w3.org/DesignIssues/Notation3">http://www.w3.org/DesignIssues/Notation3</a><span style="font-family: Courier New;"></span></small><small><span style="font-family: Courier New;">.</span></small><span style="font-weight: bold;"></span></dd> - - - - -</dl> - - - - -<dl> - - - - - <dt>[N-TRIPLES]<br /> - - - - - </dt> - - - - - <dd><cite></cite><a href="http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/">N-Triples</a> -section in [<a href="#References">RDF -Specification - Tests</a>] </dd> - - - - -</dl> - - - - -<span style="font-weight: bold;">[OMV Report] -<br /> - - - - -</span> -<div style="margin-left: 40px;"><a href="http://ontoware.org/projects/omv/">Ontology Metadata -Vocabulary for the Semantic. Web</a>. Jens Hartmann (University -of Karlsruhe), Raul Palma (Universidad Politecnica de Madrid) and Elena -Paslaru Bontas (Free University of Berlin).<br /> - - - - -</div> - - - - -<div style="margin-left: 40px;"><small style="font-family: monospace;"><a href="http://ontoware.org/projects/omv/">http://ontoware.org/projects/omv/</a>.<br /> - - - - -<br /> - - - - -</small> -</div> - - - - -<span style="font-weight: bold;"> -[OWL -Overview] </span> -<div style="margin-left: 40px;"><cite></cite><a href="http://www.w3.org/TR/owl-features/">OWL -Web Ontology -Language Overview</a>.<cite> </cite>Deborah L. -McGuinness and Frank -van Harmelen, Editors, W3C Recommendation, 10 February 2004, <br /> - - - - -<small><span style="font-family: Courier New;"><a href="http://www.w3.org/TR/owl-features/">http://www.w3.org/TR/owl-features/</a>.</span></small><span style="font-weight: bold;"></span><br /> - - - - -</div> - - - - -<dl> - - - - - <dt>[RDF]</dt> - - - - - <dd><a href="http://www.w3.org/RDF/">Resource -Description Framework</a></dd> - - - - - <dt></dt> - - - - - <dt>[RDF Specification - PRIMER]</dt> - - - - - <dd><a href="http://www.w3.org/TR/rdf-primer/">RDF -Primer</a>, Frank Manola and Eric Miller, Editors, W3C -Recommendation, 10 February 2004, <font face="Courier New"> - <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/"><font size="2">http://www.w3.org/TR/2004/REC-rdf-primer-20040210/</font></a><font size="2">.</font></font></dd> - - - - - <dt></dt> - - - - - <dt>[RDF Specification - SYNTAX]</dt> - - - - - <dd><a href="http://www.w3.org/TR/rdf-syntax-grammar/">RDF/XML -Syntax Specification</a>, Dave Beckett, Editor, W3C -Recommendation, 10 February 2004, <font face="Courier New" size="2"> <a href="http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/"> -http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/</a>.</font></dd> - - - - - <dt></dt> - - - - - <dt>[RDF Specification - CONCEPTS]</dt> - - - - - <dd><a href="http://www.w3.org/TR/rdf-concepts/">Resource -Description Framework (RDF): Concepts and Abstract Syntax</a>, -Graham Klyne and Jeremy J. Carroll, Editors, W3C Recommendation, 10 -February 2004, </dd> - - - - - <dd><font face="Courier New" size="2"><a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/">http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/</a>.</font></dd> - - - - - <dt></dt> - - - - - <dt>[RDF Specification - SEMANTICS]</dt> - - - - - <dd><a href="http://www.w3.org/TR/rdf-mt/">RDF -Semantics</a>, Patrick Hayes, Editor, W3C Recommendation, 10 -February 2004, <font face="Courier New" size="2"> <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/"> -http://www.w3.org/TR/2004/REC-rdf-mt-20040210/</a>.</font></dd> - - - - - <dt></dt> - - - - - <dt>[RDF Specification - MS]</dt> - - - - - <dd><a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">Resource -Description Framework (RDF) Model and Syntax</a>, W3C -Recommendation, 22 February 1999<br /> - - - - - <font face="Courier New" size="2"> <a href="http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/">http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/</a>.</font></dd> - - - - - <dt></dt> - - - - - <dt>[RDF Specification - TESTS]</dt> - - - - - <dd><a href="http://www.w3.org/TR/rdf-testcases/">RDF -Test Cases</a>, Jan Grant and Dave Beckett, Editors, W3C -Recommendation, 10 February 2004, <font face="Courier New" size="2"> <a href="http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/"> -http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/</a>.</font></dd> - - - - -</dl> - - - - -<dl> - - - - - <dt>[RDFS Specification]</dt> - - - - - <dd><a href="http://www.w3.org/TR/rdf-schema/">RDF -Vocabulary Description Language 1.0: RDF Schema</a>, Dan -Brickley, R.V. Guga, Brian McBride, W3C Recommendation, 10 February -2004, </dd> - - - - - <dd><font face="Courier New"><a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/"><font size="2">http://www.w3.org/TR/2004/REC-rdf-primer-20040210/</font></a><font size="2">.</font></font></dd> - - - - -</dl> - - - - -<span style="font-weight: bold;">[SPARQL-QUERY]</span><cite><br /> - - - - -</cite> -<div style="margin-left: 40px;"><cite style="font-style: italic;"></cite><span style="font-style: italic;"></span><a href="http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/">SPARQL -Query Language for RDF</a>, -E. Prud'hommeaux, A. Seaborne, Editors. World Wide Web Consortium. 23 -November 2005. Work in progress. This version is -http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/. </div> - - - - -<div style="margin-left: 40px;"><small style="font-family: Courier New,Courier,monospace;"><a href="http://www.w3.org/TR/rdf-sparql-query/">http://www.w3.org/TR/rdf-sparql-query/</a></small><small><span style="font-family: Courier New;">.</span></small><br /> - - - - -</div> - - - - -<small style="font-weight: bold;"><span style="font-family: Courier New;"></span></small><br /> - - - - -<span style="font-weight: bold;">[TRIG]<br /> - - - - -</span> -<div style="margin-left: 40px;"><span style="font-weight: bold;"></span><small><span style="font-family: Courier New;"></span></small><a style="font-weight: normal;" href="http://www.wiwiss.fu-berlin.de/suhl/bizer/TriG/">TriG -Syntax</a><span style="font-weight: normal;">, Chris -Bizer, Freie Universität Berlin extends Turtle to serialise [<a href="#References">NAMED GRAPHS</a>] <br /> - - - - -</span><small><a style="font-family: monospace;" href="http://sites.wiwiss.fu-berlin.de/suhl/bizer/TriG/">http://sites.wiwiss.fu-berlin.de/suhl/bizer/TriG/</a></small><small><span style="font-family: Courier New;">.</span></small></div> - - - - -<span style="font-weight: bold;"></span><span style="font-weight: bold;"></span><span style="font-weight: bold;"></span><small><span style="font-family: Courier New;"></span></small><span style="font-weight: bold;"></span> -<dl> - - - - - <dt><span style="font-weight: bold;">[TURTLE]</span></dt> - - - - - <dd><a href="http://www.dajobe.org/2004/01/turtle/">Terse -- RDF Triple language</a>. Dave Beckett, Editor. 04 December 2004.</dd> - - - - - <dd><small><a style="font-family: monospace;" href="http://www.dajobe.org/2004/01/turtle/">http://www.dajobe.org/2004/01/turtle/</a></small><small><span style="font-family: Courier New;">.</span></small></dd> - - - - - <dt></dt> - - - - -</dl> - - - - -<hr style="width: 100%; height: 2px;" /><span style="font-family: Courier New;"></span> -<dl> - - - - - <dd> - - - - <dl> - - - - - - - - </dl> - - - - - </dd> - - - - -</dl> - - - - -</div> diff --git a/nso/doc/nso-header.html b/nso/doc/nso-header.html deleted file mode 100644 index 08b342b..0000000 --- a/nso/doc/nso-header.html +++ /dev/null @@ -1,100 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
- <title>Nepomuk Sharing Ontology (NSO)</title>
-
-</head>
-<body>
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org">
- <img class="nepomuklogo" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
-
-<h1>Nepomuk Sharing Ontology (NSO)</h1>
-
-<h2>OSCAF Recommendation 8.11.2009</h2>
-
-<dl>
- <dt>Latest Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/nso">http://www.semanticdesktop.org/ontologies/nso</a>
- </dd>
-
- <dt>This Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2009/11/08/nso">http://www.semanticdesktop.org/ontologies/2009/11/08/nso</a>
- <br/>This file refers to the Revision 1 of NSO. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.</dd>
-
- <!--dt>Previous Version:</dt>
- <dd><a href="http://www.semanticdesktop.org/ontologies/2009/11/08/nso">http://www.semanticdesktop.org/ontologies/2009/11/08/nso</a-->
-
- <dt>Authors:</dt>
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
- <dd>Iridian Kiiskinen <a href="mailto:ext-iridian.kiiskinen@nokia.com">ext-iridian.kiiskinen@nokia.com</a></dd>
-
- <dt>Contributors:</dt>
- <dd>Sebastian Trüg, <a href="mailto:trueg@kde.org">trueg@kde.org</a></dd>
- <dd>Attendees of the <a href="http://techbase.kde.org/Projects/Nepomuk/OpenSocialSemanticDesktopWorkshop2009">OpenSocialSemanticDesktopWorkshop2009</a></dd>
-
- <dt id="ontology">Ontology:</dt>
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2009/11/08/nso/nso_data.rdfs">NSO (Data Graph Only)</a></dd>
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2009/11/08/nso/nso_metadata.rdfs">NSO (Metadata Graph Only)</a></dd>
- <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2009/11/08/nso/nso.trig">NSO (Graph Set)</a></dd>
-</dl>
-
-</div>
-
-<hr />
-<p class="copyright"> Copyright © 2009 the authors<sup>®</sup>
-The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
-</p>
-<hr />
-
-<h2 id="abstract">Abstract</h2>
-<p>
- The Nepomuk Sharing Ontology is used to express that information elements or pimo things are shared with contacts.
- Sharing is possible both for groups and for individual contacts.
- The ontology is intended to by used on a user's computer to indicate which local resources have been shared with whom.
- Services should interpret the ontology to push changes of shared things to the contacts.
-</p>
-
-<h2 id="status">Status of this document</h2>
-<p>
- This section describes the status of this document at the time of its publication.
- The form used for this status message and document is inspired by the W3C process.
-</p>
-<p>
- This document describes an <a href="http://www.oscaf.org">OSCAF ontology recommendation</a> describing the Nepomuk Sharing Ontology (NSO).
- It was created at the <a href="http://techbase.kde.org/Projects/Nepomuk/OpenSocialSemanticDesktopWorkshop2009">OpenSocialSemanticDesktopWorkshop2009</a> and is now maintained by OSCAF members.
- The listed editor is responsible to bring in feedback from the other authors, contributors,
- and the community at large.
- Other documents may supersede this document.
-</p>
-<p>
- This recommendation is <a href="#ontology">accompanied by a RDFS/NRL ontology</a>, which is the authorative formal
- description of the ontology.</b>
-</p>
-<h2 id="example">Example</h2>
-<p>
- If a local file should be shared with a contact, it can be done like the following
-</p>
-<pre>
-# N3 example
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
-@prefix nso: <http://www.semanticdesktop.org/ontologies/2009/11/08/nso#> .
-@prefix nfo: <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#> .
-@prefix nco: <http://www.semanticdesktop.org/ontologies/2007/03/22/nco#> .
-
-<file:///home/blah.odp> a nfo:Presentation.
-<nepomuk://res/23234> a nco:Contact.
-<nepomuk://res/46252> a nco:Contact.
-<nepomuk://res/55555> a nco:ContactGroup.
-<file:///home/blah.odp> nso:sharedWithContact <nepomuk://res/23234>.
-<file:///home/blah.odp> nso:sharedWithContact <nepomuk://res/46252>.
-<file:///home/blah.odp> nso:sharedWithGroup <nepomuk://res/55555>.
-</pre>
\ No newline at end of file diff --git a/pimo/doc/handbook_latex/brainstorm/skizze_grafik_uebersicht.pdf b/pimo/doc/handbook_latex/brainstorm/skizze_grafik_uebersicht.pdf Binary files differdeleted file mode 100644 index d976899..0000000 --- a/pimo/doc/handbook_latex/brainstorm/skizze_grafik_uebersicht.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/ignoredpimo.tcpDeutsch.sc b/pimo/doc/handbook_latex/ignoredpimo.tcpDeutsch.sc deleted file mode 100644 index 875cbfa..0000000 --- a/pimo/doc/handbook_latex/ignoredpimo.tcpDeutsch.sc +++ /dev/null @@ -1,51 +0,0 @@ -50
-DirkHagemann
-oller
-classofthing
-hasOtherRepresentation
-imap
-png
-hyperref
-url
-personalIdentifier
-longtable
-otherRepresentation
-PersonContact
-dev
-EmailAddress
-emailAddress
-describingthings
-metadata
-soton
-xspace
-uk
-vcf
-jpg
-nepomuk
-integratingfacts
-htb
-lat
-wikipedia
-pimoUpperClasses
-ecs
-integratingontologies
-prefLabel
-nameFamily
-nameGiven
-DBPedia
-dbpedia
-modeled
-ac
-sameAs
-wiki
-referencingOccurrence
-geo
-Hagemann
-downloadingpimo
-nao
-nmo
-URIs
-groundingOccurrence
-pimo
-pimoVSnie
-adaption
diff --git a/pimo/doc/handbook_latex/images/Bubbles.eps b/pimo/doc/handbook_latex/images/Bubbles.eps Binary files differdeleted file mode 100644 index d43df78..0000000 --- a/pimo/doc/handbook_latex/images/Bubbles.eps +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/Bubbles.pdf b/pimo/doc/handbook_latex/images/Bubbles.pdf Binary files differdeleted file mode 100644 index 95dbbaa..0000000 --- a/pimo/doc/handbook_latex/images/Bubbles.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/InformationSocietyTechnologies.eps b/pimo/doc/handbook_latex/images/InformationSocietyTechnologies.eps Binary files differdeleted file mode 100644 index b3b8d31..0000000 --- a/pimo/doc/handbook_latex/images/InformationSocietyTechnologies.eps +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/InformationSocietyTechnologies.pdf b/pimo/doc/handbook_latex/images/InformationSocietyTechnologies.pdf Binary files differdeleted file mode 100644 index 67524a6..0000000 --- a/pimo/doc/handbook_latex/images/InformationSocietyTechnologies.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/Nepomuk.eps b/pimo/doc/handbook_latex/images/Nepomuk.eps Binary files differdeleted file mode 100644 index 6ddd61b..0000000 --- a/pimo/doc/handbook_latex/images/Nepomuk.eps +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/Nepomuk.pdf b/pimo/doc/handbook_latex/images/Nepomuk.pdf Binary files differdeleted file mode 100644 index ed3743e..0000000 --- a/pimo/doc/handbook_latex/images/Nepomuk.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/PIMOextensionExample-Teaching.graffle b/pimo/doc/handbook_latex/images/PIMOextensionExample-Teaching.graffle deleted file mode 100644 index b753d7b..0000000 --- a/pimo/doc/handbook_latex/images/PIMOextensionExample-Teaching.graffle +++ /dev/null @@ -1,1703 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> -<plist version="1.0"> -<dict> - <key>ActiveLayerIndex</key> - <integer>0</integer> - <key>ApplicationVersion</key> - <array> - <string>com.omnigroup.OmniGrafflePro</string> - <string>129.18</string> - </array> - <key>AutoAdjust</key> - <false/> - <key>CanvasColor</key> - <dict> - <key>w</key> - <string>1</string> - </dict> - <key>CanvasOrigin</key> - <string>{0, 0}</string> - <key>CanvasScale</key> - <real>1</real> - <key>ColumnAlign</key> - <integer>1</integer> - <key>ColumnSpacing</key> - <real>36</real> - <key>CreationDate</key> - <string>2007-10-08 00:41:55 +0200</string> - <key>Creator</key> - <string>Knud MÜller</string> - <key>DisplayScale</key> - <string>1 cm = 1 cm</string> - <key>FileType</key> - <string>flat</string> - <key>GraphDocumentVersion</key> - <integer>5</integer> - <key>GraphicsList</key> - <array> - <dict> - <key>Bounds</key> - <string>{{77.125, 348.87}, {71, 14}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FitText</key> - <string>YES</string> - <key>Flow</key> - <string>Resize</string> - <key>ID</key> - <integer>45</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - <key>shadow</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - <key>stroke</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 subclass of}</string> - </dict> - <key>Wrap</key> - <string>NO</string> - </dict> - <dict> - <key>Bounds</key> - <string>{{78.125, 399.935}, {69, 14}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FitText</key> - <string>YES</string> - <key>Flow</key> - <string>Resize</string> - <key>ID</key> - <integer>44</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - <key>shadow</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - <key>stroke</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 instance of}</string> - </dict> - <key>Wrap</key> - <string>NO</string> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>ID</key> - <integer>43</integer> - <key>Points</key> - <array> - <string>{94.5046, 341.636}</string> - <string>{130.745, 341.636}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>ID</key> - <integer>42</integer> - <key>Points</key> - <array> - <string>{94.5046, 393.935}</string> - <string>{130.745, 393.935}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>Pattern</key> - <integer>1</integer> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>36</integer> - </dict> - <key>ID</key> - <integer>41</integer> - <key>Points</key> - <array> - <string>{179.308, 223.462}</string> - <string>{159.152, 183.447}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>Pattern</key> - <integer>1</integer> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>39</integer> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>36</integer> - </dict> - <key>ID</key> - <integer>40</integer> - <key>Points</key> - <array> - <string>{107.388, 224.114}</string> - <string>{131.487, 183.43}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>Pattern</key> - <integer>1</integer> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>38</integer> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{156, 222}, {73.7008, 56.6929}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>39</integer> - <key>Shape</key> - <string>Circle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -teaching:\ -GradeB}</string> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{55, 222}, {73.7008, 56.6929}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>38</integer> - <key>Shape</key> - <string>Circle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -teaching:\ -GradeA}</string> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>15</integer> - </dict> - <key>ID</key> - <integer>37</integer> - <key>Points</key> - <array> - <string>{182.338, 145.542}</string> - <string>{392.528, 71.4581}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>36</integer> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{111, 133.394}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>36</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -teaching:\ -Grade}</string> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{440.808, 187.66}, {99, 26}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FitText</key> - <string>YES</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica-Oblique</string> - <key>Size</key> - <real>11</real> - </dict> - <key>ID</key> - <integer>35</integer> - <key>Line</key> - <dict> - <key>ID</key> - <integer>34</integer> - <key>Position</key> - <real>0.50283467769622803</real> - <key>RotationType</key> - <integer>4</integer> - </dict> - <key>Rotation</key> - <real>270</real> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>shadow</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - <key>stroke</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\i\fs22 \cf0 teaching:\ -courseMaterialFor}</string> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>22</integer> - </dict> - <key>ID</key> - <integer>34</integer> - <key>Points</key> - <array> - <string>{451.569, 221.632}</string> - <string>{469, 202.667}</string> - <string>{513, 203.333}</string> - <string>{527.9, 221.612}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>Diamond</string> - <key>LineType</key> - <integer>1</integer> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>21</integer> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{415.628, 393.935}, {82, 26}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FitText</key> - <string>YES</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica-Oblique</string> - <key>Size</key> - <real>11</real> - </dict> - <key>ID</key> - <integer>33</integer> - <key>Line</key> - <dict> - <key>ID</key> - <integer>32</integer> - <key>Position</key> - <real>0.54689019918441772</real> - <key>RotationType</key> - <integer>0</integer> - </dict> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>shadow</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - <key>stroke</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\i\fs22 \cf0 teaching:\ -attendsCourse}</string> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>22</integer> - </dict> - <key>ID</key> - <integer>32</integer> - <key>Points</key> - <array> - <string>{270.305, 361.646}</string> - <string>{361.667, 411.333}</string> - <string>{447.667, 410}</string> - <string>{507, 366.94}</string> - <string>{539.716, 272.079}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>Diamond</string> - <key>LineType</key> - <integer>1</integer> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>25</integer> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{426.799, 297.883}, {84, 26}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FitText</key> - <string>YES</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica-Oblique</string> - <key>Size</key> - <real>11</real> - </dict> - <key>ID</key> - <integer>31</integer> - <key>Line</key> - <dict> - <key>ID</key> - <integer>30</integer> - <key>Position</key> - <real>0.58694392442703247</real> - <key>RotationType</key> - <integer>0</integer> - </dict> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>shadow</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - <key>stroke</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\i\fs22 \cf0 teaching:\ -teachesCourse}</string> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>22</integer> - </dict> - <key>ID</key> - <integer>30</integer> - <key>Points</key> - <array> - <string>{382.352, 333.326}</string> - <string>{463.866, 313.333}</string> - <string>{516.512, 271.915}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>Diamond</string> - <key>LineType</key> - <integer>1</integer> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>24</integer> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{312.914, 99.3334}, {231.038, 22}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>Flow</key> - <string>Overflow</string> - <key>ID</key> - <integer>9</integer> - <key>Line</key> - <dict> - <key>ID</key> - <integer>17</integer> - <key>Position</key> - <real>0.46242323517799377</real> - <key>RotationType</key> - <integer>0</integer> - </dict> - <key>Shape</key> - <string>Cloud</string> - <key>Style</key> - <dict> - <key>shadow</key> - <dict> - <key>Draws</key> - <string>NO</string> - </dict> - <key>stroke</key> - <dict> - <key>Pattern</key> - <integer>2</integer> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\i\fs18 \cf0 (Relation simplified)}</string> - </dict> - <key>Wrap</key> - <string>YES</string> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>13</integer> - </dict> - <key>ID</key> - <integer>29</integer> - <key>Points</key> - <array> - <string>{651.766, 316.833}</string> - <string>{651.766, 272.106}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>20</integer> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>12</integer> - </dict> - <key>ID</key> - <integer>28</integer> - <key>Points</key> - <array> - <string>{428.433, 221.5}</string> - <string>{428.433, 183.5}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>21</integer> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>10</integer> - </dict> - <key>ID</key> - <integer>27</integer> - <key>Points</key> - <array> - <string>{338.475, 316.856}</string> - <string>{296.487, 183.477}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>24</integer> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>10</integer> - </dict> - <key>ID</key> - <integer>26</integer> - <key>Points</key> - <array> - <string>{241.869, 316.853}</string> - <string>{281.093, 183.48}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>25</integer> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{199, 317.333}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>25</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -teaching:\ -Student}</string> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{311, 317.333}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>24</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -teaching:\ -Teacher}</string> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>11</integer> - </dict> - <key>ID</key> - <integer>23</integer> - <key>Points</key> - <array> - <string>{560.783, 221.551}</string> - <string>{579.416, 183.449}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>22</integer> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{513, 222}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>22</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -teaching:\ -Course}</string> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{393, 222}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>21</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -teaching:\ -Course\ -Material}</string> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{616.333, 317.333}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>20</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -teaching:\ -Lesson}</string> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>11</integer> - </dict> - <key>ID</key> - <integer>19</integer> - <key>Points</key> - <array> - <string>{634.69, 221.586}</string> - <string>{608.842, 183.414}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>13</integer> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>15</integer> - </dict> - <key>ID</key> - <integer>18</integer> - <key>Points</key> - <array> - <string>{555.906, 136.375}</string> - <string>{464.293, 80.6253}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>11</integer> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>15</integer> - </dict> - <key>ID</key> - <integer>17</integer> - <key>Points</key> - <array> - <string>{428.433, 132.894}</string> - <string>{428.433, 84.1063}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>12</integer> - </dict> - </dict> - <dict> - <key>Class</key> - <string>LineGraphic</string> - <key>Head</key> - <dict> - <key>ID</key> - <integer>15</integer> - </dict> - <key>ID</key> - <integer>16</integer> - <key>Points</key> - <array> - <string>{323.849, 133.104}</string> - <string>{393.113, 83.8959}</string> - </array> - <key>Style</key> - <dict> - <key>stroke</key> - <dict> - <key>HeadArrow</key> - <string>FilledArrow</string> - <key>TailArrow</key> - <string>0</string> - </dict> - </dict> - <key>Tail</key> - <dict> - <key>ID</key> - <integer>10</integer> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{393, 34}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>15</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>Color</key> - <dict> - <key>b</key> - <string>0.8</string> - <key>g</key> - <string>0.8</string> - <key>r</key> - <string>0.8</string> - </dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -pimo:\ -Thing}</string> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{616.333, 222}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>13</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>Color</key> - <dict> - <key>b</key> - <string>0.8</string> - <key>g</key> - <string>0.8</string> - <key>r</key> - <string>0.8</string> - </dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -pimo:\ -Meeting}</string> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{393, 133.394}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>12</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>Color</key> - <dict> - <key>b</key> - <string>0.8</string> - <key>g</key> - <string>0.8</string> - <key>r</key> - <string>0.8</string> - </dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -pimo:\ -Document}</string> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{556.333, 133.394}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>11</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>Color</key> - <dict> - <key>b</key> - <string>0.8</string> - <key>g</key> - <string>0.8</string> - <key>r</key> - <string>0.8</string> - </dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -pimo:\ -Process\ -Concept}</string> - </dict> - </dict> - <dict> - <key>Bounds</key> - <string>{{253.096, 133.394}, {70.8661, 49.6063}}</string> - <key>Class</key> - <string>ShapedGraphic</string> - <key>FontInfo</key> - <dict> - <key>Color</key> - <dict> - <key>w</key> - <string>0</string> - </dict> - <key>Font</key> - <string>Helvetica</string> - <key>NSKern</key> - <real>0.0</real> - <key>Size</key> - <real>12</real> - </dict> - <key>ID</key> - <integer>10</integer> - <key>Shape</key> - <string>Rectangle</string> - <key>Style</key> - <dict> - <key>fill</key> - <dict> - <key>Color</key> - <dict> - <key>b</key> - <string>0.8</string> - <key>g</key> - <string>0.8</string> - <key>r</key> - <string>0.8</string> - </dict> - <key>GradientColor</key> - <dict> - <key>w</key> - <string>0.666667</string> - </dict> - </dict> - </dict> - <key>Text</key> - <dict> - <key>Text</key> - <string>{\rtf1\ansi\ansicpg1252\cocoartf949 -{\fonttbl\f0\fswiss\fcharset0 Helvetica;} -{\colortbl;\red255\green255\blue255;} -\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\qc\pardirnatural - -\f0\fs24 \cf0 \expnd0\expndtw0\kerning0 -pimo:\ -Person}</string> - </dict> - </dict> - </array> - <key>GridInfo</key> - <dict/> - <key>GuidesLocked</key> - <string>NO</string> - <key>GuidesVisible</key> - <string>YES</string> - <key>HPages</key> - <integer>1</integer> - <key>ImageCounter</key> - <integer>1</integer> - <key>IsPalette</key> - <string>NO</string> - <key>KeepToScale</key> - <false/> - <key>Layers</key> - <array> - <dict> - <key>Lock</key> - <string>NO</string> - <key>Name</key> - <string>Ebene 1</string> - <key>Print</key> - <string>YES</string> - <key>View</key> - <string>YES</string> - </dict> - </array> - <key>LayoutInfo</key> - <dict/> - <key>LinksVisible</key> - <string>NO</string> - <key>MagnetsVisible</key> - <string>NO</string> - <key>MasterSheets</key> - <array> - <dict> - <key>ActiveLayerIndex</key> - <integer>0</integer> - <key>AutoAdjust</key> - <false/> - <key>CanvasColor</key> - <dict> - <key>w</key> - <string>1</string> - </dict> - <key>CanvasOrigin</key> - <string>{0, 0}</string> - <key>CanvasScale</key> - <real>1</real> - <key>ColumnAlign</key> - <integer>1</integer> - <key>ColumnSpacing</key> - <real>36</real> - <key>DisplayScale</key> - <string>1 cm = 1 cm</string> - <key>GraphicsList</key> - <array/> - <key>GridInfo</key> - <dict/> - <key>HPages</key> - <integer>1</integer> - <key>IsPalette</key> - <string>NO</string> - <key>KeepToScale</key> - <false/> - <key>Layers</key> - <array> - <dict> - <key>Lock</key> - <string>NO</string> - <key>Name</key> - <string>Ebene 1</string> - <key>Print</key> - <string>YES</string> - <key>View</key> - <string>YES</string> - </dict> - </array> - <key>LayoutInfo</key> - <dict/> - <key>Orientation</key> - <integer>2</integer> - <key>RowAlign</key> - <integer>1</integer> - <key>RowSpacing</key> - <real>36</real> - <key>SheetTitle</key> - <string>Master 1</string> - <key>UniqueID</key> - <integer>1</integer> - <key>VPages</key> - <integer>1</integer> - </dict> - </array> - <key>ModificationDate</key> - <string>2008-01-05 18:15:47 +0100</string> - <key>Modifier</key> - <string>Knud MÜller</string> - <key>NotesVisible</key> - <string>NO</string> - <key>Orientation</key> - <integer>2</integer> - <key>OriginVisible</key> - <string>NO</string> - <key>PageBreaks</key> - <string>YES</string> - <key>PrintInfo</key> - <dict> - <key>NSBottomMargin</key> - <array> - <string>float</string> - <string>36</string> - </array> - <key>NSLeftMargin</key> - <array> - <string>float</string> - <string>36</string> - </array> - <key>NSOrientation</key> - <array> - <string>int</string> - <string>1</string> - </array> - <key>NSPaperSize</key> - <array> - <string>size</string> - <string>{842, 595}</string> - </array> - <key>NSRightMargin</key> - <array> - <string>float</string> - <string>36</string> - </array> - <key>NSTopMargin</key> - <array> - <string>float</string> - <string>36</string> - </array> - </dict> - <key>ReadOnly</key> - <string>NO</string> - <key>RowAlign</key> - <integer>1</integer> - <key>RowSpacing</key> - <real>36</real> - <key>SheetTitle</key> - <string>Arbeitsfläche 1</string> - <key>SmartAlignmentGuidesActive</key> - <string>YES</string> - <key>SmartDistanceGuidesActive</key> - <string>NO</string> - <key>UniqueID</key> - <integer>1</integer> - <key>UseEntirePage</key> - <false/> - <key>VPages</key> - <integer>1</integer> - <key>WindowInfo</key> - <dict> - <key>CurrentSheet</key> - <integer>0</integer> - <key>DrawerTab</key> - <string>Outline</string> - <key>DrawerWidth</key> - <real>209</real> - <key>Frame</key> - <string>{{182, 65}, {826, 760}}</string> - <key>VisibleRegion</key> - <string>{{-20, -61}, {811, 646}}</string> - <key>Zoom</key> - <real>1</real> - </dict> -</dict> -</plist> diff --git a/pimo/doc/handbook_latex/images/PIMOextensionExample-Teaching.pdf b/pimo/doc/handbook_latex/images/PIMOextensionExample-Teaching.pdf Binary files differdeleted file mode 100644 index 8580403..0000000 --- a/pimo/doc/handbook_latex/images/PIMOextensionExample-Teaching.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/Thumbs.db b/pimo/doc/handbook_latex/images/Thumbs.db Binary files differdeleted file mode 100644 index 0ba7350..0000000 --- a/pimo/doc/handbook_latex/images/Thumbs.db +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/identification.graffle.zip b/pimo/doc/handbook_latex/images/identification.graffle.zip Binary files differdeleted file mode 100644 index a1cd6f4..0000000 --- a/pimo/doc/handbook_latex/images/identification.graffle.zip +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/identification.pdf b/pimo/doc/handbook_latex/images/identification.pdf Binary files differdeleted file mode 100644 index be55307..0000000 --- a/pimo/doc/handbook_latex/images/identification.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/images.ppt b/pimo/doc/handbook_latex/images/images.ppt Binary files differdeleted file mode 100644 index 2d583b4..0000000 --- a/pimo/doc/handbook_latex/images/images.ppt +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/roadmap.png b/pimo/doc/handbook_latex/images/roadmap.png Binary files differdeleted file mode 100644 index 937e626..0000000 --- a/pimo/doc/handbook_latex/images/roadmap.png +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/thing_vs_resource.pdf b/pimo/doc/handbook_latex/images/thing_vs_resource.pdf Binary files differdeleted file mode 100644 index efccaff..0000000 --- a/pimo/doc/handbook_latex/images/thing_vs_resource.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/images/upperclasses.png b/pimo/doc/handbook_latex/images/upperclasses.png Binary files differdeleted file mode 100644 index a21bff3..0000000 --- a/pimo/doc/handbook_latex/images/upperclasses.png +++ /dev/null diff --git a/pimo/doc/handbook_latex/nepomuk.cls b/pimo/doc/handbook_latex/nepomuk.cls deleted file mode 100644 index 81f77cc..0000000 --- a/pimo/doc/handbook_latex/nepomuk.cls +++ /dev/null @@ -1,124 +0,0 @@ -
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% Initial set up
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\NeedsTeXFormat{LaTeX2e}
-\ProvidesClass{nepomuk}[2004/03/24 2004 CleanBook LaTeX class]
-\LoadClass{article}
-\PassOptionsToClass{a4paper,11pt}{article}
-\DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}}
-\ProcessOptions
-
-%% Packages
-\RequirePackage{color}
-\RequirePackage{colortbl}
-\RequirePackage{helvet}
-\renewcommand{\familydefault}{\sfdefault}
-\usepackage{scrpage2}
-\usepackage{graphicx}
-\usepackage{color}
-\usepackage{colortbl}
-\usepackage{typearea}
-\usepackage[T1]{fontenc}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% Page Layout
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\setlength{\textwidth}{12cm}
-% \setlength{\footskip}{2cm}
-\setlength{\textheight}{24cm}
-\setlength{\oddsidemargin}{4.5cm}
-\setlength{\topmargin}{-1.0cm}
-\reversemarginpar
-\setlength{\marginparwidth}{4cm}
-\renewcommand{\arraystretch}{1.7}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% NEPOMUK colors
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\definecolor{nepomuk@lightblue}{RGB}{0,140,206}
-\definecolor{nepomuk@green}{RGB}{143,204,41}
-\definecolor{nepomuk@red}{RGB}{189,16,11}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% Headers and footers
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\pagestyle{scrheadings}
-\clearscrheadings
-\clearscrplain
-\renewcommand{\headfont}{%
-\normalfont
-}
-\renewcommand{\pnumfont}{%
-\normalfont
-}
-\setheadsepline{.4pt}[\color{nepomuk@lightblue}] % Linie unter dem Head
-\setfootsepline{.4pt}[\color{nepomuk@lightblue}] % Ganzunten
-\setheadwidth[-4.5cm]{16.5cm}
-\setfootwidth[-4.5cm]{16.5cm}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% Redefinitions (colored headings)
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-%% Paragraph skipping and indenting
-\parskip 1.mm
-\parindent 7.mm
-
-\makeatletter
-\renewcommand%
-{\section}{\@startsection{section}%
-{1}%
-{-4.5cm}%
-{2\baselineskip}%
-{1\baselineskip}%
-{\Large\bf\textcolor{nepomuk@lightblue}}%
-}
-
-\renewcommand%
-{\subsection}{\@startsection{subsection}%
-{1}%
-{-4.5cm}%
-{2\baselineskip}%
-{1\baselineskip}%
-{\large\textcolor{nepomuk@lightblue}}%
-}
-
-\renewcommand%
-{\subsubsection}{\@startsection{subsubsection}%
-{1}%
-{-4.5cm}%
-{2\baselineskip}%
-{1\baselineskip}%
-{\large\textcolor{nepomuk@lightblue}}%
-}
-\makeatother
-\newcommand{\autor}[1]{{\Large \bf \sf #1}}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% Redefinitions (toc)
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\renewcommand{\contentsname}{Table of contents}
-\makeatletter
-\renewcommand*\@dotsep{1}
-\renewcommand*\l@section{\@dottedtocline{1}{1.5em} {2.3em}}
-\renewcommand*\l@subsection{\@dottedtocline{2}{3.8 em}{3.2em}}
-\renewcommand*\l@subsubsection{\@dottedtocline{3}{ 7.0em}{4.1em}}
-\renewcommand*\l@paragraph{\@dottedtocline{4}{10em }{5em}}
-\renewcommand*\l@subparagraph{\@dottedtocline{5}{1 2em}{6em}}
-\renewcommand*\l@figure{\@dottedtocline{1}{1.5em}{ 2.3em}}
-\renewcommand*\l@table{\@dottedtocline{1}{1.5em}{ 2.3em}}
-
-\makeatother
-
-
-%\newfont{\affaddrit}{helvetica at 10pt} %13 Jan 00 gkmt
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%% Redefinitions (misc)
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\newcommand{\marginlabel}[1]
- {\mbox{}\marginpar{\raggedright\hspace{0pt}#1}}
-\renewcommand{\labelitemii}{$\circ$}
-
-\textheight25cm
\ No newline at end of file diff --git a/pimo/doc/handbook_latex/nonissues.aux b/pimo/doc/handbook_latex/nonissues.aux deleted file mode 100644 index 3101a58..0000000 --- a/pimo/doc/handbook_latex/nonissues.aux +++ /dev/null @@ -1,30 +0,0 @@ -\relax
-\@writefile{toc}{\contentsline {section}{\numberline {B}Issues Intentionally not handled by PIMO}{39}{appendix.B}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {B.1}Complex identifiers}{39}{subsection.B.1}}
-\@writefile{toc}{\contentsline {paragraph}{Proposed Solution:}{39}{section*.24}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {B.2}Modelling Default Properties and Things that have instances}{39}{subsection.B.2}}
-\@writefile{toc}{\contentsline {paragraph}{Proposed Solution:}{39}{section*.25}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {B.3}Associations implying Statements}{39}{subsection.B.3}}
-\@setckpt{nonissues}{
-\setcounter{page}{41}
-\setcounter{equation}{0}
-\setcounter{enumi}{0}
-\setcounter{enumii}{0}
-\setcounter{enumiii}{0}
-\setcounter{enumiv}{0}
-\setcounter{footnote}{29}
-\setcounter{mpfootnote}{0}
-\setcounter{part}{0}
-\setcounter{section}{2}
-\setcounter{subsection}{3}
-\setcounter{subsubsection}{0}
-\setcounter{paragraph}{0}
-\setcounter{subparagraph}{0}
-\setcounter{figure}{7}
-\setcounter{table}{1}
-\setcounter{Item}{0}
-\setcounter{Hfootnote}{29}
-\setcounter{LT@tables}{0}
-\setcounter{LT@chunks}{0}
-\setcounter{section@level}{1}
-}
diff --git a/pimo/doc/handbook_latex/nonissues.tex b/pimo/doc/handbook_latex/nonissues.tex deleted file mode 100644 index d7d9df9..0000000 --- a/pimo/doc/handbook_latex/nonissues.tex +++ /dev/null @@ -1,112 +0,0 @@ -\section{Issues Intentionally not handled by PIMO}
-
-\subsection{Complex identifiers}
-For identifiers that consist of multiple keys, or that go along more than one resource,
-we need some way to capture them.
-
-suggestion:
-{\small
-\begin{verbatim}
-
-pimo:ComplexIdentifier a rdfs:Class.
-
-pimo:ComplexIdentifierQueryBased a rdfs:Class;
- rdfs:subClassOf pimo:ComplexIdentifier.
-
-pimo:complexIdentifierTriggerProperty a rdf:Property;
- rdfs:comment """The object property indicates that
- the subject Query based complex identifier should
- be triggered, when a resource has the property set.
- For the email example, this would be
- nco:hasEmailAddress""" ;
- rdfs:domain pimo:ComplexIdentifierQueryBased;
- rdfs:range rdf:Property .
-
-pimo:complexIdentifierQuery a rdf:Property;
- rdfs:comment """Defines a query with one parameter,
- ?x, that is to be filled in. The query selects
- other variables (?y, ?z, ?a, ?number, etc.) that
- have to be the same so that two entities can be
- considered same. Example for e-mail:
- SELECT ?x ?mail
- WHERE {?x nco:hasEmailAddress ?e.
- ?e nco:emailAddress ?mail.}"""
- rdfs:domain pimo:ComplexIdentifierQueryBased;
- rdfs:range rdf:Literal.
-\end{verbatim}
-}
-
-\paragraph{Proposed Solution:} Mention that it is a problem, but give no indications for solution. Say that nao:identifier has to be enough.
-Knud, Leo, Gunnar agree on this on 8.1.2008
-
-\subsection{Modelling Default Properties and Things that have instances}
-How to model the Book ``Moby Dick'' in the version published in
-1960 with 300 pages? (example invented)
-It would be an instance of the class ``Book Edition''.
-
-Now given I have a copy of the Book, then I have an instance of ``Book Copy'',
-called ``Dirks's Moby Dick with Serial Number 123''.
-Dirk's Moby Dick has also 300 pages, but may have a sticker on the cover
-and an annotation of ``borrowed to claudia''.
-
-The same problem arises with electronic gadgets, etc, every product.
-
-\paragraph{Proposed Solution:} Leo: No Solutions, don't mention it.
-Leo, Knud agree on this on 8.1.2008
-
-
-\subsection{Associations implying Statements}
-Current status (Knud and Leo via Skype, 12.9.2007):
-We would say that this is useful and that statements and associations can be linked.
-
-Revised by Leo on 13.12.2007: no time to work on this, finish the existing Things first.
-
-A first suggestions for modelling it is in this document.
-Implementation is left open for now.
-
-One major Thing is open:
-subclassing from NAO,
-I can only do that once the RDFS is fixed.
-
-Another old idea I have to mention now, because it fits to the discussion:
-The problem is that often, relations are not just a statement (=triple) but have some metadata,
-or that N-Ary relations cannot be expressed using plain RDF. (In XML topic maps, they can)
-
-Typical problem:
-STATEMENT:
-http://sap.com - foaf:member - http://sap.com/claudia.
-
-A way to model this (this already in the PIMO last year)
-
-ROLE:
-x - type - pimo:Role;
- roleHolder - http://sap.com/claudia;
- roleContext - http://sap.com;
- roleValid - y.
-
-y - type - pimo:Duration;
- beginTime "..."
- endTime "...".
-
-Now, this is all pretty straightforward
-
-To realize an effective way of doing all this, I propose to use a meta-modelling approach, where Associations (Role is a subclass of Association) are linked to imply statements of certain property, and vice versa, that statements using a property imply that an Association must exist.
-
-Using above model Role, this means:
-STATEMENT -> ROLE.
-ROLE -> STATEMENT.
-
-> Looks good to me. But how would you link specific roles with specific properties, e.g. 'Member' with 'memberOf'? This is required for this to work.
-
-like this:
-
-pimo:Member pimo:impliesStatementRule
- "CONSTRUCT {?x pimo:hasMember ?y} WHERE {?association pimo:memberPerson ?y; pimo:memberOrganization ?x}".
-
-This requires you to model the properties and classes beforehand:
-* pimo:hasMember as the direct relation between person and organization,
-* the Member class with properties
-* pimo:memberPerson and
-* pimo:memberOrganization.
-
-is not done yet, but is probably interesting to do.
diff --git a/pimo/doc/handbook_latex/openissues.aux b/pimo/doc/handbook_latex/openissues.aux deleted file mode 100644 index 79f5a9a..0000000 --- a/pimo/doc/handbook_latex/openissues.aux +++ /dev/null @@ -1,26 +0,0 @@ -\relax
-\@writefile{toc}{\contentsline {section}{\numberline {A}Open Issues}{38}{appendix.A}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {A.1}Ranking / Rating}{38}{subsection.A.1}}
-\@setckpt{openissues}{
-\setcounter{page}{39}
-\setcounter{equation}{0}
-\setcounter{enumi}{0}
-\setcounter{enumii}{0}
-\setcounter{enumiii}{0}
-\setcounter{enumiv}{0}
-\setcounter{footnote}{29}
-\setcounter{mpfootnote}{0}
-\setcounter{part}{0}
-\setcounter{section}{1}
-\setcounter{subsection}{1}
-\setcounter{subsubsection}{0}
-\setcounter{paragraph}{0}
-\setcounter{subparagraph}{0}
-\setcounter{figure}{7}
-\setcounter{table}{1}
-\setcounter{Item}{0}
-\setcounter{Hfootnote}{29}
-\setcounter{LT@tables}{0}
-\setcounter{LT@chunks}{0}
-\setcounter{section@level}{1}
-}
diff --git a/pimo/doc/handbook_latex/openissues.tex b/pimo/doc/handbook_latex/openissues.tex deleted file mode 100644 index 8ae4f4d..0000000 --- a/pimo/doc/handbook_latex/openissues.tex +++ /dev/null @@ -1,5 +0,0 @@ -\section{Open Issues}
-
-\subsection{Ranking / Rating}
-wait for tf-ont feedback
-
diff --git a/pimo/doc/handbook_latex/pimo.aux b/pimo/doc/handbook_latex/pimo.aux deleted file mode 100644 index bc69bbb..0000000 --- a/pimo/doc/handbook_latex/pimo.aux +++ /dev/null @@ -1,592 +0,0 @@ -\relax
-\ifx\hyper@anchor\@undefined
-\global \let \oldcontentsline\contentsline
-\gdef \contentsline#1#2#3#4{\oldcontentsline{#1}{#2}{#3}}
-\global \let \oldnewlabel\newlabel
-\gdef \newlabel#1#2{\newlabelxx{#1}#2}
-\gdef \newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}}
-\AtEndDocument{\let \contentsline\oldcontentsline
-\let \newlabel\oldnewlabel}
-\else
-\global \let \hyper@last\relax
-\fi
-
-\citation{rdfs}
-\@writefile{toc}{\contentsline {section}{\numberline {1}Abstract}{1}{section.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {2}Status of this document}{1}{section.2}}
-\@writefile{toc}{\contentsline {section}{\numberline {3}Introduction}{1}{section.3}}
-\newlabel{sec:introduction}{{3}{1}{Introduction\relax }{section.3}{}}
-\citation{HolzMausBernardiRostanin2005b}
-\citation{pim2007}
-\citation{iso13250second}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Downloading PIMO}{2}{subsection.3.1}}
-\newlabel{sec:downloadingpimo}{{3.1}{2}{Downloading PIMO\relax }{subsection.3.1}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {4}PIMO integrates with key ontologies}{3}{section.4}}
-\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Integrated Ontologies}}{3}{figure.1}}
-\newlabel{fig:roadmap}{{1}{3}{Integrated Ontologies\relax }{figure.1}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {5}Examples}{4}{section.5}}
-\newlabel{sec:examples}{{5}{4}{Examples\relax }{section.5}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}PIMO ontology and namespaces}{4}{subsection.5.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {6}Creating Personal Information Models}{5}{section.6}}
-\newlabel{sec:creatingPIMOs}{{6}{5}{Creating Personal Information Models\relax }{section.6}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.1}The User and their Individual PIMO}{5}{subsection.6.1}}
-\newlabel{sec:pimo-user}{{6.1}{5}{The User and their Individual PIMO\relax }{subsection.6.1}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Things}{6}{subsection.6.2}}
-\newlabel{sec:thing}{{6.2}{6}{Things\relax }{subsection.6.2}{}}
-\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Thing and Resources}}{6}{figure.2}}
-\newlabel{fig:thing_vs_resource}{{2}{6}{Thing and Resources\relax }{figure.2}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.3}Connecting Things to the User's PIMO}{6}{subsection.6.3}}
-\newlabel{sub:connectingThingsToPimo}{{6.3}{6}{Connecting Things to the User's PIMO\relax }{subsection.6.3}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.4}Identification of Things}{7}{subsection.6.4}}
-\newlabel{sec:identification}{{6.4}{7}{Identification of Things\relax }{subsection.6.4}{}}
-\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces Different Identification Mechanisms}}{8}{figure.3}}
-\newlabel{fig:identification}{{3}{8}{Different Identification Mechanisms\relax }{figure.3}{}}
-\@writefile{toc}{\contentsline {paragraph}{NAO-Identifiers}{8}{section*.6}}
-\@writefile{toc}{\contentsline {paragraph}{Grounding Occurrence}{8}{section*.7}}
-\citation{XTM}
-\citation{Rath2003}
-\@writefile{toc}{\contentsline {paragraph}{Occurrence}{9}{section*.8}}
-\newlabel{par:referencingOccurrence}{{6.4}{9}{Referencing Occurrence\relax }{section*.9}{}}
-\@writefile{toc}{\contentsline {paragraph}{Referencing Occurrence}{9}{section*.9}}
-\newlabel{par:otherRepresentation}{{6.4}{10}{Other Representation\relax }{section*.10}{}}
-\@writefile{toc}{\contentsline {paragraph}{Other Representation}{10}{section*.10}}
-\@writefile{toc}{\contentsline {paragraph}{Other Conceptualization}{10}{section*.11}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.5}A Complete Example}{10}{subsection.6.5}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.6}Labels and Names of Things}{11}{subsection.6.6}}
-\newlabel{sec:labelling}{{6.6}{11}{Labels and Names of Things\relax }{subsection.6.6}{}}
-\@writefile{toc}{\contentsline {paragraph}{\texttt {nao:prefLabel}}{11}{section*.12}}
-\citation{rdfaprimer}
-\@writefile{toc}{\contentsline {paragraph}{\texttt {pimo:tagLabel}}{12}{section*.13}}
-\@writefile{toc}{\contentsline {paragraph}{\texttt {nao:altLabel}}{12}{section*.14}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.7}Textual description of Things}{12}{subsection.6.7}}
-\newlabel{sec:freetextdescription}{{6.7}{12}{Textual description of Things\relax }{subsection.6.7}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.8}Rating and Ranking Things}{13}{subsection.6.8}}
-\newlabel{sec:ratings}{{6.8}{13}{Rating and Ranking Things\relax }{subsection.6.8}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.9}Modelling Time}{13}{subsection.6.9}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.10}Representing Modification and Change Dates}{13}{subsection.6.10}}
-\newlabel{sec:changedates}{{6.10}{13}{Representing Modification and Change Dates\relax }{subsection.6.10}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.11}Setting the Class of a Thing}{14}{subsection.6.11}}
-\newlabel{sec:classofthing}{{6.11}{14}{Setting the Class of a Thing\relax }{subsection.6.11}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.12}The PIMO-upper ontology}{15}{subsection.6.12}}
-\newlabel{sec:pimoupper}{{6.12}{15}{The PIMO-upper ontology\relax }{subsection.6.12}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.13}Classes in PIMO-Upper}{15}{subsection.6.13}}
-\newlabel{sec:pimoUpperClasses}{{6.13}{15}{Classes in PIMO-Upper\relax }{subsection.6.13}{}}
-\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces Classes in PIMO-Upper}}{16}{figure.4}}
-\newlabel{fig:upperclasses}{{4}{16}{Classes in PIMO-Upper\relax }{figure.4}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.14}Describing Things with Attributes and Relations}{17}{subsection.6.14}}
-\newlabel{sec:describingthings}{{6.14}{17}{Describing Things with Attributes and Relations\relax }{subsection.6.14}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.15}Generic Properties in PIMO-Upper}{17}{subsection.6.15}}
-\newlabel{sec:genericproperties}{{6.15}{17}{Generic Properties in PIMO-Upper\relax }{subsection.6.15}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.16}Refined properties in PIMO-Upper}{18}{subsection.6.16}}
-\newlabel{sec:pimoupperrelations}{{6.16}{18}{Refined properties in PIMO-Upper\relax }{subsection.6.16}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.17}Tagging Things with Tags}{18}{subsection.6.17}}
-\newlabel{sec:tagginginpimo}{{6.17}{18}{Tagging Things with Tags\relax }{subsection.6.17}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.18}Topic Hierarchies}{19}{subsection.6.18}}
-\newlabel{sec:topichierarchies}{{6.18}{19}{Topic Hierarchies\relax }{subsection.6.18}{}}
-\citation{SkosStandard}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.19}Creating Personalized Classes and Properties}{20}{subsection.6.19}}
-\newlabel{sec:customontology}{{6.19}{20}{Creating Personalized Classes and Properties\relax }{subsection.6.19}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.20}Collections of Things}{21}{subsection.6.20}}
-\newlabel{sec:collections}{{6.20}{21}{Collections of Things\relax }{subsection.6.20}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {6.21}Modeling Associations and Roles in PIMO}{21}{subsection.6.21}}
-\newlabel{sec:roleBasedModeling}{{6.21}{21}{Modeling Associations and Roles in PIMO\relax }{subsection.6.21}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {7}Connecting PIMO to Information Elements}{22}{section.7}}
-\newlabel{sec:pimoVSnie}{{7}{22}{Connecting PIMO to Information Elements\relax }{section.7}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {7.1}Connecting Things and Classes to Folders}{22}{subsection.7.1}}
-\newlabel{sec:containers}{{7.1}{22}{Connecting Things and Classes to Folders\relax }{subsection.7.1}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {7.2}Integrating Facts about Things}{23}{subsection.7.2}}
-\newlabel{sec:integratingfacts}{{7.2}{23}{Integrating Facts about Things\relax }{subsection.7.2}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {8}PIMO-group level: Group and Domain ontologies}{23}{section.8}}
-\newlabel{sec:pimomid}{{8}{23}{PIMO-group level: Group and Domain ontologies\relax }{section.8}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {9}Extending PIMO}{24}{section.9}}
-\newlabel{sec:integratingontologies}{{9}{24}{Extending PIMO\relax }{section.9}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {9.1}Refining Elements of PIMO-upper}{24}{subsection.9.1}}
-\newlabel{sub:subclassing_pimo_upper}{{9.1}{24}{Refining Elements of PIMO-upper\relax }{subsection.9.1}{}}
-\newlabel{par:classes}{{9.1}{24}{Classes\relax }{section*.15}{}}
-\@writefile{toc}{\contentsline {paragraph}{Classes}{24}{section*.15}}
-\newlabel{par:instances}{{9.1}{24}{Instances\relax }{section*.16}{}}
-\@writefile{toc}{\contentsline {paragraph}{Instances}{24}{section*.16}}
-\newlabel{par:properties}{{9.1}{25}{Properties\relax }{section*.17}{}}
-\@writefile{toc}{\contentsline {paragraph}{Properties}{25}{section*.17}}
-\newlabel{par:inheritance}{{9.1}{25}{Inheritance\relax }{section*.18}{}}
-\@writefile{toc}{\contentsline {paragraph}{Inheritance}{25}{section*.18}}
-\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces Extending PIMO with new classes, properties and instances for the domain of teaching}}{26}{figure.5}}
-\newlabel{fig:extensionExampleTeaching}{{5}{26}{Extending PIMO with new classes, properties and instances for the domain of teaching\relax }{figure.5}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {9.2}Markup for the new ontology}{26}{subsection.9.2}}
-\newlabel{sec:extendingontologymarkup}{{9.2}{26}{Markup for the new ontology\relax }{subsection.9.2}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {9.3}Information Elements}{26}{subsection.9.3}}
-\newlabel{sub:information_elements}{{9.3}{26}{Information Elements\relax }{subsection.9.3}{}}
-\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces Extending PIMO with new classes, properties and instances for the domain of teaching --- N3 code}}{27}{figure.6}}
-\newlabel{fig:extensionExampleTeachingN3}{{6}{27}{Extending PIMO with new classes, properties and instances for the domain of teaching --- N3 code\relax }{figure.6}{}}
-\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces ``Inheritance'' of properties}}{28}{figure.7}}
-\newlabel{fig:propertyInheritance}{{7}{28}{``Inheritance'' of properties\relax }{figure.7}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {9.4}Extension by Sub-classing from External Classes}{28}{subsection.9.4}}
-\newlabel{sub:extension_by_subclassing_from_external_classes}{{9.4}{28}{Extension by Sub-classing from External Classes\relax }{subsection.9.4}{}}
-\citation{rohmer2005}
-\citation{rohmer2005}
-\citation{SWBPVocabularyRecipes}
-\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces A BibT\kern -.1667em\lower .5ex\hbox {E}\kern -.125emX\spacefactor \@m -based PIMO extension for scientific publications}}{29}{figure.8}}
-\newlabel{fig:bibtexExample}{{8}{29}{A Bib\TeX -based PIMO extension for scientific publications\relax }{figure.8}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {9.5}Summary}{29}{subsection.9.5}}
-\newlabel{sub:summary}{{9.5}{29}{Summary\relax }{subsection.9.5}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {10}Importing Domain Ontologies into a User's PIMO}{29}{section.10}}
-\newlabel{sec:importingontologies}{{10}{29}{Importing Domain Ontologies into a User's PIMO\relax }{section.10}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {11}Practical Directions on Using PIMO}{30}{section.11}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.1}Creating Things}{30}{subsection.11.1}}
-\newlabel{sec:creatingthingalgorithm}{{11.1}{30}{Creating Things\relax }{subsection.11.1}{}}
-\@writefile{toc}{\contentsline {paragraph}{Start}{30}{section*.19}}
-\@writefile{toc}{\contentsline {paragraph}{Check GroundingOccurrence}{30}{section*.20}}
-\@writefile{toc}{\contentsline {paragraph}{Check occurrences}{30}{section*.21}}
-\@writefile{toc}{\contentsline {paragraph}{Check identifiers}{30}{section*.22}}
-\@writefile{toc}{\contentsline {paragraph}{Create a new Thing}{31}{section*.23}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.2}Changing the Type of a Thing}{31}{subsection.11.2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.3}Deleting a Thing}{32}{subsection.11.3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.4}Deleting User-generated Classes and Properties}{32}{subsection.11.4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.5}Merging Duplicates}{32}{subsection.11.5}}
-\newlabel{sec:mergeduplicates}{{11.5}{32}{Merging Duplicates\relax }{subsection.11.5}{}}
-\citation{Dengel2006}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.6}Unification of multiple Information Elements into one Thing}{33}{subsection.11.6}}
-\newlabel{sec:unification}{{11.6}{33}{Unification of multiple Information Elements into one Thing\relax }{subsection.11.6}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.7}Tagging and Annotating Files}{34}{subsection.11.7}}
-\newlabel{sec:taggingfiles}{{11.7}{34}{Tagging and Annotating Files\relax }{subsection.11.7}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.8}Geo-locating Things}{35}{subsection.11.8}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.9}Defining what is in the PIMO and what is not: NRL Graphs and \texttt {definedBy}}{36}{subsection.11.9}}
-\newlabel{sec:nrlgraphs}{{11.9}{36}{Defining what is in the PIMO and what is not: NRL Graphs and \texttt {definedBy}\relax }{subsection.11.9}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.10}Using NAO and NIE Elements for Annotation}{37}{subsection.11.10}}
-\newlabel{sec:usingnieinpimo}{{11.10}{37}{Using NAO and NIE Elements for Annotation\relax }{subsection.11.10}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {11.11}How to Infer Knowledge Using Rules?}{37}{subsection.11.11}}
-\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces Semantics of NAO and NIE in PIMO}}{38}{table.1}}
-\newlabel{tab:SemanitcsOfNIEInPIMO}{{1}{38}{Semantics of NAO and NIE in PIMO\relax }{table.1}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {12}Rules Defined by PIMO}{39}{section.12}}
-\newlabel{sec:pimorules}{{12}{39}{Rules Defined by PIMO\relax }{section.12}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {12.1}Construction Rules}{39}{subsection.12.1}}
-\newlabel{sec:creationrules}{{12.1}{39}{Construction Rules\relax }{subsection.12.1}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {12.2}Validation Rules}{40}{subsection.12.2}}
-\newlabel{sec:validationrules}{{12.2}{40}{Validation Rules\relax }{subsection.12.2}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {12.3}Rules Valid when Integrating with NIE}{40}{subsection.12.3}}
-\citation{sauermann+2007b}
-\citation{likothanasis+2005}
-\citation{SkosStandard}
-\citation{Pepper+2003}
-\citation{Park+2005}
-\@writefile{toc}{\contentsline {section}{\numberline {13}Sources considered for designing PIMO}{41}{section.13}}
-\citation{DongH2005}
-\citation{UserProfileOntologyVersion1}
-\citation{DELOSTIM2007}
-\citation{Latif+2006}
-\@writefile{toc}{\contentsline {section}{\numberline {A}Changes}{42}{appendix.A}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {A.1}From v1.0 to 1.1}{42}{subsection.A.1}}
-\bibstyle{plain}
-\bibdata{pimo}
-\bibcite{iso13250second}{1}
-\bibcite{rdfaprimer}{2}
-\bibcite{rdfs}{3}
-\bibcite{likothanasis+2005}{4}
-\bibcite{DELOSTIM2007}{5}
-\bibcite{Dengel2006}{6}
-\bibcite{DongH2005}{7}
-\bibcite{SkosStandard}{8}
-\bibcite{UserProfileOntologyVersion1}{9}
-\bibcite{HolzMausBernardiRostanin2005b}{10}
-\bibcite{pim2007}{11}
-\bibcite{Latif+2006}{12}
-\bibcite{SWBPVocabularyRecipes}{13}
-\bibcite{Park+2005}{14}
-\bibcite{Pepper+2003}{15}
-\bibcite{Rath2003}{16}
-\bibcite{rohmer2005}{17}
-\bibcite{sauermann+2007b}{18}
-\bibcite{XTM}{19}
-\gdef \LT@i {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@ii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@iii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {section}{\numberline {B}PIMO Specification}{45}{appendix.B}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {B.1}Ontology Classes Description}{45}{subsection.B.1}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.1}Agent}{45}{subsubsection.B.1.1}}
-\newlabel{pimo:Agent}{{B.1.1}{45}{Agent\relax }{subsubsection.B.1.1}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.2}Association}{45}{subsubsection.B.1.2}}
-\newlabel{pimo:Association}{{B.1.2}{45}{Association\relax }{subsubsection.B.1.2}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.3}Attendee}{45}{subsubsection.B.1.3}}
-\newlabel{pimo:Attendee}{{B.1.3}{45}{Attendee\relax }{subsubsection.B.1.3}{}}
-\gdef \LT@iv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@v {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@vi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.4}BlogPost}{46}{subsubsection.B.1.4}}
-\newlabel{pimo:BlogPost}{{B.1.4}{46}{BlogPost\relax }{subsubsection.B.1.4}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.5}Building}{46}{subsubsection.B.1.5}}
-\newlabel{pimo:Building}{{B.1.5}{46}{Building\relax }{subsubsection.B.1.5}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.6}City}{46}{subsubsection.B.1.6}}
-\newlabel{pimo:City}{{B.1.6}{46}{City\relax }{subsubsection.B.1.6}{}}
-\gdef \LT@vii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@viii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.7}ClassOrThing}{47}{subsubsection.B.1.7}}
-\newlabel{pimo:ClassOrThing}{{B.1.7}{47}{ClassOrThing\relax }{subsubsection.B.1.7}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.8}ClassOrThingOrPropertyOrAssociation}{47}{subsubsection.B.1.8}}
-\newlabel{pimo:ClassOrThingOrPropertyOrAssociation}{{B.1.8}{47}{ClassOrThingOrPropertyOrAssociation\relax }{subsubsection.B.1.8}{}}
-\gdef \LT@ix {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@x {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.9}ClassRole}{48}{subsubsection.B.1.9}}
-\newlabel{pimo:ClassRole}{{B.1.9}{48}{ClassRole\relax }{subsubsection.B.1.9}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.10}Collection}{48}{subsubsection.B.1.10}}
-\newlabel{pimo:Collection}{{B.1.10}{48}{Collection\relax }{subsubsection.B.1.10}{}}
-\gdef \LT@xi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.11}Contract}{49}{subsubsection.B.1.11}}
-\newlabel{pimo:Contract}{{B.1.11}{49}{Contract\relax }{subsubsection.B.1.11}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.12}Country}{49}{subsubsection.B.1.12}}
-\newlabel{pimo:Country}{{B.1.12}{49}{Country\relax }{subsubsection.B.1.12}{}}
-\gdef \LT@xiii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xiv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.13}Document}{50}{subsubsection.B.1.13}}
-\newlabel{pimo:Document}{{B.1.13}{50}{Document\relax }{subsubsection.B.1.13}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.14}Event}{50}{subsubsection.B.1.14}}
-\newlabel{pimo:Event}{{B.1.14}{50}{Event\relax }{subsubsection.B.1.14}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.15}Locatable}{50}{subsubsection.B.1.15}}
-\newlabel{pimo:Locatable}{{B.1.15}{50}{Locatable\relax }{subsubsection.B.1.15}{}}
-\gdef \LT@xvi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xvii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.16}Location}{51}{subsubsection.B.1.16}}
-\newlabel{pimo:Location}{{B.1.16}{51}{Location\relax }{subsubsection.B.1.16}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.17}LogicalMediaType}{51}{subsubsection.B.1.17}}
-\newlabel{pimo:LogicalMediaType}{{B.1.17}{51}{LogicalMediaType\relax }{subsubsection.B.1.17}{}}
-\gdef \LT@xviii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xix {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xx {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.18}Meeting}{52}{subsubsection.B.1.18}}
-\newlabel{pimo:Meeting}{{B.1.18}{52}{Meeting\relax }{subsubsection.B.1.18}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.19}Note}{52}{subsubsection.B.1.19}}
-\newlabel{pimo:Note}{{B.1.19}{52}{Note\relax }{subsubsection.B.1.19}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.20}Organization}{52}{subsubsection.B.1.20}}
-\newlabel{pimo:Organization}{{B.1.20}{52}{Organization\relax }{subsubsection.B.1.20}{}}
-\gdef \LT@xxi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxiii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.21}OrganizationMember}{53}{subsubsection.B.1.21}}
-\newlabel{pimo:OrganizationMember}{{B.1.21}{53}{OrganizationMember\relax }{subsubsection.B.1.21}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.22}Person}{53}{subsubsection.B.1.22}}
-\newlabel{pimo:Person}{{B.1.22}{53}{Person\relax }{subsubsection.B.1.22}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.23}PersonGroup}{53}{subsubsection.B.1.23}}
-\newlabel{pimo:PersonGroup}{{B.1.23}{53}{PersonGroup\relax }{subsubsection.B.1.23}{}}
-\gdef \LT@xxiv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.24}PersonRole}{54}{subsubsection.B.1.24}}
-\newlabel{pimo:PersonRole}{{B.1.24}{54}{PersonRole\relax }{subsubsection.B.1.24}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.25}PersonalInformationModel}{54}{subsubsection.B.1.25}}
-\newlabel{pimo:PersonalInformationModel}{{B.1.25}{54}{PersonalInformationModel\relax }{subsubsection.B.1.25}{}}
-\gdef \LT@xxvi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxvii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxviii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.26}ProcessConcept}{55}{subsubsection.B.1.26}}
-\newlabel{pimo:ProcessConcept}{{B.1.26}{55}{ProcessConcept\relax }{subsubsection.B.1.26}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.27}Project}{55}{subsubsection.B.1.27}}
-\newlabel{pimo:Project}{{B.1.27}{55}{Project\relax }{subsubsection.B.1.27}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.28}Room}{55}{subsubsection.B.1.28}}
-\newlabel{pimo:Room}{{B.1.28}{55}{Room\relax }{subsubsection.B.1.28}{}}
-\gdef \LT@xxix {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxx {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxxi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.29}SocialEvent}{56}{subsubsection.B.1.29}}
-\newlabel{pimo:SocialEvent}{{B.1.29}{56}{SocialEvent\relax }{subsubsection.B.1.29}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.30}State}{56}{subsubsection.B.1.30}}
-\newlabel{pimo:State}{{B.1.30}{56}{State\relax }{subsubsection.B.1.30}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.31}Task}{56}{subsubsection.B.1.31}}
-\newlabel{pimo:Task}{{B.1.31}{56}{Task\relax }{subsubsection.B.1.31}{}}
-\gdef \LT@xxxii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.32}Thing}{57}{subsubsection.B.1.32}}
-\newlabel{pimo:Thing}{{B.1.32}{57}{Thing\relax }{subsubsection.B.1.32}{}}
-\gdef \LT@xxxiii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxxiv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxxv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.1.33}Topic}{58}{subsubsection.B.1.33}}
-\newlabel{pimo:Topic}{{B.1.33}{58}{Topic\relax }{subsubsection.B.1.33}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {B.2}Ontology Properties Description}{58}{subsection.B.2}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.1}associationEffectual}{58}{subsubsection.B.2.1}}
-\newlabel{pimo:associationEffectual}{{B.2.1}{58}{associationEffectual\relax }{subsubsection.B.2.1}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.2}associationMember}{58}{subsubsection.B.2.2}}
-\newlabel{pimo:associationMember}{{B.2.2}{58}{associationMember\relax }{subsubsection.B.2.2}{}}
-\gdef \LT@xxxvi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxxvii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxxviii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xxxix {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.3}attendee}{59}{subsubsection.B.2.3}}
-\newlabel{pimo:attendee}{{B.2.3}{59}{attendee\relax }{subsubsection.B.2.3}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.4}attendingMeeting}{59}{subsubsection.B.2.4}}
-\newlabel{pimo:attendingMeeting}{{B.2.4}{59}{attendingMeeting\relax }{subsubsection.B.2.4}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.5}attends}{59}{subsubsection.B.2.5}}
-\newlabel{pimo:attends}{{B.2.5}{59}{attends\relax }{subsubsection.B.2.5}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.6}broader}{59}{subsubsection.B.2.6}}
-\newlabel{pimo:broader}{{B.2.6}{59}{broader\relax }{subsubsection.B.2.6}{}}
-\gdef \LT@xl {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xli {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xlii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xliii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.7}classRole}{60}{subsubsection.B.2.7}}
-\newlabel{pimo:classRole}{{B.2.7}{60}{classRole\relax }{subsubsection.B.2.7}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.8}containsLocation}{60}{subsubsection.B.2.8}}
-\newlabel{pimo:containsLocation}{{B.2.8}{60}{containsLocation\relax }{subsubsection.B.2.8}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.9}createdPimo}{60}{subsubsection.B.2.9}}
-\newlabel{pimo:createdPimo}{{B.2.9}{60}{createdPimo\relax }{subsubsection.B.2.9}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.10}creator}{60}{subsubsection.B.2.10}}
-\newlabel{pimo:creator}{{B.2.10}{60}{creator\relax }{subsubsection.B.2.10}{}}
-\gdef \LT@xliv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xlv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xlvi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xlvii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.11}datatypeProperty}{61}{subsubsection.B.2.11}}
-\newlabel{pimo:datatypeProperty}{{B.2.11}{61}{datatypeProperty\relax }{subsubsection.B.2.11}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.12}dtend}{61}{subsubsection.B.2.12}}
-\newlabel{pimo:dtend}{{B.2.12}{61}{dtend\relax }{subsubsection.B.2.12}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.13}dtstart}{61}{subsubsection.B.2.13}}
-\newlabel{pimo:dtstart}{{B.2.13}{61}{dtstart\relax }{subsubsection.B.2.13}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.14}duration}{61}{subsubsection.B.2.14}}
-\newlabel{pimo:duration}{{B.2.14}{61}{duration\relax }{subsubsection.B.2.14}{}}
-\gdef \LT@xlviii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@xlix {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@l {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.15}groundingForDeletedThing}{62}{subsubsection.B.2.15}}
-\newlabel{pimo:groundingForDeletedThing}{{B.2.15}{62}{groundingForDeletedThing\relax }{subsubsection.B.2.15}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.16}groundingOccurrence}{62}{subsubsection.B.2.16}}
-\newlabel{pimo:groundingOccurrence}{{B.2.16}{62}{groundingOccurrence\relax }{subsubsection.B.2.16}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.17}hasDeprecatedRepresentation}{62}{subsubsection.B.2.17}}
-\newlabel{pimo:hasDeprecatedRepresentation}{{B.2.17}{62}{hasDeprecatedRepresentation\relax }{subsubsection.B.2.17}{}}
-\gdef \LT@li {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@liii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@liv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.18}hasFolder}{63}{subsubsection.B.2.18}}
-\newlabel{pimo:hasFolder}{{B.2.18}{63}{hasFolder\relax }{subsubsection.B.2.18}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.19}hasLocation}{63}{subsubsection.B.2.19}}
-\newlabel{pimo:hasLocation}{{B.2.19}{63}{hasLocation\relax }{subsubsection.B.2.19}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.20}hasOrganizationMember}{63}{subsubsection.B.2.20}}
-\newlabel{pimo:hasOrganizationMember}{{B.2.20}{63}{hasOrganizationMember\relax }{subsubsection.B.2.20}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.21}hasOtherConceptualization}{63}{subsubsection.B.2.21}}
-\newlabel{pimo:hasOtherConceptualization}{{B.2.21}{63}{hasOtherConceptualization\relax }{subsubsection.B.2.21}{}}
-\gdef \LT@lv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lvi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.22}hasOtherRepresentation}{64}{subsubsection.B.2.22}}
-\newlabel{pimo:hasOtherRepresentation}{{B.2.22}{64}{hasOtherRepresentation\relax }{subsubsection.B.2.22}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.23}hasOtherSlot}{64}{subsubsection.B.2.23}}
-\newlabel{pimo:hasOtherSlot}{{B.2.23}{64}{hasOtherSlot\relax }{subsubsection.B.2.23}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.24}hasPart}{64}{subsubsection.B.2.24}}
-\newlabel{pimo:hasPart}{{B.2.24}{64}{hasPart\relax }{subsubsection.B.2.24}{}}
-\gdef \LT@lvii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lviii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lix {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lx {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.25}hasTopic}{65}{subsubsection.B.2.25}}
-\newlabel{pimo:hasTopic}{{B.2.25}{65}{hasTopic\relax }{subsubsection.B.2.25}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.26}isDefinedBy}{65}{subsubsection.B.2.26}}
-\newlabel{pimo:isDefinedBy}{{B.2.26}{65}{isDefinedBy\relax }{subsubsection.B.2.26}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.27}isLocationOf}{65}{subsubsection.B.2.27}}
-\newlabel{pimo:isLocationOf}{{B.2.27}{65}{isLocationOf\relax }{subsubsection.B.2.27}{}}
-\gdef \LT@lxi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxiii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxiv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.28}isOrganizationMemberOf}{66}{subsubsection.B.2.28}}
-\newlabel{pimo:isOrganizationMemberOf}{{B.2.28}{66}{isOrganizationMemberOf\relax }{subsubsection.B.2.28}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.29}isRelated}{66}{subsubsection.B.2.29}}
-\newlabel{pimo:isRelated}{{B.2.29}{66}{isRelated\relax }{subsubsection.B.2.29}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.30}isTopicOf}{66}{subsubsection.B.2.30}}
-\newlabel{pimo:isTopicOf}{{B.2.30}{66}{isTopicOf\relax }{subsubsection.B.2.30}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.31}isWriteable}{66}{subsubsection.B.2.31}}
-\newlabel{pimo:isWriteable}{{B.2.31}{66}{isWriteable\relax }{subsubsection.B.2.31}{}}
-\gdef \LT@lxv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxvi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxvii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxviii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.32}jabberId}{67}{subsubsection.B.2.32}}
-\newlabel{pimo:jabberId}{{B.2.32}{67}{jabberId\relax }{subsubsection.B.2.32}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.33}locatedWithin}{67}{subsubsection.B.2.33}}
-\newlabel{pimo:locatedWithin}{{B.2.33}{67}{locatedWithin\relax }{subsubsection.B.2.33}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.34}narrower}{67}{subsubsection.B.2.34}}
-\newlabel{pimo:narrower}{{B.2.34}{67}{narrower\relax }{subsubsection.B.2.34}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.35}objectProperty}{67}{subsubsection.B.2.35}}
-\newlabel{pimo:objectProperty}{{B.2.35}{67}{objectProperty\relax }{subsubsection.B.2.35}{}}
-\gdef \LT@lxix {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxx {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxxi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.36}occurrence}{68}{subsubsection.B.2.36}}
-\newlabel{pimo:occurrence}{{B.2.36}{68}{occurrence\relax }{subsubsection.B.2.36}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.37}organization}{68}{subsubsection.B.2.37}}
-\newlabel{pimo:organization}{{B.2.37}{68}{organization\relax }{subsubsection.B.2.37}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.38}partOf}{68}{subsubsection.B.2.38}}
-\newlabel{pimo:partOf}{{B.2.38}{68}{partOf\relax }{subsubsection.B.2.38}{}}
-\gdef \LT@lxxii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxxiii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxxiv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxxv {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.39}referencingOccurrence}{69}{subsubsection.B.2.39}}
-\newlabel{pimo:referencingOccurrence}{{B.2.39}{69}{referencingOccurrence\relax }{subsubsection.B.2.39}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.40}roleContext}{69}{subsubsection.B.2.40}}
-\newlabel{pimo:roleContext}{{B.2.40}{69}{roleContext\relax }{subsubsection.B.2.40}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.41}roleHolder}{69}{subsubsection.B.2.41}}
-\newlabel{pimo:roleHolder}{{B.2.41}{69}{roleHolder\relax }{subsubsection.B.2.41}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.42}subTopic}{69}{subsubsection.B.2.42}}
-\newlabel{pimo:subTopic}{{B.2.42}{69}{subTopic\relax }{subsubsection.B.2.42}{}}
-\gdef \LT@lxxvi {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxxvii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\gdef \LT@lxxviii {\LT@entry
- {1}{115.23094pt}\LT@entry
- {1}{224.08682pt}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.43}superTopic}{70}{subsubsection.B.2.43}}
-\newlabel{pimo:superTopic}{{B.2.43}{70}{superTopic\relax }{subsubsection.B.2.43}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.44}taskDueTime}{70}{subsubsection.B.2.44}}
-\newlabel{pimo:taskDueTime}{{B.2.44}{70}{taskDueTime\relax }{subsubsection.B.2.44}{}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {B.2.45}wikiText}{70}{subsubsection.B.2.45}}
-\newlabel{pimo:wikiText}{{B.2.45}{70}{wikiText\relax }{subsubsection.B.2.45}{}}
diff --git a/pimo/doc/handbook_latex/pimo.bbl b/pimo/doc/handbook_latex/pimo.bbl deleted file mode 100644 index 665a3fe..0000000 --- a/pimo/doc/handbook_latex/pimo.bbl +++ /dev/null @@ -1,117 +0,0 @@ -\begin{thebibliography}{10}
-
-\bibitem{iso13250second}
-{ISO/IEC 13250, Topic Maps}, second edition.
-\newblock
- \url{http://www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd-ed-v2%
-.pdf}, 19 May 2002.
-
-\bibitem{rdfaprimer}
-Ben Adida and Mark Birbeck.
-\newblock Rdfa prime. bridging the human and data webs.
-\newblock W3C Working Group Note http://www.w3.org/TR/xhtml-rdfa-primer/, W3C,
- http://www.w3.org/TR/xhtml-rdfa-primer/, 14 October 2008.
-
-\bibitem{rdfs}
-D.~Brickley and R.V. Guha.
-\newblock {RDF} vocabulary description language 1.0: {RDF} schema. {W3C}
- recommendation.
-\newblock \url{http://www.w3.org/TR/rdf-schema/}, 10 February 2004.
-
-\bibitem{likothanasis+2005}
-K.~Votis C.~Alexakos, B.~Vassiliadis and S.~Likothanassis.
-\newblock {\em A Multilayer Ontology Scheme for Integrated Searching in
- Distributed Hypermedia}, volume Adaptive and Personalized Semantic Web of
- {\em Studies in Computational Intelligence}.
-\newblock Springer, 2006.
-
-\bibitem{DELOSTIM2007}
-T.~Catarci, A.~Dix, A.~Katifori, G.~Lepouras, and A.~Poggi.
-\newblock Task-centered information management.
-\newblock In C.~Thanos and F.~Borri, editors, {\em DELOS Conference 2007 on
- Working Notes}, pages 253--263, Tirrenia, Pisa, 13-14 February 2007.
-
-\bibitem{Dengel2006}
-Andreas~R. Dengel.
-\newblock Six thousand words about multi-perspective personal document
- management.
-\newblock In {\em Proc. EDM IEEE Workshop}. IEEE, Oct 2006.
-
-\bibitem{DongH2005}
-Xin Dong and Alon~Y. Halevy.
-\newblock A platform for personal information management and integration.
-\newblock In {\em Proc. of the CIDR Conference}, pages 119--130, 2005.
-
-\bibitem{SkosStandard}
-Alistair~Miles (edt).
-\newblock Simple knowledge organisation system (skos).
-\newblock \url{http://www.w3.org/2004/02/skos/}, Feb 2004.
-
-\bibitem{UserProfileOntologyVersion1}
-M.~Golemati, A.~Katifori, C.~Vassilakis, G.~Lepouras, and C.~Halatsis.
-\newblock User profile ontology version 1.
-\newblock \url{http://oceanis.mm.di.uoa.gr/pened/?category=publications}, 2006.
-
-\bibitem{HolzMausBernardiRostanin2005b}
-Harald Holz, Heiko Maus, Ansgar Bernardi, and Oleg Rostanin.
-\newblock From {L}ightweight, {P}roactive {I}nformation {D}elivery to
- {B}usiness {P}rocess-{O}riented {K}nowledge {M}anagement.
-\newblock volume~0, pages 101--127, 2005.
-
-\bibitem{pim2007}
-William Jones and Jamie Teevan, editors.
-\newblock {\em Personal Information Management}.
-\newblock {University of Washington Press}, October 2007.
-
-\bibitem{Latif+2006}
-Khalid Latif and A~Min Tjoa.
-\newblock Combining context ontology and landmarks for personal information
- management.
-\newblock In {\em Proceedings of International Conference on Computing and
- Informatics (ICOCI)}, Kuala Lumpur, Malaysia, June 2006.
-
-\bibitem{SWBPVocabularyRecipes}
-Alistair Miles, Thomas Baker, and Ralph Swick.
-\newblock Best practice recipes for publishing {RDF} vocabularies.
-\newblock {W3C} working draft, W3C, Mar 2006.
-\newblock \url{http://www.w3.org/TR/swbp-vocab-pub/}.
-
-\bibitem{Park+2005}
-Jack Park and Adam Cheyer.
-\newblock Just for me: Topic maps and ontologies.
-\newblock In Lutz Maicher and Jack Park, editors, {\em {TMRA} Charting the
- Topic Maps Research and Applications Landscape, First International Workshop
- on Topic Maps Research and Applications}, volume 3873 of {\em Lecture Notes
- in Computer Science}, pages 145--159. Springer, 2005.
-
-\bibitem{Pepper+2003}
-Steve Pepper and Sylvia Schwab.
-\newblock Curing the web's identity crisis. subject indicators for rdf.
-\newblock Technical report, Ontopia, 2003.
-
-\bibitem{Rath2003}
-Holger Rath.
-\newblock The topic maps handbook --- detailed description of the standard and
- practical guidelines for using it in knowledge management.
-\newblock empolis white paper, empolis GmbH, 2003.
-
-\bibitem{rohmer2005}
-Jean Rohmer.
-\newblock Lessons for the future of semantic desktops learnt from 10 years of
- experience with the ideliance semantic networks manager.
-\newblock In Stefan Decker, Jack Park, Dennis Quan, and Leo Sauermann, editors,
- {\em Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6}, volume 175, November 2005.
-
-\bibitem{sauermann+2007b}
-Leo Sauermann, Ludger van Elst, and Andreas Dengel.
-\newblock Pimo - a framework for representing personal information models.
-\newblock In Tassilo Pellegrini and Sebastian Schaffert, editors, {\em
- Proceedings of I-Semantics' 07}, pages pp. 270--277. JUCS, 2007.
-
-\bibitem{XTM}
-Graham Moore~(eds). Steve~Pepper.
-\newblock {XML Topic Maps (XTM)} 1.0.
-\newblock Specification, TopicMaps.Org, 2001.
-
-\end{thebibliography}
diff --git a/pimo/doc/handbook_latex/pimo.bib b/pimo/doc/handbook_latex/pimo.bib deleted file mode 100644 index 8c7c9ab..0000000 --- a/pimo/doc/handbook_latex/pimo.bib +++ /dev/null @@ -1,4341 +0,0 @@ -========================== BEGIN LEO.BIB ===========================
-This file was created with JabRef 1.8.1.
-Encoding: UTF8
-
-
-@misc{iso13250second,
- Month = {19 May},
- Title = {{ISO/IEC 13250, Topic Maps}, Second Edition},
- Url = {http://www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd-ed-v2.pdf},
- howpublished = {\url{http://www.y12.doe.gov/sgml/sc34/document/0322_files/iso13250-2nd-ed-v2.pdf}},
- year = {2002}}
-
-
-@INPROCEEDINGS{MausHolzBernardi+2005,
- author = {Heiko Maus and Harald Holz and Ansgar Bernardi and Oleg Rostanin},
- title = {Leveraging Passive Paper Piles to Active Objects in Personal Knowledge
- Spaces},
- booktitle = {Proceedings of 3rd Conference Professional Knowledge Management:
- Experiences and Visions},
- year = {2005},
- pages = {43--46},
- month = {April},
- crossref = {WM2005},
- doi = {ISBN 3-00-016020-5},
- language = {english},
- owner = {maus},
- pdf = {MausHolzBernardi+2005.pdf},
-}
-
-@INPROCEEDINGS{Park+2005,
- author = {Jack Park and Adam Cheyer},
- title = {Just For Me: Topic Maps and Ontologies},
- booktitle = {{TMRA} Charting the Topic Maps Research and Applications Landscape,
- First International Workshop on Topic Maps Research and Applications},
- year = {2005},
- editor = {Lutz Maicher and Jack Park},
- volume = {3873},
- series = {Lecture Notes in Computer Science},
- pages = {145-159},
- publisher = {Springer},
- bibsource = {DBLP, http://dblp.uni-trier.de},
- comment = {sent to me by Jack Park},
- crossref = {DBLP:conf/tmra/2005},
- ee = {http://dx.doi.org/10.1007/11676904_13},
- isbn = {3-540-32527-1},
- owner = {sauermann},
- pdf = {Park+2005.pdf},
- timestamp = {2006.07.11},
-}
-
-@INPROCEEDINGS{Bizer2006kl,
- author = {Emmanuel Pietriga and Christian Bizer and David Karger and Ryan Lee},
- title = {Fresnel: A Browser-Independent Presentation Vocabulary for RDF.},
- booktitle = {International Semantic Web Conference},
- year = {2006},
- editor = {Isabel F. Cruz and Stefan Decker and Dean Allemang and Chris Preist
- and Daniel Schwabe and Peter Mika and Michael Uschold and Lora Aroyo},
- volume = {4273},
- series = {Lecture Notes in Computer Science},
- pages = {158-171},
- publisher = {Springer},
- abstract = {SemanticWeb browsers and other tools aimed at displaying RDF data
- to end users are all concerned with the same problem: presenting
- content primarily intended for machine consumption in a human-readable
- way. Their solutions differ but in the end address the same two
- high-level issues, no matter the underlying representation paradigm:
- specifying (i) what information contained in RDF models should be
- presented (content selection) and (ii) how this information should
- be presented (content formatting and styling). However, each tool
- currently relies on its own ad hoc mechanisms and vocabulary for
- specifying RDF presentation knowledge, making it difficult to share
- and reuse such knowledge across applications. Recognizing the general
- need for presenting RDF content to users and wanting to promote
- the exchange of presentation knowledge, we designed Fresnel as a
- browser-independent vocabulary of core RDF display concepts. In
- this paper we describe Fresnelâs main concepts and present several
- RDF browsers and visualization tools that have adopted the vocabulary
- so far.},
- crossref = {conf/semweb/2006},
- date = {2006-11-09},
- description = {dblp},
- ee = {http://dx.doi.org/10.1007/11926078_12},
- isbn = {3-540-49029-9},
- keywords = {fresnel iswc rdf },
- pdf = {Bizer2006kl.pdf},
- url = {http://dblp.uni-trier.de/db/conf/semweb/iswc2006.html#PietrigaBKL06},
-}
-
-@MISC{SkosStandard,
- author = {Alistair Miles (edt)},
- title = {Simple Knowledge Organisation System (SKOS)},
- howpublished = {\url{http://www.w3.org/2004/02/skos/}},
- month = {Feb},
- year = {2004},
- owner = {sauermann},
- timestamp = {2006.10.30},
-}
-
-@TECHREPORT{SPARQLProtocol2005,
- author = {Kendall Grant Clark (edt)},
- title = {SPARQL Protocol for RDF},
- institution = {W3C},
- year = {2005},
- type = {Working Draft},
- note = {http://www.w3.org/TR/rdf-sparql-protocol/},
- abstract = {The RDF Query Language SPARQL expresses queries over RDF graphs. This
- document defines a protocol for communicating those queries to an
- RDF data service. This protocol is being developed by the W3C RDF
- Data Access Working Group (DAWG), part of the Semantic Web Activity
- as described in the activity statement .},
- owner = {Sauermann},
- url = {http://www.w3.org/TR/rdf-sparql-protocol/},
-}
-
-@ARTICLE{Abecker+98,
- author = {A. Abecker and A. Bernardi and K. Hinkelmann and O. K{\"u}hn and
- M. Sintek},
- title = {Toward a Technology for Organizational Memories},
- journal = {IEEE Intelligent Systems},
- year = {1998},
- volume = {13},
- pages = {40--48},
- number = {3},
-}
-
-@ARTICLE{AbeckerBernardiHinkelmann+98,
- author = {Abecker, Andreas and Bernardi, Ansgar and Hinkelmann, Knut and KĂźhn,
- Otto and Sintek, Michael},
- title = {Toward a {T}echnology for {O}rganizational {M}emories},
- journal = {I{EEE} {I}ntelligent {S}ystems},
- year = {1998},
- month = jun,
- keywords = {WM, Knowledge Management},
- language = {english},
- owner = {maus},
- page = {40--48},
- pdf = {project/KnowMore/AbeckerBernardiHinkelmann+98.pdf},
-}
-
-@INBOOK{AbeckerElstOntologienWM,
- chapter = {Ontologies for Knowledge Management},
- pages = {pp. 435-454, Springer.},
- title = {Handbook on Ontologies},
- publisher = {Springer},
- year = {2004},
- editor = {S. Staab and R. Studer},
- author = {Andreas Abecker and Ludger van Elst},
- owner = {Sauermann},
- pdf = {AbeckerElstOntologienWM.pdf},
-}
-
-@INPROCEEDINGS{P2PRefArch2005,
- author = {Karl Aberer and Luc Onana Alima and Ali Ghodsi and Sarunas Girdzijauskas
- and Seif Haridi and Manfred Hauswirth},
- title = {The essence of P2P: A reference architecture for overlay networks},
- booktitle = {Proc. of the Fifth IEEE International Conference on Peer-to-Peer
- Computing, "Use of Computers at the Edge of Networks (P2P, Grid,
- Clusters)"},
- year = {2005},
- month = {August 31 - September 2},
- note = {Konstanz, Germany},
- comment = {Empfohlen von Manfred Hauswirth wegen p2p Ăbersicht},
- owner = {sauermann},
- pdf = {P2P2005-RefArch.pdf},
- timestamp = {2006.02.25},
- url = {http://lsirpeople.epfl.ch/hauswirth/papers/P2P2005-RefArch.pdf},
-}
-
-@MISC{ACM1998,
- author = {ACM},
- title = {ACM Classes 1998 },
- howpublished = {\url{http://www.acm.org/class/}},
- owner = {Sauermann},
-}
-
-@INPROCEEDINGS{adali2005,
- author = { Sibel Adal? and Maria Luisa Sapino},
- title = { An activity based data model for desktop querying },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/24_adalisapino_activityquery_poster.pdf},
-}
-
-@INPROCEEDINGS{adar_haystack1999,
- author = {E. Adar and D. Karger and L. Stein},
- title = {Haystack: Per-User Information Environments},
- booktitle = {Proceedings of the 1999 Conference on Information and Knowledge Management,
- {CIKM}},
- year = {1999},
- abstract = {Traditional Information Retrieval (IR) systems are designed to provide
- uniform access to centralized corpora by large numbers of people.
- The Haystack project emphasizes the relationship between a particular
- individual and his corpus. An individual's own haystack priviliges
- information with which that user interacts, gathers data about those
- interactions, and uses this metadata to further personalize the
- retrieval process. This paper describes the prototype Haystack system.},
- keywords = {pim},
- owner = {sauermann},
- pdf = {adar_haystack1999.pdf},
- timestamp = {2007.01.21},
- url = {citeseer.ist.psu.edu/adar99haystack.html},
-}
-
-@MISC{brainfiler,
- author = {Brainbot AG},
- title = {the brainfiler text classification system},
- howpublished = {\url{http://www.brainbot.de}},
- owner = {Sauermann},
-}
-
-@PHDTHESIS{ahn2005phd,
- author = {Luis von Ahn},
- title = {Human Computation},
- school = {School of Computer Science, Carnegie Mellon University},
- year = {2005},
- month = {December},
- abstract = {Tasks like image recognition are trivial for humans, but continue
- to challenge even the most sophisticated computer programs. This
- thesis introduces a paradigm for utilizing human processing power
- to solve problems that computers cannot yet solve. Traditional approaches
- to solving such problems focus on improving software. I advocate
- a novel approach: constructively channel human brainpower using
- computer games. For example, the ESP Game, introduced in this thesis,
- is an enjoyable online game -- many people play over 40 hours a
- week -- and when people play, they help label images on the Web
- with descriptive keywords. These keywords can be used to significantly
- improve the accuracy of image search. People play the game not because
- they want to help, but because they enjoy it.
-
-
- I introduce three other examples of "games with a purpose": Peekaboom,
- which helps determine the location of objects in images, Phetch,
- which collects paragraph descriptions of arbitrary images to help
- accessibility of the Web, and Verbosity, which collects "common-sense"
- knowledge.
-
-
- In addition, I introduce CAPTCHAs, automated tests that humans can
- pass but computer programs cannot. CAPTCHAs take advantage of human
- processing power in order to differentiate humans from computers,an
- ability that has important applications in practice.
-
-
- The results of this thesis are currently in use by hundreds of Web
- sites and companies around the world, and some of the games presented
- here have been played by over 100,000 people. Practical applications
- of this work include improvements in problems such as: image search,
- adult-content filtering, spam, commonsense reasoning, computer vision,
- accessibility, and security in general.},
- comment = {Recommended by Mehdi Jazayeri on 28th Feb 2007 for evaluation of annotation
- tools.},
- editor = {Carnegie Mellon University Computer Science Department},
- key = {CMU-CS-05-193},
- keywords = {computation humans },
- url = {http://reports-archive.adm.cs.cmu.edu/anon/2005/abstracts/05-193.html},
-}
-
-@MISC{Fenfire,
- author = {Benja Fallenstein et al.},
- title = {the fenfire project},
- howpublished = {\url{http://fenfire.org/}},
- owner = {Sauermann},
-}
-
-@INPROCEEDINGS{aumueller2005,
- author = { David Aumueller},
- title = { Towards a Semantic Wiki Experience â Desktop Integration and Interactivity
- in WikSAR },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/22_aumueller_semanticwikiexperience_final.pdf},
-}
-
-@MISC{Avrilionis2004,
- author = {Denis Avrilionis and Roy Phillips },
- title = {An IT infrastructure for Knowledge Management in Agile Environments},
- year = {2004},
- note = {DarcEDGE Technologies â RDML SA 1, rue Guillaume Schneider L-2522
- Luxembourg denis@darcedge.com, roy@darcedge.com http://www.darcedge.com},
- owner = {Sauermann},
- pdf = {Avrilionis2004.pdf},
-}
-
-@TECHREPORT{EPOSGuidingExample,
- author = {Jan-Thies B\"ahr and {Ludger van} Elst and Andreas Lauer and Heiko
- Maus and Leo Sauermann and Sven Schwarz},
- title = {{{EPOS} -- {G}uiding {E}xample}},
- institution = {DFKI},
- year = {2004},
- type = {internal report},
- language = {english},
- owner = {maus},
- pdf = {project/epos/EPOS_GuidingExample.pdf},
-}
-
-@INPROCEEDINGS{bakshi2005,
- author = { Karun Bakshi and David R. Karger},
- title = { Personalized Semantic Web Application Development by End Users },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/36_bakshi_endusersemdesk_final.pdf},
-}
-
-@ARTICLE{Barreau1995,
- author = {Deborah Barreau and Bonnie A Nardi},
- title = {Finding and Reminding: File Organization from the Desktop},
- year = {1995},
- abstract = {This paper summarizes and synthesizes two independent studies of the
- ways users organize and find files on their computers. The first
- study (Barreau 1995) investigated information organization practices
- among users of DOS, Windows and OS/2. The second study (Nardi, Anderson
- and Erickson 1995), examined the finding and filing practices of
- Macintosh users. There were more similarities in the two studies
- than differences. Users in both studies (1) preferred location-based
- finding because of its crucial reminding function; (2) avoided elaborate
- filing schemes; (3) archived relatively little information; and
- (4) worked with three types of information: ephemeral, working and
- archived. A main difference between the study populations was that
- the Macintosh users used subdirectories to organize information
- and the DOS users did not.},
- owner = {Sauermann},
- url = {file:///C:/Dokumente%20und%20Einstellungen/sauermann/Eigene%20Dateien/_quellen/MaterialUnsortiert/Paper_FindingAndReminding_BarreauNardi/barreau.html},
-}
-
-@ARTICLE{Barreau1995a,
- author = {Deborah K. Barreau},
- title = {Context as a factor in personal information management systems},
- journal = {J. Am. Soc. Inf. Sci.},
- year = {1995},
- volume = {46},
- pages = {327--339},
- number = {5},
- address = {New York, NY, USA},
- doi = {http://dx.doi.org/10.1002/(SICI)1097-4571(199506)46:5<327::AID-ASI4>3.0.CO;2-C},
- issn = {0002-8231},
- publisher = {John Wiley \& Sons, Inc.},
-}
-
-@INPROCEEDINGS{BaumannDengel+02,
- author = {S. Baumann and A. Dengel and M. Junker and T. Kieninger},
- title = {Combining Ontologies and Document Retrieval Techniques},
- booktitle = {3rd International Workshop on Theory and Applications of Knowledge
- Management (TAKMA 2002)},
- year = {2002},
- address = {in conjunction with DEXA 2002, Aix-en-Provence, France},
- month = {September},
- pdf = {BaumannDengel+02.pdf},
-}
-
-@PHDTHESIS{Baumann2005,
- author = {Stephan Baumann},
- title = {Artifcial Listening Systems - Modellierung und Approximation der
- individuellen Perzeption von Musikähnlichkeit},
- school = {Vom Fachbereich Informatik der Technischen UniversitĂat Kaiserslautern},
- year = {2005},
- abstract = {Unter MusikĂahnlichkeit versteht man die von einem ZuhĂorer empfundene
- ĂAhnlich- keit zwischen zwei MusikstĂucken, die aufgrund der individuellen
- Perzeption und eines kognitiven Prozesses quasi im Kopf des hĂorenden
- Subjekts ermittelt wird. In diesem Kontext wurden in der vorliegenden
- Arbeit folgende Sachverhalte untersucht: ² die Auswahl geeigneter
- subsymbolischer und symbolischer Merkmale zur Re- prĂasentation
- von MusikstĂucken ² die Entwicklung eines hybriden ĂAhnlichkeitsmaÂźes
- zur Approximation des in- dividuellen ĂAhnlichkeitsempÂŻndens Die
- Auswahl der Merkmale stellt eine Selektion der unterschiedlichsten
- Aspekte er- lebter MusikĂahnlichkeit dar. Sie umfasst Aspekte der
- auditiven Wahrnehmung, das kognitive Begreifen von Liedtexten und
- letztendlich die gemeinschaftliche, kulturel- le Wahrnehmung von
- Musik. FĂur die abschlieÂźende, experimentelle Ausgestaltung eines
- auf dem vorgestellten Ansatz basierenden Musikempfehlungssystem,
- wurden insgesamt 785 MusikstĂucke von vierzig reprĂasentativen deutschen
- und englischen KĂunstlern herangezogen. Eine Evaluierung mit 10
- Probanden wurde durchgefĂuhrt und die Ergebnisse auf statistische
- Relevanz ĂuberprĂuft. Begleitend wurden qualita- tive Interviews
- hinsichtlich einer ersten Anwendertypologie ausgewertet.},
- owner = {Sauermann},
- pdf = {Baumann2005.pdf},
-}
-
-@MISC{Wedel2003,
- author = {Stephan Baumann and Oliver Hummel},
- title = {Using Cultural Metadata for Artist Recommendations},
- year = {2003},
- abstract = {Our approach to generate recommendations for similar artists follows
- a recent tradition of authors tackling the problem not with content-based
- audio analysis. Following this novel procedure we rely on the acquisition,
- filtering and condensing of unstructured text-based information
- that can be found in the web. The beauty of this approach lies in
- the possibility to access so-called cultural metadata that is the
- agglomeration of several independent - originally subjective - perspectives
- about music.},
- owner = {Sauermann},
- pdf = {Wedel2003.pdf},
-}
-
-@INPROCEEDINGS{Baumgartner+2005,
- author = {Robert Baumgartner and Nicola Henze and Marcus Herzog},
- title = {The Personal Publication Reader: Illustrating Web Data Extraction,
- Personalization and Reasoning for the Semantic Web},
- booktitle = {Proceedings of the European Semantic Web Conference ESWC 2005, Heraklion,
- Greece, 2005-06-01.},
- year = {2005},
- abstract = {This paper shows how Semantic Web technologies enable the design and
- implementation of advanced, personalized information systems. We
- demonstrate by means of an example application how personalized
- content syndication can be realized in the Semantic Web. Our approach
- consists of two main parts: The web data extraction part, providing
- the information system with real-time, dynamic data, and the personalization
- part, which deduces - with the aid of ontological domain knowledge
- - personalized views on the data. The prototype of the system has
- been realized using the Personal Reader Framework for designing,
- implementing, and maintaining Web content Readers.},
- owner = {Sauermann},
- pdf = {Baumgartner2005.pdf},
-}
-
-@ARTICLE{Beck1999,
- author = {Kent Beck},
- title = {Embracing Change with Extreme Programming},
- year = {1999},
- month = {October},
- comment = {0018-9162/99/$10.00},
- owner = {Sauermann},
- pdf = {C:\Dokumente und Einstellungen\Sauermann\Eigene Dateien\_quellen\EmbracingChangeWithExtremeProgramming.pdf},
-}
-
-@TECHREPORT{Beckett2003,
- author = {Dave Beckett and Jan Grant },
- title = {SWAD-Europe Deliverable 10.2: Mapping Semantic Web Data with RDBMSes},
- institution = {W3C},
- year = {2003},
- type = {Deliverable},
- owner = {Sauermann},
- pdf = {C:\Dokumente und Einstellungen\Sauermann\Eigene Dateien\_quellen\MaterialUnsortiert\RDF_RDBMS_Mapping\w3.org2001swEuropereportsscalable_rdbms_mapping_report.html},
- url = {http://www.w3.org/2001/sw/Europe/reports/scalable_rdbms_mapping_report/},
-}
-
-@PHDTHESIS{Bernardi2004,
- author = {Ansgar Bernardi},
- title = {Ein Wissensmanagementansatz fĂźr die UnterstĂźtzung der Instandhaltung
- komplexer Maschinen},
- school = {Fachbereich Informatik der Technischen Universität Kaiserslautern},
- year = {2004},
- owner = {Sauermann},
- pdf = {Bernardi2004.pdf},
- url = {http://www.dissertation.de/download/ab1151.pdf},
-}
-
-@MISC{RFC3986,
- author = {T. Berners-Lee and R. Fielding and L. Masinter},
- title = {RFC3986: Uniform Resource Identifier (URI): Generic Syntax},
- howpublished = {\url{http://www.ietf.org/rfc/rfc3986.txt}},
- month = {January},
- year = {2005},
- owner = {Sauermann},
- url = {http://www.ietf.org/rfc/rfc2396.txt},
-}
-
-@TECHREPORT{BernersLeeUri2005,
- author = {Tim Berners-Lee},
- title = {What HTTP URIs Identify},
- institution = {W3C},
- year = {2005},
- type = {Design Issue},
- month = {06},
- abstract = {HTTP URIs, in the web architecture, have been used to denote documents
- -- "web pages" inforally, or "information resources" more formally.
- However, with the growth of the Semantic Web, which uses URIs to
- denote anything at all, the urge to use and practice of using HTTP
- URIs for arbitrary things grew steadily. The W3C Technical Architectrue
- group eventually decided to resolve the architectural problem that
- if an HTTP response code of 200 (a successful retreival) was given,
- that indicated that the URI indeed was for an information resource,
- but with no such response, or with a different code, no such assumption
- could be made. This compromise resolved the issue, leaving a consistent
- architecture.},
- owner = {sauermann},
- timestamp = {2006.10.29},
- url = {http://www.w3.org/DesignIssues/HTTP-URI2.html},
-}
-
-@TECHREPORT{BernersLeeUri2002,
- author = {Tim Berners-Lee},
- title = {What do HTTP URIs Identify?},
- institution = {W3C},
- year = {2002},
- type = {Design Issue},
- month = {07},
- abstract = {This question has been addressed only vaguely in the specifications.
- However, the lack of very concise logical definition of such things
- had not been a problem, until the formal systems started to use
- them. There were no formal systems addressing this sort of issue
- (as far as I know, except for Dan Connolly's Larch work [@@]), until
- the Semantic Web introduced languages such as RDF which have well-defined
- logical properties and are used to describe (among other things)
- web operations.
-
-
- The efforts of the Technical Architecture Group to create an architecture
- document with common terms highlighted this problem. (It demonstrates
- the ambiguity of natural language that no significant problem had
- been noticed over the past decade, even though the original author
- or HTTP , and later co-author of HTTP 1.1 who also did his PhD thesis
- on an analysis of the web, and both of whom have worked with Web
- protocols ever since, had had conflicting ideas of what the various
- terms actually mean.)
-
-
- This document explains why the author find it difficult to work in
- the alternative proposed philosophies. If it misrepresents those
- others' arguments, then it fails, for which I apologize in advance
- and will endeavor to correct.},
- owner = {sauermann},
- timestamp = {2006.10.29},
- url = {http://www.w3.org/DesignIssues/HTTP-URI.html},
-}
-
-@TECHREPORT{Berners-Lee1998,
- author = {Tim Berners-Lee},
- title = {Cool URIs don't change},
- institution = {W3C},
- year = {1998},
- type = {Memo},
- note = {http://www.w3.org/Provider/Style/URI},
- owner = {sauermann},
- timestamp = {2006.10.30},
- url = {\url{http://www.w3.org/Provider/Style/URI}},
-}
-
-@TECHREPORT{Timbl1998,
- author = {Tim Berners-Lee},
- title = {Notation 3},
- institution = {W3C},
- year = {1998},
- type = {Design Issue},
- address = {http://www.w3.org/DesignIssues/Notation3.html},
- owner = {sauermann},
- timestamp = {2007.06.07},
- url = {http://www.w3.org/DesignIssues/Notation3.html},
-}
-
-@MISC{TimblFAQ,
- author = {Tim Berners-Lee},
- title = {Frequently asked questions by the Press},
- howpublished = {\url{http://www.w3.org/People/Berners-Lee/FAQ.html}},
- owner = {Sauermann},
-}
-
-@ARTICLE{Berners-Lee2001,
- author = {Tim Berners-Lee and James Hendler and Ora Lassila},
- title = {The Semantic Web},
- journal = {Scientific American},
- year = {2001},
- volume = {89},
- month = {May},
- doi = {http://www.sciam.com/print_version.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21},
- url = {file:///C:/Dokumente%20und%20Einstellungen/Sauermann/Eigene%20Dateien/_infobase/SemanticWeb_RDF/Scientific_American_Feature_Article_The_Semantic_Web_May_2001.htm},
-}
-
-@INPROCEEDINGS{Bizer+2006D2RServer,
- author = {Christian Bizer and Richard Cyganiak},
- title = {D2R-Server - Publishing Relational Databases on the Web as SPARQL-Endpoints},
- booktitle = {Proc. of the 15th International World Wide Web Conference (WWW2006)},
- year = {2006},
- abstract = {The Resource Description Framework and the SPARQL query language provide
- a standardized way for exposing and linking data sources on the
- Web. D2R Server is a turn-key solution for making the content of
- existing, non-RDF databases accessible as SPARQL endpoints. The
- server takes SPARQL queries from the Web and rewrites them via a
- mapping into SQL queries against a relational database. This on-the-fly
- translation allows RDF applications to access the content of large
- databases without having to replicate them into RDF. D2R Server
- can be used to integrate existing databases into RDF systems, and
- to add SPARQL interfaces to database-backed software products. In
- the talk, we will give an introduction into the D2RQ mapping language,
- which is used to define mappings between relational and RDF schemata,
- and demonstrate how D2R Server can be used to extend a WordPress
- blog with a SPARQL interface.},
- owner = {sauermann},
- timestamp = {2007.05.26},
-}
-
-@PHDTHESIS{Boardman2004,
- author = {Richard Boardman},
- title = {Improving Tool Support for Personal InformationManagement},
- school = {Department of Electrical and Electronic Engineering
-
- Imperial College London
-
- University of London},
- year = {2004},
- month = {July 13},
- abstract = {Personal InformationManagement (PIM) describes the acquisition, organization,
- and retrieval of information by an individual computer user. Studies
- have shown that many users struggle to manage the volume and diversity
- of information that they accumulate. Much design activity has been
- aimed at improving integration between different PIM tools, such
- as file and email managers. However, in terms of making a systematic
- contribution to HCI knowledge, much of this cross-tool design can
- be criticised for a lack of empirical grounding and evaluation.
-
- The research described in this thesis employs a user-centered design
- methodology to deepen understanding of PIM, and in particular to
- provide guidance for PIM-integration design. The research is grounded
- in an exploratory study of file, email and bookmark management,
- which is differentiated from previous studies by its cross-tool
- nature. The study offers several contributions including observations
- of participantsâ multiple organizing strategies â in both toolspecific
- and cross-tool contexts. Also, many participants had significant
- numbers of overlapping folders that appeared in multiple tool contexts.
- This finding informs the design of WorkspaceMirror, a novel PIM-integration
- prototype, which allows a user to mirror changes between their file,
- email and bookmark folders.
-
- The final stage of the research is a dual-purpose field study, aimed
- at (1) evaluatingWorkspaceMirror, and (2) investigating PIM behaviour
- over time. Participant feedback indicates that mirroring is more
- appropriate for top-level folders, and illuminates a trade-off between
- organizational consistency and organizational flexibility. The study
- also reveals the incremental nature of changes in organizing strategy,
- and highlights the supporting nature of PIM. These and other empirical
- findings are used to improve previous descriptive models of PIM
- behaviour. Furthermore, a number of design and methodological guidelines
- are developed. In particular, the author emphasizes the importance
- of assessing the strengths and weaknesses of PIM designs from both
- tool-specific and cross-tool perspectives.},
- comment = {Found by Man Luo!
-
-
- First supervisor: Prof. Bob Spence (Imperial College London)
-
- Second supervisor: Prof. Angela Sasse (University College London)
-
- A thesis submitted for the degree of
-
- Doctor of Philosophy of the University of London
-
- and for the
-
- Diploma ofMembership of the Imperial College},
- owner = {sauermann},
- pdf = {Boardman2004.pdf},
- timestamp = {2006.02.27},
-}
-
-@MISC{Booth2003,
- author = {David Booth},
- title = {Four Uses of a URL: Name, Concept, Web Location and Document Instance},
- howpublished = {Website},
- month = {Jan},
- year = {2003},
- note = {\url{http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm}},
- owner = {sauermann},
- timestamp = {2006.07.12},
-}
-
-@MISC{rdfs,
- author = {D. Brickley and R.V. Guha},
- title = {{RDF} Vocabulary Description Language 1.0: {RDF} Schema. {W3C} Recommendation},
- month = {10 February},
- year = {2004},
- howpublished = {\url{http://www.w3.org/TR/rdf-schema/}},
- owner = {Sauermann},
-}
-
-@ARTICLE{foaf_botmute,
- author = {Dan Brickley and Jo Walsh and Earle Martin and Simon Kent and Graphic
- Design by Liz Turner},
- title = {The Semantic Web - EXPLORE A NEARBY PARALLEL UNIVERSE WHERE INFORMATION
- EXCHANGE MAKES SENSE.},
- journal = {Mute 25},
- year = {May 2003},
- owner = {Sauermann},
- pdf = {foaf_botmute.pdf},
-}
-
-@INPROCEEDINGS{Sesame-ISWC2002,
- author = {Jeen Broekstra and Arjohn Kampman and Frank van Harmelen},
- title = {Sesame: A Generic Architecture for Storing and Querying RDF and RDF
- Schema},
- booktitle = {Proc. of the International Semantic Web Conference 2002},
- year = {2002},
- abstract = {Abstract. RDF and RDF Schema are two W3C standards aimed at enriching
- the Web with machine-processable semantic data. We have developed
- Sesame, an architecture for ecient storage and expressive querying
- of large quantities of metadata in RDF and RDF Schema. Sesame's
- design and implementation are independent from any speci c storage
- device. Thus, Sesame can be deployed on top of a variety of storage
- devices, such as relational databases, triple stores, or object-oriented
- databases, without having to change the query engine or other functional
- modules. Sesame o ers support for concurrency control, independent
- export of RDF and RDFS information and a query engine for RQL, a
- query language for RDF that o ers native support for RDF Schema
- semantics. We present an overview of Sesame as a generic architecture,
- as well as its implementation and our rst experiences with this
- implementation.},
- owner = {Sauermann},
- pdf = {Sesame-ISWC2002.pdf},
-}
-
-@ARTICLE{Bush1945,
- author = {Vannevar Bush},
- title = {As We May Think},
- journal = {The Atlantic Monthly},
- year = {1945},
- volume = {176(1) },
- pages = {p101-108},
- month = {July },
- owner = {Sauermann},
- url = {file:///C:/Dokumente%20und%20Einstellungen/sauermann/Eigene%20Dateien/_quellen/MaterialUnsortiert/Paper_Memex_Vannevar_Bush/bush.htm},
-}
-
-@ARTICLE{BĂśhm2005,
- author = {Karsten BÜhm and Wolf Engelbach and JÜrg Härtwig and Martin Wilcken
- and Martin Delp},
- title = {Modelling and Implementing Pre-built Information Spaces, Architecture
- and Methods for Process Oriented Knowledge Management},
- journal = {J. UCS, Special Issue on Business Process Oriented Knowledge Infrastructures},
- year = {2005},
- month = {April},
- owner = {Sauermann},
- pdf = {C:\Dokumente und Einstellungen\Sauermann\Eigene Dateien\_quellen\PREPRINT-VERSION-Modelling_and_implementing_PreBIS.pdf},
-}
-
-@INPROCEEDINGS{boehm2005,
- author = { Sebastian BĂśhm and Marko Luther and and Matthias Wagner},
- title = { Smarter Groups â Reasoning on Qualitative Information from Your
- Desktop },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/12_boehm_smartergroups-poster.pdf},
-}
-
-@INBOOK{likothanasis+2005,
- title = {A Multilayer Ontology Scheme for Integrated Searching in Distributed
- Hypermedia},
- publisher = {Springer},
- year = {2006},
- editor = {Sirmakessis, Spiros},
- author = {C. Alexakos, B. Vassiliadis, K. Votis and S. Likothanassis},
- volume = {Adaptive and Personalized Semantic Web},
- number = {14},
- series = {Studies in Computational Intelligence},
- comment = {2006, XI, 105 p. 26 illus., Hardcover},
- doi = {ISBN: 3-540-30605-6},
- owner = {sauermann},
- pdf = {likothanasis2005.pdf},
- timestamp = {2006.04.01},
-}
-
-@INPROCEEDINGS{bizer2004,
- author = {C. Bizer, A. Seaborne},
- title = {D2RQ-Treating Non-RDF Databases as Virtual RDF Graphs},
- booktitle = {Proceedings of the 3rd International Semantic Web Conference (ISWC2004)},
- year = {2004},
- owner = {Sauermann},
- pdf = {Bizer2004.pdf},
-}
-
-@INPROCEEDINGS{semex2005demo,
- author = {Yuhan Cai and Xin Luna Dong and Alon Halevy and Jing Michelle Liu
- and Jayant Madhavan},
- title = {Personal information management with SEMEX},
- booktitle = {SIGMOD '05: Proceedings of the 2005 ACM SIGMOD international conference
- on Management of data},
- year = {2005},
- pages = {921--923},
- address = {New York, NY, USA},
- publisher = {ACM Press},
- comment = {cited by SemDesk 17,25,32,33},
- doi = {http://doi.acm.org/10.1145/1066157.1066289},
- isbn = {1-59593-060-4},
- location = {Baltimore, Maryland},
- pdf = {semex2005demo.pdf},
-}
-
-@INPROCEEDINGS{NamedGraph2005,
- author = {Jeremy J. Carroll and Christian Bizer and Pat Hayes and Patrick Stickler},
- title = {Named graphs, provenance and trust},
- booktitle = {WWW '05: Proceedings of the 14th international conference on World
- Wide Web},
- year = {2005},
- pages = {613--622},
- address = {New York, NY, USA},
- publisher = {ACM Press},
- doi = {http://doi.acm.org/10.1145/1060745.1060835},
- isbn = {1-59593-046-9},
- location = {Chiba, Japan},
- pdf = {NamedGraph2005.pdf},
-}
-
-@INPROCEEDINGS{DELOSTIM2007,
- author = {T. Catarci and A. Dix and A. Katifori and G. Lepouras and A. Poggi},
- title = {Task-Centered Information Management},
- booktitle = {DELOS Conference 2007 on Working Notes},
- year = {2007},
- editor = {C. Thanos and F. Borri},
- pages = {253-263},
- address = {Tirrenia, Pisa},
- month = {13-14 February},
- owner = {sauermann},
- pdf = {DELOSTIM2007.pdf},
- timestamp = {2007.06.17},
-}
-
-@ARTICLE{Cayzer2004a,
- author = {Steve Cayzer},
- title = {Semantic blogging and decentralized knowledge management},
- journal = {Commun. ACM},
- year = {2004},
- volume = {47},
- pages = {47--52},
- number = {12},
- address = {New York, NY, USA},
- doi = {http://doi.acm.org/10.1145/1035134.1035164},
- issn = {0001-0782},
- publisher = {ACM Press},
-}
-
-@INPROCEEDINGS{cayzer2005,
- author = { Steve Cayzer and Paolo Castagna},
- title = { How to build a Snippet Manager },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/4_cayzer_snippetmanager-abstract.pdf},
-}
-
-@ARTICLE{Chao2001,
- author = {Dennis Chao},
- title = {Doom as an Interface for Process Management},
- journal = {Proceedings of the CHI2001 Conference on Human Factors in Computing
- Systems},
- year = {2001},
- owner = {Sauermann},
- pdf = {Chao2001.pdf},
-}
-
-@INPROCEEDINGS{HuajunChen+2006,
- author = {Huajun Chen and Yimin Wang and Heng Wang and Yuxin Mao and Jinmin
- Tang and Cunyin Zhou and Ainin Yin and Zhaohui Wu},
- title = {Towards a Semantic Web of Relational Databases: A Practical Semantic
- Toolkit and an In-Use Case from Traditional Chinese Medicine},
- booktitle = {The Semantic Web - ISWC 2006},
- year = {2006},
- editor = {Isabel Cruz and Stefan Decker and Dean Allemang and Chris Preist
- and Daniel Schwabe and Peter Mika and Mike Uschold and Lora Aroyo},
- volume = {4273},
- series = {LNCS},
- pages = {750--763},
- publisher = {Springer},
- isbn = {3-540-49029-9},
- pdf = {HuajunChen+2006.pdf},
-}
-
-@ARTICLE{ChenMagoulasMacredie2004,
- author = {S. Chen and G. Magoulas and R. Macredie},
- title = {Cognitive styles and usersrsquo responses to structured information
- representation},
- journal = { International Journal on Digital Libraries, Springer-Verlag Heidelberg},
- year = {2004},
- volume = {4},
- pages = {p93 - 107},
- number = {2},
- month = {October },
- doi = {10.1007/s00799-003-0073-5},
- owner = {Sauermann},
- pdf = {ChenMagoulasMacredie2004.pdf},
- url = {http://springerlink.metapress.com/openurl.asp?genre=article&issn=1432-5012&volume=4&issue=2&spage=93},
-}
-
-@INBOOK{Chernov+2007,
- chapter = {Building a Desktop Search Test-Bed},
- pages = {686-690},
- title = {Advances in Information Retrieval},
- publisher = {Springer},
- year = {2007},
- editor = {Volume 4425/2007},
- author = {Sergey Chernov and Pavel Serdyukov and Paul-Alexandru Chirita and
- Gianluca Demartini and Wolfgang Nejdl},
- abstract = {In the last years several top-quality papers utilized temporary Desktop
- data and/or browsing activity logs for experimental
-
- evaluation. Building a common testbed for the Personal Information
- Management community is thus becoming an indispensable
-
- task. In this paper we present a possible dataset design and discuss
- the means to create it.},
- doi = {10.1007/978-3-540-71496-5_69},
- owner = {sauermann},
- pdf = {Chernov+2007.pdf},
- timestamp = {2007.06.14},
- url = {http://www.springerlink.com/content/gh4066g271t9683x},
-}
-
-@INPROCEEDINGS{park2005,
- author = { Adam Cheyer and Jack Park and Richard Giuli},
- title = { IRIS: Integrate. Relate. Infer. Share. },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/17_park_iris_final.pdf},
-}
-
-@ARTICLE{DesktopSearch2004,
- author = {Paul - Alexandru Chirita and Rita Gavriloaie and Stefania Ghita and
- Wolfgang Nejdl and and Raluca Paiu},
- title = {Activity Based Metadata for Semantic Desktop Search},
- year = {2004},
- abstract = {With increasing storage capacities on current PCs, searching theWorld
- Wide Web has ironically become more efficient than searching oneâs
- own personal computer. The recently introduced desktop search engines
- are a first step towards coping with this problem, but not yet a
- satisfying solution. The reason for that is that desktop search
- is actually quite different from its web counterpart. Documents
- on the desktop are not linked to each other in a way comparable
- to the web, which means that result ranking is poor or even inexistent,
- because algorithms like PageRank cannot be used for desktop search.
- On the other hand, desktop search could potentially profit from
- a lot of implicit and explicit semantic information available in
- emails, folder hierarchies, browser cache contexts and others. This
- paper investigates how to extract and store these activity based
- context information explicitly as RDF metadata and how to use them
- as well as additional background information and ontologies to enhance
- desktop search.},
- comment = {L3S Research Center / University of Hanover Deutscher Pavillon, Expo
- Plaza 1 30539 Hanover, Germany {chirita,gavriloaie,ghita,nejdl,paiu}@l3s.de},
- owner = {Sauermann},
- pdf = {DesktopSearch2004.pdf},
- url = {http://www.l3s.de/~chirita/publications/chirita05activity.pdf},
-}
-
-@INPROCEEDINGS{chirita2005,
- author = { Paul - Alexandru Chirita and Stefania Ghita and Wolfgang Nejdl and
- and Raluca Paiu},
- title = { Semantically Enhanced Searching and Ranking on the Desktop },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/1_chirita_desktopsearch_final.pdf},
-}
-
-@INPROCEEDINGS{Chirita2005semantically,
- author = {Paul - Alexandru Chirita and Stefania Ghita and Wolfgang Nejdl and
- and Raluca Paiu},
- title = {Semantically Enhanced Searching and Ranking on the Desktop},
- booktitle = {ISWC},
- year = {2005},
- owner = {Sauermann},
- pdf = {Chirita2005semantically.pdf},
-}
-
-@INPROCEEDINGS{chirita04knowing,
- author = {Paul - Alexandru Chirita and Wolfgang Nejdl and Oana Scurtu},
- title = {Knowing Where to Search: Personalized Search Strategies for Peers
- in P2P Networks},
- booktitle = { P2P Information Retrieval Workshop},
- year = {2004},
- publisher = {27th ACM International SIGIR Conference, Sheffield, UK. },
- comment = {the complicated math. note the formulas. a student couldn't implement
- them},
- owner = {Sauermann},
- pdf = {chirita04knowing.pdf},
-}
-
-@ARTICLE{clark1996,
- author = {H. H. Clark},
- title = {Using Language},
- journal = {Cambridge University Press},
- year = {1996},
- comment = {Cambridge, UK},
- owner = {Sauermann},
-}
-
-@BOOK{Cooper+2003,
- title = {About Face 2.0 - The Essentials of Interaction Design},
- publisher = {Whiley publishing inc},
- year = {2003},
- author = {Alan Cooper and Robert Reimann},
- comment = {pointed to me by Dominik Heim},
- owner = {Sauermann},
-}
-
-@BOOK{CooperReimann2003,
- title = {About Face 2.0: The Essentials of Interaction Design},
- publisher = {Wiley Publishing, Inc.},
- year = {2003},
- author = {Alan Cooper and Robert M. Reimann},
- address = {Indianapolis, Indiana},
- abstract = {First published seven years ago-just before the World Wide Web exploded
- into dominance in the software world-About Face rapidly became a
- bestseller. While the ideasL and principles in the original book
- remain as relevant as ever, the examples in About Face 2.0 are updated
- to reflect the evolution of the Web.
-
-
- Interaction Design professionals are constantly seeking to ensure
- that software and software-enabled products are developed with the
- end-user's goals in mind, that is, to make them more powerful and
- enjoyable for people who use them. About Face 2.0 ensures that these
- objectives are met with the utmost ease and efficiency.
-
-
- Alan Cooper (Palo Alto, CA) has spent a decade making high-tech products
- easier to use and less expensive to build-a practice known as "Interaction
- Design." Cooper is now the leader in this growing field. Mr. Cooper
- is also the author of two bestselling books that are widely considered
- indispensable texts. About Face: The Essentials of User Interface
- Design, intro-duced the first comprehensive set of practical design
- principles. The Inmates Are Running the Asylum explains how talented
- people and companies continually create aggravating high-tech products
- that fail to meet customer expectations.},
-}
-
-@ARTICLE{Cope2004,
- author = {Aaron Straup Cope},
- title = {That's Quite a Mouthful-Design Issues and Technical Challenges Making
- the Eatdrinkfeelgood Markup Languge RDF-Friendly},
- year = {2004},
- note = {http://www.eatdrinkfeelgood.org/},
- owner = {Sauermann},
- pdf = {eatdrinkfeelgood2004.pdf},
-}
-
-@BOOK{Algorithms2001,
- title = {Introduction to Algorithms},
- publisher = {MIT Press and McGraw-Hill},
- year = {2001},
- author = {Thomas H. Cormen and Charles E. Leiserson and Ronald L. Rivest and
- Clifford Stein},
- edition = {Second Edition},
- doi = {ISBN 0262032937},
- owner = {sauermann},
- timestamp = {2006.07.19},
-}
-
-@MISC{rdfgateway-product,
- author = {Intellidimension Corp.},
- title = {RDF Gateway Semantic Web Server },
- howpublished = {\url{http://www.intellidimension.com/}},
- owner = {Sauermann},
-}
-
-@MISC{informatinbridgefm,
- author = {Microsoft Corp.},
- title = {Information Bridge Framework},
- howpublished = {\url{http://msdn.microsoft.com/office/understanding/ibframework/default.aspx}},
- owner = {Sauermann},
-}
-
-@INPROCEEDINGS{croke2005,
- author = { Pat Croke and Ann Johnston and Kim Tighe},
- title = { Using Named Entities as a basis to share associative trails between
- Semantic Desktops },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/19_croke_jack_final.pdf},
-}
-
-@INPROCEEDINGS{Cuel+2003,
- author = {R. Cuel and M. Bonifacio and M. Grosselle},
- title = {Knowledge Nodes: the Reification of Organizational Communities. A
- Case Study},
- booktitle = {I-Know 3rd International Conference on Knowledge Management},
- year = {2003},
- pages = {p 40-45},
- publisher = {JUCS},
- owner = {Sauermann},
-}
-
-@INPROCEEDINGS{Gate2002,
- author = {Hamish Cunningham and Diana Maynard and Kalina Bontcheva and Valentin
- Tablan},
- title = {GATE: A framework and graphical development environment for robust
- NLP tools and applications},
- booktitle = {Proceedings of the 40th Anniversary Meeting of the Association for
- Computational Linguistics},
- year = {2002},
-}
-
-@TECHREPORT{Cyganiak_algebraSPARQL2005,
- author = {Richard Cyganiak},
- title = {A relational algebra for SPARQL},
- institution = {HP Labs, Bristol, UK},
- year = {2005},
- owner = {Sauermann},
- pdf = {Cyganiak_algebraSPARQL2005.pdf},
-}
-
-@TECHREPORT{Cyganiak_dbSPARQL2005,
- author = {Richard Cyganiak},
- title = {Note on database layouts for SPARQL datastores},
- institution = {HP Labs, Bristol, UK},
- year = {2005},
- owner = {Sauermann},
- pdf = {Cyganiak_dbSPARQL2005.pdf},
-}
-
-@MISC{ontoshare2003,
- author = {John Davies and Alistair Duke and York Sure},
- title = {OntoShare â An Ontology-based Knowledge Sharing System for Virtual
- Communities of Practice},
- url = {citeseer.ist.psu.edu/576217.html},
-}
-
-@TECHREPORT{SemWave2006,
- author = {Mills Davis},
- title = {Semantic Wave 2006 - Part-1: Executive Guide to Billion Dollar Markets},
- institution = {Project10X},
- year = {2006},
- comment = {popular science, business},
- owner = {sauermann},
- pdf = {SemWave2006.pdf},
- timestamp = {2006.07.24},
-}
-
-@MISC{RFC2445,
- author = {F. Dawson and D. Stenerson},
- title = {RFC 2445: Internet Calendaring and Scheduling Core Object Specification
- (iCalendar)},
- month = {November},
- year = {1998},
- owner = {Sauermann},
- url = {http://www.ietf.org/rfc/rfc2445.txt},
-}
-
-@INPROCEEDINGS{Decker+2004,
- author = {Stefan Decker and Martin Frank},
- title = {The Social Semantic Desktop},
- booktitle = {Proc. of the WWW2004 Workshop Application Design, Development and
- Implementation Issues in the Semantic Web},
- year = {2004},
- owner = {Sauermann},
- pdf = {Decker+2004.pdf},
- url = {http://www.deri.at/publications/techpapers/documents/DERI-TR-2004-05-02.pdf},
-}
-
-@MISC{EPOS-Proposal,
- author = {Andreas Dengel and Andreas Abecker and Jan-Thies B\"ahr and Ansgar
- Bernardi and Peter Dannenmann and {Ludger van} Elst and Stefan Klink
- and Heiko Maus and Sven Schwarz and Michael Sintek},
- title = {E{POS} -- {E}volving {P}ersonal to {O}rganizational {K}nowledge {S}paces},
- year = {2002},
- institution = {DFKI GmbH Kaiserslautern},
- language = {english},
- owner = {maus},
- pdf = {project/EPOS/proposal/epos-proposal.pdf},
- type = {Project Proposal},
-}
-
-@INPROCEEDINGS{Dengel+1996a,
- author = {Andreas Dengel and Knut Hinkelmann},
- title = {The SPECIALIST BOARD. A Technology Workbench for Document Analysis
- and Understanding},
- booktitle = {Proceedings of the 2nd World Conference on Integrated Design \& Process
- Technology (IDPT96), Austin Texas},
- year = {1996},
- month = {December},
- abstract = {Document analysis and understanding (DAU) desig-
-
- nates the task of transforming data from printed media into
-
- a symbolic form allowing a further processing by electronic means.
- In order to be able to solve different DAU
-
- problems, we have developed the so-called Specialist Board
-
- as a technology workbench for the recognition, categorization and
- structured representation of documents. The model
-
- provides a collection of software specialists for the various
-
- DAU subtasks and is basically used for rapid prototyping.
-
- In this paper we will show how these specialists can be
-
- successfully organized and combined for solving different
-
- problems. Furthermore, we will introduce the fundamental
-
- principles of the model and discuss the various specialists
-
- of the workbench.},
- owner = {sauermann},
- pdf = {Dengel+1996a.pdf},
- timestamp = {2006.11.27},
-}
-
-@INPROCEEDINGS{Dengel2006,
- author = {Andreas R. Dengel},
- title = {Six Thousand Words about Multi-Perspective Personal Document Management},
- booktitle = {Proc. EDM IEEE Workshop},
- year = {2006},
- month = {Oct},
- organization = {IEEE},
- owner = {sauermann},
- pdf = {Dengel2006.pdf},
- timestamp = {2006.08.16},
-}
-
-@INPROCEEDINGS{OntoPIM2005,
- author = {Alan Dix and Tiziana Catarci and Benjamin Habegger and Yannis loannidis
- and Azrina Kamaruddin and Akrivi Katifori and Giorgos Lepouras and
- Antonella Poggi and Devina Ramduny-Ellis},
- title = {Intelligent context-sensitive interactions on desktop and the web},
- booktitle = {AVI '06: Proceedings of the international workshop in conjunciton
- with AVI 2006 on Context in advanced interfaces},
- year = {2006},
- pages = {23--27},
- address = {New York, NY, USA},
- publisher = {ACM Press},
- doi = {http://doi.acm.org/10.1145/1145706.1145710},
- location = {Venice, Italy},
- owner = {sauermann},
- pdf = {OntoPIM2005.pdf},
- timestamp = {2006.07.25},
-}
-
-@MASTERSTHESIS{Djaloeis2005,
- author = {Bima-Raymond Djaloeis},
- title = {Kaukolu: Building a Semantic Wiki},
- school = {Technische Universität Kaiserslautern},
- year = {2005},
- owner = {Sauermann},
- pdf = {Djaloeis2005.pdf},
-}
-
-@INPROCEEDINGS{Dong+2005,
- author = {Xin Dong and Alon Y. Halevy},
- title = {Malleable Schemas: A Preliminary Report.},
- booktitle = {WebDB},
- year = {2005},
- pages = {139-144},
- comment = {Used by Julien Gaugaz in PIMO things.},
- description = {dblp},
- ee = {http://webdb2005.uhasselt.be/webdb05_eproceedings.pdf},
- keywords = {nepomuk},
- pdf = {Dong+2005.pdf},
- url = {http://dblp.uni-trier.de/db/conf/webdb/webdb2005.html#DongH05},
-}
-
-@INPROCEEDINGS{DongH2005,
- author = {Xin Dong and Alon Y. Halevy},
- title = {A Platform for Personal Information Management and Integration.},
- booktitle = {Proc. of the CIDR Conference},
- year = {2005},
- pages = {119-130},
- abstract = {The explosion of the amount of information available
-
- in digital form has made search a hot research
-
- topic for the Information Management Community.
-
- While most of the research on search is focussed on
-
- the WWW, individual computer users have developed
-
- their own vast collections of data on their desktops,
-
- and these collections are in critical need for good
-
- search tools.
-
- We describe the Semex System that offers users
-
- a flexible platform for personal information management.
-
- Semex has two main goals. The first goal is to
-
- enable browsing personal information by semantically
-
- meaningful associations. The challenge it to automatically
-
- create such associations between data items on
-
- one's desktop, and to create enough of them so Se-
-
- mex becomes an indispensable tool. Our second goal
-
- is to leverage the personal information space we created
-
- to increase users' productivity. As our first target,
-
- Semex leverages the personal information to enable
-
- lightweight information integration tasks that are
-
- discouragingly diffcult to perform with today's tools.},
- pdf = {DongH2005.pdf},
- url = {http://www-db.cs.wisc.edu/cidr/cidr2005/papers/P10.pdf},
-}
-
-@INPROCEEDINGS{Dubinko+2006,
- author = {Micah Dubinko and Ravi Kumar and Joseph Magnani and Jasmine Novak
- and Prabhakar Raghavan and Andrew Tomkins},
- title = {Visualizing tags over time},
- booktitle = {WWW '06: Proceedings of the 15th international conference on World
- Wide Web},
- year = {2006},
- pages = {193--202},
- address = {New York, NY, USA},
- publisher = {ACM Press},
- doi = {http://doi.acm.org/10.1145/1135777.1135810},
- isbn = {1-59593-323-9},
- location = {Edinburgh, Scotland},
- pdf = {Dubinko+2006.pdf},
-}
-
-@INPROCEEDINGS{diaz2005,
- author = { Oscar DĂaz and Jon Iturrioz and Sergio F. Anzuola},
- title = { Authoring and annotation of desktop files in seMouse },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/8_diaz_semouse_poster.pdf},
-}
-
-@INPROCEEDINGS{Ehrig+2005,
- author = {Marc Ehrig and Steffen Staab and York Sure},
- title = {Bootstrapping Ontology Alignment Methods with APFEL},
- booktitle = {Proceedings of the 4th International Semantic Web Conference ISWC2005},
- year = {2005},
- volume = {LNCS 3729},
- pages = {p. 186 ff.},
- publisher = {Springer},
- comment = {saw the presentation at 9th november, ISWC, nice paper, have to cite
- this.},
- owner = {Sauermann},
- pdf = {Ehrig+2005.pdf},
-}
-
-@INPROCEEDINGS{Einsfeld2006:IV,
- author = {Katja Einsfeld and Stefan Agne and Matthias Deller and Achim Ebert
- and Bertin Klein and Christian Reuschling},
- title = {Dynamic Visualization and Navigation of Semantic Virtual Environments},
- booktitle = {Proceedings of the 10th International Conference on Information Visualization
- (IV 2006)},
- year = {2006},
- editor = {Ebad Banissi and Remo Aslak Burkhard and Anna Ursyn and Jian J. Zhang
- and Mark Bannatyne and Carsten Maple and Andrew J. Cowell and Gui
- Yun Tian and Ming Hou},
- pages = {569--574},
- address = {London, United Kingdom},
- month = {5-7 July},
- publisher = {IEEE Computer Society},
- annote = {ISBN 0-7695-2602-0},
- comment = {@Visor},
-}
-
-@INPROCEEDINGS{einsfeld2005,
- author = { Katja Einsfeld and Achim Ebert and Stefan Agne and and Bertin Klein},
- title = { DocuWorld â A 3D User Interface to the Semantic Desktop },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/15_einsfeld_docuworld_final.pdf},
-}
-
-@INPROCEEDINGS{ElstAbecker+04,
- author = {Elst, Ludger van and Abecker, Andreas and Bernardi, Ansgar and Lauer,
- Andreas and Maus, Heiko and Schwarz, Sven},
- title = {An Agent-based Framework for Distributed Organizational Memories},
- booktitle = {Coordination and Agent Technology in Value Networks, Multikonferenz
- Wirtschaftsinformatik (MKWI-2004), 9.-11.3.2004, Essen},
- year = {2004},
- editor = {M. Bichler and C. Holtmann and S. Kirn and J. P. MĂźller and C. Weinhardt},
- pages = {181--196},
- publisher = {GITO-Verlag, Berlin},
- keyword = {H4,I2017,I2018,I204,I2064,I4},
- owner = {maus},
- pdf = {ElstAbecker+04.pdf},
- url = {http://www.dfki.uni-kl.de/~elst/papers/frodo_mkwi2004.pdf},
-}
-
-@INPROCEEDINGS{ElstKiesel2004,
- author = {Ludger van Elst and Malte Kiesel},
- title = {Generating and Integrating Evidence for Ontology Mappings},
- booktitle = {Engineering Knowledge in the Age of the Semantic Web: Proceedings
- of the 14th International Conference, EKAW 2004},
- year = {2004},
- volume = {3257},
- series = {LNAI},
- pages = {15--29},
- address = {Heidelberg},
- publisher = {Springer},
- authorurls = {http://www.dfki.uni-kl.de/~elst/ and },
- keywords = {Ontologies, Ontology Mapping},
- url = {http://www.dfki.uni-kl.de/~elst/papers/ekaw04_LvE_MK_final.pdf},
-}
-
-@ARTICLE{CEndres_09,
- author = {Christoph Endres and Andreas Butz and Asa MacWilliams},
- title = {A Survey of Software Infrastructures and Frameworks for Ubiquitous
- Computing},
- journal = {Mobile Information Systems Journal},
- year = {2005},
- volume = {1},
- number = {1},
- month = {January--March},
- note = {To appear.},
- keywords = {augmented reality, studierstube, fluidum, dfki},
- pdf = {CEndres_09.pdf},
- url = {http://www.dfki.de/~endres/},
-}
-
-@TECHREPORT{oaei2005,
- author = {JĂŠrĂ´me Euzenat and Heiner Stuckenschmidt and Mikalai Yatskevich},
- title = {Introduction to the Ontology Alignment Evaluation 2005},
- institution = {http://oaei.ontologymatching.org/2005/results/},
- year = {2005},
- owner = {sauermann},
- pdf = {oaei2005.pdf},
- timestamp = {2006.06.14},
-}
-
-@TECHREPORT{RDFPrimer,
- author = {F. Manola, E. Miller, Editors},
- title = {RDF Primer},
- institution = {W3C},
- year = {2004},
- type = {W3C Recommendation, 2004},
- address = {http://www.w3.org/TR/2004/REC-rdf-primer-20040210/},
- month = {10 February},
- owner = {sauermann},
- timestamp = {2006.04.02},
- url = {http://www.w3.org/TR/rdf-primer/},
-}
-
-@CONFERENCE{Henze+2005,
- author = {Fabian Abel, Robert Baumgartner, Adrian Brooks, Christian Enzi, Georg
- Gottlob, Nicola Henze, Marcus Herzog, Matthias Kriesell, Wolfgang
- Nejdl, Kai Tomaschewski:},
- title = {The Personal Publication Reader.},
- booktitle = {Semantic Web Challenge, 4th International Semantic Web Conference,
- November 6-10 2005, Galway, Ireland.},
- year = {2005},
- comment = {sumbission for the semweb challenge},
- owner = {sauermann},
- pdf = {Henze+2005.pdf},
- timestamp = {2006.04.01},
-}
-
-@ARTICLE{FeatherS2003,
- author = {John Feather and Paul Sturges},
- title = {International encyclopedia of information and library science.},
- journal = {Inf. Res.},
- year = {2003},
- volume = {8},
- number = {3},
- bibsource = {DBLP, http://dblp.uni-trier.de},
- ee = {http://informationr.net/ir/reviews/revs107.html},
-}
-
-@BOOK{fensel-ontologies,
- title = {Ontologies: Silver Bullet for Knowledge Management and Electronic
- Commerce},
- publisher = {Springer Verlag},
- year = {2001},
- author = {D. Fensel},
- text = {D. Fensel. Ontologies: Silver Bullet for Knowledge Management and
- Electronic Commerce. Springer-Verlag, to appear.},
- url = {citeseer.ist.psu.edu/413498.html},
-}
-
-@INPROCEEDINGS{FernandezGarcia+2006,
- author = {Norberto Fernandez-Garcia and Leo Sauermann and Luis Sanchez and
- Ansgar Bernardi},
- title = {PIMO Population and Semantic Annotation for the Gnowsis Semantic
- Desktop},
- booktitle = {Proceedings of the Semantic Desktop and Social Semantic Collaboration
- Workshop at the ISWC},
- year = {2006},
- volume = {202},
- series = {CEUR-WS},
- abstract = {The Semantic Desktop brings the ideas and the technologies of the
- Semantic Web into the personal computer desktop. As a prerequisite
- for applying Semantic Web technologies to a certian domain of knowledge
- an ontological model of the domain is required. In the Gnowsis Semantic
- Desktop, the PIMO (Personal Information Model Ontology) addresses
- this problem by providing a generic lightweight ontology whose classes
- model the mian concepts involved in the daily activities of a person:
- places, organizations, persons, etc. But in order to be fully useful
- for a certain user, this generic model needs to be personalized
- and populated, adding more classes and concrete instances of the
- existent classes. As the process of manual population could be tedious
- and time consuming, in this paper we propose an alternative which
- tries to exploit the information that the user provides while performing
- Web searches. Apart from populating the PIMO, our approach is useful
- in resource annotation.},
- owner = {sauermann},
- pdf = {FernandezGarcia+2006.pdf},
- timestamp = {2006.12.21},
- url = {http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-202/SEMDESK2006_0008.pdf},
-}
-
-@INPROCEEDINGS{franz2005,
- author = { Thomas Franz and Steffen Staab},
- title = { SAM: Semantics Aware Instant Messaging for the Networked Semantic
- Desktop },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/11_franzstaab_sam_final.pdf},
-}
-
-@ARTICLE{FreemanGelernter96,
- author = {Eric Freeman and David Gelernter},
- title = {Lifestreams: A storage model for personal data},
- journal = {SIGMOD Record (ACM Special Interest Group on Management of Data)},
- year = {1996},
- volume = {25},
- pages = {pp80},
- number = {1},
- owner = {Sauermann},
- pdf = {FreemanGelernter96.pdf},
-}
-
-@BOOK{Gamma+1995,
- title = {Design Patterns},
- publisher = {Addison-Wesley},
- year = {1995},
- author = {Erich Gamma and Richard Helm and Ralph Johnson and John Vlissides},
- doi = {ISBN 0201633612},
- owner = {Sauermann},
-}
-
-@MASTERSTHESIS{Geldart2005,
- author = {Joe Geldart},
- title = {RDF without Revolution An Analysis and Test of RDF and Ontology },
- school = {Department of Computer Science, University of Durham},
- year = {2005},
- type = {Bachelor Thesis},
- month = {April},
- abstract = {This dissertation describes the design and development of the Frege
- shared information system. This system builds upon the work of semantic
- desktop systems such as Gnowsis and Haystack, exploring the ways
- that ontological information may be integrated into an existing
- desktop environment. The major contribution of this work is the
- introduction of the idea of âreflectionsâ between information models
- as a formal basis for integrating a shared information system with
- existing applications. The success of this work is intended to be
- judged by its ease of use for developers, the completeness of the
- model reflection and its efficiency. According to these criteria
- the design implemented may be judged a partial success, achieving
- an easy-to-use reflection which is practically too slow to use in
- general purpose systems. The work does, however, suggest means to
- improve this in future systems in order to bring about a fully-integrated,
- evolutionary semantic desktop system.},
- comment = {Friend of Michael Zeltner. Semantic Desktop Stuff.},
- owner = {Sauermann},
- pdf = {Geldart2005.pdf},
- url = {http://www.dur.ac.uk/j.r.c.geldart/projects/frege/docs/report.pdf},
-}
-
-@INPROCEEDINGS{Gemmell+2002,
- author = {Jim Gemmell and Gordon Bell and Roger Lueder and Steven Drucker and
- Curtis Wong},
- title = {MyLifeBits: Fulfilling the Memex Vision},
- booktitle = {ACM Multimedia December 1-6, Juan-les-Pins, France},
- year = {2002},
- pages = {pp. 235-238},
- owner = {Sauermann},
- pdf = {Gemmell+2002.pdf},
-}
-
-@INPROCEEDINGS{ghita2005,
- author = { Stefania Ghita and Nicola Henze and Wolfgang Nejdl},
- title = { Task Specific Semantic Views: Extracting and Integrating Contextual
- Metadata from the Web },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/3_ghita_semanticviews_final.pdf},
-}
-
-@INPROCEEDINGS{Ghita2005,
- author = {Stefania Ghita and Wolfgang Nejdl and Raluca Paiu},
- title = {Semantically Rich Recommendations in Social Networks for Sharing,
- Exchanging and Ranking Semantic Context},
- booktitle = {2005},
- year = {ISWC},
- owner = {Sauermann},
- pdf = {Ghita2005.pdf},
-}
-
-@INPROCEEDINGS{Gievska2004,
- author = {Sonja Gievska},
- title = {COMPUTER-MEDIATED COORDINATION OF INTERRUPTION},
- booktitle = {Proceedings of the Eighth IASTED International Conference},
- year = {2004},
- month = {9},
- owner = {Sauermann},
- pdf = {Gievska2004.pdf},
-}
-
-@INPROCEEDINGS{Golbeck+2002,
- author = {Jennifer Golbeck and Michael Grove and Bijan Parsia and Adtiya Kalyanpur
- and James A. Hendler},
- title = {New Tools for the Semantic Web},
- booktitle = {EKAW '02: Proceedings of the 13th International Conference on Knowledge
- Engineering and Knowledge Management. Ontologies and the Semantic
- Web},
- year = {2002},
- pages = {392--400},
- address = {London, UK},
- publisher = {Springer-Verlag},
- isbn = {3-540-44268-5},
- pdf = {Golbeck+2002.pdf},
-}
-
-@MISC{UserProfileOntologyVersion1,
- author = {M. Golemati and A. Katifori and C. Vassilakis and G. Lepouras and
- C. Halatsis},
- title = {User Profile Ontology version 1},
- howpublished = {\url{http://oceanis.mm.di.uoa.gr/pened/?category=publications}},
- year = {2006},
- owner = {sauermann},
- timestamp = {2007.06.17},
-}
-
-@INPROCEEDINGS{robles+2004community,
- author = {JesĂşs M. GonzĂĄlez-Barahona and Luis LĂłpez and Gregorio Robles},
- title = {Community structure of modules in the Apache project },
- booktitle = {Proceedings of the 4th Workshop on Open Source Software Engineering.
- 26th International Conference on Software Engineering (Edinburgh,
- Scotland)},
- year = {2004},
- month = {May 25th},
- abstract = {The relationships among modules in a software project of a certain
- size can give us much information about its internal organization
- and a way to control and monitor development activities and evolution
- of large libre software projects. In this paper, we show how information
- available in CVS repositories can be used to study the structure
- of the modules in a project when they are related by the people
- working in them, and how techniques taken from the social networks
- fields can be used to highlight the characteristics of that structure.
- As a case example, we also show some results of applying this methodology
- to the Apache project in several points in time. Among other facts,
- it is shown how the project evolves and is self-structuring, with
- developer communities of modules corresponding to semantically related
- families of modules.},
- owner = {Sauermann},
- pdf = {robles+2004community.pdf},
- url = {http://libresoft.dat.escet.urjc.es/html/downloads/woss-icse-2004.pdf},
-}
-
-@INPROCEEDINGS{Grimnes+2006,
- author = {Gunnar AAstrand Grimnes and Sven Schwarz and Leo Sauermann},
- title = {{RDFHomepage or Finally, a use for your FOAF file }},
- booktitle = {Proceedings of Semantic Web Scripting Workshop at ESWC06},
- year = {2006},
- abstract = {This paper presents the RDFHomepage project, a framework
-
- for using a personâs structured data sources to auto-generate an
-
- HTML homepage. RDFHomepage uses RDF files as input, and currently
-
- supports several well-known RDF schemas, such as FOAF. In addition
-
- to these we have RDF converters for other structured file-formats,
- like
-
- Bibtex. RDFHomepage produces valid HTML 4.01 Transitional pages,
-
- and makes it easy to roll-out functional homepages for a group of
- people.
-
- The generated HTML code is very general, allowing quick and easy
-
- page-redesigning using CSS. RDFHomepage is written in PHP and uses
-
- our system for generating PHP classes based on RDF class definitions,
-
- enabling quick and easy development of RDF handling PHP code.},
- date-added = {2006-05-02 12:14:04 +0200},
- date-modified = {2006-05-02 14:18:14 +0200},
- url = {http://www.dfki.uni-kl.de/\~grimnes/papers/rdfhomepage.pdf},
-}
-
-@INBOOK{GuarinoWelty2004,
- chapter = {An Overview of OntoClean},
- pages = {151-159},
- title = {Handbook on Ontologies},
- publisher = {Springer Verlag},
- year = {2004},
- editor = {S. Staab and R. Studer},
- author = {Guarino, N. and Welty, C},
- abstract = {OntoClean is a methodology for validating the ontological adequacy
- of taxonomic relationships. It is based on highly general ontological
- notions drawn from philosophy, like essence, identity, and unity,
- which are used to characterize relevant aspects of the intended
- meaning of the properties, classes, and relations that make up an
- ontology. These aspects are represented by formal metaproperties,
- which impose several constraints on the taxonomic structure of an
- ontology. The analysis of these constraints helps in evaluating
- and validating the choices made. In this chapter we present an informal
- overview of the philosophical notions in-volved and their role in
- OntoClean, review some common ontological pitfalls, and walk through
- the example that has appeared in pieces in previous papers and has
- been the basis of numerous tutorials and talks.},
- comment = {referenced in nepomuk wiki as good method},
- owner = {sauermann},
- pdf = {GuarinoWelty2004.pdf},
- timestamp = {2006.02.14},
-}
-
-@INPROCEEDINGS{Guha2004,
- author = {R. Guha},
- title = {Semantic Negotiation: Co-Identifying Objects across Data Sources},
- booktitle = {Semantic Web Services: Papers from the 2004 Spring Symposium},
- year = {2004},
- editor = {Terry Payne},
- organization = {American Association for Artificial Intelligence, Menlo Park, California.},
- publisher = {Technical Report SS-04-06.},
- owner = {sauermann},
- pdf = {Guha2004.pdf},
- timestamp = {2006.10.10},
- url = {http://www.aaai.org/Library/Symposia/Spring/ss04-06.php},
-}
-
-@ARTICLE{Halevy2000answering,
- author = {Alon Y. Halevy},
- title = {Answering queries using views: {A} survey},
- journal = {VLDB Journal: Very Large Data Bases},
- year = {2001},
- volume = {10},
- pages = {270--294},
- number = {4},
- pdf = {Halevy2000answering.pdf},
- url = {citeseer.ist.psu.edu/halevy00answering.html},
-}
-
-@INPROCEEDINGS{harris-ssws2005,
- author = {Stephen Harris},
- title = {SPARQL query processing with conventional relational database systems},
- booktitle = {International Workshop on Scalable Semantic Web Knowledge Base System
- (SSWS 2005).},
- year = {2005},
- abstract = {This paper describes an evolution of the 3store RDF storage system,
- extended to provide a SPARQL query interface and informed by lessons
- learned in the area of scalable RDF storage.},
- owner = {Sauermann},
- pdf = {harris-ssws2005.pdf},
-}
-
-@ARTICLE{SECO2004,
- author = {A. Harth},
- title = {SECO: mediation services for semantic Web data},
- journal = {Intelligent Systems, IEEE},
- year = {2004},
- volume = {Volume 19},
- pages = {66 - 71},
- number = {Issue 3},
- month = {May-June},
- abstract = {SECO (semantic collaboration), an infrastructure that lets agents
- uniformly access data that is potentially scattered across the Web
- is described. The SECO system provides mediation services that aggregate,
- integrate, and display RDF data obtained from the semantic Web.
- Using a crawler, SECO collects the RDF data available in files and
- uses RDF repositories as data sources. SECO applies semantic Web
- technologies to RDF data by combining techniques from information
- retrieval and semistructured databases.},
- owner = {Sauermann},
-}
-
-@MISC{Harth+2005a,
- author = {Andreas Harth and Stefan Decker},
- title = {Yet Another RDF Store: Perfect Index Structures for Storing Semantic
- Web Data With Contexts},
- howpublished = {http://sw.deri.org/2004/06/yars/doc/summary last change Jan 2005,
- visit Aug 2005},
- year = {2005},
- owner = {Sauermann},
-}
-
-@TECHREPORT{HawkeUri2003,
- author = {Sandro Hawke},
- title = {Disambiguating RDF Identifiers},
- institution = {W3C},
- year = {2003},
- type = {a completely-unofficial note},
- month = {1},
- abstract = {To date, RDF has not been clear about whether a URI like "http://www.w3.org/Consortium"
- identifies the W3C or a web page about the W3C. Throughout RDF,
- strings like "http://www.w3.org/1999/02/22-rdf-syntax-ns#type" are
- used with no consistent explanation of how they relate to the web.
- This is an old issue, and people are tired of it, but the issue
- continues to complicate the lives of RDF users. As more people author
- RDF information, it becomes more important for everyone to have
- a consistent idea of how RDF identifiers relate to the real things
- which people are using RDF to talk about.
-
-
- I propose we officially recognize this ambiguity. I also propose a
- way to settle it which is compatible with nearly all deployed systems
- and data. Finally, I explore a mechanism (some new predicates) to
- let people be explicit about URI usage in when necessary.
-
-
- The changes to the current draft RDF documents should be small. I
- have not yet constructed the exact revisions required, but I think
- they are mostly in RDF Concepts and Abstract Syntax, section 2.4.3
- Interaction between social and formal meaning. If the new predicates
- are adopted by RDF Core, they would require some wider changes,
- but they could probably go into another namespace and Recomendation.},
- owner = {sauermann},
- timestamp = {2006.10.29},
- url = {http://www.w3.org/2002/12/rdf-identifiers/},
-}
-
-@INPROCEEDINGS{heath2005,
- author = { Tom Heath and Enrico Motta and Martin Dzbor},
- title = { Context as a Foundation for a Semantic Desktop },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/23_heathmottadzbor_context_final.pdf},
-}
-
-@MASTERSTHESIS{Heim2006,
- author = {Dominik Heim},
- title = {Semantic Wikis in knowledge management - Evaluating the Gnowsis approach},
- school = {Fachhochschule Kaiserslautern},
- year = {2006},
- month = {August},
- owner = {sauermann},
- timestamp = {2006.10.07},
-}
-
-@INBOOK{Baldoni+2005,
- chapter = {p. 173},
- pages = {173--212},
- title = {Personalization for the Semantic Web},
- publisher = {Springer},
- year = {2005},
- editor = {Norbert Eisinger and Jan Ma?uszy?ski},
- author = {M. Baldoni
-
- and C. Baroglio
-
- and N. E. Henze},
- volume = {3564},
- month = {Aug},
- journal = {Lecture Notes in Computer Science},
- pdf = {Baldoni+2005.pdf},
- url = {http://www.springerlink.com/openurl.asp?genre=article&id=doi:10.1007/11526988_5},
-}
-
-@INPROCEEDINGS{Hogue+2005,
- author = {Andrew Hogue and David Karger},
- title = {Thresher: Automating the Unwrapping of Semantic Content from the
- World Wide Web},
- booktitle = {In Proceedings. WWW Conference },
- year = {2005},
- owner = {Sauermann},
- pdf = {Hogue+2005.pdf},
-}
-
-@INPROCEEDINGS{HolzMausBernardiRostanin2005b,
- author = {Holz, Harald and Maus, Heiko and Bernardi, Ansgar and Rostanin, Oleg},
- title = {From {L}ightweight, {P}roactive {I}nformation {D}elivery to {B}usiness
- {P}rocess-{O}riented {K}nowledge {M}anagement},
- year = {2005},
- volume = {0},
- number = {2},
- pages = {101--127},
- comment = {THE EPOS PAPER},
- journal = {Journal of {U}niversal {K}nowledge {M}anagement. {S}pecial {I}ssue
- on {K}nowledge {I}nfrastructures for the {S}upport of {K}nowledge
- {I}ntensive {B}usiness {P}rocesses},
- language = {english},
- owner = {maus},
- pdf = {HolzMausBernardiRostanin2005b.pdf},
- timestamp = {2005.12.07},
- url = {http://www.jukm.org/jukm_0_2/holz},
-}
-
-@MISC{Lumiere,
- author = {Eric Horvitz and Jack Breese and David Heckerman and David Hovel
- and Koos Rommeltse},
- title = {The Lumi\`{e}re Project: Bayesian User Modeling for Inferring the
- Goals and Needs of Software Users},
- note = {Microsoft Research},
- owner = {sauermann},
- timestamp = {2006.04.02},
-}
-
-@INPROCEEDINGS{piggybank2005,
- author = {David Huynh and Stefano Mazzocchi and David Karger},
- title = {Piggy Bank: Experience the Semantic Web Inside Your Web Browser},
- booktitle = {The Semantic Web â ISWC 2005},
- year = {2005},
- number = {LNCS 3729},
- abstract = {The Semantic Web Initiative envisions a Web wherein information is
- offered free of presentation, allowing more effective exchange and
- mixing across web sites and across web pages. But without substantial
- Semantic Web content, few tools will be written to consume it; without
- many such tools, there is little appeal to publish Semantic Web
- content. To break this chicken-and-egg problem, thus enabling more
- flexible informa-tion access, we have created a web browser extension
- called Piggy Bankthat lets users make use of Semantic Web content
- within Web content as users browse the Web. Wherever Semantic Web
- content is not available, Piggy Bank can invoke screenscrapers to
- re-structure information within web pages into Semantic Web format.
- Through the use of Semantic Web technologies, Piggy Bank provides
- direct, immediate benefits to users in their use of the existing
- Web. Thus, the ex-istence of even just a few Semantic Web-enabled
- sites or a few scrapers already benefits users. Piggy Bank thereby
- offers an easy, incremental upgrade path to users without requiring
- a wholesale adoption of the Semantic Webâs vision. To further improve
- this Semantic Web experience, we have created Semantic Bank, a web
- server application that lets Piggy Bank users share the Semantic
- Web information they have collected, enabling collaborative efforts
- to build so-phisticated Semantic Web information repositories through
- simple, everydayâs use of Piggy Bank.},
- owner = {Sauermann},
- pdf = {piggybank2005.pdf},
-}
-
-@INPROCEEDINGS{indratmo2005,
- author = { Indratmo and Julita Vassileva},
- title = { Human and Social Aspects of Decentralized Knowledge Communities},
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/10_indratmojulita_socialaspects_final.pdf},
-}
-
-@INPROCEEDINGS{iofciu2005,
- author = { Tereza Iofciu and Christian KohlschĂźtter and Wolfgang Nejdl and
- Raluca Paiu},
- title = { Keywords and RDF Fragments: Integrating Metadata and Full-Text Search
- in Beagle++ },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/7_iofciu_beagleplusplus_final.pdf},
-}
-
-@INPROCEEDINGS{IturriozAD2006,
- author = {Jon Iturrioz and Sergio F. Anzuola and Oscar DĂaz},
- title = {Turning the mouse into a semantic device: the seMouse experience},
- booktitle = {Proc. of the 3rd European Semantic Web Conference, ESWC 2006 Budva,
- Montenegro, June 11-14, 2006},
- year = {2006},
- editor = {York Sure and John Domingue},
- volume = {4011},
- series = {Springer LNCS},
- doi = {ISBN: 3-540-34544-2},
- owner = {sauermann},
- pdf = {IturriozAD2006.pdf},
- timestamp = {2006.07.10},
- url = {http://www.springeronline.com/3-540-34544-2},
-}
-
-@INPROCEEDINGS{Iturrioz+2003,
- author = {Jon Iturrioz and Oscar DĂaz and Sergio F. Anzuola and Iker Azpeitia},
- title = {The Semantic Desktop: an architecture to leverage document processing
- with metadata.},
- booktitle = {Proceedings of the VLDB Workshop on Multimedia and Data Document
- Engineering (MDDE'03), September 2003.},
- year = {2003},
- comment = {Found in IturriozAD2006},
- owner = {sauermann},
- pdf = {Iturrioz+2003.pdf},
- timestamp = {2006.07.10},
- url = {http://www.vldb.informatik.hu-berlin.de/locev_colocworkshps.html#mdde},
-}
-
-@INPROCEEDINGS{Iturrioz+2007a,
- author = {Jon Iturrioz and Oscar DĂaz and {Sergio F.} Anzuola},
- title = {Towards the Semantic Desktop: the seMouseapproach},
- booktitle = {IEEE Intelligent Systems (TODO)},
- year = {2007},
- abstract = {The semantic desktop aims at handling files as resources of a desktop
- ontology. This ontology captures a mental model of how the user
- conceptualizes files, and serves to re-interpret current file operations
- in a semantic manner. Now, a ``.doc'' artifact is not a mere file
- but a resource of the knowledge base. The user no longer creates
- a ``.doc'' file but an instance of, for instance, the Deliverable
- ontological class. Likewise, zipping operations do not require selecting
- one-at-a-time the files to be zipped together but semantic associations
- can be automatically traversed to locate the resources to be zipped.
- This paper presents seMouse, a realization of this vision where
- the mouse acts as a bridge between the traditional file world and
- the ontology realm. This accounts for a dual perspective of desktop
- resources. As files, traditional tooling is available (e.g. the
- Word editor). As resources, ``the semantic mouse'' permits to re-interpret
- traditional file operations from a semantic perspective whereby
- resource edition, classification, copying or ziping benefit from
- the underlying ontology. Keywords: I.2.12 Intelligent Web services
- and Semantic web, H.3.2.1 Document/file Management, I.2.13 Knowledge
- Management},
- owner = {sauermann},
- pdf = {Iturrioz+2007a.pdf},
- timestamp = {2007.03.30},
-}
-
-@ARTICLE{Ivory+2001,
- author = {Melody Y. Ivory and Marti A Hearst},
- title = {The state of the art in automating usability evaluation of user interfaces},
- journal = {ACM Comput. Surv.},
- year = {2001},
- volume = {33},
- pages = {470--516},
- number = {4},
- address = {New York, NY, USA},
- comment = {recommended by Heiko Maus},
- doi = {http://doi.acm.org/10.1145/503112.503114},
- issn = {0360-0300},
- owner = {sauermann},
- publisher = {ACM Press},
- timestamp = {2006.07.28},
-}
-
-@INPROCEEDINGS{Jones+2006,
- author = {William Jones and Harry Bruce and Austin Foxley and Charles Munat},
- title = {Planning Personal Projects and Organizing Personal Information},
- booktitle = {Proceedings of the ASIS\&T Annual Meeting},
- year = {2006},
- month = {November 3-9},
- abstract = {In a given week, an active person may be working on, or at least thinking
- about, several different projects. Some are work-related (ââŹĹprepare
- annual reportââŹÂ); others are not (ââŹĹplan family ski vacationââŹÂ).
- Projects have duration (several days to several months) and a structure
- that includes basic tasks (ââŹĹbook plane ticketsââŹÂ) and subprojects
- (ââŹĹdecide on hotelââŹÂ). This article describes exploratory research
- that looks at the kinds of projects people manage in their daily
- lives, the problems they encounter and the kinds of support people
- need to manage better. The personal project is advanced as a tractable
- unit of analysis for the study of personal information management
- (PIM): Over time, a personal project often involves several forms
- of information (paper documents, digital documents, email, web pages,
- handwritten notes, etc.) and several different supporting applications.
- In the context of a project, people face problems of information
- fragmentation that are more widely experienced in their practice
- of PIM. The article also describes current work on a Project Planner
- prototype that works as an extension to the file manager to provide
- people with rich-text overlays to their information (folders, files
- and also email, web pages, notes). The Planner explores an exciting
- possibility that an effective organization of project-related information
- can emerge as a natural by-product of efforts to plan and structure
- the project.},
- keywords = {pim semantic desktop},
- owner = {sauermann},
- pdf = {Jones+2006.pdf},
- timestamp = {2007.01.21},
- url = {http://www.asis.org/Conferences/AM06/papers/159.html},
-}
-
-@INPROCEEDINGS{Jones+2005,
- author = {Jones, William and Munat, Charles F. and Bruce, Harry and Foxley,
- Austin},
- title = {The Universal Labeler: Plan the Project and Let Your Information
- Follow},
- booktitle = {Proceedings 68th Annual Meeting of the American Society for Information
- Science and Technology (ASIST)},
- year = {2005},
- editor = {Grove and Andrew},
- abstract = {The Universal Labeler (UL) supports a single, unified scheme of "labeling"
- which can be used to organize various kinds of information including
- electronic documents, email messages and web references. The UL
- takes a project-centered approach to personal information management
- (PIM): 1. People often keep information to get things done - to
- complete projects ("finish a course", "re-model a house", etc.).
- 2. Project-planning involves problem-solving: A person's conceptualization
- of a project can often be characterized as a hierarchy of subproject/tasks.
- 3. Project structure, if made explicit, can aid not only in planning
- but also in the organization of related information. Projects, subprojects
- and tasks are represented by "labels" in the UL. Useful properties
- and behaviors can be associated with these labels - "remind me by"
- or due dates, for example. The UL is a step towards the integration
- of information regardless of its form (edocument, paper, web page)
- and towards the integration of information management with the management
- of tasks and projects.},
- keywords = {pim semantic desktop},
- owner = {sauermann},
- pdf = {Jones+2005.pdf},
- timestamp = {2007.01.21},
- url = {http://kftf.ischool.washington.edu/UL_ASIST05.pdf},
-}
-
-@TECHREPORT{ExifRdfs2004,
- author = {Masahide Kanzaki},
- title = {Exif vocabulary workspace - RDF Schema},
- institution = {RDF Interest Group},
- year = {2004},
- owner = {Sauermann},
- url = {http://www.w3.org/2003/12/exif/},
-}
-
-@INPROCEEDINGS{poggi2005,
- author = { Vivi Katifori and Antonella Poggi and Monica Scannapieco and Tiziana
- Catarci and and Yannis Ioannidis},
- title = { OntoPIM: how to rely on a personal ontology for Personal Information
- Management },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/25_poggi_ontopim_poster.pdf},
-}
-
-@INPROCEEDINGS{Kiesel2006,
- author = {Malte Kiesel},
- title = {Kaukolu: Hub of the Semantic Corporate Intranet},
- booktitle = {Proc. of the Workshop SemWiki2006 - From Wiki to Semantics at the
- ESWC Conference},
- year = {2006},
- abstract = {Due to their low entry barrier, easy deployment, and simple
-
- yet powerful features, wikis have gained popularity for agile knowledge
-
- management in communities of almost all sizes. Semantic wikis strive
-
- to give entered information more structure in order to allow automatic
-
- processing of the wikiâs contents. This facilitates enhanced navigation
-
- and search in the wiki itself as well as simple reuse of information
- in
-
- external applications or for generating different views on the same
- information.
-
- This makes semantic wikis especially interesting for corporate
-
- intranet deployment, implementing the Semantic Intranet. In this paper,
-
- we will have a look at Kaukolu, an open source semantic wiki prototype,
-
- being deployed in a corporate intranet. External applications use
- information
-
- authored in Kaukolu, effectively forming a cluster of applications
-
- interacting and sharing data.},
- owner = {sauermann},
- pdf = {Kiesel2006.pdf},
- timestamp = {2006.10.12},
-}
-
-@TECHREPORT{kiesel2005-semanticwiki,
- author = {Malte Kiesel and Bertin Klein},
- title = {Semantic Wikis â Structuring Chaos},
- institution = {DFKI},
- year = {2005},
- month = {May},
- abstract = {Nowadays, many search engines (Google Q&A, Ask Jeeves, MSN) provide
- not only search by keyword, but also feature simple question answering
- services, meaning that the search engine does not answer a question
- like âHow tall is Mount Fujiâ with a list of search results pointing
- to other web sites, but with a direct answer (â3776 metersâ). The
- facts returned are retrieved from a formalized knowledge repository
- whose content is extracted from web sites (such as Wikipedia). This
- formalization is a work-intensive and error-prone process. On the
- other hand, Semantic Web standards such as RDF(S) provide means
- to represent formalized web contents in order to make them machineprocessable.
- This should happen at the server side, not on the clientâs or search
- engineâs side, which not only ensures that experts provide formalization
- but also that the formalized contents is available to everyone interested.
- While adding semantic metadata may be used to greatly enhance search
- engine performance, many other benefits are also possible. For example,
- with web pages getting categorized, it is possible to automatically
- create hierarchical views of web pages and the topics therein. In
- this paper, we will discuss the benefits of providing semantic metadata
- for web contents, especially when combining Semantic Web technology
- with Wiki approaches.},
- comment = {should be published at wikimedia conference},
- owner = {Sauermann},
- pdf = {kiesel2005-semanticwiki.pdf},
-}
-
-@ARTICLE{Kiesel+2005,
- author = {Malte Kiesel and Leo Sauermann},
- title = {Towards Semantic Desktop Wikis},
- journal = {UPGRADE special issue on "The Semantic Web"},
- year = {2005},
- volume = {VI},
- pages = {30 - 34},
- abstract = {To manage information on a personal computer, tools are needed that
- allow easy entering of new knowledge and that can relate ideas and
- concepts to existing information. Wikis allow entering information
- in a quick and easy way. They can be employed for both collaborative
- and personal information management. Semantic Web standards such
- as RDF(S) (Resource Description Framework) and OWL (Web Ontology
- Language) provide means to represent formalized knowledge. Using
- these standards to represent relations between individual desktop
- data sources, an integrated view of the user's information can be
- realized, known as the Semantic Desktop. In this paper, we propose
- combining information represented using Semantic Web standards with
- the simple information management known from wikis. The result is
- a Semantic Desktop Wiki, which can form a melting pot for ideas
- and personal information management.},
- owner = {sauermann},
- pdf = {http://www.upgrade-cepis.org/issues/2005/6/up6-6Kiesel.pdf},
- timestamp = {2006.05.19},
- url = {http://www.upgrade-cepis.org/issues/2005/6/upgrade-vol-VI-6.html},
-}
-
-@ARTICLE{Kirsh2000,
- author = {David Kirsh},
- title = {A Few Thoughts on Cognitive Overload},
- journal = {Intellectica},
- year = {2000},
- volume = {1},
- pages = {19-51},
- comment = {recommended by Danish Nadeem on 26.07.2006},
- owner = {sauermann},
- pdf = {Kirsh2000.pdf},
- timestamp = {2006.07.26},
-}
-
-@INPROCEEDINGS{krug2005,
- author = { Sebastian Ryszard Kruk and Stefan Decker},
- title = { Semantic Social Collaborative Filtering with FOAFRealm },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/37_krug_foafrealm_final.pdf},
-}
-
-@INPROCEEDINGS{kunze.roesner.germanet2005,
- author = {Peter Michael Kruse and AndrĂŠ Naujoks and Dietmar RĂśsner and Manuela
- Kunze},
- title = {Clever Search: A WordNet Based Wrapper for Internet Search Engines},
- booktitle = {Proceedings of GLDV-Tagung 2005},
- year = {2005},
- editor = {B. Fisseni and H.-Chr. Schmitz and B. SchrĂśder and P. Wagner},
- pages = {367 - 380},
- address = {Bonn, Germany},
- publisher = {Peter Lang GmbH},
- note = {ISBN: 3-631-53874-X},
- abstract = {This paper presents an approach to enhance search engines with information
- about word senses available in WordNet. The approach exploits information
- about the conceptual relations within the lexical-semantic net.
- In the wrapper for search engines presented, WordNet information
- is used to specify a user's request or to classify the results of
- a publicly available web search engine, like Google, Yahoo, etc.
- In diesem Beitrag wird ein Ansatz vorgestellt, der auf der Grundlage
- der verfĂÂźgbaren Informationen in WordNet die Ergebnisse von herkĂÂśmmlichen
- Suchmaschinen verbessert. Es werden hierzu die konzeptuellen Relationen
- des lexikalischen-semantischen Netzes genutzt. Der beschriebene
- Suchmaschinenaufsatz nutzt WordNet-Informationen um Nutzeranfragen
- zu spezifizieren und um die gefundenen Webseiten der herkĂÂśmmlichen
- Suchmaschinen (Google, Yahoo etc.) zu klassifizieren und zu gruppieren.},
-}
-
-@INPROCEEDINGS{Latif+2006,
- author = {Khalid Latif and A Min Tjoa},
- title = {Combining Context Ontology and Landmarks for Personal Information
- Management},
- booktitle = {Proceedings of International Conference on Computing and Informatics
- (ICOCI)},
- year = {2006},
- address = {Kuala Lumpur, Malaysia},
- month = {June},
- owner = {sauermann},
- pdf = {Latif+2006.pdf},
- timestamp = {2007.06.17},
-}
-
-@TECHREPORT{DERI-TR-2004-04-03,
- author = {Holger Lausen and Michael Stollberg and RubĂŠn Lara HernĂĄndez and
- Ying Ding and Sung-Kook Han and Dieter Fensel },
- title = {Semantic Web Portals - State of the Art Survey},
- institution = {DERI },
- year = {2004},
- type = {Technical Report },
- number = {2004-04-03},
- month = {April },
- owner = {Sauermann},
- pdf = {DERI-TR-2004-04-03.pdf},
-}
-
-@BOOK{Timbl2000,
- title = {Weaving the Web, The Past, Present and Future of the World Wide Web
- by its Inventor},
- publisher = {Texere, London},
- year = {2000},
- author = {Tim Berners Lee},
- owner = {Sauermann},
-}
-
-@MASTERSTHESIS{Luo2005,
- author = {Man Luo},
- title = {Semantic Meeting Annotation},
- school = {Technical University of Berlin},
- year = {2006},
- month = {March},
- comment = {supervised by Leo Sauermann},
- owner = {sauermann},
- pdf = {Luo2005.pdf},
- timestamp = {2006.07.12},
-}
-
-@ARTICLE{Mack2001,
- author = {R. Mack and Y. Ravin and R. J. Byrd},
- title = {Knowledge portals and the emerging digital knowledge workplace},
- journal = {IBM Systems Journal},
- year = {2001},
- volume = {Volume 40},
- pages = {pp. 925-955.},
- number = {Number 4},
- owner = {Sauermann},
- pdf = {Mack2001.pdf},
-}
-
-@ARTICLE{ontologienStichwort,
- author = {Alexander Maedche and Steffen Staab and Rudi Studer},
- title = {Ontologien.},
- journal = {Wirtschaftsinformatik},
- year = {2001},
- volume = {43},
- pages = {393-396},
- number = {4},
- bibsource = {DBLP, http://dblp.uni-trier.de},
- owner = {sauermann},
- pdf = {ontologienStichwort.pdf},
- timestamp = {2007.06.10},
-}
-
-@MASTERSTHESIS{Maier2004,
- author = {Mikael Maier-Collin },
- title = {OntoOffice - Ontologiebasierte UnterstĂźtzung des Wissensprozesses
- in Office-Anwendungen .},
- school = {AIFB, Universität Karlsruhe},
- year = {2004},
- owner = {Sauermann},
-}
-
-@INBOOK{Maneewatthana+2005,
- title = {Adaptive Personal Information Environment based on Semantic Web},
- publisher = {Springer},
- year = {2006},
- editor = {Sirmakessis, Spiros},
- author = {Thanyalak Maneewatthana and Gary Wills and Wendy Hall},
- volume = {Adaptive and Personalized Semantic Web},
- number = {14},
- series = {Studies in Computational Intelligence},
- comment = {2006, XI, 105 p. 26 illus., Hardcover},
- doi = {ISBN: 3-540-30605-6},
- owner = {sauermann},
- pdf = {likothanasis2005.pdf},
- timestamp = {2006.04.01},
-}
-
-@MASTERSTHESIS{May2004,
- author = {Martin May},
- title = {kSpaces: A Distributed Knowledge Management Platform},
- school = {Department of Computing Science, University of Aberdeen},
- year = {2004},
- type = {Master Thesis},
- abstract = {kSpaces is a metadata-driven, distributed knowledge management platform.
- It was designed to be lightweight, transparent and extensible. The
- kSpaces proof-of-concept allows files to be described with arbitrary
- RDF (http://www.w3.org/RDF/) metadata. These descriptions can then
- be easily shared with and queried by other nodes in the system.
- Finally, kSpaces-managed files can be made available to all other
- nodes participating in the same kSpace. kSpaces employs file system
- monitoring and auto-tagging technologies in order to achieve almost
- full transparency to the user. Its lightweight, plugin-based design
- allows for maximum extensibility. The kSpaces reference implementation
- was written using Java for the server and C# for the client (on
- Microsoft's .NET platform). All client-server communication is done
- via SOAP (http://www.w3.org/TR/soap/), and client-client data transfers
- are made via HTTP. The kSpaces Node software works by monitoring
- a directory (My kSpace in the My Documents folder) and managing
- metadata about any files in that directory. Subdirectories are not
- supported. kSpaces automatically tags files through the use of plugins.
- The two autotagging plugins that are included analyze a file's ID3
- (http://www.id3.org/) and EXIF (http://www.exif.org/) headers, and
- then generate the appropriate RDF metadata. Metadata associated
- with a file can be viewed and edited through the kSpaces Node application,
- supported by editor plugins. Five editor plugins have been included
- in the proof-of-concept, four of which are read only. These plugins
- allow the management of a subset of Dublin Core (http://www.dublincore.org/)
- metadata, EXIF metadata, ID3 metadata and kSpaces-specific metadata.
- The Raw RDF plugin shows the raw RDF metadata associated with a
- knowledge asset. The metadata that is stored about knowledge assets
- in a kSpace can be queried using RDQL (http://www.hpl.hp.com/semweb/rdql.htm).
- In end-user applications, RDQL could be generated by using natural
- language processing or other technologies. Finally, the kSpaces
- node allows the kSpace contents to be viewed using browsing plugins.
- In this proof-of-concept, only a very basic one has been provided,
- which shows all assets present in the kSpace. Writing additional
- browsing plugins will allow users to see the kSpace assets from
- different facets that can be tailored to the user's needs.},
- owner = {sauermann},
- timestamp = {2007.03.15},
-}
-
-@INPROCEEDINGS{McBride2001,
- author = {Brian McBride},
- title = {Jena: Implementing the RDF Model and Syntax Specification },
- booktitle = {Proc. of the Semantic Web Workshop WWW2001},
- year = {2001},
- abstract = {Some aspects of W3C's RDF Model and Syntax Specification require careful
- reading and interpretation to produce a conformant implementation.
- Issues have arisen around anonymous resources, reification and RDF
- Graphs. These and other issues are identified, discussed and an
- interpretation of each is proposed. Jena, an RDF API in Java based
- on this interpretation, is described.},
- owner = {Sauermann},
- url = {http://www.hpl.hp.com/personal/bwm/papers/20001221-paper/},
-}
-
-@MISC{mcdowell04semantic,
- author = {L. McDowell and O. Etzioni and A. Halevey and H. Levy},
- title = {Semantic email},
- year = {2004},
- pdf = {mcdowell04semantic.pdf},
- text = {L. McDowell, O. Etzioni, A. Halevey, and H. Levy. Semantic email.
- In World Wide Web, 2004.},
- url = {citeseer.ist.psu.edu/mcdowell04semantic.html},
-}
-
-@MISC{owl-overview,
- author = {D. L. McGuinness and F. Harmelen},
- title = {OWL Web Ontology Language Overview W3C Recommendation 10 February
- 2004},
- howpublished = {http://www.w3.org/TR/owl-features/},
- owner = {Sauermann},
-}
-
-@INPROCEEDINGS{MesnageJazayeri2006b,
- author = {CĂŠdric Mesnage and Mehdi Jazayeri},
- title = {Specifying the Collaborative Tagging System (DRAFT, TO BE SUBMITTED)},
- booktitle = {Proceedings of the SAAW06},
- year = {2006},
- owner = {sauermann},
- pdf = {MesnageJazayeri2006b.pdf},
- timestamp = {2006.08.08},
-}
-
-@TECHREPORT{Mika2004,
- author = {Peter Mika and Hans Akkermans},
- title = {Towards a New Synthesis of Ontology Technology and Knowledge Management},
- institution = {Free University Amsterdam (VUA)},
- year = {2004},
- number = {IR-BI-001},
- month = {March},
- owner = {Sauermann},
- pdf = {Mika2004.pdf},
-}
-
-@INPROCEEDINGS{mika2005,
- author = { Peter Mika and Michel Klein and and Radu Serban},
- title = { Semantics-based Publication Management using RSS and FOAF },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/6_mika_swvu_final.pdf},
-}
-
-@MASTERSTHESIS{Mika2002,
- author = {PĂŠter Mika},
- title = {Applied Ontology-based Knowledge Management:
-
- A Report on the State-of-the-Art},
- school = {Vrije Universiteit, Amsterdam},
- year = {2002},
- type = {Masters Thesis},
- month = {July},
- abstract = {As with every major intellectual effort, there is a story behind this
- work as well.
-
- Following four years of education in Computer Science at the EĂśtvĂśs
- LorĂĄnd TudomĂĄny Egyetem (ELTE) in Budapest and a year at the Vrije
- Universiteit in Amsterdam (VUA), just like my peers, I had the obligation
- to complete a thesis work for a Master's degree in Computer Science.
- Unlike my peers, however, I was not only looking for a topic, but
- planned to find a related internship as well: I considered that
- a guarantee that the topic I chose would have a practical value
- beyond an exercise per se.
-
- In my quest I had the fortune to meet Frank van Harmelen from the
- Artificial Intelligence Department of the VUA. He not only offered
- me a topic and an internship to go with it, but also helped me to
- joining one of the most reputable research collaboration in the
- field of Semantic Web [29] technologies and applications. He also
- introduced me to Hans Akkermans from the Business Informatics Department
- of the VUA who helped as an advisor during my work. I started in
- January 2002 at EnerSearch, a Swedish case study partner in the
- On-To-Knowledge research project. In order to avoid relocation,
- AIdministrator (another partner in the project) generously hosted
- me for the duration of my work.
-
- For the following six month I had been vested the responsibility to
- assemble the components developed in the project into a comprehensive
- solution for EnerSearch. With very few experience available to build
- on, my task was rightfully expected to be a challenge and an immense
- learning endeavor. While strenuous at times and fun at others, it
- altogether gave me a unique insight into some of the most exciting
- technologies in AI today and provided the wealth of experience that
- is captured in the following thesis.},
- owner = {sauermann},
- pdf = {Mika2002.doc},
- timestamp = {2006.04.18},
-}
-
-@INPROCEEDINGS{miller2005identifying,
- author = {Tristan Miller and Stefan Agne},
- title = {Attention-based information retrieval using eye tracker data},
- booktitle = {Proceedings of the Third International Conference on Knowledge Capture
- ({K-CAP05})},
- year = {2005},
- month = sep,
- note = {To appear},
-}
-
-@TECHREPORT{miller2005efisk,
- author = {Tristan Miller and Stefan Agne and Andreas Dengel},
- title = {{eFISK}~-- eine aufmerksamkeitsbasierte {S}chlĂźsselwort-{E}xtr aktions-
- und {I}nformation {R}etrieval-{M}aschine},
- institution = {Stiftung Rheinland-Pfalz fĂźr Innovation},
- year = {2005},
- type = {Abschlussbericht},
- number = {15202-386261/659},
- month = jun,
-}
-
-@INPROCEEDINGS{moeller2005,
- author = { Knud MĂśller and Stefan Decker},
- title = { Harvesting Desktop Data for Semantic Blogging },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/29_moeller_semiblogsemdesk_final.pdf},
-}
-
-@ARTICLE{Nejdl+2005,
- author = {Wolfgang Nejdl and Raluca Paiu},
- title = {I know I stored it somewhere - Contextual Information and Ranking
- on our Desktop},
- journal = {8th International Workshop of the EU DELOS Network of Excellence
- on Future Digital Library Management Systems},
- year = {2005},
- month = {March},
- owner = {Sauermann},
- pdf = {Nejdl+2005.pdf},
- url = {http://www.kbs.uni-hannover.de/Arbeiten/Publikationen/2005/DesktopSearchOverview.pdf},
-}
-
-@ARTICLE{Nelson1972,
- author = {Ted Nelson},
- title = {As We Will Think},
- journal = {On-line 72 Conference Proceedings},
- year = {1972},
- volume = {vol. 1},
- pages = {pp. 439-454},
- owner = {Sauermann},
-}
-
-@MASTERSTHESIS{Newman2006,
- author = {Andrew Newman},
- title = {Querying the Semantic Web using a Relational Based SPARQL},
- school = {The School of Information Technology and Electrical Engineering
-
- The University of Queensland},
- year = {2006},
- type = {Bachelor Thesis},
- address = {Brisbane QLD Australia},
- month = {Oct},
- abstract = {The Semantic Web is an initiative that aims to enable data from different
- sources to be
-
- combined in a consistent way. It is particularly useful when the schemas
- and terminologies of
-
- different data sets are to be merged, or they differ between organisations
- or change over time.
-
- Semantic Web technologies have been successfully applied to data integration
- in fields such as
-
- Bio-Informatics, Life Sciences, GIS (Geographic Information Systems)
- and Material Sciences.
-
- RDF is a simple graph-based data model for representing information
- on the Web. SPARQL
-
- is the proposed standard for querying RDF and both are part of the
- W3Câs Semantic Web
-
- Activity.
-
- The current SPARQL specification shows a strong bias towards underlying
- implementations
-
- (especially SQL) and lacks a formal model. A formal model would allow:
-
-
- ⢠Independence between implementation and specification,
-
- ⢠Greater consistency with RDF, and
-
- ⢠The ability to improve implementations without affecting the userâs
- view of the
-
- system.
-
-
- Previous work has highlighted the need for a formal model in order
- to improve consistency
-
- and clarity of the existing specification. It is suggested that building
- SPARQL on the
-
- relational model allows efficient query optimisation and distribution.
-
-
- This work provides a mapping from RDF and SPARQL that is consistent
- with the relational
-
- model. The SPARQL operations UNION and OPTIONAL were implemented using
- the
-
- relational operators outer union and minimum union respectively. This
- is based on previous
-
- extensions to the relational model by Galindo-Legaria. Implementation
- details using Java and
-
- the JRDF library are described including the use of an order independent
- minimum union
-
- implementation, and the significant performance advantages of applying
- pre-existing relational
-
- optimisation techniques is explored.
-
- It is shown that by using the relational model as a basis for SPARQL
- it provides an easier to
-
- implement, more efficient, more consistent and extensible query language
- than is currently
-
- provided. It also allows the reuse of existing relational optimisation
- techniques as well as
-
- being used a basis to extend SPARQL functionality.},
- comment = {I corrected and proofread this thesis},
- owner = {sauermann},
- pdf = {Newman2006.pdf},
- timestamp = {2006.12.05},
-}
-
-@MISC{RFC2192,
- author = {C. Newman},
- title = {RFC 2192: IMAP URL Scheme},
- month = {September},
- year = {1997},
- owner = {Sauermann},
- url = {http://www.ietf.org/rfc/rfc2192.txt},
-}
-
-@MISC{NielsenSearchNote,
- author = {Jakob Nielsen},
- title = {Mental Models For Search Are Getting Firmer},
- howpublished = {\url{http://www.useit.com/alertbox/20050509.html} see also the tutorial
- on Fundamental Guidelines for Web Usability at the User Experience
- 2005 conference},
- month = {May},
- year = {2005},
- owner = {Sauermann},
-}
-
-@MISC{Odgen1923,
- author = {C. K. Odgen and I. A. Richards},
- title = {The Meaning of Meaning: A Study of the Influence of Language upon
- Thought and of the Science of Symbolism
-
- },
- howpublished = {10th Edition, Routledge \& Kegan Paul Ltd., London},
- year = {1923},
- owner = {Sauermann},
-}
-
-@INPROCEEDINGS{oren2005,
- author = { Eyal Oren},
- title = { SemperWiki: a semantic personal Wiki },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/27_oren_semperwiki_final.pdf},
-}
-
-@INPROCEEDINGS{SDWSOren2005,
- author = {Eyal Oren },
- title = {SemperWiki: a semantic personal Wiki},
- booktitle = {Proceedings of the 1st Semantic Desktop Workshop at the ISWC2005},
- year = {2005},
- owner = {Sauermann},
- url = {http://www.semanticdesktop.org/SemanticDesktopWS2005/final/27_oren_semperwiki_final.pdf},
-}
-
-@INPROCEEDINGS{Ortner2002,
- author = {Johann Ortner},
- title = {Knowledge in an Electronic World ?},
- booktitle = {PAKM2002},
- year = {2002},
- editor = {D. Karagiannis and U. Reimer},
- volume = {LNAI 2569 },
- pages = {pp. 281-300},
- publisher = {Springer-Verlag Berlin Heidelberg},
- owner = {Sauermann},
- pdf = {C:\Dokumente und Einstellungen\Sauermann\Eigene Dateien\_quellen\ortner-knowledge_in_an_electronic_world.pdf},
-}
-
-@MISC{nabuproject,
- author = {Frank Osterfeld and Malte Kiesel},
- title = {nabu semantic jabber server},
- howpublished = {http://nabu.opendfki.de},
- owner = {Sauermann},
- url = {http://nabu.opendfki.de},
-}
-
-@INPROCEEDINGS{kiesel2005,
- author = { Frank Osterfeld and Malte Kiesel and Sven Schwarz},
- title = { Nabu â A Semantic Archive for XMPP Instant Messaging },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/40_kiesel_nabu_final.pdf},
-}
-
-@INPROCEEDINGS{pammer+2006,
- author = {V. Pammer and P. Scheir and S. Lindstaedt},
- title = {Ontology Coverage Check: support for evaluation in ontology engineering},
- booktitle = {Proceedings of FOMI 2006 - 2nd Workshop on Formal Ontologies Meet
- Industry},
- year = {2006},
- comment = {referenced by APOSDLE: learn@work with semantic web technology, which
- I reviewed in June 2007},
- owner = {sauermann},
- pdf = {pammer+2006.pdf},
- timestamp = {2007.06.05},
-}
-
-@INPROCEEDINGS{akila2005,
- author = { Nilesh Patel and Akila Varadarajan},
- title = { Semantic Pen - A Personal Information Management System for Pen
- Based Devices },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/33_akila_semanticpen_final.pdf},
-}
-
-@INPROCEEDINGS{Patel-SchneiderKR2004,
- author = {Peter F. Patel-Schneider},
- title = {What Is OWL (and Why Should I Care)?},
- booktitle = {KR},
- year = {2004},
- pages = {735-737},
- comment = {Zusammenfassung:},
- description = {dblp},
- isbn = {1-57735-199-1},
- keywords = {logic ontologies owl semanticWeb semwebss06 swss06-06 },
- url = {http://www.cs.bell-labs.com/cm/cs/who/pfps/publications/what-is-owl.pdf},
-}
-
-@TECHREPORT{Pepper+2003,
- author = {Steve Pepper and Sylvia Schwab},
- title = {Curing the Web's Identity Crisis. Subject Indicators for RDF},
- institution = {Ontopia},
- year = {2003},
- abstract = {This paper describes the crisis of identity facing the World Wide
- Web and, in particular, the RDF community. It shows how that crisis
- is rooted in a lack of clarity about the nature of "resources" and
- how concepts developed during the XML Topic Maps effort can provide
- a solution that works not only for Topic Maps, but also for RDF
- and semantic web technologies in general.},
- owner = {sauermann},
- timestamp = {2006.10.29},
- url = {http://www.ontopia.net/topicmaps/materials/identitycrisis.html},
-}
-
-@MISC{Kowari-project,
- author = {the kowari project},
- howpublished = {\url{http://kowari.sourceforge.net/}},
- owner = {Sauermann},
-}
-
-@TECHREPORT{SPARQLQuery2005,
- author = {Eric Prud'hommeaux and Andy Seaborne (edts)},
- title = {SPARQL Query Language for RDF},
- institution = {W3C},
- year = {2005},
- type = {W3C Working Draft},
- note = {http://www.w3.org/TR/rdf-sparql-query/},
- abstract = {RDF is a flexible, extensible way to represent information about World
- Wide Web resources. It is used to represent, among other things,
- personal information, social networks, metadata about digital artefacts,
- like music and images, as well as provide a means of integration
- over disparate sources of information. A standardized query language
- for RDF data with multiple implementations offers developers and
- end users a way to write and to consume the results of queries across
- this wide range of information. Used with a common protocol, applications
- can access and combine information from across the web. This document
- describes the query language part of SPARQL Protocol And RDF Query
- Language for easy access to RDF stores. It is designed to meet the
- requirements and design objectives described in the W3C RDF Data
- Access Working Group (DAWG) document "RDF Data Access Use Cases
- and Requirements".},
- owner = {Sauermann},
- url = {http://www.w3.org/TR/rdf-sparql-query/},
-}
-
-@ARTICLE{Prusak2001,
- author = {L. Prusak},
- title = {Where did Knowledge management come from},
- journal = {IBM Systems Journal},
- year = {2001},
- volume = {Volume 40},
- pages = {pp. 1002-1007. },
- number = {Number 4},
- owner = {Sauermann},
- pdf = {Prusak2001.pdf},
-}
-
-@TECHREPORT{PWMKM2003,
- author = {PWM.at},
- title = {Werkzeuge fĂźrWissensmanagement},
- institution = {PWM.at},
- year = {2003},
- keywords = {Wissensmanagement Tools KM Knowledge Management},
- owner = {Sauermann},
- pdf = {C:\Dokumente und Einstellungen\Sauermann\Eigene Dateien\_quellen\softwarestudie_km_tools_2003_1_2.pdf},
-}
-
-@PHDTHESIS{QuanDiss2003,
- author = {Dennis Quan},
- title = {Designing End User Information Environments Built on Semistructured
- Data Models},
- school = {MIT},
- year = {2003},
- owner = {sauermann},
- pdf = {QuanDiss2003.pdf},
- timestamp = {2006.11.01},
-}
-
-@INPROCEEDINGS{haystack-iswc2003,
- author = {Dennis Quan and David Huynh and David R. Karger},
- title = {Haystack: A Platform for Authoring End User Semantic Web Applications},
- booktitle = {International Semantic Web Conference},
- year = {2003},
- pages = {738-753},
- owner = {Sauermann},
- pdf = {haystack-iswc2003.pdf},
-}
-
-@TECHREPORT{Rath2003,
- author = {Holger Rath},
- title = {The Topic Maps Handbook --- Detailed description of the standard and
- practical guidelines for using it in knowledge management},
- institution = {empolis GmbH},
- year = {2003},
- type = {empolis White Paper},
- owner = {sauermann},
- timestamp = {2006.04.02},
-}
-
-@INPROCEEDINGS{reeve+2005,
- author = {Lawrence Reeve and Hyoil Han},
- title = {Survey of semantic annotation platforms},
- booktitle = {SAC '05: Proceedings of the 2005 ACM symposium on Applied computing},
- year = {2005},
- pages = {1634--1638},
- address = {New York, NY, USA},
- publisher = {ACM Press},
- doi = {http://doi.acm.org/10.1145/1066677.1067049},
- isbn = {1-58113-964-0},
- location = {Santa Fe, New Mexico},
- pdf = {reeve+2005.pdf},
-}
-
-@INPROCEEDINGS{Rhodes2000,
- author = {Bradley J. Rhodes},
- title = {Margin Notes: Building a Contextually Aware Associative Memory},
- booktitle = {Proceedings of the International Conference on Intelligent User Interfaces(IUI2000)},
- year = {2000},
- month = {January},
- note = {Software Agents Group, MIT Media Lab},
- journal = {The Proceedings of the Internatial Conference on Intelligent User
- Interfaces(IUI '00)},
- owner = {sauermann},
- timestamp = {2006.04.02},
-}
-
-@INPROCEEDINGS{richter2005,
- author = { JĂśrg Richter and Max VĂślkel and Heiko Haller},
- title = { DeepaMehta â A Semantic Desktop },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/30_dm_poster.pdf},
-}
-
-@INPROCEEDINGS{metadesk2004,
- author = {Robert MacGregor, Sameer Maggon, and Baoshi Yan.},
- title = {MetaDesk: A Semantic Web Desktop Manager},
- booktitle = {In Knowledge Markup and Semantic Annotation Workshop, ISWC 2004},
- year = {2004},
- month = {November},
- comment = {found in SeMouse Iturrioz2006},
- owner = {sauermann},
- pdf = {metadesk2004.pdf},
- timestamp = {2006.07.10},
-}
-
-@INPROCEEDINGS{Robertson+1998,
- author = {George Robertson and Mary Czerwinski and Kevin Larson and Daniel
- C. Robbins and David Thiel and Maarten van Dantzich},
- title = {Data mountain: using spatial memory for document management},
- booktitle = {UIST '98: Proceedings of the 11th annual ACM symposium on User interface
- software and technology},
- year = {1998},
- pages = {153--162},
- address = {New York, NY, USA},
- publisher = {ACM Press},
- doi = {http://doi.acm.org/10.1145/288392.288596},
- isbn = {1-58113-034-1},
- location = {San Francisco, California, United States},
- pdf = {Robertson+1998.pdf},
-}
-
-@INPROCEEDINGS{robles+2005volunteer_evolution,
- author = {Robles, Gregorio and Gonzalez-Barahona, Jesus M. and Michlmayr, Martin},
- title = {Evolution of Volunteer Participation in Libre Software Projects:
- Evidence from {D}ebian},
- booktitle = {Proceedings of the First International Conference on Open Source
- Systems},
- year = {2005},
- editor = {Scotto, Marco and Succi, Giancarlo},
- pages = {100-107},
- address = {Genova, Italy},
- abstract = {Most libre software projects rely on the work of volunteers. Therefore,
- attracting people who contribute their time and technical skills
- is of paramount importance, both in technical and economic terms.
- This reliance on volunteers leads to some fundamental management
- challenges: volunteer contributions are inherently difficult to
- predict, plan and manage, especially in the case of large projects.
- In this paper we analyze the evolution in time of the human resources
- of one of the largest and most complex libre software projects composed
- primarily of volunteers, the Debian project. Debian currently has
- around 1300 volunteers working on several tasks: much activity is
- focused on packaging software applications and libraries, but there
- is also major work related to the maintenance of the infrastructure
- needed to sustain the development. We have performed a quantitative
- investigation of data from almost seven years, studying how volunteer
- involvement has affected the software released, and the developer
- community itself.},
- pdf = {robles+2005volunteer_evolution.pdf},
-}
-
-@INPROCEEDINGS{rohmer2005,
- author = { Jean Rohmer},
- title = { Lessons for the future of Semantic Desktops learnt from 10 years
- of experience with the IDELIANCE Semantic Networks Manager },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/21_Rohmer_Semanticdesktop_final.pdf},
-}
-
-@INCOLLECTION{Sauermann2006b,
- author = {Leo Sauermann},
- title = {Semantic Desktop â Der Arbeitsplatz der Zukunft},
- booktitle = {Semantic {W}eb -- {A}uf dem {W}eg zur vernetzten {W}issensgesellschaft},
- publisher = {Springer Verlag},
- year = {2006},
- editor = {Andreas Blumauer and Tassilo Pellegrini},
- series = { X.media.press},
- pages = {161-176},
- abstract = {Der Arbeitsplatz der Zukunft wird anders sein als der heutige
-
- Status Quo, die Ănderungen finden auf verschiedenen Ebenen statt:
- Technik,
-
- Informationsrepräsentation und soziale Verhaltensweisen. In diesem
- Kapitel werden
-
- aktuelle Ansätze aus verschiedenen Forschungsgebieten beschrieben
- und
-
- kombiniert, von Semantic Web bis zu Visualisierung. Semantische Technologien
-
- ermĂśglichen es, die bestehenden Daten eines Benutzers neu zu interpretieren
- und
-
- zu verwenden, dabei bringt die Kombination von Semantic Web und Desktop
-
- Computern besondere Vorteile, ein Paradigma, das unter dem Titel Semantic
-
- Desktop vorgestellt wird.},
- doi = {ISBN 3-540-29324-8},
- language = {german},
- owner = {sauermann},
- url = {http://www.semantic-web.at/springer},
-}
-
-@INPROCEEDINGS{Sauermann2005b,
- author = {Leo Sauermann},
- title = {The Semantic Desktop - a Basis for Personal Knowledge Management},
- booktitle = {Proceedings of the I-KNOW 2005. 5th International Conference on Knowledge
- Management},
- year = {2005},
- editor = {Hermann Maurer and Cristian Calude and Arto Salomaa and Klaus Tochtermann},
- pages = {294 - 301},
- doi = {ISSN 0948-695x},
- owner = {Sauermann},
- pdf = {Sauermann2005b.pdf},
- url = {http://www.dfki.uni-kl.de/\~sauermann/papers/Sauermann2005b.pdf},
-}
-
-@TECHREPORT{Sauermann2006c,
- author = {Leo Sauermann},
- title = {PIMO-a PIM Ontology for the Semantic Desktop (draft)},
- institution = {DFKI},
- year = {2006},
- type = {Draft},
- owner = {sauermann},
- timestamp = {2006.05.12},
- url = {http://www.dfki.uni-kl.de/\~sauermann/2006/01-pimo-report/pimOntologyLanguageReport.html},
-}
-
-@INPROCEEDINGS{Sauermann2005a,
- author = {Leo Sauermann},
- title = {The Gnowsis Semantic Desktop for Information Integration},
- booktitle = {Proceedings of the IOA 2005 Workshop at the WM},
- year = {2005},
- publisher = {Springer},
- owner = {Sauermann},
- pdf = {Sauermann2005a.pdf},
- url = {http://www.dfki.uni-kl.de/\~sauermann/papers/Sauermann2005a.pdf},
-}
-
-@MASTERSTHESIS{Sauermann2003,
- author = {Leo Sauermann},
- title = {The Gnowsis-Using Semantic Web Technologies to build a Semantic Desktop},
- school = {Technical University of Vienna},
- year = {2003},
- type = {Diploma thesis},
- pdf = {Sauermann2003.pdf},
- url = {http://www.dfki.uni-kl.de/\~sauermann/papers/sauermann2003.pdf},
-}
-
-@INPROCEEDINGS{sauermann2005,
- author = { Leo Sauermann and Ansgar Bernardi and Andreas Dengel},
- title = { Overview and Outlook on the Semantic Desktop },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/18_sauermann_overviewsemdesk_final.pdf},
-}
-
-@INPROCEEDINGS{Sauermann+2005d,
- author = {Leo Sauermann and Ansgar Bernardi and Andreas Dengel},
- title = {Overview and Outlook on the Semantic Desktop},
- booktitle = {Proceedings of the 1st Workshop on The Semantic Desktop at the ISWC
- 2005 Conference},
- year = {2005},
- editor = {Stefan Decker, Jack Park, Dennis Quan, and Leo Sauermann},
- abstract = {In this paper we will give an overview of the Semantic Desktop paradigm,
- beginning with the history of the term, a definition, current work
- and its relevance to knowledge management of the future. Existing
- applications and research results are listed and their role as building
- blocks of the future Semantic Desktop described. Based on the analysis
- of existing systems we propose two software architecture paradigms,
- one for the Semantic Desktop at large and another for applications
- running on a Semantic Desktop. A view on the context aspect of the
- Semantic Desktop and the Knowledge Management aspect is given. Based
- on the current events and projects, we give an outlook on the next
- steps.},
- owner = {Sauermann},
- pdf = {Sauermann+2005d.pdf},
- url = {http://www.dfki.uni-kl.de/\~sauermann/papers/Sauermann+2005d.pdf},
-}
-
-@TECHREPORT{Sauermann+2007a,
- author = {Leo Sauermann and Richard Cyganiak and Max V\"olkel},
- title = {Cool {URIs} for the Semantic Web},
- institution = {DFKI GmbH},
- year = {2007},
- type = {Technical Memo},
- number = {TM-07-01},
- address = {Deutsches Forschungszentrum f \"ur K\"unstliche Intelligenz GmbH
-
- Postfach 2080
-
- 67608 Kaiserslautern},
- month = {February},
- note = {Written by 29.11.2006},
- abstract = {The Resource Description Framework RDF allows you to describe web
- documents and resources from the real worldâpeople, organisations,
- thingsâin a computer-processable way. Publishing such descriptions
- on the web creates the semantic web. URIs are very important as
- the link between
-
- RDF and the web. This article presents guidelines for their effective
- use. We discuss two strategies, called 303 URIs and hash URIs. We
- give pointers to several web sites that use these solutions, and
- briefly discuss why several other proposals have problems.},
- owner = {sauermann},
- pdf = {Sauermann+2007a.pdf},
- timestamp = {2007.03.08},
- url = {http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/tm-07-01.pdf},
-}
-
-@INPROCEEDINGS{Sauermann+2006a,
- author = {Leo Sauermann and Andreas Dengel and Ludger van Elst and Andreas
- Lauer and Heiko Maus and Sven Schwarz},
- title = {Personalization in the EPOS project},
- booktitle = {Proceedings of the Semantic Web Personalization Workshop at the ESWC
- 2006 Conference},
- year = {2006},
- pages = {42 - 52},
- abstract = {In this work we present the results of the EPOS project with regard
- to the needs of personalization in the Semantic Web. Focus of this
- work is the subjective view of an individual person, expressed in
- a Personal Information Model (PIMO). It is matched both with personal
- resources (files, e-mails, and websites) of the user and organizational
- knowledge (ontologies). A user observation component gathers actions
- of the user to calculate the current context with regards to current
- goals and matching elements in the userâs PIMO. Combined, the representation
- of the userâs stored information and the current context provide
- a thorough representation of the user. Desktop applications can
- use this representation to provide personalized services. Three
- special purpose applications were implemented: a search engine,
- a context-sensitive assistant, and a tool for filing new information.
- An evaluation of this approach showed that it increases productivity
- and indeed reflects the subjective view of users. Also, the approach
- satisfies most of the requirements of an Adaptive Educational Hypermedia
- System AEHS. Parts of this work are published as open source projects.},
- owner = {sauermann},
- pdf = {Sauermann+2006a.pdf},
- timestamp = {2006.05.11},
- url = {http://www.dfki.uni-kl.de/\~sauermann/papers/Sauermann+2006a.pdf},
-}
-
-@INPROCEEDINGS{Sauermann+2006d,
- author = {Leo Sauermann and Gunnar Aastrand Grimnes and Malte Kiesel and Christiaan
- Fluit and Heiko Maus and Dominik Heim and Danish Nadeem and Benjamin
- Horak and Andreas Dengel},
- title = {Semantic Desktop 2.0: The {Gnowsis} Experience},
- booktitle = {Proc. of the ISWC Conference},
- year = {2006},
- pages = {887-900},
- month = {Nov},
- abstract = {In this paper we present lessons learned from building a Semantic
- Desktop system, the gnowsis beta. On desktop computers, semantic
- software has to provide stable services and has to reflect the personal
- view of the user. Our approach to ontologies, the Personal Information
- Model PIMO allows to create tagging services like del.icio.us on
- the desktop. A semantic wiki allows further annotations. Continuous
- evaluations of the system helped to improve it. These results were
- created in the EPOS research project and are available in the open
- source projects Aperture, kaukoluwiki, and gnowsis and will be continued
- in the Nepomuk project. By using these components, other developers
- can create new desktop applications the web 2.0 way.},
- doi = {http://dx.doi.org/10.1007/11926078_64},
- ee = {http://dx.doi.org/10.1007/11926078_64},
- owner = {sauermann},
- pdf = {Sauermann+2006d.pdf},
- timestamp = {2006.05.31},
- url = {http://www.dfki.uni-kl.de/\~sauermann/papers/Sauermann+2006d.pdf},
-}
-
-@INPROCEEDINGS{Sauermann+2005c,
- author = {Leo Sauermann and Sven Schwarz},
- title = {Gnowsis Adapter Framework: Treating Structured Data Sources as Virtual
- RDF Graphs},
- booktitle = {Proceedings of the ISWC 2005},
- year = {2005},
- abstract = {The integration of heterogenous data sources is a crucial step for
- the upcoming semantic web â if existing information is not integrated,
- where will the data come from that the semantic web builds on? In
- this paper we present the gnowsis adapter framework, an implementation
- of an RDF graph system that can be used to integrate structured
- data sources, together with a set of already implemented adapters
- that can be used in own applications or extended for new situations.
- We will give an overview of the architecture and implementation
- details together with a description of the common problems in this
- field and our solutions, leading to an outlook on the future developments
- we expect. Using our presented results, researchers can generate
- test data for experiments and practitioners can access their desktop
- data sources as RDF graph.},
- owner = {Sauermann},
- pdf = {Sauermann+2005c.pdf},
- url = {http://www.dfki.uni-kl.de/\~sauermann/papers/Sauermann+2005c.pdf},
-}
-
-@INPROCEEDINGS{SauermannSchwarz2004,
- author = {Leo Sauermann and Sven Schwarz},
- title = {Introducing the Gnowsis Semantic Desktop},
- booktitle = {Poster at the International Semantic Web Conference ISWC 2004},
- year = {2004},
- owner = {Sauermann},
- pdf = {SauermannSchwarz2004.pdf},
- url = {http://iswc2004.semanticweb.org/posters/PID-QLIOYDYE-1090244935.pdf},
-}
-
-@TECHREPORT{HPL-2003-235R1,
- author = {Craig Sayers and Alan H. Karp},
- title = {Computing the digest of an RDF graph},
- institution = {HPL},
- year = {2003},
- number = {HPL-2003-235R1 20040326 External },
- owner = {Sauermann},
- pdf = {HPL-2003-235R1.pdf},
-}
-
-@INPROCEEDINGS{Schneider+2005,
- author = {Michael Schneider and Mathias Bauer and Alexander KrĂśner},
- title = {Building a Personal Memory for Situated User Support},
- booktitle = {Proc. of the 1st Workshop on Exploiting Context Histories in Smart
- Environments ECHISE at Pervasive2005},
- year = {2005},
- owner = {sauermann},
- pdf = {Schneider+2005.pdf},
- timestamp = {2006.05.12},
-}
-
-@INPROCEEDINGS{SchumacherBergmann00b,
- author = {J{\"u}rgen Schumacher and Ralph Bergmann},
- title = {An Efficient Approach to Similarity-Based Retrieval on Top of Relational
- Databases},
- booktitle = {Advances in Case-Based Reasoning, Proceedings of the 5th European
- Workshop on Case-Based Reasoning, {EWCBR 2000}, Trento, Italy},
- year = {2000},
- editor = {Enrico Blanzieri and Luigi Portinale},
- pages = {273--284},
- address = {Berlin},
- publisher = {Springer-Verlag},
- pdf = {SchumacherBergmann00b.pdf},
-}
-
-@INPROCEEDINGS{schwabe2005,
- author = { Daniel Schwabe and Daniela Brauner and Demetrius A. Nunes and Guilherme
- Mamede},
- title = { HyperSD: a Semantic Desktop as a Semantic Web Application },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/38_schwabe_hyperde_poster.pdf},
-}
-
-@INPROCEEDINGS{Schwarz2006,
- author = {Sven Schwarz},
- title = {A Context Model for Personal Knowledge Management Applications},
- booktitle = {Modeling and Retrieval of Context, Second International Workshop,
- MRC 2005, Edinburgh, UK, July 31 - August 1, 2005, Revised Selected
- Papers},
- year = {2006},
- editor = {Thomas Roth-Berghofer and Stefan Schulz and David B. Leake},
- volume = {3946},
- series = {Lecture Notes in Computer Science},
- pages = {18--33},
- publisher = {Springer},
- isbn = {3-540-33587-0},
- language = {english},
- pdf = {Schwarz2006.pdf},
- url = {http://www.springerlink.com/content/4526400657457v8t/},
-}
-
-@INPROCEEDINGS{Schwarz2005,
- author = {Sven Schwarz},
- title = {A Context Model for Personal Knowledge Management},
- booktitle = {Proceedings of the IJCAII'05 Workshop on Modeling and Retrieval of
- Context},
- year = {2005},
- address = {Edinburgh},
- pdf = {Schwarz2005.pdf},
- url = {http://www.dfki.uni-kl.de/~schwarz/docs/Schwarz2005.pdf},
-}
-
-@INPROCEEDINGS{SchwarzRoth-Berghofer03,
- author = {Sven Schwarz and Thomas Roth-Berghofer},
- title = {Towards Goal Elicitation by User Observation},
- booktitle = {Proceedings of the FGWM 2003 Workshop on Knowledge and Experience
- Management},
- year = {2003},
- address = {Karlsruhe},
- keywords = {H1021, H1022, I2046, I2045, H3},
- pdf = {SchwarzRoth-Berghofer03.pdf},
-}
-
-@ARTICLE{SemWeb2006,
- author = {Shadbolt, N. and Berners-Lee, T. and Hall, W.},
- title = {The Semantic Web Revisited},
- journal = {IEEE Intelligent Systems},
- year = {2006},
- volume = {21},
- pages = {96-101},
- abstract = {The original Scientific American article on the Semantic Web appeared
- in 2001. It described the evolution of a Web that consisted largely
- of documents for humans to read to one that included data and information
- for computers to manipulate. The Semantic Web is a Web of actionable
- information--information derived from data through a semantic theory
- for interpreting the symbols.This simple idea, however, remains
- largely unrealized. Shopbots and auction bots abound on the Web,
- but these are essentially handcrafted for particular tasks; they
- have little ability to interact with heterogeneous data and information
- types. Because we haven't yet delivered large-scale, agent-based
- mediation, some commentators argue that the Semantic Web has failed
- to deliver. We argue that agents can only flourish when standards
- are well established and that the Web standards for expressing shared
- meaning have progressed steadily over the past five years. Furthermore,
- we see the use of ontologies in the e-science community presaging
- ultimate success for the Semantic Web--just as the use of HTTP within
- the CERN particle physics community led to the revolutionary success
- of the original Web. This article is part of a special issue on
- the Future of AI.},
- doi = {issn:1541-1672},
- owner = {sauermann},
- pdf = {SemWeb2006.pdf},
- timestamp = {2006.07.24},
- url = {http://www.geospatialsemanticweb.com/wp-content/uploads/2006/07/01637364.pdf},
-}
-
-@INPROCEEDINGS{ShkundinaSchwarz05,
- author = {Roza Shkundina and Sven Schwarz},
- title = {A Similarity Measure for Task Contexts},
- booktitle = {Proceedings of the Workshop Similarities - Processes - Workflows
- in conjunction with the 6th International Conference on Case-Based
- Reasoning (ICCBR 2005)},
- year = {2005},
- address = {Chicago},
- month = {aug},
- language = {english},
- owner = {sauermann},
- timestamp = {2006.04.02},
- url = {http://www.dfki.uni-kl.de/\~schwarz/docs/ShkundinaSchwarz2005.pdf},
-}
-
-@ARTICLE{ShneidermanBedersonDrucker06,
- author = {Ben Shneiderman and Benjamin B. Bederson and Steven M. Drucker},
- title = {Find that photo!: interface strategies to annotate, browse, and share},
- journal = {Commun. ACM},
- year = {2006},
- volume = {49},
- pages = {69--71},
- number = {4},
- address = {New York, NY, USA},
- comment = {recommended by Heiko Maus, 28.3.2006},
- doi = {http://doi.acm.org/10.1145/1121949.1121985},
- issn = {0001-0782},
- pdf = {ShneidermanBedersonDrucker06.pdf},
- publisher = {ACM Press},
-}
-
-@ARTICLE{Shvaiko+2005,
- author = {P. Shvaiko and J. Euzenat},
- title = {A Survey of Schema-based Matching Approaches},
- journal = {Journal on Data Semantics},
- year = {2005},
- keywords = {ontology matching alignment survey},
- owner = {Sauermann},
- pdf = {Shvaiko+2005.pdf},
-}
-
-@INPROCEEDINGS{Siebert+2006a,
- author = {Mark Siebert and Pierre Smits and Leo Sauermann and Andreas Dengel},
- title = {Personalized document retrieval in multi-party environments with
- the semantic desktop},
- booktitle = {Proceedings of the IEEE International Workshop on the Electronic
- Document Management in an Enterprise Computing Environment (IEEE
- EDM 2006) to be held in
-
- conjunction with the Tenth IEEE International EDOC Conference (IEEE
- EDOC 2006)},
- year = {2006},
- month = {October},
- owner = {sauermann},
- timestamp = {2006.08.07},
- url = {http://www4.comp.polyu.edu.hk/\~edoc06/workshop/edm.html},
-}
-
-@INPROCEEDINGS{Siebert+2006b,
- author = {Mark Siebert and Pierre Smits and Leo Sauermann and Andreas Dengel},
- title = {Increasing Search Quality with the Semantic Desktop in Proposal Development},
- booktitle = {Proceedings of the Practical Aspects of Knowledge Management PAKM
- conference},
- year = {2006},
- volume = {4333/2006},
- series = {Lecture Notes in Computer Science},
- pages = {279-290},
- publisher = {Springer Berlin / Heidelberg},
- abstract = {Quicker response times and less production costs of proposal development
- require further automation of sales assistant functionality in CRM
- environments. Automation still struggles with the handling of abstraction
- and the subjective character of knowledge. Based on the knowledge
- creation framework the paper outlines and tests the increase of
- search quality with Semantic
-
- Desktop technology. The discussion of peer-to-peer settings and semantic
- concepts illustrates the influence of individual perspectives on
- search quality. It reveals first potentials and benefits for process-integration,
- like semantic CRM and illustrates approaches to increase knowledge
- workerâs productivity.},
- doi = {http://dx.doi.org/10.1007/11944935_25},
- owner = {sauermann},
- timestamp = {2006.10.13},
-}
-
-@INPROCEEDINGS{magnet-sigmod2005,
- author = {Vineet Sinha and David R. Karger},
- title = {Magnet: Supporting Navigation in Semistructured Data Environments},
- booktitle = {in SIGMOD 2005},
- year = {2005},
- comment = {http://cimic.rutgers.edu/~sigmod05/},
- owner = {Sauermann},
- pdf = {magnet-sigmod2005.pdf},
- url = {http://haystack.lcs.mit.edu/publications.html},
-}
-
-@MASTERSTHESIS{Smits2006,
- author = {Pierre Smits},
- title = {Auswirkungen des individuellen Arbeitsplatzes auf die semantische
- Suche},
- abstract = {KĂźrzere Antwortzeiten und geringere Produktionskosten erfordern weitergehende
- Automatisierung der Sales
-
- Assistenten Funktionalität in CRM Umgebungen. Bei der Automatisierung
- werden Abstraktionslevel und
-
- der subjektive Charakter bei der Entstehung von Dokumenten in wissensintensiven
- Prozessen immer noch
-
- nicht (ausreichend) berĂźcksichtigt. Auf Basis des Knowledge Creation
- Frameworks wird anhand von
-
- Tests die Veränderung / Verbesserung der Qualität von Suchergebnissen,
- durch Verwendung semantischer
-
- Suchtechnologie, im Rahmen der peer-to-peer Sucher des Semantic Desktops
- Gnowsis, im Vergleich zu Standard-
-
- Suchtechnologien, wie sie bei Google (Desktop) oder LiveLink zu finden
- sind, veranschaulicht. Die Diskussion
-
- Ăźber die Verwendung von peer-to-peer, sowie semantischer Suche zeigt
- das Potential einer mĂśglichen Einbindung
-
- in ein semantisches CRM.},
- owner = {sauermann},
- pdf = {Smits2006.pdf},
- timestamp = {2006.07.06},
-}
-
-@INPROCEEDINGS{Staab+2000,
- author = {Steffen Staab and Michael Erdmann and Alexander Maedche and Stefan
- Decker},
- title = {An extensible approach for Modeling Ontologies in RDF(S)},
- booktitle = {Proc. of First Workshop on the Semantic Web at the Fourth European
- Conference International Workshop on Research and Advanced Technology
- for Digital Libraries, Lisbon, Portugal 18-20 September 2000},
- year = {2000},
- month = {SEP},
- pdf = {Staab+2000.pdf},
- url = {\url{http://www.aifb.uni-karlsruhe.de/WBS/Publ/2000/ecdl-sstetal.pdf}},
-}
-
-@TECHREPORT{Ontolinks-Studie,
- author = {Stefan Agne, Ludger van Elst und Bidjan Tschaitschian},
- title = {OntoLinks Beziehungen und deren Nutzung in Ontologien},
- institution = {DFKI},
- year = {2000},
- month = {March},
- owner = {Sauermann},
- pdf = {Ontolinks-Studie.pdf},
-}
-
-@TECHREPORT{XTM,
- author = {Steve Pepper, Graham Moore (eds).},
- title = {{XML Topic Maps (XTM)} 1.0.},
- institution = {TopicMaps.Org},
- year = {2001},
- type = {Specification},
- owner = {sauermann},
- timestamp = {2006.04.02},
- url = {http://www.topicmaps.org/xtm/},
-}
-
-@TECHREPORT{SticklerCBD2004,
- author = {Patrick Stickler},
- title = {{CBD} - Concise Bounded Description},
- institution = {NOKIA},
- year = {2004},
- note = {http://sw.nokia.com/uriqa/CBD.html},
- abstract = {This document defines a concise bounded description of a resource
- in terms of an RDF graph, as a general and broadly optimal unit
- of specific knowledge about that resource to be utilized by, and/or
- interchanged between, semantic web agents.},
- owner = {Sauermann},
- url = {http://sw.nokia.com/uriqa/CBD.html},
-}
-
-@TECHREPORT{SticklerUriqa2004,
- author = {Patrick Stickler},
- title = {The {URI} Query Agent Model - A Semantic Web Enabler},
- institution = {NOKIA},
- year = {2004},
- note = {http://sw.nokia.com/uriqa/URIQA.html},
- owner = {Sauermann},
-}
-
-@INPROCEEDINGS{staeudel2005,
- author = { Markus Stäudel and Bertin Klein and and Stefan Agne},
- title = { Pen-based Acquisition of Real World Annotations for Document Information
- Spaces },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/20_staeudel_penbased_final.pdf},
-}
-
-@ARTICLE{Sure2004,
- author = {York Sure},
- title = {Perspective on Semantic Web Technologies},
- journal = {Proceedings of I-KNOW},
- year = {2004},
- owner = {Sauermann},
-}
-
-@TECHREPORT{Tazzoli2004,
- author = {Roberto Tazzoli and Paolo Castagna and Stefano Emilio Campanini},
- title = {Towards a Semantic Wiki Wiki Web},
- institution = {Demo at the ISWC2004},
- year = {2004},
- abstract = {This article describes PlatypusWiki, an enhanced Wiki Wiki Web using
- technologies from the Semantic Web. Platypus Wiki offers a simple
- user interface to create Wiki pages including metadata according
- to W3C standards. It uses RDF, RDF Schema and OWL to manage the
- metadata and create ontologies. We present the essential features
- of what we have called a Semantic Wiki Wiki Web, showing how the
- existing Wiki WikiWeb can be improved and how we have implemented
- these features in Platypus Wiki. Platypus Wiki is a rapid and useful
- Personal Knowledge Management system, as well as a valuable tool
- to manage Communities of Practice.},
- owner = {Sauermann},
- url = {http://platypuswiki.sourceforge.net/whatis/documents/platypuswiki.pdf},
-}
-
-@PHDTHESIS{Fielding2000,
- author = {Fielding R. Thomas},
- title = {Architectural Styles and the Design of Network-based Software Architectures},
- school = {University of California, Irvine},
- year = {2000},
- type = {Doctoral dissertation},
- keywords = {RESTful},
- owner = {Sauermann},
- pdf = {Fielding2000.pdf},
-}
-
-@TECHREPORT{Thompson+2006draft,
- author = {Henry S. Thompson and David Orchard},
- title = {URNs, Namespaces and Registries},
- institution = {W3C},
- year = {2006},
- type = {[Editor's Draft] TAG Finding},
- note = {\url{http://www.w3.org/2001/tag/doc/URNsAndRegistries-50}},
- owner = {sauermann},
- timestamp = {2006.10.30},
- url = {\url{http://www.w3.org/2001/tag/doc/URNsAndRegistries-50}},
-}
-
-@INPROCEEDINGS{dbin2005,
- author = {G. Tummarello and C. Morbidoni and P. Puliti and F. Piazza},
- title = {The DBin Semantic Web platform: an overview},
- booktitle = {Proc. of the WWW2005 Workshop on The Semantic Computing Initiative
- SeC},
- year = {2005},
- abstract = {DBin is a tool to build âSemantic Web P2P communitiesâ.
-
- It provides a general platform on top of which it is possible
-
- to create and run P2P Semantic Web applications where
-
- users contribute by annotating topics of common interest.
-
- DBin introduces a Semantic Computing scenario where
-
- users âslowlyâ, but in a sustainable way, build a local DB
-
- and can then enjoy a variety of semantic based activities
-
- such as browsing or intelligent interaction with the local
-
- media and files. DBin accommodates a number of
-
- experimental modules to deal with specific kind of
-
- metadata (audio metadata extraction, textual analysis,
-
- desktop integration) as well as a domain oriented user
-
- interface. DBin includes an RDF subgraph digital
-
- signature facility enabling personalized trust policies to
-
- provide filtering out unwanted information. Maximum
-
- extendibility is guaranteed by the use of the Eclipse Rich
-
- Client platform and by the Open Source model.},
- owner = {sauermann},
- pdf = {dbin2005.pdf},
- timestamp = {2006.05.12},
-}
-
-@INPROCEEDINGS{Tummarello+2006ISWC,
- author = {Tummarello, Giovanni and Morbidoni, Christian and Nucci, Michele},
- title = {Enabling Semantic Web Communities with DBin: An Overview},
- booktitle = {Proceedings of the ISWC},
- year = {2006},
- pages = {943--950},
- citeulike-article-id = {1154267},
- doi = {10.1007/11926078_69},
- journal = {: The Semantic Web - ISWC 2006},
- keywords = {iswc2006 rdf},
- pdf = {Tummarello+2006ISWC.pdf},
- priority = {3},
- url = {http://dx.doi.org/10.1007/11926078_69},
-}
-
-@INPROCEEDINGS{Voelkel+2006a,
- author = {Max V\&\#246;lkel and Markus Kr\&\#246;tzsch and Denny Vrandecic
- and Heiko Haller and Rudi Studer},
- title = {Semantic Wikipedia},
- booktitle = {WWW '06: Proceedings of the 15th international conference on World
- Wide Web},
- year = {2006},
- pages = {585--594},
- address = {New York, NY, USA},
- publisher = {ACM Press},
- doi = {http://doi.acm.org/10.1145/1135777.1135863},
- isbn = {1-59593-323-9},
- location = {Edinburgh, Scotland},
- pdf = {Voelkel+2006a.pdf},
-}
-
-@TECHREPORT{voelkel-oren-2005_spkm,
- author = {Max V{\"{o}}lkel and Eyal Oren},
- title = {Personal Knowledge Management with Semantic Wikis},
- institution = {AIFB Karlsruhe},
- year = {2005},
- month = {DEC},
- abstract = {Managing knowledge is crucial in our economy. We derive requirements
-
- on personal knowledge management (finding, reminding, collaboration,
-
- knowledge re-use and cognitively adequate interfaces) from
-
- cognitive psychological research and analyse the limitations of current
-
- solutions. We introduce a restful, wiki-based, open architecture for
- semantic
-
- personal knowledge management that fulfills the analysed requirements
-
- to a high extent and gives the user a uniform way to work
-
- with knowledge on all layers (syntax, structure, formal semantics).
- We
-
- discuss architectural considerations and describe two implementations.},
- url = {citeseer.ist.psu.edu/743974.html},
-}
-
-@ARTICLE{TechnologyRadar2006web30,
- author = {Wolfgang Wahlster and Andreas Dengel, with contributions by Dietmar
- Dengler, Dominik Heckmann, Malte Kiesel, Alexander Pfalzgraf, Thomas
- Roth-Berghofer, Leo Sauermann, Eric Schwarzkopf, and Michael Sintek},
- title = {Web 3.0: Convergence of Web 2.0 and the Semantic Web},
- journal = {Technology Radar},
- year = {2006},
- volume = {II},
- pages = {1-23},
- month = {June},
- abstract = {The World Wide Web (WWW) has drastically improved access to digitally
- stored information. However, content in the WWW has so far only
- been machine-readable but not machineunderstandable. Since information
- in the WWW is mostly represented in natural language, the available
- documents are only fully understandable by human beings. The Semantic
- Web is based on the content-oriented description of digital documents
- with standardized vocabularies that provide machine understandable
- semantics. The result is the transformation from a Web of Links
- into a Web of Meaning/Semantic Web [ ], (see arrow A in Fig. ).
- On the other hand, the traditional Web .0 has recently undergone
- an orthogonal shift into a Web of People/Web 2.0 where the focus
- is set on folksonomies, collective intelligence, and the wisdom
- of groups (see arrow B in Fig. ). Only the combined muscle of semantic
- web technologies and broad user participation will ultimately lead
- to a Web 3.0, with completely new business opportunities in all
- segments of the ITC market. Without Web 2.0 technologies and without
- activating the power of community-based semantic tagging, the emerging
- semantic web cannot be scaled and broadened to the level that is
- needed for a complete transformation of the current syntactic web.
- On the other hand, current Web 2.0 technologies cannot be used for
- automatic service composition and open domain query answering without
- adding machine-understandable content descriptions based on semantic
- web technologies. The ultimate worldwide knowledge infrastructure
- cannot be fully produced automatically but needs massive user participation
- based on open semantic platforms and standards. The interesting
- and urgent question that arises is: what happens when the emerging
- Semantic Web and Web 2.0 intersect with their full potential? We
- analyze this question throughout this feature paper and present
- the converging idea that we call Web 3.0. We use the following definition
- in this paper: Web 3.0 = Semantic Web + Web 2.0. A good example
- for developing Web 3.0 is the mobile personal information assistant
- (see Fig. 2). The user makes queries using natural language, and
- the assistant answers by extracting and combining information from
- the entire web, evaluating the information found while applying
- Semantic Web technologies. Todayâs second-generation search engines
- are based on keywords within the syntactic web, while open domain
- question answering engines are based on information extraction and
- the Semantic Web.},
- owner = {sauermann},
- pdf = {TechnologyRadar2006web30.pdf},
- timestamp = {2006.11.17},
-}
-
-@INPROCEEDINGS{Weippl+04,
- author = {Edgar R Weippl and Alexander Schatten and Shuaib Karim and A. Min
- Tjoa },
- title = {SemanticLIFE Collaboration: Security Requirements and Solutions -
- Security Aspects of Semantic Knowledge Management },
- booktitle = {PAKM 2004, LNAI 3336},
- year = {2004},
- editor = {D. Karagiannis and U. Reimer},
- organization = {Vienna University of Technology},
- abstract = {SemanticLIFE is a project that stores all information an individual
- works with in a semantically enriched form. Ontologies are used
- to improve the search process and to express queries in the way
- humans think ? e.g. ?Find the draft I?ve been working on when traveling
- home from the conference in Chi- cago?. When people cooperate on
- projects they obviously need to share infor- mation without spending
- time on entering keywords and thinking about who should be able
- to access which data; the issue is to correctly configure access
- controls so that only required information is shared with the appropriate
- people. Using a combination of the Chinese Wall and the Bell LaPadula
- model we show how access controls can be configured correctly with
- little effort by the users. },
- owner = {Sauermann},
- pdf = {Weippl+04.pdf},
-}
-
-@ARTICLE{Whittaker2001,
- author = {Steve Whittaker and Julia Hirschberg},
- title = {The Character, Value, and Management of Personal Paper Archives},
- journal = {ACM Transactions on Computer-Human Interaction},
- year = {2001},
- volume = {Vol. 8},
- pages = {Pages 150â170},
- number = {No. 2},
- month = {June},
- eid = {C° 2001 ACM 1073-0516/01/0600â0150 $5.00 , },
- note = {ATT LabsâResearch},
- abstract = {We explored general issues concerning personal information management
- by investigating the characteristics of office workersâ paper-based
- information, in an industrial research environment. We examined
- the reasons people collect paper, types of data they collect, problems
- encountered in handling paper, and strategies used for processing
- it. We tested three specific hypotheses in the course of an office
- move. The greater availability of public digital data along with
- changes in peopleâs jobs or interests should lead to wholescale
- discarding of paper data, while preparing for the move. Instead
- we found workers kept large, highly valued paper archives. We also
- expected that the major part of peopleâs personal archives would
- be unique documents. However, only 49% of peopleâs archives were
- unique documents, the remainder being copies of publicly available
- data and unread information, and we explore reasons for this. We
- examined the effects of paper-processing strategies on archive structure.
- We discovered different paper-processing strategies ( filing and
- piling) that were relatively independent of job type. We predicted
- that filersâ attempts to evaluate and categorize incoming documents
- would produce smaller archives that were accessed frequently. Contrary
- to our predictions, filers amassed more information, and accessed
- it less frequently than pilers. We argue that filers may engage
- in premature filing: to clear their workspace, they archive information
- that later turns out to be of low value. Given the effort involved
- in organizing data, they are also loath to discard filed information,
- even when its value is uncertain. We discuss the implications of
- this research for digital personal information management.},
- owner = {Sauermann},
- pdf = {Whittaker2001.pdf},
-}
-
-@MISC{wikipedia,
- author = {Wikipedia},
- title = {Wikipedia{,} the free encyclopedia},
- note = {http://en.wikipedia.org/},
-}
-
-@INPROCEEDINGS{witte2005,
- author = { Rene Witte and Petra Gerlach and Markus Joachim and Thomas Kappler
- and Ralf Krestel and and Praharshana Perera},
- title = { Engineering a Semantic Desktop for Building Historians and Architects},
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/34_witte_engineeringsd_final.pdf},
-}
-
-@INPROCEEDINGS{xiao2005,
- author = {Huiyong Xiao and Isabel F. Cruz},
- title = {A Multi-Ontology Approach for Personal Information Management},
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- pdf = {C:\Dokumente und Einstellungen\sauermann\Eigene Dateien\_projekte\2005_11_06_ISWC2005\semdeskworkshop\cameraready\32_xiaocruz_multiontology_final.pdf},
- url = {http:// CEUR-WS.org/Vol-175/32_xiaocruz_multiontology_final.pdf},
-}
-
-@INPROCEEDINGS{yu2005,
- author = { Haibo Yu and Tsunenori Mine and and Makoto Amamiya},
- title = { A Web Information Retrieval System Architecture Based on Semantic
- MyPortal },
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/35_yu_myportal_final.pdf},
-}
-
-@INPROCEEDINGS{zhang2005,
- author = { Xiang Zhang and Wennan Shen and Yuzhong Qu},
- title = { WonderDesk â A Semantic Desktop for Resource Sharing and Management},
- booktitle = {Proc. of Semantic Desktop Workshop at the ISWC, Galway, Ireland,
- November 6},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- month = {November},
- url = {http:// CEUR-WS.org/Vol-175/13_zhang_wonderdesk_poster.pdf},
-}
-
-@PROCEEDINGS{semdesk2005,
- title = {The Semantic Desktop - Next Generation Information Management \&
- Collaboration Infrastructure. Proc. of Semantic Desktop Workshop
- at the ISWC, Galway, Ireland},
- year = {2005},
- editor = {Stefan Decker and Jack Park and Dennis Quan and Leo Sauermann},
- volume = {175},
- series = {CEUR Workshop Proceedings ISSN 1613-0073},
- month = {November},
- keywords = {Semantic Desktop},
- owner = {sauermann},
- pdf = {http://CEUR-WS.org/Vol-175/SemanticDesktop2005Proceedings.pdf},
- timestamp = {2006.02.23},
- url = {http://CEUR-WS.org/Vol-175/},
-}
-
-@PROCEEDINGS{SemDeskWS2006,
- title = {Proceedings of the Semantic Desktop and Social Semantic Collaboration
- Workshop (SemDesk 2006)
-
- located at the 5th International Semantic Web Conference ISWC 2006},
- year = {2006},
- editor = {Stefan Decker and Jack Park and Leo Sauermann and S\"oren Auer and
- Siegfried Handschuh},
- volume = {202},
- series = {CEUR-WS},
- address = {Athens, GA, USA},
- month = {6th November 2006},
- doi = {ISSN: 1613-0073},
- owner = {sauermann},
- timestamp = {2006.12.21},
- url = {http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-202/},
-}
-
-@TECHREPORT{Exif-2.1,
- title = {Digital Still Camera Image File Format Standard (Exchangeable image
- file format for Digital Still Cameras: Exif) Version 2.1 },
- institution = {Japan Electronic Industry Development Association (JEIDA)},
- year = {1998},
- month = {June},
- owner = {Sauermann},
-}
-
-@MISC{dcmi,
- title = {The Dublin Core Metadata Initiative},
- howpublished = {http://dublincore.org/documents/dcmi-terms/},
- owner = {Sauermann},
-}
-
-@MISC{ExifTools,
- note = {Exif2RDF by Masahide Kanzaki, \url{http://www.kanzaki.com/test/exif2rdf
- JpegRDF by Norman Walsh http://nwalsh.com/java/jpegrdf/jpegrdf.html}},
- owner = {Sauermann},
-}
-
-@MISC{GnowsisProjectWebsite,
- title = {the gnowsis semantic desktop project website http://www.gnowsis.org},
- owner = {Sauermann},
- url = {http://www.gnowsis.org},
-}
-
-@comment{jabref-meta: selector_keywords:pim;semantic desktop;}
-
-@comment{jabref-meta: selector_publisher:Springer;}
-
-
-
-
-
-
-
-========================== END LEO.BIB ===========================
-
-
-
-
-
-
-
-@misc{SPARQLW3C,
- TITLE = {SPARQL Query Language for RDF},
- AUTHOR = {Eric Prud'hommeaux and Andy Seaborne},
- HOWPUBLISHED = {\url{http://www.w3.org/TR/rdf-sparql-protocol/}},
- URL = {\url{http://www.w3.org/TR/rdf-sparql-protocol/}}
-}
-
-@misc{RDFSemantics,
- TITLE = {RDF Semantics},
- AUTHOR = {Patrick Hayes},
- HOWPUBLISHED = {\url{http://www.w3.org/TR/rdf-mt/}},
- URL = {\url{http://www.w3.org/TR/rdf-mt/}}
-}
-
-@misc{DCSpec,
- TITLE = {Dublin Core Metadata Element Set, Version 1.1},
- PUBLISHER = {Dublin Core Metadata Initiative},
- KEY = {Dublin Core Metadata Initiative},
- HOWPUBLISHED = {\url{http://www.dublincore.org/documents/dces/}},
- URL = {\url{http://www.dublincore.org/documents/dces/}}
-}
-
-@misc{EXIFRDF,
- TITLE = {Exif data description vocabulary},
- AUTHOR = {Masahide Kanzaki},
- HOWPUBLISHED = {\url{http://www.kanzaki.com/ns/exif}},
- URL = {\url{http://www.kanzaki.com/ns/exif}}
-}
-
-@misc{RFC2426,
- TITLE = {vCard MIME Directory Profile},
- AUTHOR = {Frank Dawson and Tim Howes},
- URL = {\url{http://www.ietf.org/rfc/rfc2426.txt}},
- HOWPUBLISHED = {\url{http://www.ietf.org/rfc/rfc2426.txt}}
-}
-
-@misc{NRLSpec,
- TITLE = {NEPOMUK Representational Language (NRL) Vocabulary Specification [Draft]},
- AUTHOR = {Nepomuk Task Force Ontologies},
- HOWPUBLISHED = {\url{http://svn.nepomuk.semanticdesktop.org/repos/trunk/taskforce/TF-Ont/draft/NRL.html}},
- URL = {\url{http://svn.nepomuk.semanticdesktop.org/repos/trunk/taskforce/TF-Ont/draft/NRL.html}}
-}
-
-@misc{VCARDRDF,
- TITLE = {Representing vCard Objects in RDF/XML},
- AUTHOR = {Renato Ianella},
- HOWPUBLISHED = {\url{http://www.w3.org/TR/vcard-rdf}},
- URL = {\url{http://www.w3.org/TR/vcard-rdf}}
-}
-
-@misc{RFC2445,
- TITLE = {Internet Calendaring and Scheduling Core Objects Specification},
- AUTHOR = {Frank Dawson and Derik Stenerson},
- YEAR = {1998},
- HOWPUBLISHED = {\url{http://www.ietf.org/rfc/rfc2445.txt}},
- URL = {\url{http://www.ietf.org/rfc/rfc2445.txt}}
-}
-
-@misc{SWADDeliverable3.7,
- TITLE = {SWAD-Europe Deliverable 3.7: Developer Workshop Report 2 - Semantic Web calendaring},
- AUTHOR = {Libby Miller},
- YEAR = {2002},
- HOWPUBLISHED = {\url{http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_2/}},
- URL = {\url{http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_2/}}
-}
-
-@misc{TimBLICal,
- TITLE = {A quick look at iCalendar},
- AUTHOR = {Tim Berners-Lee},
- YEAR = {2001},
- HOWPUBLISHED = {\url{http://www.w3.org/2000/01/foo}},
- URL = {\url{http://www.w3.org/2000/01/foo}}
-}
-
-@misc{HybridIcal,
- TITLE = {Hybrid ICal RDF Schema},
- AUTHOR = {Michael Arick and Libby Miller},
- YEAR = {2001},
- HOWPUBLISHED = {\url{http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf}},
- URL = {\url{http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf}}
-}
-
-@misc{AnotherIcal,
- TITLE = {Another iCalendar model},
- AUTHOR = {Dan Connoly},
- YEAR = {2000},
- HOWPUBLISHED = {\url{http://www.w3.org/2000/10/swap/pim/ical.rdf}},
- URL = {\url{http://www.w3.org/2000/10/swap/pim/ical.rdf}}
-}
-
-@misc{PalmIcal,
- TITLE = {Palm Datebook},
- AUTHOR = {Dan Connoly},
- YEAR = {2000},
- HOWPUBLISHED = {\url{http://www.w3.org/2000/08/palm56/datebook}},
- URL = {\url{http://www.w3.org/2000/08/palm56/datebook}}
-}
-
-@misc{ICALRDF,
- TITLE = {RDF Calendar - an application of the Resource Description Framework to iCalendar Data},
- AUTHOR = {Dan Connolly and Libby Miller},
- HOWPUBLISHED = {\url{http://www.w3.org/TR/rdfcal/}},
- URL = {\url{http://www.w3.org/TR/rdfcal/}}
-}
-
-@misc{ID3Standard,
- TITLE = {ID3 Tag version 2.3.0 - Informal Standard},
- AUTHOR = {Martin Nilsson},
- HOWPUBLISHED = {\url{http://www.id3.org/id3v2.3.0}},
- URL = {\url{http://www.id3.org/id3v2.3.0}}
-}
-
-@InCollection{PereiraWalle2005,
- AUTHOR = {Fernando Pereira and Rik van de Walle},
- TITLE = {Multimedia Content description in MPEG-7 and MPEG-21},
- BOOKTITLE = {Multimedia Content and the Semantic Web},
- EDITOR = {Giorgios Stamou and Stefanos Kolias},
- PAGES = {3--43},
- PUBLISHER = {Wiley},
- YEAR = {2005}
-}
-
-@InCollection{Hunter2005,
- AUTHOR = {Jane Hunter},
- TITLE = {Adding Multimedia to the Semantic Web. Building an applying an MPEG-7 Ontology},
- BOOKTITLE = {Multimedia Content and the Semantic Web},
- EDITOR = {Giorgios Stamou and Stefanos Kolias},
- PAGES = {75--106},
- PUBLISHER = {Wiley},
- YEAR = {2005},
- URL = {\url{http://www.itee.uq.edu.au/~jane/jane-hunter/swws.pdf}}
-}
-
-@InProceedings{TsinarakiCAiSE2004,
- AUTHOR = {Chrisa Tsinaraki AND Panagiotis Polydoros AND Stavros Christodoulakis},
- TITLE = {Integration of OWL ontologies in MPEG-7 and TVAnytime compliant Semantic Indexing},
- BOOKTITLE = {Proc. of the 16th International Conference on Advanced Information Systems Engineering (CAiSE 2004)},
- MONTH = {June},
- YEAR = {2004},
- ADDRESS = {Riga, Latvia},
- URL = {\url{http://www.music.tuc.gr/Staff/Director/Publications/publ_files/C_TSPC_CAISE_2004.pdf}}
-}
-
-@InProceedings{TsinarakiRIAO2004,
- AUTHOR = {Chrisa Tsinaraki AND Panagiotis Polydoros AND Nektarios Moumoutzis AND Stavros Christodoulakis},
- TITLE = {Coupling OWL with MPEG-7 and TV-Anytime for Domain-specific
- Multimedia Information Integration and Retrieval},
- BOOKTITLE = {Proc. of RIAO 2004},
- MONTH = {April},
- YEAR = {2004},
- ADDRESS = {Avignon, France},
- URL = {\url{http://www.ced.tuc.gr/Staff/Director/Publications/publ_files/C_TPMC_RIAO_2004.pdf}}
-}
-
-@InProceedings{TsinarakiCIVR2004,
- AUTHOR = {Chrisa Tsinaraki AND Panagiotis Polydoros AND Stavros Christodoulakis},
- TITLE = {Interoperability support for Ontology-based Video Retrieval Applications},
- BOOKTITLE = {Proc. of 3rd International Conference on Image and Video Retrieval (CIVR 2004)},
- MONTH = {April},
- YEAR = {2004},
- ADDRESS = {Dublin, Ireland},
- URL = {\url{http://www.music.tuc.gr/Staff/Director/Publications/publ_files/C_TSPC_CIVR_2004.pdf}}
-}
-
-@InProceedings{GarciaCelma2005,
- AUTHOR = {Roberto Garcia AND Oscar Celma},
- TITLE = {Semantic Integration and Retrieval of Multimedia Metadata},
- BOOKTITLE = {Proceedings of the 5th International Workshop on Knowledge Markup
- and Semantic Annotation (SemAnnot 2005)},
- MONTH = {November},
- YEAR = {2005},
- ADDRESS = {Galway, Ireland},
- PUBLISHER = {\url{http://ceur-ws.org}}
-}
-
-@Misc{Vembu2005,
- AUTHOR = {Shankar Vembu and Malte Kiesel and Michael Sintek and Stephan Baumann},
- TITLE = {Towards Bridging the Semantic Gap in Multimedia Annotation and Retrieval},
- BOOKTITLE = {Proceedings of the 5th International Workshop on Knowledge Markup
- and Semantic Annotation (SemAnnot 2005)},
- MONTH = {May},
- YEAR = {2006},
- ADDRESS = {Edinburgh, UK},
- HOWPUBLISHED = {\url{http://image.ntua.gr/swamm2006/resources/paper18.pdf}}}
-}
-
-@Book{ISO:15938:P2,
- author = {International Organization for Standardization},
- title = {Information technology -- Multimedia content description interface --
- Part 2: Description definition language},
- publisher = {International Organization for Standardization},
- address = {Geneva, Switzerland},
- pages = {37},
- year = {2007},
- series = {International standard; ISO 15938}
-}
-
-@Book{ISO:15938:P3,
- author = {International Organization for Standardization},
- title = {Information technology -- Multimedia content description interface --
- Part 3: Visual},
- publisher = {International Organization for Standardization},
- address = {Geneva, Switzerland},
- pages = {175},
- year = {2007},
- series = {International standard; ISO 15938}
-}
-
-@Book{ISO:15938:P5,
- author = {International Organization for Standardization},
- title = {Information technology -- Multimedia content description interface --
- Part 5: Multimedia Description Schemes},
- publisher = {International Organization for Standardization},
- address = {Geneva, Switzerland},
- pages = {730},
- year = {2003},
- series = {International standard; ISO 15938}
-}
-
-@Book{ExifSpec,
- AUTHOR = {JEITA Technical Standardization Committee on AV \& IT Storage Systems and Equipment},
- TITLE = {Exchangeable Image Format for digital still cameras: Exif Version 2.2},
- PUBLISHER = {Japan Electronics and Information Technology Industries Association},
- ADDRESS = {Japan},
- YEAR = {2002},
- MONTH = {April},
- SERIES = {Standard of Japan Electronics and Information Technology Industries Association: JEITA CP-3451}
-}
-
-@INPROCEEDINGS{sauermann+2007b,
- author = {Leo Sauermann and Ludger van Elst and Andreas Dengel},
- title = {PIMO - a Framework for Representing Personal Information Models},
- booktitle = {Proceedings of I-Semantics' 07},
- year = {2007},
- editor = {Tassilo Pellegrini and Sebastian Schaffert},
- pages = {pp. 270-277},
- publisher = {JUCS},
- doi = {ISSN 0948-6968},
- owner = {sauermann},
- pdf = {sauermann+2007b.pdf},
- timestamp = {2007.09.12},
- url = {http://www.dfki.uni-kl.de/~sauermann/papers/sauermann+2007b.pdf},
-}
-
-@TECHREPORT{Sauermann+2007a,
- author = {Leo Sauermann and Richard Cyganiak and Max V\"olkel},
- title = {Cool URIs for the Semantic Web},
- institution = {DFKI GmbH},
- year = {2007},
- type = {Technical Memo},
- number = {TM-07-01},
- address = {Deutsches Forschungszentrum f\"ur K\"unstliche Intelligenz GmbH
-
- Postfach 2080
-
- 67608 Kaiserslautern},
- month = {February},
- note = {Written by 29.11.2006},
- abstract = {The Resource Description Framework RDF allows you to describe web
- documents and resources from the real worldpeople, organisations,
- thingsin a computer-processable way. Publishing such descriptions
- on the web creates the semantic web. URIs are very important as
- the link between
-
- RDF and the web. This article presents guidelines for their effective
- use. We discuss two strategies, called 303 URIs and hash URIs. We
- give pointers to several web sites that use these solutions, and
- briefly discuss why several other proposals have problems.},
- owner = {sauermann},
- pdf = {Sauermann+2007a.pdf},
- timestamp = {2007.03.08},
- url = {http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/tm-07-01.pdf},
-}
-
-@TECHREPORT{SWBPVocabularyRecipes,
- author = {Alistair Miles and Thomas Baker and Ralph Swick},
- title = {Best Practice Recipes for Publishing {RDF} Vocabularies},
- type = {{W3C} Working Draft},
- institution = {W3C},
- year = {2006},
- month = {Mar},
- note = {\url{http://www.w3.org/TR/swbp-vocab-pub/}},
-}
-
-
-@BOOK{pim2007,
- title = {Personal Information Management},
- publisher = {{University of Washington Press}},
- year = {2007},
- editor = {William Jones and Jamie Teevan},
- month = {October},
- citeulike-article-id = {1834863},
- howpublished = {Paperback},
- isbn = {0295987375},
- keywords = {information-retrieval},
- owner = {sauermann},
- posted-at = {2008-03-24 02:50:56},
- priority = {2},
- timestamp = {2008.05.16},
- url = {http://www.amazon.ca/exec/obidos/redirect?tag=citeulike09-20\&path=ASIN/0295987375},
-}
-
-@TECHREPORT{rdfaprimer,
- author = {Ben Adida and Mark Birbeck},
- title = {RDFa Prime. Bridging the Human and Data Webs},
- institution = {W3C},
- year = {2008},
- type = {W3C Working Group Note},
- number = {http://www.w3.org/TR/xhtml-rdfa-primer/},
- address = {http://www.w3.org/TR/xhtml-rdfa-primer/},
- month = {14 October},
- abstract = {Today's web is built predominantly for human consumption. Even as
- machine-readable data begins to appear on the web, it is typically
- distributed in a separate file, with a separate format, and very
- limited correspondence between the human and machine versions. As
- a result, web browsers can provide only minimal assistance to humans
- in parsing and processing web data: browsers only see presentation
- information. We introduce RDFa, which provides a set of XHTML attributes
- to augment visual data with machine-readable hints. We show how
- to express simple and more complex datasets using RDFa, and in particular
- how to turn the existing human-visible text and links into machine-readable
- data without repeating content.
-
-
- This document provides only a Primer to RDFa. The normative specification
- of RDFa can be found in [RDFA-SYNTAX].},
- owner = {sauermann},
- timestamp = {2009.01.29},
- url = {http://www.w3.org/TR/xhtml-rdfa-primer/},
-}
diff --git a/pimo/doc/handbook_latex/pimo.bib.bak b/pimo/doc/handbook_latex/pimo.bib.bak deleted file mode 100644 index 380e6ef..0000000 --- a/pimo/doc/handbook_latex/pimo.bib.bak +++ /dev/null @@ -1,228 +0,0 @@ -@misc{SPARQLW3C,
- TITLE = {SPARQL Query Language for RDF},
- AUTHOR = {Eric Prud'hommeaux and Andy Seaborne},
- HOWPUBLISHED = {\url{http://www.w3.org/TR/rdf-sparql-protocol/}},
- URL = {\url{http://www.w3.org/TR/rdf-sparql-protocol/}}
-}
-
-@misc{RDFSemantics,
- TITLE = {RDF Semantics},
- AUTHOR = {Patrick Hayes},
- HOWPUBLISHED = {\url{http://www.w3.org/TR/rdf-mt/}},
- URL = {\url{http://www.w3.org/TR/rdf-mt/}}
-}
-
-@misc{DCSpec,
- TITLE = {Dublin Core Metadata Element Set, Version 1.1},
- PUBLISHER = {Dublin Core Metadata Initiative},
- KEY = {Dublin Core Metadata Initiative},
- HOWPUBLISHED = {\url{http://www.dublincore.org/documents/dces/}},
- URL = {\url{http://www.dublincore.org/documents/dces/}}
-}
-
-@misc{EXIFRDF,
- TITLE = {Exif data description vocabulary},
- AUTHOR = {Masahide Kanzaki},
- HOWPUBLISHED = {\url{http://www.kanzaki.com/ns/exif}},
- URL = {\url{http://www.kanzaki.com/ns/exif}}
-}
-
-@misc{RFC2426,
- TITLE = {vCard MIME Directory Profile},
- AUTHOR = {Frank Dawson and Tim Howes},
- URL = {\url{http://www.ietf.org/rfc/rfc2426.txt}},
- HOWPUBLISHED = {\url{http://www.ietf.org/rfc/rfc2426.txt}}
-}
-
-@misc{NRLSpec,
- TITLE = {NEPOMUK Representational Language (NRL) Vocabulary Specification [Draft]},
- AUTHOR = {Nepomuk Task Force Ontologies},
- HOWPUBLISHED = {\url{http://svn.nepomuk.semanticdesktop.org/repos/trunk/taskforce/TF-Ont/draft/NRL.html}},
- URL = {\url{http://svn.nepomuk.semanticdesktop.org/repos/trunk/taskforce/TF-Ont/draft/NRL.html}}
-}
-
-@misc{VCARDRDF,
- TITLE = {Representing vCard Objects in RDF/XML},
- AUTHOR = {Renato Ianella},
- HOWPUBLISHED = {\url{http://www.w3.org/TR/vcard-rdf}},
- URL = {\url{http://www.w3.org/TR/vcard-rdf}}
-}
-
-@misc{RFC2445,
- TITLE = {Internet Calendaring and Scheduling Core Objects Specification},
- AUTHOR = {Frank Dawson and Derik Stenerson},
- YEAR = {1998},
- HOWPUBLISHED = {\url{http://www.ietf.org/rfc/rfc2445.txt}},
- URL = {\url{http://www.ietf.org/rfc/rfc2445.txt}}
-}
-
-@misc{SWADDeliverable3.7,
- TITLE = {SWAD-Europe Deliverable 3.7: Developer Workshop Report 2 - Semantic Web calendaring},
- AUTHOR = {Libby Miller},
- YEAR = {2002},
- HOWPUBLISHED = {\url{http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_2/}},
- URL = {\url{http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_2/}}
-}
-
-@misc{TimBLICal,
- TITLE = {A quick look at iCalendar},
- AUTHOR = {Tim Berners-Lee},
- YEAR = {2001},
- HOWPUBLISHED = {\url{http://www.w3.org/2000/01/foo}},
- URL = {\url{http://www.w3.org/2000/01/foo}}
-}
-
-@misc{HybridIcal,
- TITLE = {Hybrid ICal RDF Schema},
- AUTHOR = {Michael Arick and Libby Miller},
- YEAR = {2001},
- HOWPUBLISHED = {\url{http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf}},
- URL = {\url{http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf}}
-}
-
-@misc{AnotherIcal,
- TITLE = {Another iCalendar model},
- AUTHOR = {Dan Connoly},
- YEAR = {2000},
- HOWPUBLISHED = {\url{http://www.w3.org/2000/10/swap/pim/ical.rdf}},
- URL = {\url{http://www.w3.org/2000/10/swap/pim/ical.rdf}}
-}
-
-@misc{PalmIcal,
- TITLE = {Palm Datebook},
- AUTHOR = {Dan Connoly},
- YEAR = {2000},
- HOWPUBLISHED = {\url{http://www.w3.org/2000/08/palm56/datebook}},
- URL = {\url{http://www.w3.org/2000/08/palm56/datebook}}
-}
-
-@misc{ICALRDF,
- TITLE = {RDF Calendar - an application of the Resource Description Framework to iCalendar Data},
- AUTHOR = {Dan Connolly and Libby Miller},
- HOWPUBLISHED = {\url{http://www.w3.org/TR/rdfcal/}},
- URL = {\url{http://www.w3.org/TR/rdfcal/}}
-}
-
-@misc{ID3Standard,
- TITLE = {ID3 Tag version 2.3.0 - Informal Standard},
- AUTHOR = {Martin Nilsson},
- HOWPUBLISHED = {\url{http://www.id3.org/id3v2.3.0}},
- URL = {\url{http://www.id3.org/id3v2.3.0}}
-}
-
-@InCollection{PereiraWalle2005,
- AUTHOR = {Fernando Pereira and Rik van de Walle},
- TITLE = {Multimedia Content description in MPEG-7 and MPEG-21},
- BOOKTITLE = {Multimedia Content and the Semantic Web},
- EDITOR = {Giorgios Stamou and Stefanos Kolias},
- PAGES = {3--43},
- PUBLISHER = {Wiley},
- YEAR = {2005}
-}
-
-@InCollection{Hunter2005,
- AUTHOR = {Jane Hunter},
- TITLE = {Adding Multimedia to the Semantic Web. Building an applying an MPEG-7 Ontology},
- BOOKTITLE = {Multimedia Content and the Semantic Web},
- EDITOR = {Giorgios Stamou and Stefanos Kolias},
- PAGES = {75--106},
- PUBLISHER = {Wiley},
- YEAR = {2005},
- URL = {\url{http://www.itee.uq.edu.au/~jane/jane-hunter/swws.pdf}}
-}
-
-@InProceedings{TsinarakiCAiSE2004,
- AUTHOR = {Chrisa Tsinaraki AND Panagiotis Polydoros AND Stavros Christodoulakis},
- TITLE = {Integration of OWL ontologies in MPEG-7 and TVAnytime compliant Semantic Indexing},
- BOOKTITLE = {Proc. of the 16th International Conference on Advanced Information Systems Engineering (CAiSE 2004)},
- MONTH = {June},
- YEAR = {2004},
- ADDRESS = {Riga, Latvia},
- URL = {\url{http://www.music.tuc.gr/Staff/Director/Publications/publ_files/C_TSPC_CAISE_2004.pdf}}
-}
-
-@InProceedings{TsinarakiRIAO2004,
- AUTHOR = {Chrisa Tsinaraki AND Panagiotis Polydoros AND Nektarios Moumoutzis AND Stavros Christodoulakis},
- TITLE = {Coupling OWL with MPEG-7 and TV-Anytime for Domain-specific
- Multimedia Information Integration and Retrieval},
- BOOKTITLE = {Proc. of RIAO 2004},
- MONTH = {April},
- YEAR = {2004},
- ADDRESS = {Avignon, France},
- URL = {\url{http://www.ced.tuc.gr/Staff/Director/Publications/publ_files/C_TPMC_RIAO_2004.pdf}}
-}
-
-@InProceedings{TsinarakiCIVR2004,
- AUTHOR = {Chrisa Tsinaraki AND Panagiotis Polydoros AND Stavros Christodoulakis},
- TITLE = {Interoperability support for Ontology-based Video Retrieval Applications},
- BOOKTITLE = {Proc. of 3rd International Conference on Image and Video Retrieval (CIVR 2004)},
- MONTH = {April},
- YEAR = {2004},
- ADDRESS = {Dublin, Ireland},
- URL = {\url{http://www.music.tuc.gr/Staff/Director/Publications/publ_files/C_TSPC_CIVR_2004.pdf}}
-}
-
-@InProceedings{GarciaCelma2005,
- AUTHOR = {Roberto Garcia AND Oscar Celma},
- TITLE = {Semantic Integration and Retrieval of Multimedia Metadata},
- BOOKTITLE = {Proceedings of the 5th International Workshop on Knowledge Markup
- and Semantic Annotation (SemAnnot 2005)},
- MONTH = {November},
- YEAR = {2005},
- ADDRESS = {Galway, Ireland},
- PUBLISHER = {\url{http://ceur-ws.org}}
-}
-
-@Misc{Vembu2005,
- AUTHOR = {Shankar Vembu and Malte Kiesel and Michael Sintek and Stephan Baumann},
- TITLE = {Towards Bridging the Semantic Gap in Multimedia Annotation and Retrieval},
- BOOKTITLE = {Proceedings of the 5th International Workshop on Knowledge Markup
- and Semantic Annotation (SemAnnot 2005)},
- MONTH = {May},
- YEAR = {2006},
- ADDRESS = {Edinburgh, UK},
- HOWPUBLISHED = {\url{http://image.ntua.gr/swamm2006/resources/paper18.pdf}}}
-}
-
-@Book{ISO:15938:P2,
- author = {International Organization for Standardization},
- title = {Information technology -- Multimedia content description interface --
- Part 2: Description definition language},
- publisher = {International Organization for Standardization},
- address = {Geneva, Switzerland},
- pages = {37},
- year = {2007},
- series = {International standard; ISO 15938}
-}
-
-@Book{ISO:15938:P3,
- author = {International Organization for Standardization},
- title = {Information technology -- Multimedia content description interface --
- Part 3: Visual},
- publisher = {International Organization for Standardization},
- address = {Geneva, Switzerland},
- pages = {175},
- year = {2007},
- series = {International standard; ISO 15938}
-}
-
-@Book{ISO:15938:P5,
- author = {International Organization for Standardization},
- title = {Information technology -- Multimedia content description interface --
- Part 5: Multimedia Description Schemes},
- publisher = {International Organization for Standardization},
- address = {Geneva, Switzerland},
- pages = {730},
- year = {2003},
- series = {International standard; ISO 15938}
-}
-
-@Book{ExifSpec,
- AUTHOR = {JEITA Technical Standardization Committee on AV \& IT Storage Systems and Equipment},
- TITLE = {Exchangeable Image Format for digital still cameras: Exif Version 2.2},
- PUBLISHER = {Japan Electronics and Information Technology Industries Association},
- ADDRESS = {Japan},
- YEAR = {2002},
- MONTH = {April},
- SERIES = {Standard of Japan Electronics and Information Technology Industries Association: JEITA CP-3451}
-}
\ No newline at end of file diff --git a/pimo/doc/handbook_latex/pimo.blg b/pimo/doc/handbook_latex/pimo.blg deleted file mode 100644 index ae2c3cb..0000000 --- a/pimo/doc/handbook_latex/pimo.blg +++ /dev/null @@ -1,13 +0,0 @@ -This is BibTeX, Version 0.99cThe top-level auxiliary file: C:\workspace_nepomuk\pimo\latex\pimo.aux
-The style file: plain.bst
-Database file #1: pimo.bib
-A bad cross reference---entry "Park+2005"
-refers to entry "DBLP:conf/tmra/2005", which doesn't exist
-Warning--I didn't find a database entry for "DBLP:conf/tmra/2005"
-Warning--to sort, need author or key in iso13250second
-Warning--can't use both author and editor fields in likothanasis+2005
-Warning--can't use both volume and number fields in likothanasis+2005
-Warning--empty chapter and pages in likothanasis+2005
-Warning--empty booktitle in HolzMausBernardiRostanin2005b
-Warning--can't use both volume and number fields in HolzMausBernardiRostanin2005b
-(There was 1 error message)
diff --git a/pimo/doc/handbook_latex/pimo.dvi b/pimo/doc/handbook_latex/pimo.dvi Binary files differdeleted file mode 100644 index 64fc0fa..0000000 --- a/pimo/doc/handbook_latex/pimo.dvi +++ /dev/null diff --git a/pimo/doc/handbook_latex/pimo.log b/pimo/doc/handbook_latex/pimo.log deleted file mode 100644 index 9f7ae9f..0000000 --- a/pimo/doc/handbook_latex/pimo.log +++ /dev/null @@ -1,1160 +0,0 @@ -This is pdfTeX, Version 3.141592-1.40.4 (MiKTeX 2.6) (preloaded format=pdflatex 2008.7.30) 30 JAN 2009 15:41
-entering extended mode
-**C:/workspace_nepomuk/pimo/latex/pimo.tex
-(C:\workspace_nepomuk\pimo\latex\pimo.tex
-LaTeX2e <2005/12/01>
-Babel <v3.8h> and hyphenation patterns for english, dumylang, nohyphenation, german, ngerman, french, loaded.
-(nepomuk.cls
-Document Class: nepomuk 2004/03/24 2004 CleanBook LaTeX class
-(C:\MiKTeX2.6\tex\latex\base\article.cls
-Document Class: article 2005/09/16 v1.4f Standard LaTeX document class
-(C:\MiKTeX2.6\tex\latex\base\size10.clo
-File: size10.clo 2005/09/16 v1.4f Standard LaTeX file (size option)
-)
-\c@part=\count79
-\c@section=\count80
-\c@subsection=\count81
-\c@subsubsection=\count82
-\c@paragraph=\count83
-\c@subparagraph=\count84
-\c@figure=\count85
-\c@table=\count86
-\abovecaptionskip=\skip41
-\belowcaptionskip=\skip42
-\bibindent=\dimen102
-) (C:\MiKTeX2.6\tex\latex\graphics\color.sty
-Package: color 2005/11/14 v1.0j Standard LaTeX Color (DPC)
-
-(C:\MiKTeX2.6\tex\latex\00miktex\color.cfg
-File: color.cfg 2007/01/18 v1.5 color configuration of teTeX/TeXLive
-)
-Package color Info: Driver file: pdftex.def on input line 130.
- (C:\MiKTeX2.6\tex\latex\graphics\pdftex.def
-File: pdftex.def 2007/06/12 v0.04h Graphics/color for pdfTeX
-\Gread@gobject=\count87
-))
-(C:\MiKTeX2.6\tex\latex\colortbl\colortbl.sty
-Package: colortbl 2001/02/13 v0.1j Color table columns (DPC)
- (C:\MiKTeX2.6\tex\latex\tools\array.sty
-Package: array 2005/08/23 v2.4b Tabular extension package (FMi)
-\col@sep=\dimen103
-\extrarowheight=\dimen104
-\NC@list=\toks14
-\extratabsurround=\skip43
-\backup@length=\skip44
-)
-\everycr=\toks15
-\minrowclearance=\skip45
-)
-(C:\MiKTeX2.6\tex\latex\psnfss\helvet.sty
-Package: helvet 2005/04/12 PSNFSS-v9.2a (WaS)
- (C:\MiKTeX2.6\tex\latex\graphics\keyval.sty
-Package: keyval 1999/03/16 v1.13 key=value parser (DPC)
-\KV@toks@=\toks16
-))
-(C:\MiKTeX2.6\tex\latex\koma-script\scrpage2.sty
-Package: scrpage2 2007/07/23 v2.2e LaTeX2e KOMA-Script package
-) (C:\MiKTeX2.6\tex\latex\graphics\graphicx.sty
-Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR)
-
-(C:\MiKTeX2.6\tex\latex\graphics\graphics.sty
-Package: graphics 2006/02/20 v1.0o Standard LaTeX Graphics (DPC,SPQR)
- (C:\MiKTeX2.6\tex\latex\graphics\trig.sty
-Package: trig 1999/03/16 v1.09 sin cos tan (DPC)
-)
-(C:\MiKTeX2.6\tex\latex\00miktex\graphics.cfg
-File: graphics.cfg 2007/01/18 v1.5 graphics configuration of teTeX/TeXLive
-)
-Package graphics Info: Driver file: pdftex.def on input line 90.
-)
-\Gin@req@height=\dimen105
-\Gin@req@width=\dimen106
-) (C:\MiKTeX2.6\tex\latex\koma-script\typearea.sty
-Package: typearea 2007/10/12 v2.97d KOMA-Script package (type area)
-
-Package typearea, 2007/10/12 v2.97d KOMA-Script package (type area)
- Copyright (C) Frank Neukam, 1992-1994
- Copyright (C) Markus Kohm, 1994-
-
-(C:\MiKTeX2.6\tex\latex\koma-script\scrkbase.sty
-Package: scrkbase 2007/10/12 v2.97d KOMA-Script package (basics and keyval use)
- (C:\MiKTeX2.6\tex\latex\koma-script\scrlfile.sty
-Package: scrlfile 2007/03/07 v2.97a KOMA-Script package (loading files)
-
-Package scrlfile, 2007/03/07 v2.97a KOMA-Script package (loading files)
- Copyright (C) Markus Kohm
-
-))
-\ta@bcor=\skip46
-\ta@div=\count88
-\ta@hblk=\skip47
-\ta@vblk=\skip48
-\ta@temp=\skip49
-LaTeX Font Info: Try loading font information for OT1+phv on input line 890.
- (C:\MiKTeX2.6\tex\latex\psnfss\ot1phv.fd
-File: ot1phv.fd 2001/06/04 scalable font definitions for OT1/phv.
-)
-Package typearea Info: These are the values describing the layout:
-(typearea) DIV = 8
-(typearea) BCOR = 0.0pt
-(typearea) \paperwidth = 597.50793pt
-(typearea) \textwidth = 373.44246pt
-(typearea) DIV-departure = -4/100
-(typearea) \evensidemargin = 39.76274pt
-(typearea) \oddsidemargin = 39.76274pt
-(typearea) \paperheight = 845.04694pt
-(typearea) \textheight = 538.0pt
-(typearea) \topmargin = 0.36087pt
-(typearea) \headheight = 15.0pt
-(typearea) \headsep = 18.0pt
-(typearea) \topskip = 10.0pt
-(typearea) \footskip = 42.0pt
-(typearea) \baselineskip = 12.0pt
-(typearea) on input line 890.
-) (C:\MiKTeX2.6\tex\latex\base\fontenc.sty
-Package: fontenc 2005/09/27 v1.99g Standard LaTeX package
-
-(C:\MiKTeX2.6\tex\latex\base\t1enc.def
-File: t1enc.def 2005/09/27 v1.99g Standard LaTeX file
-LaTeX Font Info: Redeclaring font encoding T1 on input line 43.
-))) (C:\MiKTeX2.6\tex\latex\hyperref\hyperref.sty
-Package: hyperref 2007/10/30 v6.77b Hypertext links for LaTeX
-
-(C:\MiKTeX2.6\tex\latex\oberdiek\hycolor.sty
-Package: hycolor 2007/04/11 v1.1 Code for color options of hyperref/bookmark (HO)
-)
-\@linkdim=\dimen107
-\Hy@linkcounter=\count89
-\Hy@pagecounter=\count90
- (C:\MiKTeX2.6\tex\latex\hyperref\pd1enc.def
-File: pd1enc.def 2007/10/30 v6.77b Hyperref: PDFDocEncoding definition (HO)
-)
-(C:\MiKTeX2.6\tex\generic\oberdiek\etexcmds.sty
-Package: etexcmds 2007/09/09 v1.1 Prefix for e-TeX command names (HO)
- (C:\MiKTeX2.6\tex\generic\oberdiek\infwarerr.sty
-Package: infwarerr 2007/09/09 v1.2 Providing info/warning/message (HO)
-))
-(C:\MiKTeX2.6\tex\latex\00miktex\hyperref.cfg
-File: hyperref.cfg 2002/06/06 v1.2 hyperref configuration of TeXLive
-) (C:\MiKTeX2.6\tex\latex\oberdiek\kvoptions.sty
-Package: kvoptions 2007/10/18 v3.0 Keyval support for LaTeX options (HO)
-)
-Package hyperref Info: Hyper figures OFF on input line 2675.
-Package hyperref Info: Link nesting OFF on input line 2680.
-Package hyperref Info: Hyper index ON on input line 2683.
-Package hyperref Info: Plain pages OFF on input line 2690.
-Package hyperref Info: Backreferencing OFF on input line 2695.
-
-Implicit mode ON; LaTeX internals redefined
-Package hyperref Info: Bookmarks ON on input line 2851.
-(C:\MiKTeX2.6\tex\latex\ltxmisc\url.sty
-\Urlmuskip=\muskip10
-Package: url 2005/06/27 ver 3.2 Verb mode for urls, etc.
-)
-LaTeX Info: Redefining \url on input line 3021.
- (C:\MiKTeX2.6\tex\generic\oberdiek\bitset.sty
-Package: bitset 2007/09/28 v1.0 Data type bit set (HO)
-
-(C:\MiKTeX2.6\tex\generic\oberdiek\intcalc.sty
-Package: intcalc 2007/09/27 v1.1 Expandable integer calculations (HO)
-) (C:\MiKTeX2.6\tex\generic\oberdiek\bigintcalc.sty
-Package: bigintcalc 2007/09/27 v1.0 Expandable big integer calculations (HO)
-))
-(C:\MiKTeX2.6\tex\generic\oberdiek\kvsetkeys.sty
-Package: kvsetkeys 2007/09/29 v1.3 Key value parser with default handler support (HO)
-)
-\Fld@menulength=\count91
-\Field@Width=\dimen108
-\Fld@charsize=\dimen109
-\Field@toks=\toks17
-Package hyperref Info: Hyper figures OFF on input line 3894.
-Package hyperref Info: Link nesting OFF on input line 3899.
-Package hyperref Info: Hyper index ON on input line 3902.
-Package hyperref Info: backreferencing OFF on input line 3909.
-Package hyperref Info: Link coloring OFF on input line 3914.
- (C:\MiKTeX2.6\tex\generic\oberdiek\atbegshi.sty
-Package: atbegshi 2007/09/09 v1.6 At begin shipout hook (HO)
-
-(C:\MiKTeX2.6\tex\generic\oberdiek\ifpdf.sty
-Package: ifpdf 2007/09/09 v1.5 Provides the ifpdf switch (HO)
-Package ifpdf Info: pdfTeX in pdf mode detected.
-))
-\Hy@abspage=\count92
-\c@Item=\count93
-\c@Hfootnote=\count94
-)
-*hyperref using default driver hpdftex*
-(C:\MiKTeX2.6\tex\latex\hyperref\hpdftex.def
-File: hpdftex.def 2007/10/30 v6.77b Hyperref driver for pdfTeX
-\Fld@listcount=\count95
-) (C:\MiKTeX2.6\tex\latex\tools\verbatim.sty
-Package: verbatim 2003/08/22 v1.5q LaTeX2e package for verbatim enhancements
-\every@verbatim=\toks18
-\verbatim@line=\toks19
-\verbatim@in@stream=\read1
-)
-(C:\MiKTeX2.6\tex\latex\tools\longtable.sty
-Package: longtable 2004/02/01 v4.11 Multi-page Table package (DPC)
-\LTleft=\skip50
-\LTright=\skip51
-\LTpre=\skip52
-\LTpost=\skip53
-\LTchunksize=\count96
-\LTcapwidth=\dimen110
-\LT@head=\box26
-\LT@firsthead=\box27
-\LT@foot=\box28
-\LT@lastfoot=\box29
-\LT@cols=\count97
-\LT@rows=\count98
-\c@LT@tables=\count99
-\c@LT@chunks=\count100
-\LT@p@ftn=\toks20
-) (C:\MiKTeX2.6\tex\latex\tools\xspace.sty
-Package: xspace 2006/05/08 v1.12 Space after command names (DPC,MH)
-)
-(C:\MiKTeX2.6\tex\latex\microtype\microtype.sty
-Package: microtype 2008/06/04 v2.3b Micro-typography with pdfTeX (RS)
-\MT@toks=\toks21
-\MT@count=\count101
-LaTeX Info: Redefining \lsstyle on input line 1553.
-LaTeX Info: Redefining \lslig on input line 1553.
-\MT@outer@space=\skip54
-LaTeX Info: Redefining \textls on input line 1554.
-\MT@outer@kern=\dimen111
-LaTeX Info: Redefining \textmicrotypecontext on input line 2094.
-Package microtype Info: Loading configuration file microtype.cfg.
- (C:\MiKTeX2.6\tex\latex\microtype\microtype.cfg
-File: microtype.cfg 2008/06/04 v2.3b microtype main configuration file (RS)
-)) (pimo.aux)
-LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 47.
-LaTeX Font Info: ... okay on input line 47.
-LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 47.
-LaTeX Font Info: ... okay on input line 47.
-LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 47.
-LaTeX Font Info: ... okay on input line 47.
-LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 47.
-LaTeX Font Info: ... okay on input line 47.
-LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 47.
-LaTeX Font Info: ... okay on input line 47.
-LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 47.
-LaTeX Font Info: ... okay on input line 47.
-LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 47.
-LaTeX Font Info: ... okay on input line 47.
-LaTeX Font Info: Try loading font information for T1+phv on input line 47.
-
-(C:\MiKTeX2.6\tex\latex\psnfss\t1phv.fd
-File: t1phv.fd 2001/06/04 scalable font definitions for T1/phv.
-) (C:\MiKTeX2.6\tex\context\base\supp-pdf.tex
-[Loading MPS to PDF converter (version 2006.09.02).]
-\scratchcounter=\count102
-\scratchdimen=\dimen112
-\scratchbox=\box30
-\nofMPsegments=\count103
-\nofMParguments=\count104
-\MPscratchCnt=\count105
-\MPscratchDim=\dimen113
-\MPnumerator=\count106
-\everyMPtoPDFconversion=\toks22
-)
-Package hyperref Info: Link coloring OFF on input line 47.
- (C:\MiKTeX2.6\tex\latex\hyperref\nameref.sty
-Package: nameref 2007/05/29 v2.31 Cross-referencing by name of section
- (C:\MiKTeX2.6\tex\latex\oberdiek\refcount.sty
-Package: refcount 2006/02/20 v3.0 Data extraction from references (HO)
-)
-\c@section@level=\count107
-)
-LaTeX Info: Redefining \ref on input line 47.
-LaTeX Info: Redefining \pageref on input line 47.
- (pimo.out) (pimo.out)
-\@outlinefile=\write3
-\AtBeginShipoutBox=\box31
-LaTeX Info: Redefining \microtypecontext on input line 47.
-Package microtype Info: Generating PDF output.
-Package microtype Info: Character protrusion enabled (level 2).
-Package microtype Info: Using default protrusion set `alltext'.
-Package microtype Info: Automatic font expansion enabled (level 2),
-(microtype) stretch: 20, shrink: 20, step: 4, non-selected.
-Package microtype Info: Using default expansion set `basictext'.
-Package microtype Info: No tracking.
-Package microtype Info: No adjustment of interword spacing.
-Package microtype Info: No adjustment of character kerning.
-
-(C:\MiKTeX2.6\tex\latex\microtype\mt-cmr.cfg
-File: mt-cmr.cfg 2008/02/29 v1.9a microtype config. file: Computer Modern Roman (RS)
-)
-LaTeX Font Info: External font `cmex10' loaded for size
-(Font) <12> on input line 90.
-LaTeX Font Info: External font `cmex10' loaded for size
-(Font) <8> on input line 90.
-LaTeX Font Info: External font `cmex10' loaded for size
-(Font) <6> on input line 90.
-
-Overfull \hbox (6.7248pt too wide) in paragraph at lines 90--92
-[][][]
- []
-
-LaTeX Font Info: External font `cmex10' loaded for size
-(Font) <7> on input line 92.
-LaTeX Font Info: External font `cmex10' loaded for size
-(Font) <5> on input line 92.
-<images/InformationSocietyTechnologies.pdf, id=255, 383.4325pt x 199.74625pt>
-File: images/InformationSocietyTechnologies.pdf Graphic file (type pdf)
-
-<use images/InformationSocietyTechnologies.pdf> <images/Nepomuk.pdf, id=257, 433.62pt x 210.7875pt>
-File: images/Nepomuk.pdf Graphic file (type pdf)
-
-<use images/Nepomuk.pdf>
-LaTeX Font Info: Font shape `T1/phv/bx/n' in size <24.88> not available
-(Font) Font shape `T1/phv/b/n' tried instead on input line 111.
-
-Overfull \hbox (343.55304pt too wide) in paragraph at lines 111--113
-[][][][] [][][]
- []
-
-<images/Bubbles.pdf, id=258, 448.67625pt x 558.085pt>
-File: images/Bubbles.pdf Graphic file (type pdf)
- <use images/Bubbles.pdf> [1
-
-{psfonts.map} <images/InformationSocietyTechnologies.pdf> <images/Nepomuk.pdf> <images/Bubbles.pdf>]
-LaTeX Font Info: Font shape `T1/phv/bx/n' in size <14.4> not available
-(Font) Font shape `T1/phv/b/n' tried instead on input line 163.
-
-Underfull \hbox (badness 10000) in paragraph at lines 165--168
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 174--180
-
- []
-
-[2
-
-]
-LaTeX Font Info: Font shape `T1/phv/bx/n' in size <10> not available
-(Font) Font shape `T1/phv/b/n' tried instead on input line 230.
-
-Underfull \hbox (badness 10000) in paragraph at lines 230--243
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 230--243
-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 230--243
-
- []
-
-[3
-
-] (pimo.toc [4]
-LaTeX Font Info: Try loading font information for T1+cmtt on input line 68.
- (C:\MiKTeX2.6\tex\latex\base\t1cmtt.fd
-File: t1cmtt.fd 1999/05/25 v2.5h Standard LaTeX font definitions
-))
-\tf@toc=\write4
- [5]
-LaTeX Font Info: Font shape `T1/phv/m/it' in size <10> not available
-(Font) Font shape `T1/phv/m/sl' tried instead on input line 288.
- [1
-
-
-] [2]
-LaTeX Font Info: Try loading font information for OMS+phv on input line 360.
- (C:\MiKTeX2.6\tex\latex\psnfss\omsphv.fd
-File: omsphv.fd
-)
-LaTeX Font Info: Font shape `OMS/phv/m/n' in size <10> not available
-(Font) Font shape `OMS/cmsy/m/n' tried instead on input line 360.
-LaTeX Font Info: External font `cmex10' loaded for size
-(Font) <9> on input line 361.
-
-Overfull \hbox (1.48184pt too wide) in paragraph at lines 360--362
-[]$\T1/cmtt/m/n/9 http : / / www . semanticdesktop . org / ontologies / 2007 / 11 / 01 / pimo / pimo _ data .
- []
-
-
-Overfull \hbox (20.37723pt too wide) in paragraph at lines 362--364
-[]$\T1/cmtt/m/n/9 http : / / www . semanticdesktop . org / ontologies / 2007 / 11 / 01 / pimo / pimo _ metadata .
- []
-
-<images/roadmap.png, id=411, 439.6425pt x 365.86688pt>
-File: images/roadmap.png Graphic file (type png)
- <use images/roadmap.png> [3 <images/roadmap.png (PNG copy)>]
-[4]
-Overfull \hbox (4.5887pt too wide) in paragraph at lines 444--444
-[]\T1/cmtt/m/n/9 @prefix nrl: <http://www.semanticdesktop.org/ontologies/2007/08/15/nrl#>.[]
- []
-
-
-Overfull \hbox (4.5887pt too wide) in paragraph at lines 445--445
-[]\T1/cmtt/m/n/9 @prefix nao: <http://www.semanticdesktop.org/ontologies/2007/08/15/nao#>.[]
- []
-
-
-Overfull \hbox (9.31255pt too wide) in paragraph at lines 446--446
-[]\T1/cmtt/m/n/9 @prefix pimo: <http://www.semanticdesktop.org/ontologies/2007/11/01/pimo#>.[]
- []
-
-
-Overfull \hbox (9.31255pt too wide) in paragraph at lines 447--447
-[]\T1/cmtt/m/n/9 @prefix ncal: <http://ont.semanticdesktop.org/ontologies/2007/04/02/ncal#>.[]
- []
-
-
-Overfull \hbox (4.5887pt too wide) in paragraph at lines 448--448
-[]\T1/cmtt/m/n/9 @prefix nco: <http://ont.semanticdesktop.org/ontologies/2007/03/22/nco#>.[]
- []
-
-
-Overfull \hbox (4.5887pt too wide) in paragraph at lines 449--449
-[]\T1/cmtt/m/n/9 @prefix nfo: <http://ont.semanticdesktop.org/ontologies/2007/03/22/nfo#>.[]
- []
-
-
-Overfull \hbox (4.5887pt too wide) in paragraph at lines 450--450
-[]\T1/cmtt/m/n/9 @prefix nie: <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#>.[]
- []
-
-
-Overfull \hbox (4.5887pt too wide) in paragraph at lines 451--451
-[]\T1/cmtt/m/n/9 @prefix nmo: <http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#>.[]
- []
-
-[5] <images/thing_vs_resource.pdf, id=439, 610.28pt x 233.87375pt>
-File: images/thing_vs_resource.pdf Graphic file (type pdf)
- <use images/thing_vs_resource.pdf>
-LaTeX Font Info: Font shape `T1/phv/m/it' in size <8> not available
-(Font) Font shape `T1/phv/m/sl' tried instead on input line 542.
- [6 <images/thing_vs_resource.pdf>]
-Underfull \hbox (badness 10000) in paragraph at lines 550--550
-[][][][]$\T1/cmtt/m/n/8 http : / / www . w3 . org / 2007 / OWL / wiki / Syntax # Declarations _ and _ Structural _
- []
-
-<images/identification.pdf, id=503, 817.0525pt x 290.08376pt>
-File: images/identification.pdf Graphic file (type pdf)
- <use images/identification.pdf> [7] [8 <images/identification.pdf>]
-Overfull \hbox (32.94919pt too wide) in paragraph at lines 673--676
-[]\T1/phv/m/n/10 (-20) Besides iden-ti-fi-ca-tion, both the \T1/cmtt/m/n/10 pimo:groundingOccurrence \T1/phv/m/n/10 (-20
-) and the \T1/cmtt/m/n/10 pimo:occurrence
- []
-
-
-Overfull \hbox (0.10104pt too wide) in paragraph at lines 690--690
-[] \T1/cmtt/m/n/9 pimo:referencingOccurrence <http://www.example.com/people/DirkHagemann>.[]
- []
-
-[9]
-Overfull \hbox (13.90517pt too wide) in paragraph at lines 722--722
-[] \T1/cmtt/m/n/10 pimo:hasOtherRepresentation <http://dbpedia.org/resource/Belfast>;[]
- []
-
-[10]
-Overfull \hbox (1.99057pt too wide) in paragraph at lines 760--760
-[] \T1/cmtt/m/n/9 pimo:referencingOccurrence <http://www.example.com/people/DirkHagemann>;[]
- []
-
-LaTeX Font Info: Font shape `T1/cmtt/bx/n' in size <10> not available
-(Font) Font shape `T1/cmtt/m/n' tried instead on input line 801.
-[11] [12]
-Underfull \hbox (badness 2837) in paragraph at lines 889--889
-[][][]\T1/phv/m/n/8 (+20) The XS name-space is \T1/cmtt/m/n/8 http://www.w3.org/2001/XMLSchema\T1/phv/m/n/8 (+20) , but
-the two du-ra-tion
- []
-
-
-Overfull \hbox (49.20067pt too wide) in paragraph at lines 894--896
-\T1/phv/m/n/10 (-20) Implementers are free to use ei-ther the XSD types or sub-classes of \T1/cmtt/m/n/10 pimo:ProcessCo
-ncept\T1/phv/m/n/10 (-20) .
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 903--910
-
- []
-
-[13]
-Overfull \hbox (37.42215pt too wide) in paragraph at lines 921--926
-\T1/cmtt/m/n/10 pimo:objectProperty \T1/phv/m/n/10 (-20) (\T1/cmtt/m/n/10 pimo:related\T1/phv/m/n/10 (-20) , \T1/cmtt/m/
-n/10 pimo:hasTag\T1/phv/m/n/10 (-20) , etc.) or \T1/cmtt/m/n/10 pimo:datatypeProperty
- []
-
-[14] <images/upperclasses.png, id=660, 256.96pt x 591.20876pt>
-File: images/upperclasses.png Graphic file (type png)
- <use images/upperclasses.png> [15] [16 <images/upperclasses.png (PNG copy)>]
-Overfull \hbox (3.10783pt too wide) in paragraph at lines 1022--1027
-[]\T1/phv/m/n/10 (-20) Implementers may use these generic prop-er-ties di-rectly, or cre-ate sub-properties
- []
-
-[17] [18]
-Overfull \hbox (3.40773pt too wide) in paragraph at lines 1089--1089
-[] \T1/cmtt/m/n/10 pimo:groundingOccurrence <file://home/claudia/doc/tripplan.pdf>;[]
- []
-
-[19]
-Overfull \hbox (18.35776pt too wide) in paragraph at lines 1109--1110
-\T1/phv/m/n/10 (-20) re-la-tion to an-other Topic or be de-fined as root Topic us-ing \T1/cmtt/m/n/10 pimo:hasRootTopic\
-T1/phv/m/n/10 (-20) .
- []
-
-
-Overfull \hbox (13.38681pt too wide) in paragraph at lines 1128--1130
-\T1/phv/m/n/10 (-20) SKOS[[]]. The \T1/cmtt/m/n/10 pimo:subTopic \T1/phv/m/n/10 (-20) re-la-tion is equiv-a-lent to \T1/
-cmtt/m/n/10 skos:narrowerTransitive\T1/phv/m/n/10 (-20) .
- []
-
-[20]
-Overfull \hbox (45.7279pt too wide) in paragraph at lines 1151--1152
-[]\T1/phv/m/n/10 (-20) The super-property \T1/phv/b/n/10 should \T1/phv/m/n/10 (-20) be one of \T1/cmtt/m/n/10 pimo:rela
-ted\T1/phv/m/n/10 (-20) , \T1/cmtt/m/n/10 pimo:hasTag\T1/phv/m/n/10 (-20) , \T1/cmtt/m/n/10 pimo:isTagFor\T1/phv/m/n/10
-(-20) ,
- []
-
-[21]
-Overfull \hbox (11.62361pt too wide) in paragraph at lines 1209--1213
-\T1/phv/m/n/10 (-20) meet-ing''). The two re-la-tions used are sub-properties of \T1/cmtt/m/n/10 pimo:associationMember
- []
-
-[22] [23]
-Overfull \hbox (47.74051pt too wide) in paragraph at lines 1323--1326
-\T1/phv/b/n/10 classes of PIMO-upper classes (see Sect. []6.13[]) or sub-classing \T1/cmtt/m/n/10 InformationElement
- []
-
-[24]
-Overfull \hbox (17.10521pt too wide) in paragraph at lines 1354--1355
-\T1/phv/m/n/10 (-20) be-tween course ma-te-rial and a course (e.g. \T1/cmtt/m/n/10 courseMaterialFor(CourseMaterial,
- []
-
-
-Overfull \hbox (69.25992pt too wide) in paragraph at lines 1365--1366
-[]\T1/phv/m/n/10 (-20) Some new prop-er-ties may be de-fined as sub-properties of \T1/cmtt/m/n/10 pimo:referencingOccurr
-ence
- []
-
-<images/PIMOextensionExample-Teaching.pdf, id=750, 656.4525pt x 395.4775pt>
-File: images/PIMOextensionExample-Teaching.pdf Graphic file (type pdf)
-
-<use images/PIMOextensionExample-Teaching.pdf>
-
-LaTeX Warning: Float too large for page by 61.0157pt on input line 1447.
-
-[25] [26 <images/PIMOextensionExample-Teaching.pdf>] [27]
-Overfull \hbox (36.47466pt too wide) in paragraph at lines 1526--1526
-[] \T1/cmtt/m/n/10 # native structures tier: interpreted by the system as nfo:TextDocument[]
- []
-
-[28] [29] [30] [31]
-Overfull \hbox (38.64911pt too wide) in paragraph at lines 1805--1806
-[]\T1/phv/m/n/10 (-20) The URI of $\OML/cmm/m/it/10 C$ \T1/phv/m/n/10 (-20) is ei-ther $\OML/cmm/m/it/10 A$ \T1/phv/m/n/
-10 (-20) or $\OML/cmm/m/it/10 B$\T1/phv/m/n/10 (-20) , the older re-source (as de-fined by \T1/cmtt/m/n/10 nao:creationD
-ate\T1/phv/m/n/10 (-20) ,
- []
-
-[32]
-Overfull \hbox (17.64505pt too wide) in paragraph at lines 1814--1817
-\T1/phv/m/n/10 (-20) mapped to ex-actly one \T1/cmtt/m/n/10 pimo:Thing \T1/phv/m/n/10 (-20) in-stance us-ing the \T1/cmt
-t/m/n/10 pimo:groundingOccurrence
- []
-
-
-Overfull \hbox (23.17877pt too wide) in paragraph at lines 1821--1822
-[]\T1/phv/m/n/10 (-20) a view that in-fers oc-cur-rences based on \T1/cmtt/m/n/10 nie:identifiers
- []
-
-
-Overfull \hbox (1.99057pt too wide) in paragraph at lines 1851--1851
-[] \T1/cmtt/m/n/9 pimo:referencingOccurrence <http://www.example.com/people/DirkHagemann>;[]
- []
-
-[33]
-Overfull \hbox (3.40773pt too wide) in paragraph at lines 1901--1901
-[] \T1/cmtt/m/n/10 pimo:groundingOccurrence <file://home/claudia/doc/tripplan.pdf>;[]
- []
-
-
-Overfull \hbox (3.40773pt too wide) in paragraph at lines 1936--1936
-[] \T1/cmtt/m/n/10 pimo:groundingOccurrence <file://home/claudia/doc/tripplan.pdf>;[]
- []
-
-[34]
-Overfull \hbox (13.90517pt too wide) in paragraph at lines 1937--1937
-[] \T1/cmtt/m/n/10 pimo:occurrence <http://www.buseireann.ie/timetables/belfast.pdf>;[]
- []
-
-[35] [36]
-Overfull \hbox (43.48953pt too wide) in paragraph at lines 2171--2209
- [][]
- []
-
-[37] [38] [39] [40] [41]
-Overfull \hbox (12.39114pt too wide) in paragraph at lines 2459--2460
-[]\T1/cmtt/m/n/10 pimo:tagLabel \T1/phv/m/n/10 (-20) is in-tro-duced as a sub-prop-erty of \T1/cmtt/m/n/10 nao:personalI
-dentifier\T1/phv/m/n/10 (-20) ,
- []
-
-[42] (pimo.bbl [43
-
-]) [44] (sections\pimo.tex
-Underfull \hbox (badness 10000) in paragraph at lines 7--7
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 14
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 22--22
-[]|\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 27
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 35--35
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 40
- []
-
-[45
-
-]
-Underfull \hbox (badness 10000) in paragraph at lines 48--48
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 53
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 61--61
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 66
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 74--74
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 79
- []
-
-[46]
-Underfull \hbox (badness 10000) in paragraph at lines 87--87
-[]|\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 92
- []
-
-
-Underfull \vbox (badness 10000) detected at line 105
- []
-
-[47]
-Underfull \vbox (badness 10000) detected at line 119
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 127--127
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 132
- []
-
-[48]
-Underfull \hbox (badness 10000) in paragraph at lines 140--140
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 145
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 153--153
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 158
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 166--166
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-[49]
-Underfull \vbox (badness 10000) detected at line 171
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 179--179
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 185
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 193--193
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 198
- []
-
-[50]
-Underfull \hbox (badness 10000) in paragraph at lines 206--206
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 211
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 219--219
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 225
- []
-
-[51]
-Underfull \hbox (badness 10000) in paragraph at lines 233--233
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 238
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 246--246
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 251
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 259--259
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 264
- []
-
-[52]
-Underfull \hbox (badness 10000) in paragraph at lines 272--272
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 277
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 285--285
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 290
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 298--298
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 303
- []
-
-[53]
-Underfull \hbox (badness 10000) in paragraph at lines 311--311
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 316
- []
-
-
-Underfull \vbox (badness 10000) detected at line 329
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 337--337
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-[54]
-Underfull \vbox (badness 10000) detected at line 342
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 350--350
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 355
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 363--363
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 368
- []
-
-[55]
-Underfull \hbox (badness 10000) in paragraph at lines 376--376
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 381
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 389--389
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 394
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 402--402
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 407
- []
-
-[56]
-Underfull \hbox (badness 10000) in paragraph at lines 415--415
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 420
- []
-
-[57]
-Underfull \hbox (badness 10000) in paragraph at lines 428--428
-\T1/phv/m/sl/10 (+20) pimo:\T1/phv/m/n/10 (+20) ClassOrThingOrPropertyOrAssociation
- []
-
-
-Underfull \vbox (badness 10000) detected at line 433
- []
-
-
-Underfull \vbox (badness 10000) detected at line 448
- []
-
-
-Underfull \vbox (badness 10000) detected at line 460
- []
-
-[58]
-Underfull \vbox (badness 10000) detected at line 472
- []
-
-
-Underfull \vbox (badness 10000) detected at line 484
- []
-
-
-Underfull \vbox (badness 10000) detected at line 496
- []
-
-
-Underfull \vbox (badness 10000) detected at line 508
- []
-
-[59]
-Underfull \vbox (badness 10000) detected at line 520
- []
-
-
-Underfull \vbox (badness 10000) detected at line 532
- []
-
-
-Underfull \vbox (badness 10000) detected at line 544
- []
-
-
-Underfull \vbox (badness 10000) detected at line 556
- []
-
-[60]
-Underfull \vbox (badness 10000) detected at line 568
- []
-
-
-Underfull \vbox (badness 10000) detected at line 580
- []
-
-
-Underfull \vbox (badness 10000) detected at line 592
- []
-
-
-Underfull \vbox (badness 10000) detected at line 604
- []
-
-[61]
-Underfull \vbox (badness 10000) detected at line 616
- []
-
-
-LaTeX Warning: Reference `nie:InformationElement' on page 62 undefined on input line 624.
-
-
-LaTeX Warning: Reference `nie:InformationElement' on page 62 undefined on input line 624.
-
-
-Underfull \vbox (badness 10000) detected at line 628
- []
-
-
-Underfull \vbox (badness 10000) detected at line 640
- []
-
-
-LaTeX Warning: Reference `nfo:Folder' on page 62 undefined on input line 648.
-
-
-LaTeX Warning: Reference `nfo:Folder' on page 62 undefined on input line 648.
-
-[62]
-Underfull \vbox (badness 10000) detected at line 652
- []
-
-
-Underfull \vbox (badness 10000) detected at line 664
- []
-
-
-Underfull \vbox (badness 10000) detected at line 676
- []
-
-
-Underfull \vbox (badness 10000) detected at line 690
- []
-
-[63]
-Underfull \vbox (badness 10000) detected at line 709
- []
-
-
-Underfull \vbox (badness 10000) detected at line 721
- []
-
-
-Underfull \vbox (badness 10000) detected at line 733
- []
-
-[64]
-Underfull \vbox (badness 10000) detected at line 745
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 752--752
-[]|\T1/phv/m/sl/10 (+20) pimo \T1/phv/m/n/10 (+20) Clas-sOr-Thin-gOr-Prop-er-ty-OrAs-so-ci-a-tion
- []
-
-
-Underfull \vbox (badness 10000) detected at line 757
- []
-
-
-Underfull \vbox (badness 10000) detected at line 769
- []
-
-[65]
-Underfull \vbox (badness 10000) detected at line 781
- []
-
-
-Underfull \vbox (badness 10000) detected at line 793
- []
-
-
-Underfull \vbox (badness 10000) detected at line 805
- []
-
-
-Underfull \vbox (badness 10000) detected at line 817
- []
-
-
-Underfull \hbox (badness 1117) in paragraph at lines 828--828
-[]|\T1/phv/m/n/10 (+20) Jabber-ID of the user. Used to com-mu-ni-
- []
-
-
-Underfull \hbox (badness 1436) in paragraph at lines 828--828
-\T1/phv/m/n/10 (+20) cate amongst peers in the so-cial sce-nario
- []
-
-
-Underfull \hbox (badness 1888) in paragraph at lines 828--828
-\T1/phv/m/n/10 (+20) of the se-man-tic desk-top. Use the xmpp
- []
-
-
-Overfull \hbox (16.62721pt too wide) in paragraph at lines 828--828
-\T1/phv/m/n/10 (-20) http://www.xmpp.org/specs/rfc3920.html#addressing-
- []
-
-
-Underfull \hbox (badness 1253) in paragraph at lines 828--828
-\T1/phv/m/n/10 (+20) node. The for-mat is the same as e-mail
- []
-
-[66]
-Underfull \vbox (badness 10000) detected at line 829
- []
-
-
-Underfull \vbox (badness 10000) detected at line 841
- []
-
-
-Underfull \vbox (badness 10000) detected at line 853
- []
-
-
-Underfull \vbox (badness 10000) detected at line 865
- []
-
-[67]
-Underfull \vbox (badness 10000) detected at line 877
- []
-
-
-Underfull \vbox (badness 10000) detected at line 889
- []
-
-
-Underfull \vbox (badness 10000) detected at line 901
- []
-
-[68]
-
-LaTeX Warning: Reference `nie:InformationElement' on page 69 undefined on input line 909.
-
-
-LaTeX Warning: Reference `nie:InformationElement' on page 69 undefined on input line 909.
-
-
-Underfull \vbox (badness 10000) detected at line 913
- []
-
-
-Underfull \vbox (badness 10000) detected at line 925
- []
-
-
-Underfull \vbox (badness 10000) detected at line 937
- []
-
-
-Underfull \vbox (badness 10000) detected at line 949
- []
-
-[69]
-Underfull \vbox (badness 10000) detected at line 961
- []
-
-
-Underfull \vbox (badness 10000) detected at line 973
- []
-
-
-Underfull \hbox (badness 2158) in paragraph at lines 984--984
-\T1/phv/m/n/10 (+20) a lim-ited set of HTML el-e-ments and can
- []
-
-
-Underfull \hbox (badness 1102) in paragraph at lines 984--984
-\T1/phv/m/n/10 (+20) con-tain links to other Things. The for-mat
- []
-
-
-Overfull \hbox (29.23505pt too wide) in paragraph at lines 984--984
-\T1/phv/m/n/10 (-20) (http://semanticweb.org/wiki/Wiki_Interchange_Format).|
- []
-
-
-Underfull \vbox (badness 10000) detected at line 985
- []
-
-) [70] (pimo.aux)
-
-LaTeX Warning: There were undefined references.
-
- )
-(\end occurred inside a group at level 1)
-
-### simple group (level 1) entered at line 2155 ({)
-### bottom level
-Here is how much of TeX's memory you used:
- 7562 strings out of 95282
- 108329 string characters out of 1185109
- 209367 words of memory out of 1201803
- 9887 multiletter control sequences out of 60000
- 56308 words of font info for 150 fonts, out of 1000000 for 2000
- 17 hyphenation exceptions out of 8191
- 41i,12n,39p,2384b,453s stack positions out of 5000i,500n,10000p,200000b,32768s
- <C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\MiKTeX\2.6\fonts\pk\ljfour\jknappen\ec\dpi600
-\ectt1200.pk> <C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\MiKTeX\2.6\fonts\pk\ljfour\jknappen\ec\dpi600\ec
-tt0900.pk> <C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\MiKTeX\2.6\fonts\pk\ljfour\jknappen\ec\dpi600\ectt0
-800.pk>{8r.enc} <C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\MiKTeX\2.6\fonts\pk\ljfour\jknappen\ec\dpi600\
-ectt1000.pk><C:/MiKTeX2.6/fonts/type1/bluesky/cm/cmmi10.pfb><C:/MiKTeX2.6/fonts/type1/bluesky/cm/cmmi8.pfb><C:/MiKTeX2.6
-/fonts/type1/bluesky/cm/cmr10.pfb><C:/MiKTeX2.6/fonts/type1/bluesky/cm/cmr8.pfb><C:/MiKTeX2.6/fonts/type1/bluesky/cm/cms
-y10.pfb><C:/MiKTeX2.6/fonts/type1/urw/helvetic/uhvb8a.pfb><C:/MiKTeX2.6/fonts/type1/urw/helvetic/uhvr8a.pfb><C:/MiKTeX2.
-6/fonts/type1/urw/helvetic/uhvro8a.pfb>
-Output written on pimo.pdf (75 pages, 1014841 bytes).
-PDF statistics:
- 2448 PDF objects out of 300000 (max. 8388607)
- 381 named destinations out of 300000 (max. 131072)
- 41007 words of extra memory for PDF output out of 65536 (max. 10000000)
-
diff --git a/pimo/doc/handbook_latex/pimo.out b/pimo/doc/handbook_latex/pimo.out deleted file mode 100644 index dcd0d9b..0000000 --- a/pimo/doc/handbook_latex/pimo.out +++ /dev/null @@ -1,62 +0,0 @@ -\BOOKMARK [1][-]{section.1}{Abstract}{}
-\BOOKMARK [1][-]{section.2}{Status of this document}{}
-\BOOKMARK [1][-]{section.3}{Introduction}{}
-\BOOKMARK [2][-]{subsection.3.1}{Downloading PIMO}{section.3}
-\BOOKMARK [1][-]{section.4}{PIMO integrates with key ontologies}{}
-\BOOKMARK [1][-]{section.5}{Examples}{}
-\BOOKMARK [2][-]{subsection.5.1}{PIMO ontology and namespaces}{section.5}
-\BOOKMARK [1][-]{section.6}{Creating Personal Information Models}{}
-\BOOKMARK [2][-]{subsection.6.1}{The User and their Individual PIMO}{section.6}
-\BOOKMARK [2][-]{subsection.6.2}{Things}{section.6}
-\BOOKMARK [2][-]{subsection.6.3}{Connecting Things to the User's PIMO}{section.6}
-\BOOKMARK [2][-]{subsection.6.4}{Identification of Things}{section.6}
-\BOOKMARK [2][-]{subsection.6.5}{A Complete Example}{section.6}
-\BOOKMARK [2][-]{subsection.6.6}{Labels and Names of Things}{section.6}
-\BOOKMARK [2][-]{subsection.6.7}{Textual description of Things}{section.6}
-\BOOKMARK [2][-]{subsection.6.8}{Rating and Ranking Things}{section.6}
-\BOOKMARK [2][-]{subsection.6.9}{Modelling Time}{section.6}
-\BOOKMARK [2][-]{subsection.6.10}{Representing Modification and Change Dates}{section.6}
-\BOOKMARK [2][-]{subsection.6.11}{Setting the Class of a Thing}{section.6}
-\BOOKMARK [2][-]{subsection.6.12}{The PIMO-upper ontology}{section.6}
-\BOOKMARK [2][-]{subsection.6.13}{Classes in PIMO-Upper}{section.6}
-\BOOKMARK [2][-]{subsection.6.14}{Describing Things with Attributes and Relations}{section.6}
-\BOOKMARK [2][-]{subsection.6.15}{Generic Properties in PIMO-Upper}{section.6}
-\BOOKMARK [2][-]{subsection.6.16}{Refined properties in PIMO-Upper}{section.6}
-\BOOKMARK [2][-]{subsection.6.17}{Tagging Things with Tags}{section.6}
-\BOOKMARK [2][-]{subsection.6.18}{Topic Hierarchies}{section.6}
-\BOOKMARK [2][-]{subsection.6.19}{Creating Personalized Classes and Properties}{section.6}
-\BOOKMARK [2][-]{subsection.6.20}{Collections of Things}{section.6}
-\BOOKMARK [2][-]{subsection.6.21}{Modeling Associations and Roles in PIMO}{section.6}
-\BOOKMARK [1][-]{section.7}{Connecting PIMO to Information Elements}{}
-\BOOKMARK [2][-]{subsection.7.1}{Connecting Things and Classes to Folders}{section.7}
-\BOOKMARK [2][-]{subsection.7.2}{Integrating Facts about Things}{section.7}
-\BOOKMARK [1][-]{section.8}{PIMO-group level: Group and Domain ontologies}{}
-\BOOKMARK [1][-]{section.9}{Extending PIMO}{}
-\BOOKMARK [2][-]{subsection.9.1}{Refining Elements of PIMO-upper}{section.9}
-\BOOKMARK [2][-]{subsection.9.2}{Markup for the new ontology}{section.9}
-\BOOKMARK [2][-]{subsection.9.3}{Information Elements}{section.9}
-\BOOKMARK [2][-]{subsection.9.4}{Extension by Sub-classing from External Classes}{section.9}
-\BOOKMARK [2][-]{subsection.9.5}{Summary}{section.9}
-\BOOKMARK [1][-]{section.10}{Importing Domain Ontologies into a User's PIMO}{}
-\BOOKMARK [1][-]{section.11}{Practical Directions on Using PIMO}{}
-\BOOKMARK [2][-]{subsection.11.1}{Creating Things}{section.11}
-\BOOKMARK [2][-]{subsection.11.2}{Changing the Type of a Thing}{section.11}
-\BOOKMARK [2][-]{subsection.11.3}{Deleting a Thing}{section.11}
-\BOOKMARK [2][-]{subsection.11.4}{Deleting User-generated Classes and Properties}{section.11}
-\BOOKMARK [2][-]{subsection.11.5}{Merging Duplicates}{section.11}
-\BOOKMARK [2][-]{subsection.11.6}{Unification of multiple Information Elements into one Thing}{section.11}
-\BOOKMARK [2][-]{subsection.11.7}{Tagging and Annotating Files}{section.11}
-\BOOKMARK [2][-]{subsection.11.8}{Geo-locating Things}{section.11}
-\BOOKMARK [2][-]{subsection.11.9}{Defining what is in the PIMO and what is not: NRL Graphs and definedBy}{section.11}
-\BOOKMARK [2][-]{subsection.11.10}{Using NAO and NIE Elements for Annotation}{section.11}
-\BOOKMARK [2][-]{subsection.11.11}{How to Infer Knowledge Using Rules?}{section.11}
-\BOOKMARK [1][-]{section.12}{Rules Defined by PIMO}{}
-\BOOKMARK [2][-]{subsection.12.1}{Construction Rules}{section.12}
-\BOOKMARK [2][-]{subsection.12.2}{Validation Rules}{section.12}
-\BOOKMARK [2][-]{subsection.12.3}{Rules Valid when Integrating with NIE}{section.12}
-\BOOKMARK [1][-]{section.13}{Sources considered for designing PIMO}{}
-\BOOKMARK [1][-]{appendix.A}{Changes}{}
-\BOOKMARK [2][-]{subsection.A.1}{From v1.0 to 1.1}{appendix.A}
-\BOOKMARK [1][-]{appendix.B}{PIMO Specification}{}
-\BOOKMARK [2][-]{subsection.B.1}{Ontology Classes Description}{appendix.B}
-\BOOKMARK [2][-]{subsection.B.2}{Ontology Properties Description}{appendix.B}
diff --git a/pimo/doc/handbook_latex/pimo.pdf b/pimo/doc/handbook_latex/pimo.pdf Binary files differdeleted file mode 100644 index ee10114..0000000 --- a/pimo/doc/handbook_latex/pimo.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/pimo.tcp b/pimo/doc/handbook_latex/pimo.tcp deleted file mode 100644 index 1af5b2e..0000000 --- a/pimo/doc/handbook_latex/pimo.tcp +++ /dev/null @@ -1,12 +0,0 @@ -[FormatInfo]
-Type=TeXnicCenterProjectInformation
-Version=4
-
-[ProjectInfo]
-MainFile=pimo.tex
-UseBibTeX=1
-UseMakeIndex=0
-ActiveProfile=LaTeX => PDF
-ProjectLanguage=en
-ProjectDialect=US
-
diff --git a/pimo/doc/handbook_latex/pimo.tex b/pimo/doc/handbook_latex/pimo.tex deleted file mode 100644 index 77460c8..0000000 --- a/pimo/doc/handbook_latex/pimo.tex +++ /dev/null @@ -1,2473 +0,0 @@ -% Process:
-% issues are added as \note{\emph{Name}: problem is that x!=y}
-% when issues are solved, they are commented out.
-
-% STATUS
-% Knud: we should do two documents, one short and precise one describing the standard and a longer one for
-% explaining the decision made and the design rationale.
-% Renauld and Knud work on it from DERI side.
-
-% next todos:
-
-% TODO: I often used the syntax <pimo:<Name>> to describe elements of the ontology, they should later be hyperlinked to the description in the appendix. Linking these elements to the ontology should be done in a script.
-
-% DONE:
-% 20.06.2007 : Leo adds his latest status on the core questions and answers that PIMO should give, also explaining the ontology from the rdfs folder.
-% LEO: check if all NAO has been used
-% LEO: copy/paste mid/domain-level stuff from iSemantics Paper
-
-% SOURCES FROM WHERE LEO COPY/PASTED - code will contain comments where this happened
-% SauermannElstDengel2007 - the PIMO paper at ISemantics 2007
-% SauermannDissertation - Leo's diss, the soon-ending project. There is an intended overlap between SauermannElstDengel2007 and the diss.
-
-% History:
-% 10.8.2007: Knud commits review, Leo works on arguments
-% 20.06.2007: Leo and Knud skype and exchange plans.
-% 29.06.2007: Leo has a first draft for review, this now reflects Leos view and the most important decisions made, Ludger and Sintek have to review to achieve a DFKI view.
-% 12.09.2007: Leo and Knud Skype.
-% LEO: take agreed problem EQUIVALENCE, document it, move it to solved.
-
-% INPUT AND INSPIRATION
-% This document should use other RDF standards as input, these are well known documents:
-% http://www.w3.org/TR/rdf-schema/ RDFS Primer
-% http://www.w3.org/TR/swbp-skos-core-guide SKOS Core guide
-% http://svn.nepomuk.semanticdesktop.org/repos/trunk/taskforce/TF-Ont/draft/NRL.html NRL spec (draft)
-
-
-\documentclass[11pt]{nepomuk}
-\usepackage{hyperref} % turn on when latex is used (not miktec)
-\usepackage{url} % LEO: urls \url{}
-\usepackage{verbatim} % code and comment
-\usepackage{longtable}
-\usepackage{xspace} % whitespace after a macro if no punctuation after the macro
-\usepackage{microtype} % maybe fixes hyphenation in \texttt{pimo:Thing} sentences, see http://newsgroups.derkeiler.com/Archive/Comp/comp.text.tex/2007-08/msg01174.html
-%\usepackage[htt]{hyphenat}
-\parindent0pt
-
-\begin{document}
-% explicit hyphenations
-\hyphenation{RDF-Re-po-si-to-ry}
-\hyphenation{name-space}
-\hyphenation{So-cket-A-dap-ter}
-
-
-% DEBUGGING HBOXES
-%\overfullrule=5pt
-
-% OUR chosen wording:
-% Thing uppercase
-% sub-property and sub-class instead of subproperty in prosa-text.
-
-% even with goodwill and installing winfonts,
-% \emph does NOT work with tahoma.
-% \fontfamily{tahoma}\selectfont
-%\def\note#1{\marginpar{\footnotesize#1}} % use this to show the notes in the document
-\def\note#1{} % use this to hide the notes
-
-\def\ie{\textit{i.\,e.},\ }
-\def\eg{\textit{e.\,g.},\ }
-
-\newcommand{\pimo}{\emph{PIMO}\xspace}
-\newcommand{\pimos}{\emph{PIMO}s\xspace}
-\newenvironment{definition}{}{}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% TITLE PAGES
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\thispagestyle{empty}
-
-\pagenumbering{roman}
-
-\hspace*{-4.5cm}
-\begin{minipage}[p]{7cm}
-\begin{large}
-\textcolor{nepomuk@lightblue}{
-\begin{tabular}{l}
-Integrated Project \\
-Priority 2.4.7 \\
-Semantic based knowledge systems\\
-\end{tabular}
-}
-\end{large}
-\end{minipage}
-
-\vspace{-2.8cm}
-
-
-\begin{flushright}
- \includegraphics*[width=3.89cm]{images/InformationSocietyTechnologies}
-\end{flushright}
-
-\vspace{0.5cm}
-
-\begin{flushright}
- \includegraphics[width=12cm]{images/Nepomuk}
-\end{flushright}
-
-
-\vspace{1cm}
-
-
-\textcolor{nepomuk@lightblue}{\rightline{\Huge{\bfseries \sffamily Personal Information Model (PIMO)}}}
-\textcolor{nepomuk@lightblue}{\rightline{\Huge{\bfseries \sffamily Ontology Guide}}}
-
-\vspace{0.3cm}
-
-\textcolor{nepomuk@green}{\rightline{\huge NEPOMUK Recommendation v1.1}}
-
-\vspace{0cm}
-
-%\begin{figure}[h!]
-\begin{flushright}
- \includegraphics[width=9cm]{images/Bubbles}
-\end{flushright}
-%\end{figure}
-
-
-\vspace*{-5.5cm}
-
-\renewcommand{\arraystretch}{1.2}
-\hspace*{-4.5cm}
-\begin{minipage}[p]{11cm}
-\begin{large}
-\textcolor{nepomuk@red}{
-\begin{tabular*}{8cm}{l@{\extracolsep{\fill}}l}
-\multicolumn{2}{l}{\Large Version 1.1} \\
-\multicolumn{2}{l}{\Large 02.02.2009} \\
-\multicolumn{2}{l}{\Large Dissemination level: PU} \\
-\\
-Nature & Report \\
-%Due date & 31.05.2006 \\
-Lead contractor & DFKI\\
-Start date of project \qquad & 01.01.2006 \\
-Duration & 36 months \\
-\end{tabular*}
-}
-\end{large}
-\end{minipage}
-
-\clearpage
-%%%%%%%%%%%%%%
-% NEXT PAGES %
-%%%%%%%%%%%%%%
-\pagestyle{scrheadings}
-
-\cohead{\small\textcolor{nepomuk@lightblue}{NEPOMUK}}
-\rohead{\small\textcolor{nepomuk@lightblue}{02.09.2008}}
-\lofoot{\small\textcolor{nepomuk@lightblue}{Task Force Ontologies}}
-\cofoot{\small\textcolor{nepomuk@lightblue}{Version 1.0}}
-\rofoot{\small\textcolor{nepomuk@lightblue}{\thepage}}
-
-\newpage
-
-\section*{Authors}
-\hspace*{-2,5cm}\begin{minipage}[p]{14cm}
-Leo Sauermann, DFKI \\
-Ludger Van Elst, DFKI \\
-Knud M\"oller, DERI\\
-\end{minipage}
-
-
-\vfill
-\section*{Project Co-ordinator}
-\hspace*{-2,5cm}\begin{minipage}[p]{14cm}
-Dr. Ansgar Bernardi \\
-German Research Center for Artificial Intelligence (DFKI) GmbH \\
-Trippstadter Strasse 122 \\
-D 67663 Kaiserslautern \\
-Germany \\
-Email: bernardi@dfki.uni-kl.de, phone: +49 631 205 3582, fax: +49 631 205 4910 \\
-\end{minipage}
-
-
-\section*{Partners}
-\hspace*{-2,5cm}\begin{minipage}[p]{14cm}
-DEUTSCHES FORSCHUNGSZENTRUM F. KUENSTLICHE INTELLIGENZ GMBH \\
-IBM IRELAND PRODUCT DISTRIBUTION LIMITED \\
-SAP AG \\
-HEWLETT PACKARD GALWAY LTD \\
-THALES S.A. \\
-PRC GROUP - THE MANAGEMENT HOUSE S.A. \\
-EDGE-IT S.A.R.L \\
-COGNIUM SYSTEMS S.A. \\
-NATIONAL UNIVERSITY OF IRELAND, GALWAY \\
-ECOLE POLYTECHNIQUE FEDERALE DE LAUSANNE \\
-FORSCHUNGSZENTRUM INFORMATIK AN DER UNIVERSITAET KARLSRUHE \\
-UNIVERSITAET HANNOVER \\
-INSTITUTE OF COMMUNICATION AND COMPUTER SYSTEMS \\
-KUNGLIGA TEKNISKA HOEGSKOLAN \\
-UNIVERSITA DELLA SVIZZERA ITALIANA \\
-IRION MANAGEMENT CONSULTING GMBH
-
-\vspace{0.3cm}
-\begin{footnotesize}
-Copyright: NEPOMUK Consortium 2006\\
-Copyright on template: Irion Management Consulting GmbH 2006
-\end{footnotesize}
-\end{minipage}
-
-\clearpage
-
-
-\section*{Versions}
-
-\begin{footnotesize}
-\begin{tabular}{|c|c|p{8cm}|}
-\hline
-\rowcolor{nepomuk@lightblue}\textcolor{white}{Version} &
- \textcolor{white}{Date} &
- \textcolor{white}{Reason} \\ \hline
-0.1 & 01.06.2007 & a template of the document prepared by Antoni Mylka \\ \hline
-0.9 & 12.08.2008 & Finished for review. \\ \hline
-1.0 & 02.09.2008 & Reviewed and accepted. \\ \hline
-1.1 & 02.02.2009 & Incorporating new handling of Tagging \\ \hline
-\end{tabular}
-\end{footnotesize}
-
-\color{black}
-
-\vfill
-{\bf Explanations of abbreviations on front page}\\
-\\
-Nature \\
-R: Report \\
-P: Prototype \\
-R/P: Report and Prototype \\
-O: Other \\
- \\
-Dissemination level \\
-PU: Public \\
-PP: Restricted to other FP6 participants \\
-RE: Restricted to specified group \\
-CO: Confidential, only for NEPOMUK partners \\
-
-\newpage
-
-%%%%%%%%%%%%%%%%%%%%%
-% TABLE OF CONTENTS %
-%%%%%%%%%%%%%%%%%%%%%
-\setcounter{tocdepth}{2}
-\tableofcontents
-\cleardoublepage
-\pagenumbering{arabic}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%
-% BEGINNING OF SECTIONS %
-%%%%%%%%%%%%%%%%%%%%%%%%%
-\clearpage
-\section{Abstract}
-The PIMO Ontology can be used to express Personal Information Models of individuals. It is based on RDF and NRL, the NEPOMUK Representational Language and other Semantic Web ontologies. This document describes the principle elements of the language and how to use them.
-
-\section{Status of this document}
-This section describes the status of this document at the time of its publication. The form used for this status message and document is inspired by the W3C process.
-
-This document is an NEPOMUK recommendation produced by Leo Sauermann and Knud M\"oller as part of the task-force Ontologies in the NEPOMUK Project.
-The document has been promoted from a draft form to this official form upon reviewing by the general NEPOMUK consortium. Subsequent versions of PIMO might mean that the specification documents of the later versions render this document obsolete, with respect to the version of PIMO in use, but not with respect to this version.
-
-%\note{\emph{Knud}: Is PIMO really a language?}
-%\note{\emph{Leo}: probably not, its an ontology}
-This document and the PIMO ontology as such is a continuation and improvement of existing work. Other documents may supersede this document.
-Parts of this document will be published in other documents, such as scientific publications. This document is based on various other publications by the authors, and is a continuation of existing work. Some formulations from the RDFS primer and SKOS primer documents were reused.
-
-Additional to this document, a FAQ is maintained in the public NEPOMUK
-wiki\footnote{\url{http://dev.nepomuk.semanticdesktop.org/wiki/PimoFaq}}.
-\textbf{This document is accompanied by a RDFS/NRL ontology\footnote{\url{http://www.semanticdesktop.org/ontologies/2007/11/01/pimo\#}}, which should be downloaded (see Section~\ref{sec:downloadingpimo}) and read in parallel to learn more about PIMO.}
-
-The key phrase ``\textbf{At Risk of Change}'' is used to mark parts of the recommendation
-that are under discussion and change in future versions (can appear in footnotes).
-
-The editors of this document value feedback from from the public and from the NEPOMUK consortium.
-Typographic errors and change requests of the ontology can be reported using the NEPOMUK tracker\footnote{\url{https://dev.nepomuk.semanticdesktop.org/newticket}}, using the category \textbf{ontology-pimo}. General questions about using the ontology will be answered in the FAQ.
-Subsequent versions of the ontology will include improvements gathered in this way.
-
-We want to thank our reviewers for their feedback: Ansgar Bernardi, Siegfried Handschuh, P\"ar Lanner\"o, Enrico Minack, Gerald Reif, and Max V\"olkel.
-
-
-\section{Introduction}
-\label{sec:introduction}
-\pimo is the abbreviation for the \emph{Personal Information Model} of a user. The PIMO-Ontology is both an RDF vocabulary\footnote{More precisely, PIMO is based on the NEPOMUK Representational Language (NRL), which extends the RDF model with a semantic model and support for named graphs and other features. However, for the sake of simplicity, we will use the term RDF throughout most of this document.} to express such a model and an upper ontology defining basic classes and properties to use.
-
-Readers of this document should be familiar with the Resource Description Framework on the level described in the RDFS-Primer~\cite{rdfs} and the NRL specification\footnote{\url{http://www.semanticdesktop.org/ontologies/nrl/}}.
-The emphasized key words ``\textbf{must}'', ``\textbf{must not}'', ``\textbf{required}'', ``\textbf{shall}'', ``\textbf{shall not}'', ``\textbf{should}'', ``\textbf{should not}'', ``\textbf{recommended}'', ``\textbf{may}'', and
-``\textbf{optional}'' in this document are to be interpreted as described in
-RFC 2119.
-
-The scope of a PIMO is to model data that is within the attention of the user and needed for knowledge work or private use. The focus is on data that is accessed through a Semantic Desktop or other personalized Semantic Web applications. We call this the \textbf{Personal Knowledge Workspace}~\cite{HolzMausBernardiRostanin2005b} or \textbf{Personal Space of Information (PSI)}~\cite{pim2007},
-embracing all data ``\emph{needed by an individual to
-perform knowledge work}''. It is (1) independent from the way the user accesses the data, (2) independent from the source, format, and author of the data.
-The abbreviation \textbf{PSI} will be used.
-\note{\emph{Knud}: This is a strange sentence. What does ``never part of computerized systems'' mean? Is ``Love'' such data?\\
-\emph{Leo}: Added a sentence below about ``existing information''}
-%Is Data that is never part of computerized systems is out of scope.
-
-
-Today, such data is typically stored in files, in Personal Information Management (PIM) or in groupware systems. A user has to cope with
-\note{\emph{Knud}: What is ERP?} different formats of data, such as text documents, contact information, e-mails, appointments, task lists, project plans, or an Enterprise Resource Planning (ERP) system.
-% replacement for the ``Love'' problem above:
-Existing information that is already stored in information systems is in the scope of PIMO, but abstract concepts (such as ``Love'', ``Language'') can also be represented, if needed.
-
-%Existing information is represented using the NEPOMUK Information Element (NIE) ontology framework~\footnote{\url{http://www.semanticdesktop.org/ontologies/nie/}}. It defines classes for Information Elements, such as e-mails, documents, appointments, and contacts.
-
-%\note{\emph{Knud}: Why XML TMs? It's the model that matters, not the syntax, right?
-%\emph{Leo}: Topic Maps has a different approach to modelling than RDF. Especially
-%indirect identification using identifiers is clearly specified in TM, but not in RDF. Moved the reference to TM a bit lower and adding a note to identity}
-
-%Similar to SKOS,
-PIMO is based on the idea that users have a \emph{mental model} to categorize their environment.
-It represents the user itself and the fact that he has a \emph{Personal Information Model}, this is described in Section~\ref{sec:pimo-user}.
-Building a PIMO for the imaginary user \textit{Claudia Stern} is the guiding example for this document.
-Each concept in the environment of the user is represented as \emph{Thing} in the model,
-and mapped to documents and other entities that mention the concept (see Section~\ref{sec:thing}).
-Things can be described via their relations to other Things or by literal RDF properties,
-the key properties are defined in Section~\ref{sec:describingthings} and directions given
-how to use them.
-An important question is the class of a Thing; the semantics of classes and top level classes are presented in Sections~\ref{sec:classofthing}-\ref{sec:pimoUpperClasses}.
-To match and align similar concepts, existing identification systems are reused and integrated (Section ~\ref{sec:identification}).
-
-PIMO is similar to SKOS or Topic Maps (TM)~\cite{iso13250second} in its goal of providing an easy way of modelling, but different in the way concepts are modeled. RDFS classes and sub-class relations (which are used in NRL) are used to represent the classes of Things, individuals are represented using typed RDF resources. From TM, the idea of indirect identification is taken up.
-%, in this regard PIMO is similar to OWL.
-%\note{\emph{Knud}: this sounds very weird. PIMO is similar to OWL because it uses RDFS class and instances are RDF resource? Then PIMO is first and foremost similar to RDFS!
-%\emph{Leo}: Removed the reference to OWL, not needed. Reference to RDFS is implicit.}
-
-%\note{\emph{Knud}: really? Each element is a pimo:Thing?
-%\emph{Leo}: Thing and subclasses, but thats the key idea, we have to discuss and agree on this.}
-%\note{\emph{Knud}: of course sameAs is directed! Every arc in an RDF graph is directed! Also, directedness and whether or not resources form a graph are not contradictions, so why do you say ``rather''?
-%\emph{Leo} owl:sameAs is symmetric, so the direction is not known, the inverse of sameAs is sameAs. In pimo, directed relations are used, with the Thing as subject and the resource as object}
-PIMO is different from OWL, where \texttt{sameAs} relations are symmetric equivalence relations forming a fully connected graph amongst identical resources.
-In PIMO, Things are connected to their equivalent resources using directed relations.
-
-The design rationale %(see Section~\ref{sec:designrationale})
-is to keep the PIMO ontology as minimal as possible, and also the data needed to create a PIMO for a user as minimal as possible. Inside one PIMO of a user, duplication is avoided.
-PIMO builds on Semantic Desktop ontologies (NRL, NIE, NAO) and guidelines are provided how to reuse other existing RDFS ontologies (Section~\ref{sec:integratingontologies}) and import data expressed in these ontologies.
-After importing, rules are used to integrate facts (see Section~\ref{sec:integratingfacts}).
-% this is a typical ``summary'' sentence, but in a standards document, there are usually no ``summary'' sections, so it remains here. REALLY, the RDFS primer has no summary nor has the SKOS primer. live with it.
-% BTW: Leo invested four fucking years into this, so the reader HAS the 20 seconds time to read this.
-
-Only by addressing all key issues --- precise representation, easy adoption, easy to understand by users, extensibility, interoperability, reuse of existing ontologies, data integration --- PIMO provides a framework for creating personal information management applications and ontologies.
-
-\subsection{Downloading PIMO}
-\label{sec:downloadingpimo}
-The RDF descriptions of the ontology can be retrieved from its namespace using content negotiation:
-{\small
-\begin{verbatim}
-Namespace:
-http://www.semanticdesktop.org/ontologies/2007/11/01/pimo#
-\end{verbatim}
-}
-
-Different serializations are available:
-\begin{itemize}
- \item XML/RDFS Serialization: PIMO (Data Graph Only)\\
- {\small\url{http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/pimo_data.rdfs}}
- \item XML/RDFS Serialization: PIMO (Metadata Graph Only)\\
- {\small\url{http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/pimo_metadata.rdfs}}
- \item TriG Serialization: PIMO (Graph Set)\\
- {\small\url{http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/pimo.trig}}
-\end{itemize}
-
-\section{PIMO integrates with key ontologies}
-The PIMO framework does not stand alone but is part of a set of
-carefully designed and integrated ontologies for the Semantic Desktop
-which were developed in parallel to provide an integrated framework.
-In Figure~\ref{fig:roadmap} an overview is given.
-
-\begin{figure}[htb]
- \centering
- \includegraphics[width=1.00\textwidth]{images/roadmap.png}
- \caption{Integrated Ontologies}
- \label{fig:roadmap}
-\end{figure}
-
-The NEPOMUK Representational Language \textbf{NRL ontology}\footnote{\url{http://www.semanticdesktop.org/ontologies/nrl/}} builds the representational layer and the semantic
-metadata axioms used to express PIMO.
-NRL is a meta-language comparable to OWL or RDF/S.
-The key characteristics of NRL are (on top of RDF/S) support for named graphs
-in semantic statements, a notation for contextualized inference and semantics,
-and a selection of semantic relations (inverse, transitive, reflexive).
-
-The NEPOMUK Information Element \textbf{NIE ontology}\footnote{\url{http://www.semanticdesktop.org/ontologies/nie/}} describes desktop elements such as address book entries, documents,
-e-mails, appointments, pictures, and multimedia files.
-The ontology discriminates between the representation (binary files)
-and the information stored therein.
-PIMO reuses the classes of NIE and suggests how to integrate
-and annotate vast personal spaces of information (PSI) expressed in NIE.
-
-Annotations and tagging are represented in the NEPOMUK Annotation \textbf{NAO ontology}.
-It represents change-dates, author, and other key metadata of documents.
-NIE and PIMO both extend NAO. A part of NAO is the NEPOMUK Graph Metadata \textbf{NGM ontology} to annotate named graphs.
-
-The PIMO ontology crosses two of the layers in the ontology pyramid, data related to PIMO can be divided into three smaller layers (also visible in Figure\ref{fig:roadmap}):
-\begin{itemize}
- \item \emph{Foundational PIMO}: The PIMO ontology as such, as defined in this specification and accompanying NRL serialization. This includes the classes and properties of \emph{PIMO-upper} (see Section \ref{sec:pimoupper}), which work on the \emph{Upper-Level Layer} of NEPOMUK and everything else defined in the PIMO vocabulary. PIMO-upper is the same for every Semantic Desktop user and is valid in a global context.
- \item \emph{Group-level PIMO}: Domain ontologies that are shared within a group. They can be imported by users. A description is given in Section~\ref{sec:pimomid}.
- \item \emph{Personal-level PIMO}: The classes, properties, and Things created by an individual user. Also called \emph{user-PIMO}, this layer includes the data that is only relevant in the context of one individual.
-\end{itemize}
-
-\section{Examples}
-\label{sec:examples}
-A scenario is used to explain the ontology elements. A fictional persona, Claudia Stern, is our example user. She is working for EX-Ample Inc., a fictional company producing ``\textbf{Ex}treme Guitar \textbf{Ampl}ifi\textbf{e}rs'', and her current task is to organize a business trip to a meeting with guitarists and bass players in Belfast.
-
-% taken from RDFS primer
-For convenience and readability, this specification uses an abbreviated form to represent URI-References. A name of the form \texttt{prefix:suffix} should be interpreted as a URI-Reference consisting of the URI-Reference associated with the prefix concatenated with the suffix.
-
-RDF graphs are written in N3/Turtle syntax. Examples serialized as RDF appear in this typesetting:
-%\note{\emph{Knud}: I find the statement (Claudia user Claudia) very confusing. What's that supposed to mean? \emph{Leo}: that was garbage, we had it in the ontology before as an alternative to isDefinedBy.}
-{\small
-\begin{verbatim}
-claudia:Claudia a pimo:Person;
- pimo:isDefinedBy claudia:PIMO;
- nco:hasEmailAddress <mailto:claudia@example.com> .
-\end{verbatim}
-}
-
-\subsection{PIMO ontology and namespaces}
-The ontology described in this document has this namespace:
-
-{\small
-\begin{verbatim}
-Namespace:
-http://www.semanticdesktop.org/ontologies/2007/11/01/pimo#
-\end{verbatim}
-}
-
-During the lifetime of the NEPOMUK project (until Dec 2008), the PIMO ontology
-and the according documentation may change, but the namespace will not change.
-The namespace stays fixed to keep the necessary changes
-of software implementations at a minimal level.
-We have adopted this practice from other projects, which have applied it successfully. Examples are the W3C's XSD datatypes (the recommendation changed in 2007, the namespace did not) or the FOAF project.
-
-Throughout this document these ontologies and namespaces are used, also indicating their respective versions PIMO is building on:
-{\small
-\begin{verbatim}
-@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix nrl: <http://www.semanticdesktop.org/ontologies/2007/08/15/nrl#>.
-@prefix nao: <http://www.semanticdesktop.org/ontologies/2007/08/15/nao#>.
-@prefix pimo: <http://www.semanticdesktop.org/ontologies/2007/11/01/pimo#>.
-@prefix ncal: <http://ont.semanticdesktop.org/ontologies/2007/04/02/ncal#>.
-@prefix nco: <http://ont.semanticdesktop.org/ontologies/2007/03/22/nco#>.
-@prefix nfo: <http://ont.semanticdesktop.org/ontologies/2007/03/22/nfo#>.
-@prefix nie: <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#>.
-@prefix nmo: <http://www.semanticdesktop.org/ontologies/2007/03/22/nmo#>.
-
-@prefix claudia: <http://www.example.com/people/claudia#> .
-\end{verbatim}
-}
-
-\section{Creating Personal Information Models}
-\label{sec:creatingPIMOs}
-In this section, all key elements of the ontology are presented.
-The order used reflects the steps a knowledge engineer will have to take to implement this recommendation.
-
-\subsection{The User and their Individual PIMO}
-\label{sec:pimo-user}
-As a prerequisite to create a PIMO and Things inside the PIMO, each user needs a \emph{personal namespace}. The namespace is used as a prefix for all URIs minted for the user. Often these are namespaces using the HTTP URI scheme, but any RDF namespace can be used. The example namespace used in this document is \texttt{http://www.example.com/people/claudia\#} and is abbreviated with ``\texttt{claudia:}''.
-
-\note{\emph{Knud}: In general, I would write all ontology elements in a different font. E.g., \texttt{pimo:Person}
-\emph{Leo}: actually, I would like to write a script that, once this is converted
-to HTML, replaces all ``pimo:NAME'' with HTML links to the ontology definition
-within the namespace.
-\emph{Knud, 28/12:} unfortunately, there isn't always a namespace given. For now, I changed all ontology elements to monospaced font}
-
-Users are represented as instances of the class \texttt{pimo:Person}. For each instance, a new URI is generated and a few key facts are represented to identify the user.
-After the user has been instantiated, details such as email addresses are added by using terms from the NEPOMUK contact ontology, NCO.
-%\note{Knud: What do you mean by ``as the second object''? \emph{Leo}: fixed this, its a new resource.}
-In NCO, contact information connected to people is modeled as a complex resource, not as a simple literal:
-%For the sake of simplicity, we used the URL \texttt{mailto:claudia@example.com} as identifier for this nco:EmailAddress resource.
-{\small
-\begin{verbatim}
-claudia:Claudia a pimo:Person;
- rdfs:label "Claudia Stern";
- nco:hasEmailAddress mailto:claudia@example.com.
-
-mailto:claudia@example.com a nco:EmailAddress;
- nco:contactMediumComment "work";
- nco:emailAddress "claudia@example.com".
-\end{verbatim}
-}
-
-The second entity that needs to be represented is the \emph{Personal Information Model of the User}. It is connected to the user via the \texttt{pimo:creator} relation, and the user's namespace is added.
-For Claudia this is:
-
-{\small
-\begin{verbatim}
-claudia:PIMO a pimo:PersonalInformationModel;
- pimo:creator claudia:Claudia;
- nao:hasDefaultNamespace "http://www.example.com/people/claudia#";
- nao:hasDefaultNamespaceAbbreviation "claudia".
-\end{verbatim}
-}
-
-\texttt{pimo:PersonalInformationModel} is a sub-class of \texttt{nrl:Ontology}, allowing more metadata to be added using NRL compliant standards. More about NRL metadata is described in Section~\ref{sec:nrlgraphs}.
-We further call a this instance of \texttt{pimo:PersonalInformationModel} of an individual a \emph{user-PIMO}. Claudia's user-PIMO is \texttt{claudia:PIMO}. As an abbreviation, it is also correct to write ``Claudia's PIMO'' instead of ``Claudia's user-PIMO''.
-\note{\emph{Knud, 28/12:} I'm confused by this term PIMO-user. It sounds as if it meant ``The user of the PIMO'', but it actually means ``The PIMO of the user'' --- correct? That's potentially confusing.}
-\note{\emph{Leo, 8/1:} reduce to ``user's PIMO'' and ``Claudia's PIMO''?}
-
-\subsection{Things}
-\label{sec:thing}
-The PIMO ontology defines the basic class \texttt{Thing} for mental concepts. Every information element encountered in knowledge work by a user is represented as a Thing.
-\note{\emph{Knud, 28/12:} Thing is inconsistently spelled with lower- and upper-case throughout the document.}
-A Thing is a unique representation of an entity of the real world within one user-PIMO. On the PSI of a user, a real world entity can be represented in multiple data sources. For example, the person ``Dirk Hagemann'' may be author of an e-mail, described in an address book entry, and stored in a accounting tool, all part of the workspace of ``Claudia''.
-One instance of \texttt{pimo:Person} is created as unique \texttt{Thing} linking to these multiple representations, such as shown in Figure~\ref{fig:thing_vs_resource}.
-\note{\emph{Knud, 28/12:} Yes, this is a Thing, but it is also a pimo:Person? Potentially confusing. \emph{Leo, 8/1:} changed the wording to speak of a Person}
-
-\begin{figure}[htbp]
- \centering
- \includegraphics[width=1.00\textwidth]{images/thing_vs_resource}
- \caption{Thing and Resources}
- \label{fig:thing_vs_resource}
-\end{figure}
-
-An application handling a resource in the workspace can be aware that there may be a Thing representing the resource. For example, Claudia's e-mail client may examine the sender of an e-mail (Dirk) and search for the \texttt{pimo:Thing} that represents Dirk uniquely. Once the right Thing is found by the application, more information about Dirk can be discovered.
-
-This principle includes all elements (\texttt{nie:InformationElement} and other RDF resources) in the user's \emph{Personal Space of Information (PSI)}.
-For each information element, a Thing in the user's PIMO must be created.
-The information element exists independent of the user, the same element can
-be stored in multiple folders or data sources on one desktop, and also on other desktops and on the web.
-A Thing is the personalized view of \emph{one user} on this information element, independent of representation or storage location.
-
-To be adequate, a PIMO of a user should contain all nameable entities known to the user,
-but to be efficient, this representation should be restricted to the minimal data needed.
-%Leo 29.7.2008: this is also explained later
-% Identification is part of this minimal data, and \texttt{nao:identifier} provides the property for it.
-
-\subsection{Connecting Things to the User's PIMO}
-\label{sub:connectingThingsToPimo}
-In a scenario of multiple connected semantic desktops, it will frequently occur that users import data from each other's desktop onto their own desktop.
-It is therefore important to know which resources (primarily Things, but also Classes and Properties) were created by which user and originate from which PIMO. For this, the property \texttt{pimo:isDefinedBy} is used.
-
-Continuing the example above, this property connects the Person to the PIMO in which it is defined. This is mandatory for every defined Thing and allows applications to identify which elements are part of a user-PIMO and which are not\footnote{We intentionally did not only rely on NRL graphs to model the relation between the model and instances defined by it. A graph can only contain \emph{statements},
-about, but not \emph{resources} as such.
-To model that a resource is part of a PIMO, the \texttt{pimo:isDefinedBy} relation is a clear representation.
-Additionally, named graphs can be used to declare what \emph{statements} are declared in a PIMO, see~\ref{sec:nrlgraphs}}.
-
-{\small
-\begin{verbatim}
-claudia:Claudia pimo:isDefinedBy claudia:PIMO.
-\end{verbatim}
-}
-
-An \texttt{isDefinedBy} property is also defined in RDFS, where resources can be connected to their defining ontologies, and is also discussed in the light of the OWL standard\footnote{\url{http://www.w3.org/2007/OWL/wiki/Syntax\#Declarations_and_Structural_Consistency}}.
-The semantics of \texttt{isDefinedBy} in PIMO is based on these, with the extension that we define it as a required property.
-
-\subsection{Identification of Things}
-\label{sec:identification}
-A Thing \textbf{must} have an URI and \textbf{should} be described with properties that identify it.
-Identifiers allow to analyse information elements and find occurrences of the Thing.
-For example, the person ``Dirk Hagemann'' is represented once as an instance of the class \texttt{pimo:Person} and identified using his e-mail address.
-The RDF descriptions of emails and documents can then be analysed to find resources that represent the same entity via this identifier.
-{\small
-\begin{verbatim}
-# The canonical Dirk
-claudia:DirkHagemann a pimo:Person;
- pimo:isDefinedBy claudia:PIMO;
- nco:hasEmailAddress <mailto:dirk@example.com>.
-
-# An e-mail in which Dirk #2 occurs
-<imap://claudia@example.com/INBOX/1> a nmo:Mail;
- nmo:from <imap://claudia@example.com/INBOX/1#from>.
-
-# Dirk #2, the email sender
-<imap://claudia@example.com/INBOX/1#from> a nco:Contact;
- nco:hasEmailAddress <mailto:dirk@example.com>.
-<mailto:dirk@example.com> a nmo:EmailAddress;
- nco:emailAddress "dirk@example.com".
-
-# Dirk #3, as address book contact
-<file://home/claudia/dirk.vcf#dirk> a nco:PersonContact;
- nco:nameFamily "Hagemann";
- nco:nameGiven "Dirk";
- nco:hasEmailAddress <mailto:dirk@example.com>;
- nco:photo <http://www.example.com/people/dirk/photo.jpg>.
-
-\end{verbatim}
-}
-
-In this example, we see that the Person Dirk appears three times in this knowledge workspace. First, in the form of an instance of \texttt{pimo:Person}, as the canonical Dirk. Second, as sender of an e-mail and third as entry in an address book. Only one instance is the \texttt{pimo:Thing} representation of Dirk: \texttt{claudia:DirkHagemann}. The others are information elements representing the same entity.
-
-\begin{figure}[htb]
- \centering
- \includegraphics[width=1.00\textwidth]{images/identification}
- \caption{Different Identification Mechanisms}
- \label{fig:identification}
-\end{figure}
-
-
-%\note{\emph{Knud}: can one ``use'' an assumption? Leo: rephrased to ``is based on''}
-To work effectively, PIMO is based on the \emph{Unique Name Assumption} (UNA).
-The UNA is a rule that declares two RDF resources with different URIs as different individuals.
-This is common in desktop applications (for example files with different names are different) and intuitive to grasp for users. But it is different from the OWL ontology language
-%\note{\emph{Knud}: is OWL a system? Leo: its an ontology language}
-where duplicate entries are common and the UNA is not enforced.
-PIMO is designed for personal systems, where an application has access to the complete model and can avoid duplicates before creating them.
-
-To enforce the UNA, duplicate Things \textbf{must} be avoided.
-The crucial moment to do this is before creating a new Thing.
-Things can either be created by the user manually or automatically by analysing existing native resources. In any case, before creating a new Thing, all existing Things have to be examined if a Thing with a same name or same identifying properties already exists.
-If an existing Thing is found, it \textbf{must} be reused.
-Immediately after creating a new Thing, identifying properties should be set to distinguish the Thing and avoid duplication.
-% fix to https://dev.nepomuk.semanticdesktop.org/ticket/498
-Section \ref{sec:creatingthingalgorithm} further describes the complete process of creating things.
-
-In the next paragraphs, essential identifying properties are described, an overview is given in Figure~\ref{fig:identification}.
-
-\textbf{The primary identifier of a Thing is it's URI}. New URIs for Things \textbf{must} be generated using the namespace of the user as prefix and then a unique local name.
-Although the local name can be entirely a random string, we recommend to include the label in the URI for readability. When minting a new URI that clashes with an existing URI, a random element can be added to the new URI. A URI for Claudia Stern is:
-\begin{verbatim}
-claudia:Claudia
-\end{verbatim}
-
-\paragraph{NAO-Identifiers} Existing identification schemes based on NAO should be reused for this purpose by representing them with
-%\note{Knud: you say pimo:identifier here and nao:identifier in the example below. Which one is it?\emph{Leo}: its nao:identifier (28.8.2007).}
-\texttt{nao:identifier} and its sub-properties.
-If an identifier is found as meta-data of a native resource (usually an \texttt{nie:InformationElement}), the identifier \textbf{must} be copied to the Thing.
-This allows others to match and identify the correct Thing when encountering the next information element.
-Example identifiers are \texttt{nmo:messageId} for e-mails, \texttt{ncal:uid} for appointments, or \texttt{nexif:imageUniqueID} for images.
-Instead of using the plain \texttt{nao:identifier} property, these specific properties should be used or new sub-properties of \texttt{nao:identifier} created
-\footnote{I.e. if you want to represent ISBN numbers and there is no property for them, create a new sub-property \texttt{isbn} of \texttt{nao:identifier}.}.
-In this document, we assume that e-mail addresses can be used to identify persons.
-
-\note{\emph{Leo}: this example is not good, as e-mail addresses are modeled
-differently in NCO. How else can we identify a person? \emph{Knud, 28/12:} I think we can't... :P}
-\begin{verbatim}
-# Copy all identifiers you can find about the Thing.
-claudia:DirkHagemann a pimo:Person;
- nao:identifier "dirk@example.com".
-\end{verbatim}
-
-Identifiers consisting of multiple RDF statements cannot be captured using \texttt{nao:identifier}.
-They are comparable to a primary key in a relational database consisting of multiple
-columns. These \textbf{multi-key identifiers} \textbf{must} be merged into one \texttt{nao:identifier}.
-
-\paragraph{Grounding Occurrence} The relation \texttt{pimo:groundingOccurrence} is used to link a Thing to an \texttt{nie:InformationElement} that has this Thing as primary topic. For example, the grounding for a person could be the entry in the address book describing the person. On the other hand, an e-mail with this person as the sender or recipient would normally not be a grounding occurrence. A Thing represents the mental concept, the \texttt{pimo:groundingOccurrence} links to existing Information Elements that are handled by existing applications. This is a key for reusing the features of these applications.
-The grounding occurrence can change, for instance if a file was moved and the URI of the Information Element changed, the grounding occurrence relation needs to be changed.
-A similar case happens when a file is uploaded to a shared workspace and not kept locally any more --- all annotations of the Thing stay the same (the URI of the Thing does not change), the Information Element changes.
-Multiple values are allowed, this reflects the fact that the same Thing can be represented in multiple applications, and dependent on the work context, the user may want to open a different application.
-{\small
-\begin{verbatim}
-# Link to Dirk #3 from example above.
-claudia:DirkHagemann a pimo:Person;
- pimo:groundingOccurrence <file://home/claudia/dirk.vcf#dirk>.
-\end{verbatim}
-}
-\paragraph{Occurrence} The relation \texttt{pimo:occurrence} connects a \texttt{pimo:Thing} with a resource representing the same real world entity.
-Facts about the occurrence are then also valid for the connected Thing.
-For example, if the person Dirk appears as sender of an e-mail, then the resource identifying the sender is an \emph{occurrence} of Dirk.
-Based on the occurrence relation, Dirk (the unique \texttt{pimo:Person}) is the sender of the given e-mail.
-Occurrence relations are to be used on resources \emph{representing} the same entity in a different context, but not on resources \emph{mentioning} the entity. For example, it is not valid to say that an e-mail is an occurrence of a person, only the sender or recipient can be occurrences of a person.
-
-%Not the e-mail as such is the occurrence, but the sender within.
-\note{\emph{Knud, 28/12:} Why is the e-mail as such not the occurrence? This should be explained, or not mentioned at all.
-Leo: done, removed sentence, replaced with longer explanation.}
-Occurrences of a Thing can be found by searching for entities with the same identifying properties.
-
-{\small
-\begin{verbatim}
-# Link to Dirk #2 from example above,
-# he occurs as sender of an e-mail
-claudia:DirkHagemann a pimo:Person;
- pimo:occurrence <imap://claudia@example.com/INBOX/1#from>.
-\end{verbatim}
-}
-
-Besides identification, both the \texttt{pimo:groundingOccurrence} and the \texttt{pimo:occurrence} relation have
-implications on data integration and affect semantic meaning of a Thing.
-This will be described later in Section \ref{sec:pimoVSnie}.
-
-\paragraph{Referencing Occurrence}
-%\note{Maybe rename to indicatingOccurrence, closer to Topic Maps? Leo: I don't care, leave it as is.}
-\label{par:referencingOccurrence}
-A Referencing Occurrence is an indirect approach to identification.
-Annotating a Thing with an information element as \emph{referencing occurrence} states that the information element contains a description of the Thing.
-Its primary topic must be the Thing.
-The Thing is indirectly identified by the element, when two Things in different models share the same information element as referencing occurrence, they may be equal and could be matched.
-The following description is an adaption of XTM's subject indicators~\cite{XTM,Rath2003}.
-The referencing occurrence is a kind of proxy for the Thing. Examples of referencing occurrences are:
-
-{\small
-\begin{verbatim}
-claudia:DirkHagemann a pimo:Person;
- pimo:referencingOccurrence <http://www.example.com/people/DirkHagemann>.
-
-claudia:ExampleInc a pimo:Organization;
- pimo:referencingOccurrence <http://www.example.com/>;
- pimo:referencingOccurrence <http://en.wikipedia.org/wiki/Example.com>.
-\end{verbatim}
-}
-
-It should contain a human readable documentation describing the concept. The resource could be a document, ontology, video, audio, anything able to describe to a human what the concept is about. The resource is a reference to the concept of the Thing.
-A good example for a referencing occurrence is a wikipedia article.
-
-A referencing occurrence describes the concept with the purpose of being widely used by ontologies. Consequently, it is important that the document describes exactly what concept it is about and what not. Even if the author works as accurately as possible, different people will never interpret a referencing occurrence 100\% the same way. However, the concept of referencing occurrences is worth using it, because it allows a shallow match of heterogenous information models, and because there is finally no alternative to it.
-
-\textbf{It is recommended to use wikipedia URIs as objects of referencing occurrences.} In contrast, URIs minted by \emph{DBPedia}\footnote{DBPedia is a Semantic Web representation of wikipedia and provides URIs for concepts, whereas wikipedia provides URIs for documents describing concepts. An example DBPedia URI is: \url{http://dbpedia.org/page/Berlin}} \textbf{must} be related using the \texttt{pimo:hasOtherRepresentation} relation.
-
-\paragraph{Other Representation}
-\label{par:otherRepresentation}
-The \texttt{pimo:hasOtherRepresentation} relation is used to connect \texttt{pimo:Things} with other representations of the same Thing in other Semantic Web ontologies.
-This can be the case with shared ontologies, such as company white page systems or Semantic Social Networking websites.
-
-The knowledge modeled should be compatible with the ontologies used by the user. An example for such other representation is\footnote{Using the URI scheme of the ECS University in our example domain. \url{http://id.ecs.soton.ac.uk/docs/}}:
-\begin{verbatim}
-claudia:DirkHagemann a pimo:Person;
- pimo:hasOtherRepresentation <http://id.example.com/person/1650>.
-\end{verbatim}
-
-Another example would be the city of Belfast where Claudia wants to travel to,
-linked to the DBPedia entry about it:
-\begin{verbatim}
-claudia:Belfast a pimo:City, pimo:Tag;
- pimo:isDefinedBy claudia:PIMO;
- pimo:tagLabel "Belfast";
- pimo:hasOtherRepresentation <http://dbpedia.org/resource/Belfast>;
- geo:lat "54.5833333";
- geo:long "-5.9333333".
-\end{verbatim}
-The relation can be used both to identify Things by their other representations,
-and to fetch more data.
-In this example, the latitude and longitude are actually superfluous data,
-as they can be retrieved from the other representation
-in DBPedia.
-Assuming Dirk also represents Belfast in his PIMO, but independent from Claudia,
-but linking to the same DBPedia entry, algorithmically matching their different representations is straightforward.
-
-\paragraph{Other Conceptualization}
-To map user-generated classes to classes defined in other ontologies, the
-\texttt{pimo:hasOtherConceptualization} relation connects classes defined in a user's PIMO
-with classes defined in domain ontologies.
-Classes defined in domain ontologies should be sub-classes of PIMO-upper classes, see Section \ref{sec:integratingontologies}.
-
-Implementations can use the \texttt{pimo:hasOtherConceptualization} to allow the user and algorithms
-to map user--specific classes to classes defined in other ontologies,
-without implying that there is a sub-class relationship.
-
-\subsection{A Complete Example}
-A complete example for all different identification properties
-can now be built from the above annotations.
-
-For Claudia, her co-worker Dirk Hagemann is identified and linked to occurrences like this:
-
-{\small
-\begin{verbatim}
-# The canonical pimo:Person Dirk,
-# a pimo:Thing from Claudia's PIMO
-claudia:DirkHagemann a pimo:Person;
- pimo:isDefinedBy claudia:PIMO;
- nao:prefLabel 'Dirk Hagemann';
- nao:identifier "dirk@example.com";
- pimo:occurrence <imap://claudia@example.com/INBOX/1#from>;
- pimo:groundingOccurrence <file://home/claudia/dirk.vcf#dirk>;
- pimo:referencingOccurrence <http://www.example.com/people/DirkHagemann>;
- pimo:hasOtherRepresentation <http://id.example.com/person/1650>.
-
-
-# An e-mail in which Dirk #2 occurs
-<imap://claudia@example.com/INBOX/1> a nmo:Mail;
- nmo:from <imap://claudia@example.com/INBOX/1#from>.
-
-# Dirk #2, as email sender
-<imap://claudia@example.com/INBOX/1#from> a nco:Contact;
- nco:hasEmailAddress <mailto:dirk@example.com>.
-
-<mailto:dirk@example.com> a nmo:EmailAddress;
- nco:emailAddress "dirk@example.com".
-
-# Dirk #3, as address book contact
-<file://home/claudia/dirk.vcf#dirk> a nco:PersonContact;
- nco:nameFamily "Hagemann";
- nco:nameGiven "Dirk";
- nco:hasEmailAddress <mailto:dirk@example.com>;
- nco:photo <http://www.example.com/people/dirk/photo.jpg>.
-\end{verbatim}
-}
-
-This allows implementations to:
-\begin{itemize}
- \item identify the Thing when found occurring in documents,
- \item open a grounding occurrence to see the Thing within an existing desktop application (i.e. the address book entry for a person),
- \item match this Thing with other representations via the same referencing occurrence,
- \item use the other representation from the company's white pages to show additional data about the Thing.
-\end{itemize}
-
-The \texttt{pimo:occurrence} link is the generic basis, \texttt{pimo:groundingOccurrence} and \texttt{pimo:hasOtherRepresentation} are sub-properties of it. This data should be generated automatically and unsupervised.
-Adding identifying properties to a Thing helps to find more occurrences and therefore more information about it.
-
-\subsection{Labels and Names of Things}
-\label{sec:labelling}
-To label Things, we recommend the NEPOMUK Annotation Ontology (NAO) vocabulary
-and extended it.
-NAO defines properties for the \emph{preferred label}, \emph{multiple alternative labels}. PIMO defines \emph{tag labels} as unique names for unique Tags.
-
-\paragraph{\texttt{nao:prefLabel}} \textit{A preferred label for a Thing}.
-This property \textbf{must} be applied to every instance of \texttt{pimo:Thing} (or its sub-propery \texttt{pimo:tagLabel}).
-It can be used by applications to represent the Thing with a textual label and should be human-readable. There must only be one \texttt{prefLabel} per Thing (mincardinality and maxcardinality should be one)\footnote{These restrictions are not explicitly noted in the RDF description of the property, as NRL does not support property restrictions for classes.}.
-
-\paragraph{\texttt{pimo:tagLabel}} \textit{Defines a unique personal label for a Thing, which then is also a Tag.}
-The label \textbf{must} be unique within
-the scope of a user.
-If both are set, \texttt{pimo:tagLabel} and \texttt{nao:prefLabel} of a resource \textbf{must} have the same value.
-It is a sub-property of \texttt{nao:prefLabel} and of \texttt{nao:personalIdentifier}.
-
-\textbf{Tag labels are the \textbf{recommended} way to label and identify Things that are used for classification}.
-As they are unique and human-readable, they \textbf{may} be used for multiple application scenarios such as wikis, tagging, or matching terms found in free-text.
-Naming a Thing with a \texttt{pimo:tagLabel} gives the Thing a second type, \texttt{pimo:Tag}, which indicates that the Thing should now be considered part of the user's tagging system, see Section~\ref{sec:tagginginpimo}.
-\note{\emph{Knud, 28/12:} I don't understand: should the two properties be the same or not? Leo: recommended they should be the same.}
-
-\paragraph{\texttt{nao:altLabel}} \textit{An alternative label alongside the preferred label for a Thing.} These are alternative spellings, translations, nick-names.
-%\note{\emph{Knud, 28/12:} Spelling Mistakes? Leo: removed this, replaced with nick-names}
-Implementations can use these labels to find Things when the user enters a text in a search box or when analysing free text.
-If a Thing has occurrences, the labels of occurrences \textbf{should} be copied as alternative labels to the thing.
-
-In combination, these labelling techniques allow applications to clearly label Things in user interfaces but also to lookup for Things based on alternative names. For our example, these are:
-
-\begin{verbatim}
-claudia:DirkHagemann a pimo:Person;
-# preferred label when shown
- nao:prefLabel "Dirk Hagemann";
-# a nickname for Dirk
- nao:altLabel "hacki";
-# a common misspelling
- nao:altLabel "Dirck Hagemann";
-# the personal identifier and tag label,
-# Attention: this requires the class pimo:Tag
- pimo:tagLabel "Dirk Hagemann".
-\end{verbatim}
-
-Additionally, visual cues (icons, images, thumbnails) can be attached by using NAO symbol relations:
-\begin{itemize}
- \item \texttt{nao:hasSymbol}
- \item \texttt{nao:prefSymbol}
- \item \texttt{nao:altSymbol}
-\end{itemize}
-
-\subsection{Textual description of Things}
-\label{sec:freetextdescription}
-To describe Things with a free-text, the simple \texttt{nao:description} property should be used. This allows users to add a (possibly searchable) description of the Thing in a simple way. The description string value should contain no format markup but be a plain text.
-
-For more complex free-text descriptions of Things, the property \texttt{pimo:wikiText} is reserved.
-Formatting (font-weight, italics) and linking to other pages is supported
-in this property, implementers may use the \emph{Wiki Interchange Format}
-\footnote{\url{http://semanticweb.org/wiki/Wiki_Interchange_Format}}
-as syntax, or RDFa\cite{rdfaprimer}.
-
-\subsection{Rating and Ranking Things} % (fold)
-\label{sec:ratings}
-\textbf{Ratings of Things} can be expressed using \texttt{nao:numericRating}.
-For numericRating, the range of values \textbf{must} be within $[0..10]$ (inclusive)
-\footnote{Implementers may wonder why the range is not standardized as $[0..1.0]$. The recommended range is based on an implementation decision taken in KDE.}.
-A value of '0' is interpreted as not set, a rating of 1 a \emph{bad rating} and a rating of 10 a \emph{good rating}.
-Furthermore, resources can only be given at most one numeric rating, thus the maximum cardinality is 1.
-Applications \textbf{may} partition the values into discrete ratings (such as 2, 4, 6, 8, 10 to represent the semantics of ``5 star ratings'').
-
-The rating values may and should be used for \emph{ranking} of Things
-and filtering. A populated PIMO contains thousands of Things,
-user interfaces should use the \texttt{nao:numericRating} values
-to filter out low-ranked resources and highlight high-ranked
-resources.
-Implementations \emph{can} set the \texttt{nao:numericRating}
-values automatically to computed values.
-% Alternatively, implementations can set an automated rank and
-% compute the overall rank using auotmated rank + nao:numericRating
-
-
-% paragraph ratings (end)
-
-\subsection{Modelling Time}
-In PIMO, no special treatment of time is modeled.
-We are aware that representing points in time, durations, and other periods of time
-is an important aspect of ontologies.
-We recommend to use the XML Schema Datatypes
-to represent time.
-There, ISO 8601 is recommended. Timezones must be handled according to this standard,
-encoded inside the literal value\footnote{For a detailed representation of time events, refer to the NIE documentation, where timezones are discussed (\url{http://www.semanticdesktop.org/ontologies/2007/04/02/ncal/\#sec-tzd}).
-NIE represents time using the NcalDateTime class and its properties
-date, dateTime, ncalTimezone. Timezones are represented using a Timezone class,
-that is inspired by RFC 2445.}.
-
-Periods of time can be represented using sub-classes of the abstract class
-\texttt{pimo:ProcessConcept} which represents lasting processes such as events
-or projects. For durations that last a number of days or months, we recommend to use the standardized XML datatypes\footnote{The XS namespace is \texttt{http://www.w3.org/2001/XMLSchema}, but the two duration datatypes are defined in the XPath recommendation in 2007, see \url{http://www.w3.org/TR/xpath-functions/\#dt-dayTimeDuration}}:
-\begin{itemize}
- \item \texttt{xs:dayTimeDuration} for durations measured in days, hours, and minutes.
- \item \texttt{xs:yearMonthDuration} for durations measured in months and years
-\end{itemize}
-Implementers are free to use either the XSD types or sub-classes of
-\texttt{pimo:ProcessConcept}.
-
-There have been issues with other notations of duration and therefore the W3C Semantic Web Best Practices and Deployment Group published a note\footnote{\url{http://www.w3.org/TR/swbp-xsch-datatypes/\#section-duration} Since XPath 2.0 has become a W3C recommendation in January 2007, this note is partly obsoleted.} to restrict durations to these values.
-
-\subsection{Representing Modification and Change Dates}
-\label{sec:changedates}
-The change and creation dates of Things are important metadata for personal information management applications. Knowing about recent changes is an important cue for users to retrieve documents. Many applications offer the feature to show recent changes or filter by them. Consequently, it has to be straightforward, simple, and fast to query for the modification dates.
-
-The NAO properties \texttt{nao:created}, \texttt{nao:modified}, and \texttt{nao:lastModified} \textbf{shall} be used to track the change dates of Things.
-Creation and modification allow only one, modification allows multiple date values.
-Created and lastModified values \textbf{must} be set for each Thing,
-at least one modified value \textbf{must} be set.
-These values are intended for resources of type \texttt{pimo:Thing}, \texttt{pimo:Association}, \texttt{rdfs:Class}, and \texttt{rdf:Property} when created by the user.
-\note{\emph{Knud, 28/12:} Why is this not enforced?
-\emph{Leo, 8/1:} mandatory is better anyway, CHANGED}
-
-Example:
-\begin{verbatim}
-# Represent modification dates of a Thing
-claudia:DirkHagemann
- nao:created "2007-10-26T15:23:01";
- nao:modified "2007-10-26T15:23:01";
- nao:modified "2007-10-29T08:04:30";
- nao:lastModified "2007-10-29T08:04:30".
-\end{verbatim}
-
-The \textbf{semantics} of these dates is that the description of the Thing has changed, facts about the Thing have been added, removed, or modified. Changes to \texttt{pimo:objectProperty} (\texttt{pimo:related}, \texttt{pimo:hasTag}, etc.) or \texttt{pimo:datatypeProperty} (\texttt{name}, \texttt{address}, \texttt{label}, etc.) imply such a modification.
-Included are also changes to the labels (\texttt{nao:prefLabel}, \texttt{nao:altLabel}, \texttt{pimo:tagLabel}).
-Modification of any other statement (such as \texttt{pimo:definedBy}, \texttt{nao:modified}) do not imply a modification nor a change of dates.
-As current RDF stores a priori do not support automatic tracking of changes, applications have to implement housekeeping of these dates, or use services for tracking.
-\footnote{The value of lastModified is redundant as it could be computed by sorting the modified dates during query time, but this is not possible without nested SPARQL queries, a $max()$ function, and grouping, none of these part of the SPARQL standard. The stores that support such non-standard operations still need time to compute the value. As the last modification date is very important for applications to assist users finding information, the redundancy is intended.}
-
-\note{\emph{Knud, 28/12:} I removed a paragraph here (still commented in the source), because I think it doesn't belong here. This document is a specification, not a scientific document. Leo: OK}
-%In RDF and using named graphs, there are more ways of representing change dates. It is possible to remember the date when a graph changes, implying that all triples inside the graph have changed. Based on this, it can be implied that all resources described in these triples have changed. But there is no formal relation between a resource and a graph that describes it. For example a class being used as object of a rdf:type relation, does this express that the class has changed? Or a resource being annotated in a reification statement. Changes to the graph may not directly relate to changes of the resource in the view of the user.
-%Also, as dates are a very prominent fact needed for data visualization and search result ranking, a graph-based approach will not provide satisfactory answer times
-%\footnote{To select a date using graph metadata, a query for the context of all statements where a resource is either in subject or object role and the change date of these contexts would be needed.}.
-
-\subsection{Setting the Class of a Thing}
-\label{sec:classofthing}
-All Things are of type \texttt{pimo:Thing} or one of its sub-classes. The PIMO ontology itself defines several sub-classes such as \texttt{pimo:Person} or \texttt{pimo:Organization}. If these are not specific enough, the user can either create new sub-classes manually (see Section \ref{sec:customontology}), or import group-level ontologies (Section~\ref{sec:integratingontologies}).
-
-As a rule of thumb, the question to be answered by assigning the class is ``\emph{What is this Thing?}''.
-In comparison to OWL, where classes are commonly based on the properties of the object (``vegetarians are entities not eating flesh'') , classes represent the type (the \emph{nature}) alone.
-\note{\emph{Knud, 28/12:} idea: paragraphs such as this should be marked as ``suggestion for use''. Again, they don't really belong in a specification.
-\emph{Leo, 8/1:} This paragraph is explanatory of the idea of classes in comparison to OWL, where most things are modeled as ``does this thing belong to a class or not'' Its important to have it. Cutted it, reworded it to refer to OWL. DONE?}
-%For the concrete example of ``importance'', we recommend using the property \texttt{nao:numericRating} or by using part-of relations like ``this Thing is part of the collection of important things''.
-%To model collections of things that share a common property (such as ``important Things''), the class \texttt{pimo:Collection} is provided.
-
-It is also recommended to only use one explicit class for a Thing. The wish to add multiple classes is often an indication that some classes can be better modeled using relations.
-For example, it is recommended to use a datatype property \emph{``is this person a vegetarian? yes or no''} and explicitly set it instead of assigning a sub-class of Person called \emph{Vegetarian}.
-If Things with two classes are needed (for example, if something is both a ``Car'' and a ``Locatable'') then the preferred way is to change the class model (make Car a subclass of Locatable or create a new class ``LocatableCar'' with both as superclass) than to add both types to one Thing. Nevertheless, it is not forbidden to add two types.
-%Superclasses are inferred implicitly, and are not affected by this recommendation.
-
-When a Thing has occurrences that are expressed in the NEPOMUK Information Element ontology (NIE), suitable mappings from NIE classes to PIMO classes are available in a mapping file
-\footnote{\url{http://www.semanticdesktop.org/ontologies/2007/11/01/nietopimomapping.rdf}}.
-
-\subsection{The PIMO-upper ontology}
-\label{sec:pimoupper}
-PIMO contains an \emph{upper ontology} for basic concepts in Personal Information Management (PIM):
-Person, Location, Event, Organization, Topic, Document, Time. They are modeled
-to answer basic questions about a Thing:
-\begin{itemize}
- \item Who is associated? Person
- \item Where is this? Location
- \item When is it? Time
- \item What is it about? Topic
-\end{itemize}
-% addressing the ``foundational'' part of figure 1
-The classes are the \emph{foundational part} of PIMO in the \emph{Upper-Level Layer} of the overall NEPOMUK ontologies as shown in~\ref{fig:roadmap}.
-This level serves as integration point for PIM applications,
-in the broader perspective of the Semantic Desktop, the classes can serve as upper classes for group-- and domain--level ontologies (see Sect.~\ref{sec:integratingontologies}).
-
-\subsection{Classes in PIMO-Upper}
-\label{sec:pimoUpperClasses}
-The classes have been defined based on related ontologies, a user study, and several software prototypes that have been evaluated. Figure~\ref{fig:upperclasses} gives a rough overview of the available classes.
-
-\begin{figure}
- \centering
- \includegraphics{images/upperclasses.png}
- \caption{Classes in PIMO-Upper}
- \label{fig:upperclasses}
-\end{figure}
-
-\begin{description}
-%
-% NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-% These are copied from the ontology, and if not, the
-% descriptions have to be the same in the ontology and here.
-%
- \item[Thing] The root class of the upper ontology. Every entity that can be in the direct attention of the user is a Thing.
- \item[Collection] A collection of Things, independent of their class. The items in the collection share a common property. Several usability studies showed that collections are important for PIM. It is recommended to either use the \texttt{pimo:hasPart} or the \texttt{pimo:isTagFor} relation to connect a collection with the Thing it contains\footnote{A Risk Of Change: A clear recommendation to either property may follow in future versions}.
- \item[Group] A group of Persons. They are connected to each other by sharing a common attribute, for example they all belong to the same organization or have a common interest.
- \item [Location] A physical location. Sub-classes are modeled for the most common locations humans work in: Building, City, Country, Room, State. This selection is intended to be applicable cross-cultural and cross-domain. City is a prototype that can be further refined for villages, etc.
- \item [LogicalMediaType] MediaConcepts are logical media types (e.g., a book, a contract, a promotional video, a todo list). The user can create new logical media types dependent on their domain: a salesman will need MarketingFlyer, Offer, Invoice while a student might create Report, Thesis and Homework.
- \item [Organization] An administrative and functional structure (such as a business or a political party).
- \item [Person] Represents a person. Either living, dead, real or imaginary. In this regards, similar to \texttt{foaf:Person}.
- %\item [PhysicalObject] An object of interest in the physical world. \note{\emph{Knud}: if there is a physical object, how about an abstract object? Love? Language?
-%\emph{Leo}: correct. I see a problem with Organozations and Topics, they have
-%an overlap with AbstractObject. This can lead to a longer discussion...
-% we should consult sumo. I added this as an open issue at the end.\ref{issue:abstractobject}}
-% It can be touched, it is concrete and it is of interest to the user. Examples are cars, tables, products and goods of business interest.
- \item[ProcessConcept] Concepts that relate to a series of actions or operations conducing to an end. Sub-classes are defined for Event, SocialEvent, Meeting, Project, and Task.
- \item[Topic] A topic is the subject of a discussion or document. Topics are distinguished from Things in their taxonomic nature, examples are scientific areas.
- \item[Tag] Tag is an abstract marker class to specify which Things in the user's PIMO should be considered useful tags in a tagging system. All Topics are Tags (Topic is a subclass of Tag). Implementations should support the user by using a useful set of Things as Tags, see Section~\ref{sec:tagginginpimo}.
-\end{description}
-
-These classes are intentionally kept generic. More specialized ontologies should be used for certain domains of application, see Section~\ref{sec:integratingontologies}. The classes of these ontologies are then sub-classes of upper ontology classes.
-
-\subsection{Describing Things with Attributes and Relations}
-\label{sec:describingthings}
-Conventional RDF statements are used to describe Things. Predicates have to be defined as \texttt{rdfs:Properties} according to the NRL standard. Alternatively, it is also possible to use properties from other modeling languages like OWL or RDFS although we do not encourage this without a proper mapping of existing ontologies to PIMO (see~\ref{sec:integratingontologies}).
-
-Properties that are intended to be editable and visible to end users \textbf{must} be sub-properties of either \texttt{pimo:datatypeProperty} or \texttt{pimo:objectProperty}.
-
-Many NIE and NAO properties can be used from PIMO Things, see Section~\ref{sec:usingnieinpimo}.
-
-\subsection{Generic Properties in PIMO-Upper}
-\label{sec:genericproperties}
-The PIMO-upper ontology contains basic relations between Things and a few core attributes for identifying them (described above in Sect.~\ref{sec:identification}).
-These sub-properties of \texttt{pimo:objectProperty} are:
-\begin{description}
- \item [\texttt{pimo:related}] is the most generic relation, giving no further indication how Things may be related. Related is defined to have itself as inverse property,
- it is indirectly a \texttt{nrl:SymmetricProperty}, but does not inherit this attribute to sub-properties. Sub-properties can be asymmetric, depending on the inverse-of relation they define.
- \item [\texttt{pimo:hasPart}] and \texttt{pimo:partOf} model partitive relations. They are inverse. Neither is transitive, because part-of relations used for modelling in the domain of Personal Information Management are vague due to the many contexts of interpretation (a hotel may be part of a trip plan, a trip plan part of a project, but this does not indicate the hotel to be part of the project).
- \item [\texttt{pimo:hasTag}] and \texttt{pimo:isTagFor} connect a Thing of interest with a Tag characterizing it. For example, a meeting can have a project as a tag, or a document has a meeting as a tag, when the goal of the meeting is to discuss the document. After the meeting, the meeting minutes are a new Thing having the meeting as a tag. This is not restricted to meetings but also an organization or a person can have a certain technology as a tag to express that they are working on the topic described by the tag. The relation is not transitive, not symmetric. It is not asymmetric because a thing A may have thing B as tag, and B also A, if both are tags. The range of the \texttt{pimo:hasTag} relation is restricted to the class \texttt{pimo:Tag}. Topic is a subclass of tag. See Section~\ref{sec:tagginginpimo}.
-\end{description}
-
-Implementers may use these generic properties directly, or create sub-properties of them
-or sub-properties of the more generic \texttt{pimo:objectProperty}.
-The main reason to have the generic properties is the semantic meaning of the relations,
-which can help to create user interfaces or model domains.
-Ontology authors can ask themselves ``does a new property model a part-of relation or not, does it assign a thing with a topic, or is it a generic relation?'' and then extend one of the generic properties.
-
-For these generic relations, specialized sub-properties are defined when used on specific classes in the PIMO upper ontology.
-
-\subsection{Refined properties in PIMO-Upper}
-\label{sec:pimoupperrelations}
-Additional to the above relations, semantically interesting relations between PIMO upper classes are modeled. Especially those which can be used as symmetric or transitive relations for inference.
-
-\begin{description}
- \item[\texttt{pimo:subTopic}] and \texttt{pimo:superTopic} relate Topics to each other. As Topics are an important mean to organize document collections based on a taxonomy, these two predicates are defined. They are inverse of each other and transitive.
- \item[\texttt{pimo:hasOrganizationMember}] and \texttt{pimo:isOrganizationMemberOf} are relations connecting a Person to an Organization.
- \item[\texttt{pimo:hasLocation}] and \texttt{pimo:isLocationOf} relate a locatable Thing with its Location. Locatable is an abstract sub-class of Thing.
- \item[\texttt{pimo:containsLocation}] and \texttt{pimo:locatedWithin} relate two locations within each other. Note that for geographic locations representing a physical space, inclusion is transitive.
-\end{description}
-
-\subsection{Tagging Things with Tags}
-\label{sec:tagginginpimo}
-% Say that PIMO is intended to work as an ontology, but also as a tagging system. When tagging e-mails or other elements, the name of the used tag must be unique. This is to be compatible with existing tagging systems, and to simplify the model. Intended use of TAG is to build a tag-cloud and organization system for the user's documents. Say that all topics are tags and are also arranged in a hierarchy (see next section). Recommend which classes make good tags: classes that exist for a longer time and can be used to classify many documents: topic, collection, group, city, person, organization, project. Say why it won't work without pimo:Tag. The classification system must be smaller than the document collection, to optimize retrieval.
-The generic properties described in the last Sections show how Things can be related to each other.
-An important aspect of PIMO is to classify Things using ``Tags''.
-Compared to normal PIMO Things, \emph{Tags} have one important additional restriction to make them compatible with Tags from other tagging system (folksonomies and Topic Maps):
-\begin{itemize}
- \item The label of a Tag is unique, within the scope of one Personal Information Model.
-\end{itemize}
-Using Tags, PIMO can be used similar to an existing tagging system.
-
-To extend a Thing to become a Tag, add the type \texttt{pimo:Tag}:
-\begin{verbatim}
-# The Person Dirk
-claudia:DirkHagemann
- a pimo:Person;
-# also a Tag
- a pimo:Tag;
-# Must define the required pimo:tagLabel
- pimo:tagLabel "Dirk Hagemann".
-\end{verbatim}
-The \texttt{pimo:tagLabel} is required for all instances of \texttt{pimo:Tag}, and as it is a subproperty of \texttt{nao:prefLabel}, it can replace an existing prefLabel.
-The \emph{intended use of Tags} is to build a clear category system for the user's documents.
-Once a Thing is \emph{tagged}, it can be retrieved by finding first the Tag, and then Things associated with the Tag.
-A user's Tags are good candidates as first entry points to explore a data space, they can be visualized in a tag cloud or an alphabetical list. Tags can be clustered by type (each has an additional PIMO type), and by hierarchy (Tags can be organized in a part-of hierarchy, Topics are organized in a subTopic hierarchy).
-
-To be useful as classification system, there should be a limited number of Tags to classify the potentially larger amount of documents.
-Examples are Things which exist for a longer period of time and Things that are of much importance to the user.
-Implementations \textbf{should} provide means to use the following as Tags.
-\begin{itemize}
- \item All \textbf{Topics} can be considered Tags. This is expressed by the fact that Topic is a subclass of Tag.
- \item \textbf{Collections} work well as Tags, the act of putting something into a collection can be considered an act of tagging.
- \item A \textbf{person}.
- \item A \textbf{group of persons}.
- \item A \textbf{city}, as there is a limited number of cities a person interacts with.
- \item \textbf{Projects} are defined as an ``enterprise carefully planned'', the planning and execution of a project may involve tagging many Things as belonging to the project.
- \item A \textbf{task}, as documents may be needed to fulfill the task.
- \item An \textbf{organization} to classify to which organization a person belongs or by which organization a document was published.
-\end{itemize}
-The process of using an existing Thing as Tag \textbf{may} be automated. For example, a user searching for a possible Tag for a document should be able to pick from a list of existing Tags, and additionally search for Things of the above type to convert them to a Tag (such as a ``more Tags'' button).
-The conversion from Thing to Tag \textbf{may} then be automated and not visible to the user.
-
-Tagging a document is illustrated in the following example, for more details refer to Section~\ref{sec:taggingfiles}.
-\begin{verbatim}
-claudia:BelfastMeetingPackage a claudia:MeetingPackage, pimo:Tag;
- pimo:tagLabel "Belfast Meeting Package".
-
-claudia:BelfastBusTimetable a pimo:Document;
- pimo:groundingOccurrence <file://home/claudia/doc/tripplan.pdf>;
- pimo:hasTag claudia:BelfastMeetingPackage.
-\end{verbatim}
-
-In general, it should be avoided to use \texttt{pimo:Document} instances as Tags.
-Typically the amount of documents is high, making them less useful as categorization scheme compared to the above mentioned Thing classes.
-The reason to introduce Tags in PIMO is to allow implementers to separate between categorization scheme and annotated instance base (which is usually a document corpus).
-Without a class to mark Tags, it would not be possible to restrict the \texttt{pimo:tagLabel} predicate to a minimum cardinality of one, and also Topics could not automatically be defined as Tags.
-
-\subsection{Topic Hierarchies}
-\label{sec:topichierarchies}
-% say that PIMO is a taxonomy system comparable to SKOS. The hierarchical ordering of Topics is important to organize the system. Hierarchies are also used to allow semantic search on subtopic structures. add rules.
-The methodologies so far allow the description of individual Things with labels, properties, classes, and Tags.
-Besides the view on individuals, their place inside an overall organization scheme of the user can be important --- where is a Thing located in a hierarchy?
-Things can be placed in a hierarchy using the \texttt{pimo:hasPart} relation.
-In an overall hierarchy, the part relation can be confusing, as Things both have a class and can be part of something. For example, \emph{workpackage 2} is \emph{part of } the \emph{CID project}. In a combined hierarchy including class and part-of relations, it would appear at two positions: as instance of workpackage and as part of CID.
-
-To simplify the system for novice users, it is \textbf{recommended} for implementers to support a \emph{Topic Hierarchy}, where hierarchical part-of structures are shown to end-users. The semantic ``is-a'' relations \textbf{should} be hidden in the Topic hierarchy.
-This allows users to model parts of their PIMO as taxonomy.
-\begin{itemize}
- \item Each instance of \texttt{pimo:Topic} \textbf{must} either have a \texttt{pimo:hasSuperTopic} relation to another Topic or be defined as root Topic using \texttt{pimo:hasRootTopic}.
- \item All Topics \textbf{must} be connected (indirectly or directly) to a root Topic, or be a root Topic themselves.
- \item User interfaces \textbf{should} render Topics using the hierarchical structure.
- \item Cycles in the super-topic structure are allowed but \textbf{should} be avoided.
- \item A Topic can have multiple super Topics, PIMO allows poly-hierarchical structures.
- \item The \texttt{pimo:subTopic} and \texttt{pimo:superTopic} relations are defined \emph{transitive}.
- \item When displaying Topics in hierarchical user interfaces, the transitivity of \texttt{pimo:subTopic} \textbf{should} not be inferred. The user experience should be the same when modelling and when browsing the hierarchy.
- \item When searching for Things using the \texttt{pimo:hasTag} relation, the transitivity of \texttt{pimo:subTopic} \textbf{should} be inferred, see below.
-\end{itemize}
-
-To support \emph{semantic search} in Topic hierarchies, the following rule for tagging does apply when searching for Things using the hasTag relation (for a detailled description, see Section~\ref{sec:pimorules}):
-\begin{verbatim}
-CONSTRUCT
-{?x pimo:hasTag ?B.}
-WHERE
-{?x pimo:hasTag ?A.
-?A pimo:superTopic ?B.}
-\end{verbatim}
-
-The hierarchical structure of Topics in PIMO is comparable to the modeling in SKOS\cite{SkosStandard}. The \texttt{pimo:subTopic} relation is equivalent to \texttt{skos:narrowerTransitive}.
-PIMO requires all Topics to be connected to root Topics, SKOS does not require this in the semantics of \texttt{skos:hasTopConcept}.
-
-\subsection{Creating Personalized Classes and Properties}
-\label{sec:customontology}
-The predefined classes and properties are intended as a generic basis to be extended.
-The user can always create new classes and property types, or existing ontologies can be imported (see Section~\ref{sec:pimomid}).
-A number of requirements apply:
-\begin{itemize}
- \item The superclass has to be \texttt{pimo:Thing} or a sub-class.
-% \item The property pimo:isDefinedBy has to be set to express that the user created the % class.
- \item The class has to be labelled with \texttt{nao:prefLabel}.
- \item The class has to be related to the user's PIMO with \texttt{pimo:isDefinedBy}.
-\end{itemize}
-
-Similarly for custom properties:
-\begin{itemize}
- \item The property has to be labelled with \texttt{nao:prefLabel}.
- \item The property has to be related to the user's PIMO with \texttt{pimo:isDefinedBy}.
-\end{itemize}
-For properties that relate two things, the following applies:
-\begin{itemize}
- \item The property \textbf{must} be a sub-property of \texttt{pimo:objectProperty} (either directly or indirectly via inference).
- \item The super-property \textbf{should} be one of \texttt{pimo:related}, \texttt{pimo:hasTag}, \texttt{pimo:isTagFor}, \texttt{pimo:hasPart}, or \texttt{pimo:partOf}.
- \item An inverse property \textbf{must} be defined. Inverse properties define the semantic meaning in both ways, which is required for
-user interfaces showing relations.
-\end{itemize}
-For custom properties that have \emph{a literal or datatype as range} the following applies:
-\begin{itemize}
- \item They must be a sub-property of \texttt{pimo:datatypeProperty}.
- \item Inverse properties should not be defined (as Literals cannot be subject of statements, inverse does not apply anyway).
-\end{itemize}
-
-For all custom-created properties and classes,
-modification dates \textbf{must} be set.
-
-\subsection{Collections of Things}
-\label{sec:collections}
-In Personal Information Management, grouping multiple Things into one collection is a crucial feature. Today's hierarchical file systems are a good example: a folder can be created to contain multiple elements. Later, actions on this folder, such as compressing it, or deleting it are supported.
-The generic \emph{has Part} relation provides the semantics of putting a Thing into another Thing. For usability reasons, we also provide a class \texttt{pimo:Collection} to be used for generic collections of multiple items.
-
-Applications that want to present the complex possibilities of PIMO in a simpler way can offer collections.
-First, an instance of the class \texttt{pimo:Collection} is created. Then, elements are added to the collection using the \texttt{pimo:hasPart} relation.
-A typical application of collections is the list of ``Favourites'' containing recently used and important resources.
-
-Collections are unordered, the ordering of items inside the collection can be done using alphabetical order, time, geographic location (if they are locatable), or type.
-
-Tags are another simplification, described below in Section~\ref{sec:taggingfiles}.
-
-%\begin{itemize}
-% \item collections are unordered
-% \item temporal order is expressed using implizit modeling (the time difference is implicit and has to be calculated for explizit knowing it for sorting)
-% \item in science, different sorting systems are described: geographical, alphabetically, by Time, by Categories, by Hierarchy. (Location, Alphabet, Time, Category, and Hierarchy, known as LATCH cite R. Wurman, D. Sume, and L. Leifer, Information Anxiety 2, Que, 2000.)
-% \item Latif and Tjoa, 2006 \cite{Latif+2006} have existing systems are build on LATCH, and additionally refine it saying that hierarchy is often taxonomic and that people are an important ordering factor, as also does Dengel2006.
-% \item That said, we see that ordering is dependent on the view in the application and on the attributes of the elements, there is a reason WHY the elements are ordered in a way based on their attributes. For PIMO, we do not provide an explicit sort order (before/after) relations, this can be added by implementers as extensions. The NEPOMUK Conceptual Elements model, developed by Max Völkel and Heiko Haller defines the standards for ordering. On the level of PIMO, ordering of items in a collection is implizit by the attributes of the items in the collection and handled by the user interface, by showing the elements in whatever order is appropriate.
-% \item The Collection class can be used to model collections of items that share a common attribute.
-% \item Members of collection are modeled using hasPart.
-%\end{itemize}
-
-\subsection{Modeling Associations and Roles in PIMO}
-\label{sec:roleBasedModeling}
-Often there is a need to add meta-data about a relation, for example the date of creation of a relation.
-In RDF, this is typically done using reification, and then adding meta-data about the
-reified Statement using an instance of the class \texttt{rdf:Statement}.
-A problem with reification is that when using the generic class \texttt{rdf:Statement}
-to represent it, there are no guidelines which properties are now suitable to annotate the statement.
-More precise sub-classes of Statement would solve this.
-Another problem is that \emph{n-ary} relations cannot be expressed with triple statements.
-
-In PIMO, \textbf{Associations} are used to add metadata about relations and to create
-n-ary relations. They are entities representing the relation of multiple Things with each other.
-Each Thing part of an Association is related to the association using the \texttt{pimo:associationMember} property or more precise sub-properties of it.
-
-As an example, the fact that Claudia attended a meeting can be expressed using the \texttt{pimo:Attendee} role.
-
-\begin{verbatim}
-claudia:AttendsInitialMeetinginBelfast a pimo:Attendee;
- pimo:attendingMeeting claudia:InitialMeetinginBelfast;
- pimo:roleHolder claudia:Claudia.
-\end{verbatim}
-
-Here, the class \texttt{pimo:Attendee} is a sub-class of \texttt{pimo:Association}
-and represents the association as such (``this is an association between a person and a meeting''). The two relations used are sub-properties of \texttt{pimo:associationMember} and identify the two Things to relate, the specific relations determine the role taken by each Thing.
-New sub-classes of association can be created when needed, also new sub-properties
-of \texttt{pimo:associationMember} for more specific roles.
-
-Associations are elements of a user's PIMO and \textbf{must} be connected to the user's PIMO with a \texttt{pimo:isDefinedBy} relation.
-Modification dates are to be handled the same way as with Things (see Section \ref{sec:changedates}).
-
-\section{Connecting PIMO to Information Elements}
-\label{sec:pimoVSnie}
-In the last section, the Things created within a user-PIMO were described.
-They are to be unique, described with defined ontologies,
-and ought to be identified well.
-The next step is to connect these to the files, e-mails, and other Information Elements
-which exist in the user's PSI.
-These are ambiguous, described in various ontologies, and in general more chaotic when compared to the user-PIMO.
-The crucial point is to use Things as organization scheme to classify and integrate
-existing data found in a PSI.
-
-The first step is to \textbf{connect Things to Information Elements} that represent them.
-As described above (Section \ref{sec:identification}), the \texttt{pimo:groundingOccurrence}
-and \texttt{pimo:occurrence} relations are to be used to connect them.
-This connection has the semantics of a unification --- both the Thing and the Information Element represent the same real-world entity.
-But the Thing is the unique, static representation that should be used to annotate the entity.
-Implementations \textbf{should not} allow the users to annotate Information Elements directly, instead it is \textbf{recommended} to connect the Information Element to a Thing using \texttt{pimo:groundingOccurrence} and then annotate the Thing.
-The rationale is that Information Elements can change their URI, be deleted or moved, and then the annotations may be disconnected from the described resource.
-
-Creating a Thing for each annotated document will result in vast amounts of instances in the sub-classes of \texttt{pimo:Document}, as users can likely have access to thousands (sometimes millions) of documents. To navigate effectively through such large structures, PIMO Topics can be used to annotate documents using the \texttt{pimo:hasTag} relation.
-
-How to annotate documents using PIMO is described in Section \ref{sec:taggingfiles}.
-
-\subsection{Connecting Things and Classes to Folders}
-\label{sec:containers}
-Things can also be connected to folders in the file-system to express that
-these folders contain information related to the thing.
-Use the \texttt{pimo:hasFolder} relation to connect a Thing or a Class with a folder.
-The semantic meaning of this relation is not formally restricted but open to be used in various ways.
-For folders connected to Things, it is \textbf{recommended}
-to interpret the content of the folder as ``having the Thing as topic''.
-Implementers \textbf{may} add a \texttt{pimo:hasTag} relation between the Things inside the folder and the Thing.
-
-For folders connected to Classes, it is \textbf{recommended}
-to interpret the content of the folder as ``being an instance of the Class''.
-Implementers \textbf{may} add a \texttt{rdf:type} relation between the Things inside the folder and the Class.
-
-In all cases, files or other information elements in folders have to
-be represented as Things first, before further annotation (see Section \ref{sec:creatingthingalgorithm}).
-
-The property \texttt{pimo:hasFolder} \emph{can} be used by implementers
-to suggest folders for information elements --- if an information element
-is annotated with a \texttt{pimo:hasTag} relation to a topic that is connected
-to a folder, this is an indication to move the element to the folder, if needed.
-
-\subsection{Integrating Facts about Things}
-\label{sec:integratingfacts}
-The unification of multiple Information Elements into one Thing is also
-on the level of facts, RDF statements.
-To answer the question ``when did I last communicate with people shown on this
-picture'' can only be answered when facts from multiple sources (e-mails, photos, photo annotations and the user-PIMO) can be queried as one model.
-The statements about the Information Elements connected to a Thing via \texttt{pimo:groundingOccurrence} and \texttt{pimo:occurrence} can be \textbf{superimposed} to the Thing.
-The exact rules are given in Section \ref{sec:creationrules} and directions
-how to use them are in Section \ref{sec:unification}.
-
-Through this process, a view on the data is generated.
-The user can get an overview of all existing data --- in an integrated way --- and then
-drill down into specific occurrences.
-In this view, it is possible that a Thing has multiple classes (as \texttt{rdf:type}),
-one from the level of PIMO ontologies and others from the integrated Information Elements.
-In the example given in Section \ref{sec:unification},
-Dirk Hagemann is inferred to be both a \texttt{pimo:Person}
-and a \texttt{pimo:PersonContact}.
-The two classes are not required to be sub-classes of each other.
-To get a coherent and meaningful view, the class of the InformationElement (or related resource) \textbf{may} be related to a PIMO class using the \emph{pimo:hasOtherConceptualization} relation, as described later in Section~\ref{sec:integratingontologies}.
-
-It is not required that the used ontologies are formally aligned and mapped.
-Rather, it is assumed that the user will be able to interpret the statements based on his knowledge about the data in his PSI.
-
-The details about the integration of facts are given in Section \ref{sec:unification} on \emph{unification}.
-
-\section{PIMO-group level: Group and Domain ontologies}
-\label{sec:pimomid}
-% In this section we introduce the idea of specializations of
-% PIMO upper that are shared amongst companies and groups.
-% COPIED FROM SauermannElstDengel2007
-The upper (foundational) level of \pimo just makes a few, basic
-ontological statements about Things which exist on a Semantic Desktop, \ie Things which
-are essential in a knowledge worker's mental model.
-In order to avoid a \emph{cold start problem}
-\footnote{The problem of cold starts is well known in knowledge-based systems: In the beginning a system, such as a shell, has little or no information and therefore doesn't seem to be useful to a new user.
-Consequently, they are not motivated to invest in using and feeding the system with new
-information, which again would be a prerequisite for it to be \emph{more} useful. Enter vicious cycle...}
-with PIMO-based
-applications, more ontologies defining concepts shared within groups
-or modeling domains are needed.
-The user's company and its organizational structure may be such a domain, or a shared public ontology.
-Classes are refinements of PIMO-Upper, allowing an integration
-of various domain ontologies via the upper layer.
-
-In the following section, recommendations are given how to model group and
-domain level ontologies.
-
-%\section{Mapping ontologies to PIMO-upper}
-\section{Extending PIMO}
-\label{sec:integratingontologies}
-%\note{Knud: I changed the title, because I think this chapter is not only about mapping ontologies, but more generally speaking about how to extend PIMO for one's needs. Leo: perfect.}
-%\note{Leo: this section should be either merged with the previous one, or the previous one removed. Both is fine, removing above is probably nicer.}
-Out of the box, PIMO is kept sufficiently simple and only contains relatively few classes and properties. This was done in order to ensure that the ontology is general enough to apply to almost any relevant domain.
-% removed. see https://dev.nepomuk.semanticdesktop.org/ticket/534
-%At the same time, PIMO contains enough basic elements to allow the user to start working straight away and prevent the cold start phenomenon.
-However, as soon as the set of pre-existing classes and properties becomes too narrow and confining, it is a very simple matter to extend PIMO and add domain-specific extensions, or map external ontologies onto PIMO. E.g., PIMO can easily be extended to express the organizational structure of the user's workplace, a biological classification system, or to include a PIMO-version of the BibTeX vocabulary.
-These \emph{domain ontologies} differ from \emph{personalized classes and properties} (see Section \ref{sec:customontology}) by the fact that they are not created by the user,
-but created by a third party for multiple users.
-\subsection{Refining Elements of PIMO-upper} % (fold)
-\label{sub:subclassing_pimo_upper}
-Creating group--level ontologies is a simple matter of \textbf{defining new sub-classes of PIMO-upper classes (see Sect.~\ref{sec:pimoUpperClasses}) or sub-classing \texttt{InformationElement} classes}.
-If needed, new properties can also be added, which apply to the new classes via domain or range.
-Importing created \emph{group--level ontologies} into a user's PIMO is described in the next Section (\ref{sec:importingontologies}).
-
-\paragraph{Classes} % (fold)
-\label{par:classes}
-
-%\note{Leo 13.12.: The individual values for Grades are a good example where instances must be added to domain ontologies. Could you add the grades such as teaching:GradeA, teaching:GradeB, teaching:GradeC, ... teaching: GradeF and give them preflables ``A''..''F'' ? This also looks good in N3. The argumentation is that teachers can then search for Students having grade ``A''.. etc ... and these are shared amongst teachers.}
-%\note{Knud, 05.01: Done! :)}
-%\note{Leo 13.12: in general, instances can be added to domain ontologies when they are shared amongst all users, for example a school may publish a domain ontology with instances for all teachers and personnel, and typical courses for each year to take the burden of modeling away from the teachers}
-% Leo: commented out above notes, they are DONE!
-As an example, you may work in the domain of teaching and training, and therefore want to extend PIMO with elements specific for this domain, such as \emph{courses}, \emph{lessons}, \emph{teachers} or \emph{students}. In this case, you would look for existing PIMO-upper classes which could be considered generalizations of your new classes. E.g., a course would be a sub-class of \texttt{pimo:ProcessConcept}, training lessons could be a sub-class of \texttt{pimo:Meeting}, teachers and students could be sub-classes of \texttt{pimo:Person} (or \texttt{pimo:Role} --- role-based modeling is discussed in Sect.~\ref{sec:roleBasedModeling}) and training material a sub-class of \texttt{pimo:Document}. Since all pre-existing PIMO-upper classes derive from \texttt{pimo:Thing}, all your new classes automatically do as well (except for roles: \texttt{pimo:Role} is not a sub-class of \texttt{pimo:Thing}).
-
-There could also be cases where no existing PIMO-upper class seems to apply to your new class --- in this case, the new class would directly derive from \texttt{pimo:Thing}. Consider, e.g., that you want to include the concept of \emph{grades} in your PIMO. There isn't really a good pre-existing superclass for grades in PIMO-upper, so your new \texttt{Grade} class would be a direct sub-class of \texttt{pimo:Thing}.
-
-Even if there might be a potential superclass, it may be wise to postpone this decision if one isn't completely sure, and instead just sub-class \texttt{pimo:Thing}. It is always easier to add a superclass relationship later, rather than make a bad decision now and then have to deal with incorrect data at a later stage.
-
-If needed, the new classes can also have sub-class relationships into other ontologies, such as other NIE-based ontologies or completely different ontologies such as WordNet\footnote{\url{http://wordnet.princeton.edu/}}, SUMO\footnote{\url{http://www.ontologyportal.org/}}, or Dolce\footnote{\url{http://www.loa-cnr.it/DOLCE.html}}.
-
-% paragraph classes (end)
-
-\paragraph{Instances} % (fold)
-\label{par:instances}
-
-In some cases, you will also want to add instances of classes to the ontology you are integrating with PIMO. This makes sense if those instances are shared and used among a many users. An example are actual grades that a teacher might gives their students, such as grades from A--F. Each such grade (\texttt{teaching:GradeA}, \texttt{teaching:GradeB}, etc.) is an instance of the class \texttt{Grade}, but since those instances will be used by all teachers and students, they can become part of the teaching ontology. Similarly, if a school decides to introduce the teaching ontology, they might include instances for all their teachers, students, classes, courses, etc.
-
-% paragraph instances (end)
-
-\paragraph{Properties} % (fold)
-\label{par:properties}
-
-New properties can then refer to the new classes via domain or range and thus further specify them. Examples are the relation between courses and teachers/instructors (e.g., \texttt{teachesCourse(Teacher, Course)}) or between course material and a course (e.g. \texttt{courseMaterialFor(CourseMaterial, Course)}). This example is illustrated graphically in Fig.~\ref{fig:extensionExampleTeaching}, as well in N3 source code in Fig.~\ref{fig:extensionExampleTeachingN3}. This approach is a \textbf{typical example of how to integrate domain ontologies for specific application areas into PIMO}.
-
-There are some general guidelines for introducing new properties:
-\begin{itemize}
- \item Properties which connect two \texttt{pimo:Thing}s (or sub-classes) should be defined as sub-properties of \texttt{pimo:related}, \texttt{pimo:hasTag}, \texttt{pimo:isTagFor}, \texttt{pimo:hasPart}, or \texttt{pimo:partOf} (see Sect.~\ref{sec:genericproperties}). By relating new, specialized properties to the more generic PIMO properties, the new ontology can integrate better with existing desktop environment. When not extending the generic properties, at least new properties should exted \texttt{pimo:objectProperty}.
- \item All new object-properties \textbf{must} define an inverse property, as required
- in Section~\ref{sec:customontology}.
- \item Identifying properties (such as a name) that have domain \texttt{pimo:Thing} and a literal range should be mapped as sub-properties of \texttt{nao:identifier}. An example is give in Fig.~\ref{fig:bibtexExample}.
- \item
-% Leo 8/1: removed the note, the fix seems to be accepted by Knud.
-%\note{\emph{Knud}: I don't understand this at all. Leo: I splitted it up to two items and explained the concept of referencing occurrences a little.}
- Some new properties may be defined as sub-properties of \texttt{pimo:referencingOccurrence} (see Sect.~\ref{par:referencingOccurrence}). This is true for all object properties (i.e., properties which have a resource range and not a literal range) which describe or identify the subject in an unambiguous way. In other words, the object resource exclusively describes the subject. A typical example is \texttt{foaf:homepage}: two different people would most likely not have the same homepage (ignoring exceptions such as family homepages). If, however, we come across two different RDF resources which have the same \texttt{foaf:homepage}, we can assume that they describe the same real-life person.
- \item A frequent situation in Semantic Web and Semantic Desktop scenarios is that the same real-life object (i.e., a person, country, project, etc.) is defined as a resource in many different ontologies. The PIMO property \texttt{pimo:hasOtherRepresentation} is used in such cases. If your new ontology contains a property which expresses a similar (more specific) relation between resources, then it should be a sub-property of \texttt{pimo:hasOtherRepresentation} (see Sect.~\ref{par:otherRepresentation}). In the vanilla SW world, a similar property is \texttt{rdfs:seeAlso}.
-\end{itemize}
-
-% paragraph properties (end)
-
-\begin{figure}
- \begin{center}
- \includegraphics[width=\linewidth]{images/PIMOextensionExample-Teaching}
- \caption{Extending PIMO with new classes, properties and instances for the domain of teaching}
- \label{fig:extensionExampleTeaching}
- \end{center}
-\end{figure}
-
-\begin{figure}
- \begin{center}
- \begin{verbatim}
-# new classes:
- teaching:Grade a rdfs:Class;
- rdfs:subClassOf pimo:Thing.
-
- teaching:Student a rdfs:Class;
- rdfs:subClassOf pimo:Person.
-
- teaching:Teacher a rdfs:Class;
- rdfs:subClassOf pimo:Person.
-
- teaching:CourseMaterial a rdfs:Class;
- rdfs:subClassOf pimo:Document.
-
- teaching:Course a rdfs:Class;
- rdfs:subClassOf pimo:ProcessConcept.
-
- teaching:Lesson a rdfs:Class;
- rdfs:subClassOf pimo:Meeting.
-
-# new properties and their inverse:
- teaching:courseMaterialFor a rdf:Property;
- rdfs:subPropertyOf pimo:partOf;
- rdfs:domain teaching:CourseMaterial;
- rdfs:range teaching:Course;
- nrl:inverseProperty teaching:hasCourseMaterial.
- teaching:hasCourseMaterial;
- rdfs:subPropertyOf pimo:hasPart;
- rdfs:domain teaching:Course;
- rdfs:range teaching:CourseMaterial;
- nrl:inverseProperty teaching:courseMaterialFor.
-
- teaching:teachesCourse a rdf:Property;
- rdfs:subPropertyOf pimo:related;
- rdfs:domain teaching:Teacher;
- rdfs:range teaching:Course;
- nrl:inverseProperty teaching:taughtBy.
- teaching:taughtBy a rdf:Property;
- rdfs:subPropertyOf pimo:related;
- rdfs:domain teaching:Course;
- rdfs:range teaching:Teacher;
- nrl:inverseProperty teaching:teachesCourse.
-
- teaching:attendsCourse a rdf:Property;
- rdfs:subPropertyOf pimo:related;
- rdfs:domain teaching:Student;
- rdfs:range teaching:Course;
- nrl:inverseProperty teaching:attendeeStudent.
- teaching:attendeeStudent a rdf:Property;
- rdfs:subPropertyOf pimo:related;
- rdfs:domain teaching:Course;
- rdfs:range teaching:Student;
- nrl:inverseProperty teaching:attendsCourse.
-
-# new instances:
- teaching:GradeA a teaching:Grade;
- nao:prefLabel "A".
-
- teaching:GradeB a teaching:Grade;
- nao:prefLabel "B".
-
- ...
- \end{verbatim}
- \caption{Extending PIMO with new classes, properties and instances for the domain of teaching --- N3 code}
- \label{fig:extensionExampleTeachingN3}
-\end{center}
-\end{figure}
-
-\paragraph{Inheritance} % (fold)
-\label{par:inheritance}
-
-Sub-classing any class from PIMO (whether it be existing classes from PIMO-upper or classes that have been added later) also means that the new sub-class can be used with the same properties that have been defined with its superclass. Remember that NRL has a closed world assumption, and not an open world assumption, as RDFS traditionally has. In NRL\footnote{\url{http://www.semanticdesktop.org/ontologies/nrl/}}, ontologies can be used to validate statements.
-%\note{reference to NRL spec --- 05.01.08, done}
-E.g., if the property \texttt{name(pimo:Person, String)} has been defined, and if we define our new class \texttt{teaching:Student} to be a sub-class of \texttt{pimo:Person}, then this will allow us to use \texttt{name} with instances of \texttt{Student} as well - an NRL validator will permit this, because all instances of \texttt{Student} are also instances of \texttt{Person}. An example of this is shown in Fig.~\ref{fig:propertyInheritance}: this concept is very similar to the idea of inheritance in object-orientation, even though strictly speaking it is not the same.
-
-% paragraph inheritance (end)
-
-\begin{figure}
- \begin{center}
- \begin{verbatim}
-
- pimo:name a rdf:Property;
- rdfs:Domain pimo:Person;
- rdfs:Domain rdfs:Literal.
-
- teaching:Student a rdfs:Class;
- rdfs:subClassOf pimo:Person.
-
- knud a teaching:Student;
- pimo:name "Knud Möller".
-
- \end{verbatim}
- \caption{``Inheritance'' of properties}
- \label{fig:propertyInheritance}
-\end{center}
-\end{figure}
-
-% subsection subclassing_pimo_upper (end)
-
-\subsection{Markup for the new ontology}
-\label{sec:extendingontologymarkup}
-The teaching ontology still needs to be defined as proper NRL ontology
-to be usable with PIMO. The ontology \textbf{must} to be identified via its URI
-and the author of the ontology can be added
-as \texttt{nao:creator}.
-
-\begin{verbatim}
-teaching:TeachingOntology a nrl:Ontology;
- nao:creator teaching:TeachingOntologyCreator.
-
-teaching:TeachingOntologyCreator a nao:Party;
- rdfs:label "Knud Möller".
-
-\end{verbatim}
-
-\subsection{Information Elements} % (fold)
-\label{sub:information_elements}
-
-An important feature of the NEPOMUK ontology architecture is the fact that it is divided into two tiers: the PIMO tier and the Native Structures tier, as defined in the NEPOMUK Information Element Ontology (NIE)\footnote{\url{http://www.semanticdesktop.org/ontologies/nie/}} and its sub-ontologies, such as the NEPOMUK File Ontology (NFO)\footnote{\url{http://www.semanticdesktop.org/ontologies/nfo/}}.
-%\note{reference to NIE spec --- 05.01.08, done}
-While the former covers the internal mental model of a user or an organization (people, events, projects, etc.), the latter covers the physical representations of data (address book entries, calendar entries, files, etc.). Obviously, there are numerous connections between the tiers: people are represented by address book entries, events appear in the calendar, projects have files associated to them.
-
-Whenever classes that are introduced to PIMO have a physical representation on the user's desktop, a connection to NIE must be modeled as well. Consider the example of the teaching ontology above: Such an ontology will contain classes for Things like exams and essays. Those classes belong to the PIMO tier. Their representation within the computer --- e.g., as text files --- belongs to the native structures tier. Or, in a more complex case, the new ontology could very well come with a specialized application, such as a Training Course Manager, where users can assign attendees to trainings, etc. In this case, people and courses (PIMO tier) would be represented by the application as application-specific data structures or information elements (native structures tier). In both cases a link from the new PIMO classes to the information elements represented with NIE is required to fully exploit the possibilities of the semantic desktop.
-
-% subsection information_elements (end)
-
-%\note{Knud, 05.01.08: I decided to drop the Author class in the BibTeX example. Authors should really just be pimo:Persons, not a subclass thereof.
-%Leo, 8/1: OK, DONE}
-
-As a second example, we can consider an ontology for scientific publications. This ontology (which would probably be based on Bib\TeX), would come with classes such as \texttt{Article} or \texttt{Book} and relations between them like \texttt{bookContainsArticle} or \texttt{hasAuthor}. For the integration into PIMO, \texttt{Article} would most likely become a sub-class of \texttt{pimo:Document}.
-Documents have two types: one which anchors them in the PIMO tier, and one which anchors them in the native structures tier.
-The \texttt{pimo:LogicalMediaType} (and its sub-classes, e.g., \texttt{pimo:Document}) captures how a document is interpreted by the user and belongs to the PIMO tier. Logical media types can be contracts, invoices, assignments, invitations, law texts, etc.
-The other type, which is the \texttt{nfo:Document} type, captures how the system interprets the document, and belongs to the native structures tier.
-This is the physical document type as modeled by NIE.
-Instances of a logical media type can have various representations in the native structures tier:
-for example, a text interpreted as an invoice by the user can either be an \texttt{nfo:PlainTextDocument} or an \texttt{nfo:PaginatedTextDocument}.
-Vice-versa, one physical type can be used to represent both an invitation or an invoice, which are different logical media types.
-Keeping this this separation of content and representation in mind, one can model concrete documents having two types, one on each tier.
-
-\begin{figure}
- \begin{center}
-\begin{verbatim}
-bibtex:Article a rdfs:Class;
- # PIMO tier: interpreted by the user as nie:Document
- rdfs:subClassOf pimo:Document;
- # native structures tier: interpreted by the system as nfo:TextDocument
- rdfs:subClassOf nfo:TextDocument.
-
-bibtex:hasAuthor a rdf:Property;
- rdfs:subPropertyOf pimo:related;
- rdfs:subPropertyOf nfo:creator;
- rdfs:domain bibtex:Article;
- rdfs:range pimo:Person.
-
-bibtex:hasLCCN a rdf:Property;
- rdfs:subPropertyOf nao:identifier; \# add an identifier
- rdfs:domain bibtex:Article.
-\end{verbatim}
- \caption{A Bib\TeX-based PIMO extension for scientific publications}
- \label{fig:bibtexExample}
-\end{center}
-\end{figure}
-%bibtex:Author a rdfs:Class;
-% # this adds properties like Name
-% rdfs:subClassOf pimo:Person.
-
-\subsection{Extension by Sub-classing from External Classes} % (fold)
-\label{sub:extension_by_subclassing_from_external_classes}
-
-\textbf{Another possibility is extending existing PIMO-upper classes by sub-classing them from external classes.} \emph{This is discouraged}. For example, if the class \texttt{pimo:Person} was defined a sub-class of \texttt{nco:PersonContact} and \texttt{pimo:Organization} a sub-class of \texttt{nco:OrganizationContact}, all instances of these classes would automatically be inferred to be \texttt{pimo:Thing}s. However, those instances would probably not have some of the properties required by the \texttt{Thing} defined, which would render the imported data invalid.
-Similarly, when a mapped class X has cardinality restrictions on its properties (such as required properties), adding X as new superclass to an existing PIMO class can render the instances of the PIMO class invalid.
-
-% subsection extension_by_subclassing_from_external_classes (end)
-
-\subsection{Summary} % (fold)
-\label{sub:summary}
-
-The very condensed summary to extending PIMO and mapping frome existing ontologies to PIMO is the following:
-
-\begin{itemize}
- \item Make classes sub-classes of PIMO-upper classes.
- \item Make properties sub-properties of PIMO-upper properties.
- \item Relations: Links between Things have to be browseable, properties should have inverse relations defined (see \cite{rohmer2005})
- \item Extensibility: Users are free to add new relation types and new classes (see \cite{rohmer2005})
-\end{itemize}
-
-% subsection summary (end)
-
-\section{Importing Domain Ontologies into a User's PIMO}
-\label{sec:importingontologies}
-%\note{Written by Leo, but Knud: feel free to mash it up}
-Once modeled, the new domain ontology such as the teaching ontology in the previous examples can be made available publicly for others, for example by publishing it on the Web. A good reference for doing this is \emph{Best Practice Recipes for Publishing RDF Vocabularies}~\cite{SWBPVocabularyRecipes}.
-
-% adressing
-Semantically, an imported ontology is captured using a \texttt{nrl:imports} statement.
-When a user imports a domain ontology, this statement \textbf{should} be added.
-
-{\small
-\begin{verbatim}
-claudia:Pimo nrl:imports teaching:TeachingOntology.
-\end{verbatim}
-}
-
-%Importing the ontology to a Sematic Desktop or other Personal Information Management system can then be done by downloading the ontology file and storing it into the RDF store where the PIMO of the user is kept.
-% Stuff like downloading is outside the scope of PIMO and really has no place in the PIMO specification
-Once the user of a Semantic Desktop system imports an external PIMO into their own desktop, all new classes (which are sub-classes of \texttt{pimo:Thing}) \textbf{should} become available to them as if they had created those classes themselves.
-Instances, on the other hand, are not automatically available.
-As said in the introduction, the scope of a PIMO for an individual user is to model data that is within their own attention and needed for knowledge work or private use.
-However, when importing external ontologies or knowledge bases, not all instances may be of interest to the user. As with imported information elements, a separate Thing is created to represent the imported resource within the PIMO of the user and connected to the imported instance using \texttt{pimo:hasOtherRepresentation}\footnote{An alternative would be to treat all Things present in the RDF data available of the user as if they were created by the user, imported or not. This has the drawback that it allows to represent the same real-world entity twice, first in the imported domain ontology and second in the user's own PIMO.}.
-Before creating a new Thing for an imported instance, the PIMO of the user has to be checked if the entity is already represented as a Thing, as indicated above in Section~\ref{sec:creatingthingalgorithm}.
-Once represented as a Thing in the user's PIMO, it is possible to assign a personal identifier to it, annotate it, and use it.
-
-Implementations \textbf{must} automate the importing process. The user should be able to interact with imported Things as if they were created by themselves.
-
-\begin{comment}
-LEO: THIS COMMENTED OUT NOW, ITS TOO SCIENTIFIC.
-\section{Design Rationale}
-\label{sec:designrationale}
-In this section the design rationale behind \pimo and the sources which influenced us are described.
-% COPIED FROM SauermannElstDengel2007
-%The motivation for creating the PIMO is to find a language to name the terms
-%that are relevant to a knowledge worker and to have ways to express facts about
-%these terms. Once this language is defined and formalized in the ontological
-%description of the PIMO, it can be used to translate existing resources, and to
-%express information about them. The PIMO is a user-centric view on existing
-%documents, domain ontologies, and web data sources.
-%
-%While the organization asks for universally applicable and standardized
-%persistent structures, processes, and work organizations to achieve and
-%maintain universally accessible information archives, the individual knowledge
-%worker requests individualized structures and flexibility in processes and work
-%organization in order to reach optimal support for the individual activities.
-%
-The vision behind this work is that a \emph{Personal Information Model} reflects and captures a user's
-personal knowledge, \eg about people and their roles, about organizations, processes,
-things, and so forth, by \emph{providing the vocabulary} (concepts and their relationships)
-required for expressing it as well as concrete instances. In other words, the domain of a
-\pimo is meant to be ``all Things and native resources that are in the attention of the
-user when doing knowledge work''.
-\note{Knud, 07.01.08: Probably quickly explain what native structures are?}
-Though ``native'' information models and structures are
-widely used, there is still much potential
-for a more effective and efficient exploitation of the underlying knowledge. We think that,
-compared to the cognitive representations humans build, there are mainly two shortcomings
-in native structures:
-\begin{itemize}
- \item \emph{Richness of models}: Current state of cognitive psychology
- assumes that humans build very rich models, encoding not
- only detailed factual aspects, but also episodic and situational
- information. Native structures are mostly taxonomy- or
- keyword-oriented.
- \item \emph{Coherence of models}: Though nowadays (business)
- life is very fragmented humans tend to interpret situations as a
- coherent whole and have representations of concepts that are comprehensive
- across contexts. Native structures, on the other hand, often
- reflect the fragmentation of multiple contexts. They tend to be
- redundant (i.e., the same concepts at multiple places in
- multiple native structures). Frequently, inconsistencies are the
- consequence.
-\end{itemize}
-
-The \pimo shall mitigate the shortcomings of native structures by providing a
-\emph{comprehensive model} on a \emph{sound formal basis}.
-
-% next snip
-%When building concrete \pimos, we now have the
-%problem of two, potentially conflicting demands: On the one hand, we want to give the user
-%the opportunity to span his information space largely in the way \emph{he} wants. The
-%\pimo should model \emph{his} mental models. In consequence, we cannot prescribe much of
-%this structure. On the other hand, ``empty'' systems often suffer from the cold
-%start problem, being not accepted by user when not already equipped with some initial content.
-%Using a multi-layer approach (see also \cite{Sauermann+2006d}), we try to find a balance through providing
-%the presentational basis as given, which users \emph{can} incorporate or extend:
-%by a layered approach to \pimos : The representational basis
-%as well as the basic dimensions of a \pimo are pre-given, but flexible enough for simple as
-%well as more advanced modeling. Lower levels are meant as a proposition; when establishing
-%an individual \pimo, users \emph{can} incorporate them into their model if they find them
-%adequate and useful, but they don't have to. In the following, we briefly sketch the
-%proposed \pimo layers:
-
-% NOTE: THIS IS BAD, PIMO-MID IS a FORBIDDEN WORD and therefore replaced with XXXXXXX
-%\subsection{PIMO-Basic, PIMO-Upper, PIMO-XXXXXXX and Domain Ontologies}
-%Apart from the native structures, the mental models are represented using a multi-layer
-%approach. These layers are:
-%\begin{itemize}
-% \item PIMO-Basic: defines the basic language constructs. The class
-% pimo-basic:Thing represents a super-class of other classes.
-% \item PIMO-Upper: A domain-independent ontology defining abstract sub-classes of
-% Thing. Such abstract classes are PersonConcept, OrganizationalConcept,
-% LocationConcept, Document, etc.
-% \item PIMO-XXXXXXX: More concrete sub-classes of upper-classes. The
-% mid-level ontology serves to integrate various domain ontologies and provides
-% classes for Person, Project, Company, etc.
-% \item Domain ontologies: A set of domain ontologies where each describes a
-% concrete domain of interest of the user. The user's company and its
-% organizational structure may be such a domain, or a shared public ontology.
-% Classes are refinements of PIMO-XXXXXXX and PIMO-Upper, allowing an integration
-% of various domain ontologies via the upper layers.
-% \item PIMO-User: the extensions of above models created by an individual for
-% personal use. Classes, properties and Things are created by the user.
-%\end{itemize}
-
-% END OF SauermannElstDengel2007
-\end{comment}
-
-
-\section{Practical Directions on Using PIMO}
-In this section, a few issues that will arise in actual PIMO usage are discussed. For each of these issues, we will suggest a recommended way of handling them. Even though those things are not strictly speaking part of the ontology, they are part of the standard defining how to use the PIMO ontology in applications.
-Implementers \textbf{should} conform to these directions.
-
-\subsection{Creating Things}
-\label{sec:creatingthingalgorithm}
-New PIMO Things can be created freely, but usually the creation of a Thing is rooted in the existence of an information element.
-An algorithm to create new Things based on information elements \textbf{should} follow these steps:
-
-\paragraph{Start} The software agent encounters a resource with URI $X$ and wants to verify if the user already has knowledge about \textbf{$X$}.
-\paragraph{Check GroundingOccurrence} Query the user-PIMO for:
-\begin{verbatim}
-SELECT ?thing WHERE {?thing pimo:groundingOccurrence ?X.}
-\end{verbatim}
-When a Thing is found, finished.
-\paragraph{Check occurrences} Repeat the last step to search if $X$ is an occurrence of a Thing.
-\paragraph{Check identifiers} Validate if the InformationElement has an identifier or a referencing occurrence that is also used on an existing Thing. The information element is called an \textbf{occurrence} of a Thing when it shares the same identifiers. The correct query is:
-\begin{verbatim}
-SELECT ?thing
-WHERE {
-?thing ?p ?o.
-?X ?p ?o.
-?p rdfs:subPropertyOf nao:identifier.
-} UNION {
-?thing ?p ?o.
-?X ?p ?o.
-?p rdfs:subPropertyOf pimo:referencingOccurrence.
-}
-\end{verbatim}
-When a Thing is found, finished.
-\paragraph{Create a new Thing}
-When the last step did not return an existing Thing, this can be an indicator that element $X$ is new to the user and should be modeled with a new Thing.
-Mint a new URI and add the identity values from the InformationElement.
-
-In the following SPARQL query example, we assume that Claudia's System has just encountered a new calendar event $X$ and represents it using the new minted URI $claudia:Event42$.
-{\small
-\begin{verbatim}
-CONSTRUCT {
-<claudia:Event42> rdf:type pimo:Thing.
-<claudia:Event42> ?i ?io.
-<claudia:Event42> nao:prefLabel ?title.
-<claudia:Event42> rdf:type ?type.
-<claudia:Event42> rdf:type ?pimotype.
-<claudia:Event42> pimo:groundingOccurrence ?X.
-<claudia:Event42> nao:created ``2007-06-30T18:11:00Z''.
-<claudia:Event42> pimo:isDefinedBy claudia:PIMO.
-} WHERE {
-OPTIONAL (?X ?i ?io. ?i rdfs:subPropertyOf nao:identifier.).
-OPTIONAL (?X nie:title ?title).
-OPTIONAL (?X rdf:type ?type).
-OPTIONAL (?X rdf:type ?type. ?pimotype rdfs:subClassOf ?type.
- ?pimotype rdfs:subClassOf pimo:Thing).
-}
-\end{verbatim}
-}
-The different parts of this query are:
-\begin{itemize}
- \item all identifiers are copied (?i, ?io)
- \item the title is copied for readability and to use it for tagging (?title)
- \item the original type(s) are copied (?type)
- \item find possible PIMO:Thing classes that can be used for this type (?pimotype)
- \item the groundingOccurrence relation is added
- \item the created timestamp is set to the current date
- \item the isDefinedBy relation is set
-\end{itemize}
-Finding a suitable class to represent the resource
-in the PIMO depends on a mapping of information element classes to PIMO classes
-and can be realized in different ways, see Section~\ref{sec:classofthing}.
-
-\subsection{Changing the Type of a Thing}
-\note{Knud, 06.01.08: Can we change "Thing" into "Instance" (also below)? To me, "thing" sounds much too ambiguous.
-\emph{Leo, 8/1:}I would stick to \texttt{Thing} as a word used before}
-Changing the type of an instance can lead to invalid statements in the knowledge base. E.g., this can happen when the instance in question is involved in statements using a property with a specific domain and range, and the new type is not compatible to those.
-As this would render the model invalid, this situation must be avoided in applications interacting with PIMO data.
-A user interface should remind the user of possible problems and should suggest solutions.
-
-\note{Knud, 06.01.08: Is it even possible that domain and range are not set in NRL? If not, maybe remove this paragraph.
-\emph{Leo, 8/1:} NRL does not require it} A different approach is ontology-by-examples where the main principles is that ``the user is always right'' and domain/range values are not explicitly set but implied by previous usage.
-User interfaces may support this behavior by setting the domain and range to \texttt{pimo:Thing} and suggest properties suitable for class by analysing previous usage of the property.
-
-\subsection{Deleting a Thing}
-We can say that, in RDF, instances do not exist independently, but only as part of statements. Thus, ``deleting an instance'' really means deleting all statements in which this instance is involved (as subject or object).
-%Note, that also \texttt{pimo:creationSupportedBy} links will be deleted by this, which may result that an algorithm soon creates the instance again (if the user somewhere configured to created instances automatically). See below in section Automatic Creation of Things from ResourceManifestations.
-%In this case, it may be better to use the \texttt{pimo:metaHidden} property to hide it.
-\note{Knud, 06.01.08: this needs to be explained, otherwise it's incomprehensible.
-\emph{Leo, 8/1:} actually, the groundingForDeletedThing is the needed Thing, I described it.}
-If the instance has a grounding occurrence relation, a new \texttt{pimo:groundingForDeletedThing} relation should be created to record the deletion.
-Data integration algorithms analysing resource to automatically create Things can then avoid re-creating the already deleted Thing.
-
-\subsection{Deleting User-generated Classes and Properties}
-Deleting a user-generated class is allowed but requires that instances are re-typed to the direct super-class of the deleted class. Also the domains and ranges of all properties defined with the class as domain or range need to be changed to the direct superclass.
-These changes are necessary to prevent the model from becoming invalid.
-Classes defined in the pimo language cannot be deleted, only classes defined by the user can be deleted.
-
-The direct super-class $S$ of the class $C$ is defined as the class where no other class $T$ exists where $C$ has superclass $T$ and $T$ has superclass $S$. If there are multiple $S$, all of them should be used as replacement when deleting a class.
-
-%\note{Knud, 06.01.08: Saying that something is ``forbidden'' sounds really strange. Also, why not just say: \emph{If user-generated properties are deleted, this requires all statements in which those properties are involved to be deleted as well, in order to prevent the model to become invalid. Alternativaly, all occurrences of the property could be replaced by its super-property.}
-%\emph{Leo, 8/1:OK}}
-If user-generated properties are deleted, this requires all statements in which those properties are involved to be deleted as well, in order to prevent the model to become invalid.
-Alternatively, all occurrences of the property could be replaced by its super-property.
-%This would be analogous to how classes are handled.} Deleting a user-generated property that was used as predicate in statements is forbidden, as it is not clear what the semantics of the statements would be nor what property should be used as replacement in the statements. User-generated properties can be deleted when all statements using them are deleted a priori.
-
-
-
-\subsection{Merging Duplicates}
-\label{sec:mergeduplicates}
-\emph{Duplicates} are two Things that represent the same real-world entity within a user's PIMO. As we apply the unique name assumption (two Things with different names are different), duplicates should be found and corrected.
-When duplicates are found, both (the ``duplicate'' and the ``original'') can be merged into one single instance.
-In this process, RDF statements involving the duplicate are changed so that they now refer to the original.
-In a local setup with one desktop and all data stored in a single database, this process is without information loss and causes no side-effects. As Semantic Web applications are in a distributed scenario, deleting a duplicate resource can cause dangling links in related databases and other side-effects.
-\note{Knud, 06.01.08: The idea of dangling links here is a bit misleading here. It implies that the Thing the link refers to is somehow \emph{gone}. However, the Thing was never really there --- there are always only statements about Things.}
-\note{Leo: no, its ok. Deleting/merging Things may cause these problems the suggested
-hasDeprecatedRepresentation fixes it like a 301 ``moved permanently''}
-
-For this, the \texttt{pimo:hasDeprecatedRepresentation} property \textbf{should} be used to relate the original with the (now deleted) duplicate. Note that the range of this property is not defined, as all data about the duplicate resource (including the type) is deleted.
-
-When merging two duplicate resource $A$ and $B$ into one resource $C$, a few practical guidelines can reduce side-effects:
-\begin{itemize}
- \item The URI of $C$ is either $A$ or $B$, the older resource (as defined by \texttt{nao:creationDate}, see Section~\ref{sec:changedates}) is to be preferred as it has a higher chance of being used.
- \item The classes of $C$ are the union of the classes of $A$ and $B$.
- \item All statements about $A$ and $B$ are merged to $C$.
-\end{itemize}
-
-\subsection{Unification of multiple Information Elements into one Thing}
-\label{sec:unification}
-In comparison to merging duplicate Things, \emph{unification} is the process when multiple information elements representing the same real-world entity are mapped to one \texttt{pimo:Thing} instance.
-
-In PIMO, multiple information elements representing one real-world entity are mapped to exactly one \texttt{pimo:Thing} instance using the \texttt{pimo:groundingOccurrence} and \texttt{pimo:occurrence} relations.
-Algorithms or user interfaces implementing unification must consider the identifying properties of a Thing (see Section~\ref{sec:identification}) when searching for possible Things to representing information elements.
-%If algorithms don't find an existing Thing to represent and information element, they should create a new instance. See Section~\ref{sec:classofthing} about suitable PIMO classes to represent information elements.
-
-Four default \textbf{NRL Views} and \textbf{NRL ViewSpecifications} are defined for different levels of inference. Each creates a named graph that contains the instance data and the inferred statements.
-
-\begin{description}
- \item[\texttt{pimo:InferOccurrences}] a view that infers occurrences based on \texttt{nie:identifiers} and pimo:referencingOccurrence annotations.
- \item[\texttt{pimo:GroundingClosure}] a view that adds statements about the grounding Occurrences and \texttt{hasOtherRepresentation} to a Thing.
- \item[\texttt{pimo:OccurrenceClosure}] a view that adds statements about all occurrences to a Thing.
- \item[\texttt{pimo:FullPimoView}] a supergraph of all above.
-\end{description}
-
-By providing these graphs, we let the user and software agent decide if the full closure is needed at all times. When no closure is needed, the plain NRL data graphs can be used as-is.
-To answer complex queries like ``Which e-mails were sent to me by attendees of meetings that I have today'', the full closure is a good choice.
-
-The ability to superimpose data using inference limits the data needed in a PIMO to a necessary minimum: only the identification properties are mandatory, the occurrence and the hasOtherRepresentation properties superimpose existing data.
-
-\begin{verbatim}
-claudia:DirkHagemann a pimo:Person;
- pimo:occurrence <imap://claudia@example.com/INBOX/1#from>;
- pimo:groundingOccurrence <file://home/claudia/dirk.vcf#dirk>.
-\end{verbatim}
-
-
-Using the guiding example, an integrated view of Claudia on Paul is the following, assuming full closure:
-{\small
-\begin{verbatim}
-# The canonical Dirk
-claudia:DirkHagemann a pimo:Person;
-# the second type is also inferred
- a nco:PersonContact;
- pimo:isDefinedBy claudia:PIMO;
- nao:prefLabel 'Dirk Hagemann';
- nao:identifier "dirk@example.com";
- pimo:occurrence <imap://claudia@example.com/INBOX/1#from>;
- pimo:groundingOccurrence <file://home/claudia/dirk.vcf#dirk>;
- pimo:referencingOccurrence <http://www.example.com/people/DirkHagemann>;
- pimo:hasOtherRepresentation <http://id.example.com/person/1650>;
-# the inferred facts
- nco:hasEmailAddress <mailto:dirk@example.com>;
- nco:nameFamily "Hagemann";
- nco:nameGiven "Dirk";
- nco:photo <http://www.example.com/people/dirk/photo.jpg>.
-
-# E-mail, now pointing to the canonical Dirk
-<imap://claudia@example.com/INBOX/1> a nmo:Mail;
- nmo:from claudia:DirkHagemann.
-\end{verbatim}
-}
-
-%From the perspective of the user, facts stated about grounding occurrences are correct (they have been taken from existing data managed by the user); as are hasOtherRepresentation
-%(they are from formal ontologies imported and accepted by the user). If this is not the case, the incorrect statements must not be integrated, which is interesting but out of the scope of PIMO for now.
-%As a result of the unification process, one Thing points to multiple information elements. This is also reflected in the previous examples, such as this:
-
-\subsection{Tagging and Annotating Files}
-\label{sec:taggingfiles}
-Conceptually, once an Information Element (a file, an e-mail, a webpage, an address book entry, etc.)
-is in the attention of the user
-and is read or annotated, it is also a Thing in the mental model of the user.
-A core idea of the Semantic Desktop is to use other Things as dimensions to annotate files and retrieve them later, as described in~\cite{Dengel2006}.
-
-Lets assume the file \texttt{/home/claudia/doc/tripplan.pdf} is to be tagged with the tag ``Belfast Meeting Package''.
-
-A representation of the file is already extracted by the semantic desktop data wrapper system
-(or any other content management system):
-
-\begin{verbatim}
-<file://home/claudia/doc/tripplan.pdf> a nie:TextDocument;
- nie:language "en";
- nie:title "Belfast Bus Timetable".
-\end{verbatim}
-
-Additionally, the city of Belfast and the Belfast meeting package already exist in the model, as well as a \texttt{MeetingPackage} class (which was either created by Claudia, or came as part of a shared domain/group ontology):
-\begin{verbatim}
-claudia:BelfastMeetingPackage a claudia:MeetingPackage, pimo:Tag;
- pimo:tagLabel "Belfast Meeting Package";
- pimo:isDefinedBy claudia:PIMO.
-\end{verbatim}
-
-To add a simple tag, the file is now represented as a Thing (\textit{thingified}) and
-the tagging relation set.
-
-\begin{verbatim}
-claudia:BelfastBusTimetable a pimo:Document;
- nao:prefLabel "Belfast Bus Timetable";
- pimo:isDefinedBy claudia:PIMO;
- pimo:groundingOccurrence <file://home/claudia/doc/tripplan.pdf>;
- nao:hasTag claudia:BelfastMeetingPackage.
-\end{verbatim}
-
-The interested reader may now ask, ``but why create a new Thing and
-not just add the nao:hasTag relation directly to the file?''
-The reason to \textit{thingify} the file is twofold:
-first, it is possible to assign a new class to the file, for example
-creating the class \texttt{claudia:BusTimetable}.
-Second, the same timetable may be available in different data objects,
-if it is stored in an e-mail attachment, a web resource,
-or a local file --- it is always the same document.
-A tag added to one occurrence of the file is also valid for other occurrences. Also refer to Sections~\ref{sec:pimoVSnie},\ref{sub:information_elements}.
-
-Given Claudia finds the same timetable on a website, the system
-can link the two based on \texttt{nie:identifiers} (which should be globally unique
-identifiers for information elements, independent of the data object
-they are stored in). This example shows this case (with copied identifiers):
-
-\begin{verbatim}
-# the file on the harddisk
-<file://home/claudia/doc/tripplan.pdf> a nie:TextDocument;
- nie:language "en";
- nie:title "Belfast Bus Timetable";
- # this isbn is fictional
- nie:identifier "ISBN:12123-123123".
-
-<http://www.buseireann.ie/timetables/belfast.pdf>
- a nie:TextDocument;
- nie:title "Belfast Bus Timetable";
- # this isbn is fictional
- nie:identifier "ISBN:12123-123123".
-
-claudia:BelfastBusTimetable a pimo:Document;
- pimo:isDefinedBy claudia:PIMO;
- pimo:groundingOccurrence <file://home/claudia/doc/tripplan.pdf>;
- pimo:occurrence <http://www.buseireann.ie/timetables/belfast.pdf>;
- nie:identifier "ISBN:12123-123123";
- pimo:hasTag claudia:BelfastMeetingPackage.
-\end{verbatim}
-The tag assigned to the bus time table is now valid,
-independent of the data object.
-
-Using the generic tag relation \textbf{pimo:hasTag} is
-an easy-to-use entry point for users that don't need
-formal semantic relations.
-
-Using the property \emph{nao:hasTag} is not sufficient
-to be PIMO conformant, implementers \textbf{must} use
-the \emph{pimo:hasTag} relation for desktop tagging.
-The \emph{nao:hasTag} property and \emph{nao:Tag} class are reserved for data of information elements that are imported into a PIMO.
-
-\textbf{Example}: The Belfast Bus Timetable has the topic Belfast,
-which is not just a Tag but says more about the relation between the
-timetable and the city. The \textbf{has Tag} relation can be used for this:
-\begin{verbatim}
-claudia:BelfastBusTimetable a pimo:Document;
- pimo:hasTag claudia:Belfast.
-\end{verbatim}
-
-\textbf{Example}: The relation between Claudia and the
-BelfastMeetingPackage can be expressed using ``has tag'' but
-may also be represented with a relation saying more about
-the semantics: Claudia is ``attending this meeting''.
-Assuming that the MeetingPackage is a sub-class of meeting,
-this could be expressed like:
-\begin{verbatim}
-claudia:BelfastMeetingPackage a meeting:MeetingPackage.
-
-# instead of nao:hasTag, a semantic relation is used
-claudia:Claudia pimo:attendee claudia:BelfastMeetingPackage.
-\end{verbatim}
-
-\subsection{Geo-locating Things}
-Things can be geo-located, meaning that their geographical location is set using latitude, longitude and altitude information in the WGS84 geodetic reference datum.
-In PIMO, the location is a separate entity of type \texttt{Location}, and other items can then be geo-located there. The relation \texttt{pimo:hasLocation} is used for this, \texttt{pimo:isLocationOf} is the inverse.
-There is an abstract marker class for locatable Things: pimo:Locatable.
-Social events, organizations, persons, and physical objects are locatable.
-
-To add a location to a meeting, this data is added, for your reference the location is also given:
-\begin{verbatim}
-claudia:InitialMeetinginBelfast a pimo:Meeting;
- nao:prefLabel "Initial Meeting in Belfast";
- pimo:hasLocation claudia:Belfast.
-
-claudia:Belfast a pimo:City;
- nao:prefLabel "Belfast";
- geo:lat "54.5833333";
- geo:long "-5.9333333".
-\end{verbatim}
-
-Usually, locations should be reused to locate multiple Things,
-but new locations can of course be generated anytime.
-
-PIMO defines a number of general-purpose classes for countries, states, cities, buildings, and rooms, which we consider independent of culture and domain. Domain-specific ontologies can specify those classes further.
-In the rare case when the type of location cannot be specified with any of the existing classes, the superclass \texttt{pimo:Location} can be used.
-In some application scenarios (such as geo-locating a large amount of photos or measurement values), many locations would be needed.
-To simplify annotation and remove clutter, specialized vocabularies may
-then be used, as for example done in the NEXIF vocabulary for photos.
-
-\subsection{Defining what is in the PIMO and what is not: NRL Graphs and \texttt{definedBy}}
-\label{sec:nrlgraphs}
-The facts (i.e., the statements) used to describe Things should be kept in named graphs according to the NRL standard. This allows to express metadata about the facts, such as to which
-PIMO the Things belong (see Sect.~\ref{sub:connectingThingsToPimo}) or when individual triples were changed (see Sect.~\ref{sec:changedates}) and by whom.
-Another important feature is to find which Things are in the user's PIMO and
-which not. In a shared environment, users may often import group-level ontologies that contain
-Things modeled by others. Considering this, it is important to keep up-to-date as to who said what, or, in other words, to detect if a Thing was modeled by the user or not.
-
-All data expressed about Things can be kept in NRL graphs.
-The minimal metadata is:
-\begin{itemize}
- \item The type of the graph is \texttt{nrl:KnowledgeBase}, as it can contain both instances and ontology constructs (see the NRL specification for more details).
- \item The graph is imported into the user's PIMO.
-\end{itemize}
-Additional metadata such as \texttt{nao:created} can be added.
-These facts can be expressed in a separate metadata graph.
-An example of how this looks like in code using Trig Notation\footnote{\url{http://sites.wiwiss.fu-berlin.de/suhl/bizer/TriG/}}:
-
-\begin{verbatim}
-# The instance data
-claudia:graph1 {
- claudia:DirkHagemann a pimo:Person;
- nao:prefLabel 'Dirk Hagemann'.
-}
-# The metadata
-claudia:graph1_metadata {
- claudia:graph1 a nrl:KnowledgeBase;
- claudia:PIMO nrl:imports claudia:graph1.
-}
-\end{verbatim}
-
-
-\textbf{As not all implementers can or want to use NRL graphs to keep track of the boundaries of a PIMO,
-\texttt{pimo:isDefinedBy} must be used} to connect classes, properties, and instances to the PIMO that defines them\footnote{Separation based on the namespace was considered by some to be enough, but is not (as stores use fulltext comparison to handle namespaces, namespaces as such don't exist in RDF but only in XML).}.
-
-To support both ways of detecting the boundaries of a user-PIMO,
-implementations \textbf{may} add the NRL metadata in addition to the \texttt{pimo:isDefinedBy}
-statements to the generated data.
-Resulting in:
-
-\begin{verbatim}
-# The instance data
-claudia:graph1 {
- claudia:DirkHagemann a pimo:Person;
- pimo:isDefinedBy claudia:PIMO.
- nao:prefLabel 'Dirk Hagemann'.
-}
-# The metadata
-claudia:graph1_metadata {
- claudia:graph1 a nrl:KnowledgeBase;
- claudia:PIMO nrl:imports claudia:graph1.
-}\end{verbatim}
-
-%This may produce legal but not valid NRL data, as explained in the NRL specification, Section 2.3.4
-%\footnote{\url{http://www.semanticdesktop.org/ontologies/nrl/\#mozTocId220340}}.
-%\note{Knud, 06.01.08: What does \emph{legal but not valid} mean?
-%\emph{Leo, 8/1:}added link to NRL. DONE}
-
-%\subsection{Annotating Websites}
-% LEO: I cut that section, when we already have files, we don't need websites anymore.
-
-%\subsection{Annotating an Event with NIE and PIMO}
-% LEO: I cut that section, when we already have files, we don't need Event anymore.
-
-\begin{comment}
-\subsection{Annotating Resources without Creating New Things}
-\label{sec:annotatingexternalresources}
-\note{Knud, 06.01.08: To be honest, I find this section a bit esoteric (and I also admit I probably don't fully understand it). Do we really need this in the PIMO-Spec? I feel like we should try to keep the spec concise and drop this (would be nice in a paper, but not here).}
-The interested reader may have come to the conclusion, that the suggested
-way of handling annotation in PIMO is complicated and cumbersome; based
-on the observation that to annotate a file, a new ``Thing'' resource
-has to be created. Creating a Thing requires minting a new URI, describing
-it and linking it to the annotated resource using the \texttt{pimo:groundingOccurrence}
-relation.
-
-There are two reasons for this approach:
-\begin{itemize}
- \item From a philosophical point of view, the resource can exist without the user's observation of it.
- The user annotates what perception and interpretation they have of the resource,
- a personal perspective. To represent it, the resource is ``thingified'', a new URI is minted,
- to represent that the ``user views the resource''.
- \item Technically, a newly minted URI inside the user's namespace has some qualities that
- make it a good RDF URI: it is retrievable, it does not change, it is unique.
-\end{itemize}
-
-But this also implies, that once a system satisfies both reasons, no new URI has to be minted.
-A Semantic Web system to handle resources could fulfil these requirements:
-\begin{itemize}
- \item Allow users to express their personal view on resources in a way that
- represents ``this user has that view on resource X''. A possible technical
- realization of this requirement is to use graph-metadata to annotate
- which triples are created by which user. The NRL specification allows this.
- \item URIs of resources have to be \textbf{retrievable}. Today, only a few web-applications
- hosting URIs fulfil all requirements of the Technical Architecture Group (TAG)
- of the W3C towards Semantic Web URIs\footnote{See the decision taken to answer the
- http-range-14 issue at \url{http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html}}.
- A human-friendly version of these requirements
- is written in \cite{Sauermann+2007a}. Simplified, servers must implement HTTP GET content
- negotiation and return either RDF or HTML representations.
- \item An URI must not change. Some content management systems don't fulfill this,
- also none of the common file systems (when a file is moved, the URI changes)
- nor does it the IMAP URI scheme.
-\end{itemize}
-
-Simply put: the system storing resources to be annotated must be fully Semantic Web and NRL compliant.
-Such resources could then be annotated directly, without creating Things and relating them to grounding occurrences.
-
-\textbf{Example}: annotating a correct Semantic Web URI without creating a new URI for it.
-\begin{verbatim}
-# It is mandatory that the used URIs conform to the open linked data standards
-@prefix claudia: <http://www.example.com/people/claudia#> .
-
-# The annotation is about Tim Berners Lee,
-# identified by a correct Semantic Web URI
-@prefix timblcard: <http://www.w3.org/People/Berners-Lee/card#>.
-
-
-# A named graph containing the metadata about Graph1
-claudia:Graph1Meta {
- claudia:Graph1 a nrl:KnowledgeBase;
- nao:creator claudia:Claudia.
- # The annotations are now part of her user-PIMO
- claudia:PIMO nrl:imports claudia:Graph1.
-}
-# This is the annotation by Claudia about Tim Berners Lee
-claudia:Graph1 {
- # Claudia says: he is a Person
- timblcard:i a pimo:Person;
- # he is now also part of Claudia's personal view on the world,
- # this is valid within this graph
- pimo:isDefinedBy claudia:PIMO;
- # a tag is added
- nao:hasTag claudia:SemanticWeb.
-}
-\end{verbatim}
-We would recommend to try this out experimentally, when you have access to
-a system that fulfils the requirements,
-but not before.
-Without a proper NRL implementation, misleading information
-could be inferred.
-The PIMO framework is intended to work today,
-therefore the pimo:groundingOccurrence relation and the minting of new
-URIs is recommended. It is also compatible for
-the next years, when Semantic Web and NRL compliant systems exist.
-\end{comment}
-
-\subsection{Using NAO and NIE Elements for Annotation}
-\label{sec:usingnieinpimo}
-Throughout this document, we have shown several uses of NAO and NIE elements
-that can be applied to \texttt{pimo:Thing} instances.
-
-Semantically, we start from the assumption that a Thing modeled in PIMO is describing a concept from the real world.
-On the other hand, the Thing itself can be viewed as a set of statements or triples stored in a computer system.
-Thus, Things are resources and can be annotated with NAO.
-Also, using PIMO closure as described in Sect.~{\ref{sec:integratingfacts},
-facts of NIE elements can be inferred as facts of PIMO Things.
-Thus, Things can also have a NIE class as type.
-
-In Table~\ref{tab:SemanitcsOfNIEInPIMO} we give an overview of how the semantics of
-the predicates may alter when interpreted within the PIMO.
-
-The text ``\textbf{no change}'' means that the interpretation is unchanged, ``\textbf{not interpreted}'' means you should avoid interpreting this property in PIMO. You may notice that some properties are not interpreted because they have DataObjects or Strings as range, where PIMO has properties modeling the same semantics but using other \texttt{pimo:Thing}s as range, which is a more precise way of modeling because of the UNA.
-``\textbf{Required}'' means that this property is required for all instances of \texttt{pimo:Thing}
-and this can be validated using the rules from Section \ref{sec:validationrules}.
-``\textbf{Recommended}'' means that you should use this property as if it is required, but it cannot be validated in NRL as property restrictions are only available in OWL.
-
-The properties describing how information is stored (mime-type, bytesize, characterset) are obsolete for Things, as they describe a serialization.
-
-\begin{table}[h!tbp]
- \centering
- \begin{tabular}{|l|p{0.7\textwidth}|}
- \hline
- Term & Semantics\\
- \hline
- \texttt{nao:created} & \textbf{Recommended} When the RDF Resource representing this Thing was first created in the user's PIMO.\\
- \texttt{nao:identifier} & no change, used for identification and matching.\\
- \texttt{nao:lastModified} & \textbf{Recommended} When the Resource representing this Thing was last changed in the user's PIMO. Note that it can be different from the nie:contentLastModified property of a groundingOccurrence. When blending multiple groundingOccurrences into a Thing, the latest contentLastModified should be chosen.\\
- \texttt{nao:modified} & \textbf{Recommended}\\
- \texttt{nao:personalIdentifier} & \textbf{Not recommended}, \texttt{pimo:tagLabel} \textbf{must} be used.\\
- \texttt{nao:prefLabel} & \textbf{Recommended}\\
- \texttt{nie:characterSet} & \textbf{Not interpreted}, obsolete in RDF\\
- \texttt{nie:comment} & no change\\
- \texttt{nie:contentCreated} & \textbf{Not interpreted} \\
- \texttt{nie:contentLastModified} & \textbf{Not interpreted} \\
- \texttt{nie:contentSize} & \textbf{Not interpreted}, obsolete in RDF\\
- \texttt{nie:copyright} & no change, can be set by the user when sharing Things with others. See also nie:legal\\
- \texttt{nie:depends} & no change\\
- \texttt{nie:description} & no change\\
- \texttt{nie:disclaimer} & \textbf{not interpreted}\\
- \texttt{nie:generator} & no change, \texttt{pimo:Things} can be generated automatically by software or manipulated by user interfaces\\
- \texttt{nie:generatorOption} & no change\\
- \texttt{nie:hasPart} & \textbf{not interpreted}, \texttt{pimo:hasPart} should be used\\
- \texttt{nie:identifier} & no change\\
- \texttt{nie:isStoredIn} & \textbf{not interpreted}, \texttt{pimo:isDefinedBy} covers the storage.\\
- \texttt{nie:keyword} & \textbf{not interpreted}, should be modeled using hasTag and assigning the keyword as title of the topic.\\
- \texttt{nie:language} & no change\\
- \texttt{nie:legal} & no change, by default all legal properties scope all the statements having the same subject as the legal statement\\
- \texttt{nie:license} & no change\\
- \texttt{nie:licenseType} & no change\\
- \texttt{nie:links} & \textbf{not interpreted}, use pimo:related or pimo:hasTag\\
- \texttt{nie:mimeType} & \textbf{not interpreted}, obsolete in RDF\\
- \texttt{nie:plainTextContent} & no change\\
- \texttt{nie:relatedTo} & \textbf{not interpreted}, use pimo:related\\
- \texttt{nie:subject} & \textbf{not interpreted}, use pimo:hasTag\\
- \texttt{nie:title} & \textbf{not interpreted}\\
- \texttt{nie:version} & no change\\
- \hline
- \end{tabular}
- \caption{Semantics of NAO and NIE in PIMO}
- \label{tab:SemanitcsOfNIEInPIMO}
-\end{table}
-
-\begin{comment}
-\subsection{Isn't Reification Enough for a Personal View?}
-\note{Knud, 06.01.08: For this section (though good), I have the same comment as before: I consider it to be outside the scope of a concise specification. Someone who is new to the whole SemDesk Thing and wants to work with it, will want to read this spec asking "ok, now how do I use PIMO". They will not want to know why certain decisions where \emph{not} taken. They will want to look up how stuff works, not how it \emph{doesn't} work. This section would be more appropriate in a document about the design decisions behind PIMO. Just my opinion!}
-\note{Leo: moved to http://dev.nepomuk.semanticdesktop.org/wiki/OntologiesHowTo}
-The Semantic Web provides another possibility to express a personal view on information elements, namely using normal annotations to the existing elements (by adding triples to them) and then reifying the triples and annotating them as ``being expressed as personal view''. Using named graphs and NRL is conceptually the same to reification and could also be used for this.
-The reasons not to use reification or Named Graphs as primary modeling concept are both technical and political:
-\begin{itemize}
- \item Data expressed in PIMO should be long-lasting and not be influenced by changes of operating systems, applications or the movement of files. To ensure this, the primary URIs of Things are generated in a separated namespace, tied to the user.
- \item When Information Elements move, are deleted or are not accessible by the user anymore, they can be found again based on the identifying properties annotated to the stable URIs minted for Things.
- \item Using annotations on existing URIs would make the decision for the ``primary'' URI for a Thing ambiguous. The structure of Things implies that there is one primary representation, the Thing with its minted URI, pointing to all other representations using relations.
- This allows implementations to quickly find the focus point (the Thing) from which all other information about it can be found. Although this is typically handled by inference engines, the current approach allows to find various sources of information about a Thing in the globally distributed Semantic Web, where distributed inference is not available.
- \item Reification is often criticized as being complicated, basing the whole system on it would direct this critique in the wrong direction.
- \item From a philosophical point of view, each individual sees and perceives the world through their own eyes and interprets it according to their own mental model.
-\end{itemize}
-\end{comment}
-
-\begin{comment}
-\subsection{Why not Use owl:sameAs?}
-\label{seq:faqsameas}
-\note{Knud, 06.01.08: as before. Is this necessary in a specification document?}
-\note{LEO: moved to http://dev.nepomuk.semanticdesktop.org/wiki/OntologiesHowTo}
-
-OWL's \texttt{sameAs} is an equivalence relation (transitive, reflexive, symmetric) whereas \texttt{groundingOccurrence} is directed and inverse functional.
-To express that a Thing and an entity from a domain ontology are modeling the same concept from the real world, and that users have agreed on that, use \texttt{pimo:hasOtherRepresentation} (or \texttt{pimo:hasOtherConceptualization} for classes).
-
-Connecting two resources with owl:sameAs implies that they refer to the same real-world entity. As PIMO is subjective, \texttt{pimo:groundingOccurrence} expresses that from the point of view of the user, they are the same, but not necessarily for other users. Using \texttt{sameAs} would create \texttt{n!} relations between \texttt{n} same objects, a fully connected graph. Given an \texttt{InformationElement} as input, querying what Thing has this as a grounding occurrence returns in one step the correct single answer, using a simplest query possible. This cannot be done using \texttt{owl:sameAs}, because the answers are possibly many InformationElements from the model, the unique Thing being one of them, only distinguished by its class being a sub-class of \texttt{pimo:Thing}. So the separation has the semantic reason that the view is directed from the user towards his InformationElements, and the technical reason that this allows an efficient realization in possible implementations.
-\end{comment}
-\begin{comment}
-\subsection{Why isn't skos:Concept Used?}
-\note{Knud, 06.01.08: specification?}
-\note{LEO: moved to http://dev.nepomuk.semanticdesktop.org/wiki/OntologiesHowTo}
-The interested reader may suggest to use \texttt{skos:Concept} instead of \texttt{pimo:Thing.} But then, all resources would have the same type, namely \texttt{skos:Concept}. Then all domain/range, sub-class and sub-property features of RDF are not usable and existing ontologies (such as NRL or NIE)
-cannot be used to model Things. This is visible when looking at the \texttt{skos:narrowerInstantive} property, which is a parallel approach to \texttt{rdf:type}.
-We have tried SKOS in an evaluation and implemented a prototype using it during the EPOS project, coming to this conclusion.
-\end{comment}
-
-\subsection{How to Infer Knowledge Using Rules?}
-The presented ontology may be used to express facts that can
-be used to infer new knowledge. For example, the person Claudia may be working
-on the project ``CID''. Claudia is also employed by the company Example Inc. ---
-this may be used to infer that the company Example is involved in ``CID''
-Such rules are very useful to improve the results when querying, as they will provide more answers.
-
-In PIMO and NRL, it is not straightforward how to express these rules.
-Also, as PIMO-upper is generic, any rules defined on this level may
-not apply in all group-level ontologies.
-
-We recommend to express such rules using a rule language (such as the
-ones defined by the RIF working group of W3C\footnote{\url{http://www.w3.org/2005/rules/}}) or SPARQL-create statements.
-These should be part of domain and group ontologies.
-
-\section{Rules Defined by PIMO}
-\label{sec:pimorules}
-Some of the rules defined in PIMO cannot be expressed using ordinary NRL semantics. These rules are written here using SPARQL construct queries \textbf{and are also part of the ontology, by virtue of \texttt{nrl:RuleViewSpecification}}.
-The rules help to infer additional statements or validate a model.
-\textbf{All rules in this section assume that at least the sub-class and sub-property
-relations are inferred.}
-
-\subsection{Construction Rules}
-\label{sec:creationrules}
-The first set of rules define new information that is inferred from existing data. They are used for integrating facts about Things by blending, see Sect.~\ref{sec:integratingfacts}.
-The rules are expressed based on the assumption that Tbox inferenced facts are available in querying, whereas Abox inference may or may not. This means, sub-class and sub-property relations are fully inferred, but the statements implied by them may or may not\footnote{In instance bases, rules rdfs7 and rdfs9 make the majority of inferred statements and for storage optimization \url{http://www.w3.org/TR/rdf-mt/\#RDFSRules}}.
-For some of the rules, the semantics of equality comparison is clearer under this assumption.
-For example, assume two sub-properties of \texttt{nao:identifier}: \texttt{book:number} and \texttt{person:number}, both with a range of integer and values starting with numbers from 0.
-Expressing a rule as ``two Things are equal when their \texttt{nao:identifier} is equal''
-could imply, that a book is equal a person.
-
-\textbf{\texttt{pimo:InferOccurrences} Level}: These are the rules to infer what resources are occurrences of Things based on identifiers. You can use this approach to integrate data from large stores. For example to see all appearances of a document using the document's NIE-identifier, this query searches for the \texttt{pimo:occurrence} relations.
-\begin{verbatim}
-CONSTRUCT {
-?thing pimo:occurrence ?occurrence.
-} WHERE {
-?i rdfs:subPropertyOf nao:identifier.
-?thing ?i ?value.
-?occurrence ?i ?value.
-}
-\end{verbatim}
-
-\textbf{\texttt{pimo:GroundingClosure} Level}: This adds all facts from grounding occurrences and \texttt{hasOtherRepresentation} occurrences to Things.
-\begin{verbatim}
-CONSTRUCT {
-?thing ?p ?o
-} WHERE {
-?thing pimo:groundingOccurrence ?x.
-?x ?p ?o.
-}
-CONSTRUCT {
-?s ?p ?thing
-} WHERE {
-?thing pimo:groundingOccurrence ?x.
-?s ?p ?x.
-}
-CONSTRUCT {
-?thing ?p ?o
-} WHERE {
-?thing pimo:hasOtherRepresentation ?x.
-?x ?p ?o.
-}
-CONSTRUCT {
-?s ?p ?thing
-} WHERE {
-?thing pimo:hasOtherRepresentation ?x.
-?s ?p ?x.
-}
-\end{verbatim}
-
-
-\textbf{\texttt{pimo:OccurrenceClosure} Level}: This adds all facts of all occurrences to Things.
-\begin{verbatim}
-CONSTRUCT {
-?thing ?p ?o
-} WHERE {
-?thing pimo:occurrence ?x.
-?x ?p ?o.
-}
-CONSTRUCT {
-?s ?p ?thing
-} WHERE {
-?thing pimo:occurrence ?x.
-?s ?p ?x.
-}
-\end{verbatim}
-
-
-\textbf{A broader Topic is also the Topic of a Thing.} If a Thing X has the tag A and topic A has a super topic B, then X has also the tag B. \texttt{superTopic} and \texttt{subTopic} are transitive.
-\begin{verbatim}
-CONSTRUCT {?x pimo:hasTag ?B}
-WHERE
-{?x pimo:hasTag ?A.
-?A pimo:superTopic ?B.}
-\end{verbatim}
-Note that this is not true for the \texttt{hasPart} relation.
-
-An alternative to the \texttt{hasTag} rules would have been to represent topics as RDFS classes (instead of having them as instance of type \texttt{pimo:Topic}) and using \texttt{rdfs:subClassOf} relations instead of broader/narrower. But this has a nasty side-effect that for a topic like ``Web'' having a sub-topic ``Semantic Web'', the user would suddenly be able to create instances of ``Semantic Web'', this would be confusing.
-
-\subsection{Validation Rules}
-\label{sec:validationrules}
-These rules validate a model. Some assumptions stated in the text can be validated using these rules. As a model for validation, we have chosen to pick a similar approach as the Jena validation engine, namely creating errors. The classes \texttt{error:Error} and \texttt{error:Message} were introduced for this purpose and not defined any further, we assume Errors can have parameters that are passed back as \texttt{error:param1}, \texttt{error:param2}, etc. The parameters can be referenced in the error message for readability.
-
-\subsection{Rules Valid when Integrating with NIE}
-When using PIMO in coordination with NIE, certain properties from NIE can be reused.
-The rules are often used to restrict properties defined in the NIE ontology to be mandatory on \texttt{pimo:Things}, whereas they are optional when used on \texttt{nie:InformationElement}. Such restrictions are possible in OWL but not in NRL.
-
-\textbf{Every Thing must have a \texttt{nao:prefLabel}.}
-\begin{verbatim}
-CONSTRUCT {
-_:err a error:Error.
-_:err error:Message ``Thing \%1 does not have a nao:prefLabel''.
-_:err error:param1 ?x.
-} WHERE {
-?x rdf:type pimo:Thing.
-OPTIONAL { ?x nao:prefLabel ?title } .
-FILTER (!bound(?title))
-}
-\end{verbatim}
-
-\textbf{Every Thing must have \texttt{nao:created}.}
-\begin{verbatim}
-CONSTRUCT {
-_:err a error:Error.
-_:err error:Message ``Thing \%1 does not have a nao:created''.
-_:err error:param1 ?x.
-} WHERE {
-?x rdf:type pimo:Thing.
-OPTIONAL { ?x nao:created ?created } .
-FILTER (!bound(?created))
-}
-\end{verbatim}
-
-\section{Sources considered for designing PIMO}
-Several ontologies and scientific publications predate this specification.
-A definition of the term PIMO was given in~\cite{sauermann+2007b}:
-\begin{definition}
-A PIMO is a Personal Information Model of one person. It is a formal representation of
-parts of the users Mental Model. Each concept in the Mental Model can be represented using
-a Thing or a sub-class of this class in RDF. Native Resources found in the Personal
-Knowledge Workspace can be categorized, then they are occurrences of a Thing.
-\end{definition}
-
-%COPIED FROM SauermannElstDengel2007
-A similar approach was used by Huiyong Xiao and
-Isabel F. Cruz in their paper on ``A Multi-Ontology Approach for Personal
-Information Management'', where they differentiate between \emph{Application
-Layer, Domain Layer and Resource Layer}. Alexakos et al. described ``A
-Multilayer Ontology Scheme for Integrated Searching in Distributed Hypermedia''
-in~\cite{likothanasis+2005}. There, the layers consist of an\emph{ upper search
-ontology layer, domain description ontologies layer, and a semantic metadata
-layer}.
-
-PIMO is different from Topic Maps (TM) in that it is based on the logical and semantic foundations of RDF and RDFS, whereas TM have no such foundation.
-A major difference between TM and RDF is that Topic Maps Associations are n-ary relations,
-whereas in RDF relations are always binary.
-In RDF, a similar approach as to TM is the SKOS vocabulary~\cite{SkosStandard}.
-It represents all Things using the class \emph{Concept}, this prohibits reusing inference and typed properties of concepts (e.g., the ``first name'' property of a person cannot be modeled in SKOS).
-%END OF SauermannElstDengel2007
-
-% THIS was good for Leos diss and leo has not to forget to copy/paste it there
-The idea of mapping SKOS, RDF, OWL and topic maps with upper ontologies has come up repeatedly, but with varying outcome. We value these articles as very important for our work, because of their excellent research and the experience of the authors.
-\begin{itemize}
- \item Pepper and Schwab~\cite{Pepper+2003} try to map the identification approach of XML Topic Maps to RDF, leaving a few issues open.
- \item Jack Park and Adam Cheyer mapped Topic Maps to Semantic Desktops for Personal Information Management in \cite{Park+2005}.
- \item The \emph{Semex} system provides ideas about reference reconciliation~\cite{DongH2005}
- \item Jerome Euzenat proposed a top-level ontology for PIM in light of FOAF\footnote{\url{http://www.w3.org/2001/sw/Europe/200210/calendar/SyncLink.html}}
- Although this is a small, seemingly unimportant footnote, it shows how often capable people tried to address this problem.
- \item User Profile Ontology version 1\cite{UserProfileOntologyVersion1},
- mentioned in \cite{DELOSTIM2007}\footnote{\url{http://oceanis.mm.di.uoa.gr/pened/?category=publications}}.
-% \item Richard Saul Wurman found: geographical, alphabetically,
-% by Time, by Categories, by Hierarchy.
-% (Location, Alphabet, Time, Category, and Hierarchy, known as LATCH cite R. Wurman, D. Sume, and L. Leifer, Information Anxiety 2, Que, 2000.)
- \item Latif and Tjoa \cite{Latif+2006} map a user ontology against other top-level ontologies such as SUMO and DOLCE and use the LATCH approach from Richard Saul Wurman.
- %\item Nejdl's Beagle stuff. % too late to document this, we must finish now
-\end{itemize}
-
-% is this really true? Well, we comment it out
-%They key factors that we found in most related work are \textbf{identifying resources unambiguously} and \textbf{modeling the complicated specializations in specialized domain ontologies} while keeping the core clean. So \textbf{integration of heterogenous data wins over trying to make a world-embracing super ontology}.
-%% do we agree on that?
-%The PIMO approach, using the pimo:groundingOccurrence and the pimo:hasOtherRepresentation relations together with blending data, instead of using owl:sameAs seems (from our perspectice) the right choice.
-
-
-
-\appendix
-% THESE were part of development of this document
-%\include{openissues}
-%\include{nonissues}
-%\include{solvedissues}
-
-\section{Changes}
-This Section lists changes from different version.
-
-\subsection{From v1.0 to 1.1}
-General:
-\begin{itemize}
- \item Two new Sections: tagging~\ref{sec:tagginginpimo} and topic hierarchies~\ref{sec:topichierarchies}.
- \item \texttt{pimo:tagLabel} must be used instead of \texttt{nao:personalIdentifier}.
- \item Added \texttt{pimo:hasRootTopic} to link to root topics.
- \item Added \texttt{pimo:hasGlobalNamespace} to express the global namespace as written in the semdesk URI draft.
- \item Added \texttt{pimo:hasLocalNamespace} to express the local namespace as written in the semdesk URI draft.
- \item The range of \texttt{rating} has changed to $[0..10]$.
-\end{itemize}
-Introducing \texttt{pimo:Tag} to unify the problematic parallel worlds of \texttt{nao:Tag} and \texttt{pimo:Thing}. \texttt{pimo:Tag} is the class to use for tags.
-\begin{itemize}
- \item \texttt{pimo:Tag} is an adaption of \texttt{nao:Tag} for PIMO with precise semantics.
- \item \texttt{pimo:Topic} is a sublcass of \texttt{pimo:Tag}.
- \item \texttt{pimo:Tag} is a subclass of \texttt{pimo:Thing}.
- \item \texttt{pimo:hasTopic} is renamed to \texttt{pimo:hasTag} and the range is Tag
- \item \texttt{pimo:isTopicOf} is renamed to \texttt{pimo:isTagFor} and the domain is Tag
- \item \texttt{pimo:tagLabel} is introduced as a subproperty of \texttt{nao:personalIdentifier}, domain \texttt{pimo:Tag} and with mincardinality 1 and maxcardinality 1.
-\end{itemize}
-
-\clearpage
-\bibliographystyle{plain}
-\bibliography{pimo}
-
-\clearpage
-
-\section{PIMO Specification}
-
-%spec
-\input{sections/pimo}
-
-\end{document}
diff --git a/pimo/doc/handbook_latex/pimo.tex.bak b/pimo/doc/handbook_latex/pimo.tex.bak deleted file mode 100644 index f68e3a0..0000000 --- a/pimo/doc/handbook_latex/pimo.tex.bak +++ /dev/null @@ -1,309 +0,0 @@ -% STATUS
-% Knud: we should do two documents, one short and precise one describing the standard and a longer one for
-% explaining the decision made and the design rationale.
-% Renauld and Knud work on it from DERI side.
-
-
-
-\documentclass[11pt]{nepomuk}
-\usepackage{hyperref} % turn on when latex is used (not miktec)
-\usepackage{url} % LEO: urls \url{}
-\usepackage{verbatim} % code and comment
-\usepackage{longtable}
-\parindent0pt
-
-\begin{document}
-% explicit hyphenations
-\hyphenation{RDF-Re-po-si-to-ry}
-\hyphenation{name-space}
-\hyphenation{So-cket-A-dap-ter}
-
-\fontfamily{tahoma}\selectfont
-\def\note#1{\marginpar{\footnotesize#1}} % use this to show the notes in the document
-%\def\note#1{} % use this to hide the notes
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-% TITLE PAGES
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\thispagestyle{empty}
-
-\pagenumbering{roman}
-
-\hspace*{-4.5cm}
-\begin{minipage}[p]{7cm}
-\begin{large}
-\textcolor{nepomuk@lightblue}{
-\begin{tabular}{l}
-Integrated Project \\
-Priority 2.4.7 \\
-Semantic based knowledge systems\\
-\end{tabular}
-}
-\end{large}
-\end{minipage}
-
-\vspace{-2.8cm}
-
-
-\begin{flushright}
- \includegraphics*[width=3.89cm]{images/InformationSocietyTechnologies}
-\end{flushright}
-
-\vspace{0.5cm}
-
-\begin{flushright}
- \includegraphics[width=12cm]{images/Nepomuk}
-\end{flushright}
-
-
-\vspace{1cm}
-
-
-\textcolor{nepomuk@lightblue}{\rightline{\Huge{\bfseries \sffamily Personal Information Element}}}
-\textcolor{nepomuk@lightblue}{\rightline{\Huge{\bfseries \sffamily Ontology}}}
-
-\vspace{0.3cm}
-
-\textcolor{nepomuk@green}{\rightline{\huge specification draft}}
-
-\vspace{0cm}
-
-%\begin{figure}[h!]
-\begin{flushright}
- \includegraphics[width=9cm]{images/Bubbles}
-\end{flushright}
-%\end{figure}
-
-
-\vspace*{-5.5cm}
-
-\renewcommand{\arraystretch}{1.2}
-\hspace*{-4.5cm}
-\begin{minipage}[p]{11cm}
-\begin{large}
-\textcolor{nepomuk@red}{
-\begin{tabular*}{8cm}{l@{\extracolsep{\fill}}l}
-\multicolumn{2}{l}{\Large Version 0.1} \\
-\multicolumn{2}{l}{\Large 01.06.2007} \\
-\multicolumn{2}{l}{\Large Dissemination level: PU} \\
-\\
-Nature & Prototype \\
-Due date & 31.05.2006 \\
-Lead contractor & DFKI\\
-Start date of project \qquad & 01.01.2006 \\
-Duration & 36 months \\
-\end{tabular*}
-}
-\end{large}
-\end{minipage}
-
-\clearpage
-%%%%%%%%%%%%%%
-% NEXT PAGES %
-%%%%%%%%%%%%%%
-\pagestyle{scrheadings}
-
-\cohead{\small\textcolor{nepomuk@lightblue}{NEPOMUK}}
-\rohead{\small\textcolor{nepomuk@lightblue}{20.03.2007}}
-\lofoot{\small\textcolor{nepomuk@lightblue}{Task Force Ontologies}}
-\cofoot{\small\textcolor{nepomuk@lightblue}{Version 0.1}}
-\rofoot{\small\textcolor{nepomuk@lightblue}{\thepage}}
-
-\newpage
-
-\section*{Authors}
-\hspace*{-2,5cm}\begin{minipage}[p]{14cm}
-Leo Sauermann, DFKI \\
-\end{minipage}
-
-
-\vfill
-\section*{Project Co-ordinator}
-\hspace*{-2,5cm}\begin{minipage}[p]{14cm}
-Dr. Ansgar Bernardi \\
-German Research Center for Artificial Intelligence (DFKI) GmbH \\
-Trippstadter Strasse 122 \\
-D 67663 Kaiserslautern \\
-Germany \\
-Email: bernardi@dfki.uni-kl.de, phone: +49 631 205 3582, fax: +49 631 205 4910 \\
-\end{minipage}
-
-
-\section*{Partners}
-\hspace*{-2,5cm}\begin{minipage}[p]{14cm}
-DEUTSCHES FORSCHUNGSZENTRUM F. KUENSTLICHE INTELLIGENZ GMBH \\
-IBM IRELAND PRODUCT DISTRIBUTION LIMITED \\
-SAP AG \\
-HEWLETT PACKARD GALWAY LTD \\
-THALES S.A. \\
-PRC GROUP - THE MANAGEMENT HOUSE S.A. \\
-EDGE-IT S.A.R.L \\
-COGNIUM SYSTEMS S.A. \\
-NATIONAL UNIVERSITY OF IRELAND, GALWAY \\
-ECOLE POLYTECHNIQUE FEDERALE DE LAUSANNE \\
-FORSCHUNGSZENTRUM INFORMATIK AN DER UNIVERSITAET KARLSRUHE \\
-UNIVERSITAET HANNOVER \\
-INSTITUTE OF COMMUNICATION AND COMPUTER SYSTEMS \\
-KUNGLIGA TEKNISKA HOEGSKOLAN \\
-UNIVERSITA DELLA SVIZZERA ITALIANA \\
-IRION MANAGEMENT CONSULTING GMBH
-
-\vspace{0.3cm}
-\begin{footnotesize}
-Copyright: NEPOMUK Consortium 2006\\
-Copyright on template: Irion Management Consulting GmbH 2006
-\end{footnotesize}
-\end{minipage}
-
-\clearpage
-
-
-\section*{Versions}
-
-\begin{footnotesize}
-\begin{tabular}{|c|c|p{8cm}|}
-\hline
-\rowcolor{nepomuk@lightblue}\textcolor{white}{Version} &
- \textcolor{white}{Date} &
- \textcolor{white}{Reason} \\ \hline
-0.1 & 01.06.2007 & a template of the document prepared by Antoni Mylka \\ \hline
-\end{tabular}
-\end{footnotesize}
-
-\color{black}
-
-\vfill
-{\bf Explanations of abbreviations on front page}\\
-\\
-Nature \\
-R: Report \\
-P: Prototype \\
-R/P: Report and Prototype \\
-O: Other \\
- \\
-Dissemination level \\
-PU: Public \\
-PP: Restricted to other FP6 participants \\
-RE: Restricted to specified group \\
-CO: Confidential, only for NEPOMUK partners \\
-
-\newpage
-\section*{Status of this document}
-
-{\footnotesize
-\begin{verbatim}
-
-Copyright (c) 2007 DFKI
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
-THE SOFTWARE.
-
-\end{verbatim}
-}
-
-This draft is a work in progress, open for review and comments. Please contact
-leo.sauermann@dfki.de if you'd like to use it.
-
-This document describes the Personal Information Model Ontology (PIMO)
-
-\newpage
-
-%%%%%%%%%%%%%%%%%%%%%
-% TABLE OF CONTENTS %
-%%%%%%%%%%%%%%%%%%%%%
-\setcounter{tocdepth}{2}
-\tableofcontents
-\cleardoublepage
-\pagenumbering{arabic}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%
-% BEGINNING OF SECTIONS %
-%%%%%%%%%%%%%%%%%%%%%%%%%
-\clearpage
-\section{Introduction}
-
-This is going to be an introduction about pimo.
-
-\subsection{Scope of the PIMO}
-% SOURCE1 copied from Leos Dissertation & PIMO Paper / Ludger
-The motivation for creating the PIMO is to find a language to name the terms
-that are relevant to a knowledge worker and to have ways to express facts about
-these terms. Once this language is defined and formalized in the ontological
-description of the PIMO, it can be used to translate existing resources, and to
-express information about them. The PIMO is a user-centric view on existing
-documents, domain ontologies, and web data sources.
-
-While the organization asks for universally applicable and standardized
-persistent structures, processes, and work organizations to achieve and
-maintain universally accessible information archives, the individual knowledge
-worker requests individualized structures and flexibility in processes and work
-organization in order to reach optimal support for the individual activities.
-
-The \emph{Personal Information Model (PIMO)} as created in the EPOS project was
-driven by four requirements:
-\begin{itemize}
- \item Sound formal basis: The PIMO must support various knowledge
- services, among them logics-based services (e.g., ontology-based information
- retrieval). Therefore, the PIMO must employ an expressive representation language and
- has to wipe out the contradictions and redundancies of the native structures.
- \item Bridge between individual and organizational Knowledge Management:
- The PIMO has to incorporate global ontologies, but also has
- to reflect the changes and updates of native structures. The PIMO itself should
- be a source of input for OM-wide ontologies.
- \item Maintenance: Adequate means have to be provided that assist the user with
- stepwise formalization of native structures and inspection of the PIMO.
-\end{itemize}
-% END OF SOURCE1
-
-Features that the PIMO has to realize are based on requirements from the user side.
-\begin{itemize}
- \item Representing Things: Represent things of interest.
- \item Uniqueness and merging: two information elements that represent the same thing have to be mapped to one entity.
- \item Relations: Links between things have to be browseable, properties should have inverse relations defined (see \cite{rohmer2005})
- \item Extensibility: Users are free to add new relation types and new classes (see \cite{rohmer2005})
-\end{itemize}
-
-\subsection{Open Questions to be addressed}
-A few questions are solved by the PIMO approach, these can be asked by programmers, knowledge engineers,
-or end-users of Semantic Desktops.
-
-\begin{description}
- \item[What classes and instances appear in a user interface?]
- Assumed that many classes and instances are stored in an available RDF data store,
- what classes and instances should be shown to the user? Are all of them of interest?
- When applying filter rules, should the filter rules be excluding
- (not wanted classes are filtered out) or including (wanted classes are filtered in).
- \item[]
-\end{description}
-
-\section{Description}
-
-This is going to be a description of PIMO with some informal overview of the classes and properties. Maybe some diagrams.
-
-\clearpage
-\bibliographystyle{plain}
-\bibliography{pimo}
-
-\clearpage
-
-\appendix
-
-\section{PIMO Specification}
-
-\input{sections/pimo}
-
-\end{document}
diff --git a/pimo/doc/handbook_latex/pimo.toc b/pimo/doc/handbook_latex/pimo.toc deleted file mode 100644 index 675e103..0000000 --- a/pimo/doc/handbook_latex/pimo.toc +++ /dev/null @@ -1,158 +0,0 @@ -\contentsline {section}{\numberline {1}Abstract}{1}{section.1}
-\contentsline {section}{\numberline {2}Status of this document}{1}{section.2}
-\contentsline {section}{\numberline {3}Introduction}{1}{section.3}
-\contentsline {subsection}{\numberline {3.1}Downloading PIMO}{2}{subsection.3.1}
-\contentsline {section}{\numberline {4}PIMO integrates with key ontologies}{3}{section.4}
-\contentsline {section}{\numberline {5}Examples}{4}{section.5}
-\contentsline {subsection}{\numberline {5.1}PIMO ontology and namespaces}{4}{subsection.5.1}
-\contentsline {section}{\numberline {6}Creating Personal Information Models}{5}{section.6}
-\contentsline {subsection}{\numberline {6.1}The User and their Individual PIMO}{5}{subsection.6.1}
-\contentsline {subsection}{\numberline {6.2}Things}{6}{subsection.6.2}
-\contentsline {subsection}{\numberline {6.3}Connecting Things to the User's PIMO}{6}{subsection.6.3}
-\contentsline {subsection}{\numberline {6.4}Identification of Things}{7}{subsection.6.4}
-\contentsline {paragraph}{NAO-Identifiers}{8}{section*.6}
-\contentsline {paragraph}{Grounding Occurrence}{8}{section*.7}
-\contentsline {paragraph}{Occurrence}{9}{section*.8}
-\contentsline {paragraph}{Referencing Occurrence}{9}{section*.9}
-\contentsline {paragraph}{Other Representation}{10}{section*.10}
-\contentsline {paragraph}{Other Conceptualization}{10}{section*.11}
-\contentsline {subsection}{\numberline {6.5}A Complete Example}{10}{subsection.6.5}
-\contentsline {subsection}{\numberline {6.6}Labels and Names of Things}{11}{subsection.6.6}
-\contentsline {paragraph}{\texttt {nao:prefLabel}}{11}{section*.12}
-\contentsline {paragraph}{\texttt {pimo:tagLabel}}{12}{section*.13}
-\contentsline {paragraph}{\texttt {nao:altLabel}}{12}{section*.14}
-\contentsline {subsection}{\numberline {6.7}Textual description of Things}{12}{subsection.6.7}
-\contentsline {subsection}{\numberline {6.8}Rating and Ranking Things}{13}{subsection.6.8}
-\contentsline {subsection}{\numberline {6.9}Modelling Time}{13}{subsection.6.9}
-\contentsline {subsection}{\numberline {6.10}Representing Modification and Change Dates}{13}{subsection.6.10}
-\contentsline {subsection}{\numberline {6.11}Setting the Class of a Thing}{14}{subsection.6.11}
-\contentsline {subsection}{\numberline {6.12}The PIMO-upper ontology}{15}{subsection.6.12}
-\contentsline {subsection}{\numberline {6.13}Classes in PIMO-Upper}{15}{subsection.6.13}
-\contentsline {subsection}{\numberline {6.14}Describing Things with Attributes and Relations}{17}{subsection.6.14}
-\contentsline {subsection}{\numberline {6.15}Generic Properties in PIMO-Upper}{17}{subsection.6.15}
-\contentsline {subsection}{\numberline {6.16}Refined properties in PIMO-Upper}{18}{subsection.6.16}
-\contentsline {subsection}{\numberline {6.17}Tagging Things with Tags}{18}{subsection.6.17}
-\contentsline {subsection}{\numberline {6.18}Topic Hierarchies}{19}{subsection.6.18}
-\contentsline {subsection}{\numberline {6.19}Creating Personalized Classes and Properties}{20}{subsection.6.19}
-\contentsline {subsection}{\numberline {6.20}Collections of Things}{21}{subsection.6.20}
-\contentsline {subsection}{\numberline {6.21}Modeling Associations and Roles in PIMO}{21}{subsection.6.21}
-\contentsline {section}{\numberline {7}Connecting PIMO to Information Elements}{22}{section.7}
-\contentsline {subsection}{\numberline {7.1}Connecting Things and Classes to Folders}{22}{subsection.7.1}
-\contentsline {subsection}{\numberline {7.2}Integrating Facts about Things}{23}{subsection.7.2}
-\contentsline {section}{\numberline {8}PIMO-group level: Group and Domain ontologies}{23}{section.8}
-\contentsline {section}{\numberline {9}Extending PIMO}{24}{section.9}
-\contentsline {subsection}{\numberline {9.1}Refining Elements of PIMO-upper}{24}{subsection.9.1}
-\contentsline {paragraph}{Classes}{24}{section*.15}
-\contentsline {paragraph}{Instances}{24}{section*.16}
-\contentsline {paragraph}{Properties}{25}{section*.17}
-\contentsline {paragraph}{Inheritance}{25}{section*.18}
-\contentsline {subsection}{\numberline {9.2}Markup for the new ontology}{26}{subsection.9.2}
-\contentsline {subsection}{\numberline {9.3}Information Elements}{26}{subsection.9.3}
-\contentsline {subsection}{\numberline {9.4}Extension by Sub-classing from External Classes}{28}{subsection.9.4}
-\contentsline {subsection}{\numberline {9.5}Summary}{29}{subsection.9.5}
-\contentsline {section}{\numberline {10}Importing Domain Ontologies into a User's PIMO}{29}{section.10}
-\contentsline {section}{\numberline {11}Practical Directions on Using PIMO}{30}{section.11}
-\contentsline {subsection}{\numberline {11.1}Creating Things}{30}{subsection.11.1}
-\contentsline {paragraph}{Start}{30}{section*.19}
-\contentsline {paragraph}{Check GroundingOccurrence}{30}{section*.20}
-\contentsline {paragraph}{Check occurrences}{30}{section*.21}
-\contentsline {paragraph}{Check identifiers}{30}{section*.22}
-\contentsline {paragraph}{Create a new Thing}{31}{section*.23}
-\contentsline {subsection}{\numberline {11.2}Changing the Type of a Thing}{31}{subsection.11.2}
-\contentsline {subsection}{\numberline {11.3}Deleting a Thing}{32}{subsection.11.3}
-\contentsline {subsection}{\numberline {11.4}Deleting User-generated Classes and Properties}{32}{subsection.11.4}
-\contentsline {subsection}{\numberline {11.5}Merging Duplicates}{32}{subsection.11.5}
-\contentsline {subsection}{\numberline {11.6}Unification of multiple Information Elements into one Thing}{33}{subsection.11.6}
-\contentsline {subsection}{\numberline {11.7}Tagging and Annotating Files}{34}{subsection.11.7}
-\contentsline {subsection}{\numberline {11.8}Geo-locating Things}{35}{subsection.11.8}
-\contentsline {subsection}{\numberline {11.9}Defining what is in the PIMO and what is not: NRL Graphs and \texttt {definedBy}}{36}{subsection.11.9}
-\contentsline {subsection}{\numberline {11.10}Using NAO and NIE Elements for Annotation}{37}{subsection.11.10}
-\contentsline {subsection}{\numberline {11.11}How to Infer Knowledge Using Rules?}{37}{subsection.11.11}
-\contentsline {section}{\numberline {12}Rules Defined by PIMO}{39}{section.12}
-\contentsline {subsection}{\numberline {12.1}Construction Rules}{39}{subsection.12.1}
-\contentsline {subsection}{\numberline {12.2}Validation Rules}{40}{subsection.12.2}
-\contentsline {subsection}{\numberline {12.3}Rules Valid when Integrating with NIE}{40}{subsection.12.3}
-\contentsline {section}{\numberline {13}Sources considered for designing PIMO}{41}{section.13}
-\contentsline {section}{\numberline {A}Changes}{42}{appendix.A}
-\contentsline {subsection}{\numberline {A.1}From v1.0 to 1.1}{42}{subsection.A.1}
-\contentsline {section}{\numberline {B}PIMO Specification}{45}{appendix.B}
-\contentsline {subsection}{\numberline {B.1}Ontology Classes Description}{45}{subsection.B.1}
-\contentsline {subsubsection}{\numberline {B.1.1}Agent}{45}{subsubsection.B.1.1}
-\contentsline {subsubsection}{\numberline {B.1.2}Association}{45}{subsubsection.B.1.2}
-\contentsline {subsubsection}{\numberline {B.1.3}Attendee}{45}{subsubsection.B.1.3}
-\contentsline {subsubsection}{\numberline {B.1.4}BlogPost}{46}{subsubsection.B.1.4}
-\contentsline {subsubsection}{\numberline {B.1.5}Building}{46}{subsubsection.B.1.5}
-\contentsline {subsubsection}{\numberline {B.1.6}City}{46}{subsubsection.B.1.6}
-\contentsline {subsubsection}{\numberline {B.1.7}ClassOrThing}{47}{subsubsection.B.1.7}
-\contentsline {subsubsection}{\numberline {B.1.8}ClassOrThingOrPropertyOrAssociation}{47}{subsubsection.B.1.8}
-\contentsline {subsubsection}{\numberline {B.1.9}ClassRole}{48}{subsubsection.B.1.9}
-\contentsline {subsubsection}{\numberline {B.1.10}Collection}{48}{subsubsection.B.1.10}
-\contentsline {subsubsection}{\numberline {B.1.11}Contract}{49}{subsubsection.B.1.11}
-\contentsline {subsubsection}{\numberline {B.1.12}Country}{49}{subsubsection.B.1.12}
-\contentsline {subsubsection}{\numberline {B.1.13}Document}{50}{subsubsection.B.1.13}
-\contentsline {subsubsection}{\numberline {B.1.14}Event}{50}{subsubsection.B.1.14}
-\contentsline {subsubsection}{\numberline {B.1.15}Locatable}{50}{subsubsection.B.1.15}
-\contentsline {subsubsection}{\numberline {B.1.16}Location}{51}{subsubsection.B.1.16}
-\contentsline {subsubsection}{\numberline {B.1.17}LogicalMediaType}{51}{subsubsection.B.1.17}
-\contentsline {subsubsection}{\numberline {B.1.18}Meeting}{52}{subsubsection.B.1.18}
-\contentsline {subsubsection}{\numberline {B.1.19}Note}{52}{subsubsection.B.1.19}
-\contentsline {subsubsection}{\numberline {B.1.20}Organization}{52}{subsubsection.B.1.20}
-\contentsline {subsubsection}{\numberline {B.1.21}OrganizationMember}{53}{subsubsection.B.1.21}
-\contentsline {subsubsection}{\numberline {B.1.22}Person}{53}{subsubsection.B.1.22}
-\contentsline {subsubsection}{\numberline {B.1.23}PersonGroup}{53}{subsubsection.B.1.23}
-\contentsline {subsubsection}{\numberline {B.1.24}PersonRole}{54}{subsubsection.B.1.24}
-\contentsline {subsubsection}{\numberline {B.1.25}PersonalInformationModel}{54}{subsubsection.B.1.25}
-\contentsline {subsubsection}{\numberline {B.1.26}ProcessConcept}{55}{subsubsection.B.1.26}
-\contentsline {subsubsection}{\numberline {B.1.27}Project}{55}{subsubsection.B.1.27}
-\contentsline {subsubsection}{\numberline {B.1.28}Room}{55}{subsubsection.B.1.28}
-\contentsline {subsubsection}{\numberline {B.1.29}SocialEvent}{56}{subsubsection.B.1.29}
-\contentsline {subsubsection}{\numberline {B.1.30}State}{56}{subsubsection.B.1.30}
-\contentsline {subsubsection}{\numberline {B.1.31}Task}{56}{subsubsection.B.1.31}
-\contentsline {subsubsection}{\numberline {B.1.32}Thing}{57}{subsubsection.B.1.32}
-\contentsline {subsubsection}{\numberline {B.1.33}Topic}{58}{subsubsection.B.1.33}
-\contentsline {subsection}{\numberline {B.2}Ontology Properties Description}{58}{subsection.B.2}
-\contentsline {subsubsection}{\numberline {B.2.1}associationEffectual}{58}{subsubsection.B.2.1}
-\contentsline {subsubsection}{\numberline {B.2.2}associationMember}{58}{subsubsection.B.2.2}
-\contentsline {subsubsection}{\numberline {B.2.3}attendee}{59}{subsubsection.B.2.3}
-\contentsline {subsubsection}{\numberline {B.2.4}attendingMeeting}{59}{subsubsection.B.2.4}
-\contentsline {subsubsection}{\numberline {B.2.5}attends}{59}{subsubsection.B.2.5}
-\contentsline {subsubsection}{\numberline {B.2.6}broader}{59}{subsubsection.B.2.6}
-\contentsline {subsubsection}{\numberline {B.2.7}classRole}{60}{subsubsection.B.2.7}
-\contentsline {subsubsection}{\numberline {B.2.8}containsLocation}{60}{subsubsection.B.2.8}
-\contentsline {subsubsection}{\numberline {B.2.9}createdPimo}{60}{subsubsection.B.2.9}
-\contentsline {subsubsection}{\numberline {B.2.10}creator}{60}{subsubsection.B.2.10}
-\contentsline {subsubsection}{\numberline {B.2.11}datatypeProperty}{61}{subsubsection.B.2.11}
-\contentsline {subsubsection}{\numberline {B.2.12}dtend}{61}{subsubsection.B.2.12}
-\contentsline {subsubsection}{\numberline {B.2.13}dtstart}{61}{subsubsection.B.2.13}
-\contentsline {subsubsection}{\numberline {B.2.14}duration}{61}{subsubsection.B.2.14}
-\contentsline {subsubsection}{\numberline {B.2.15}groundingForDeletedThing}{62}{subsubsection.B.2.15}
-\contentsline {subsubsection}{\numberline {B.2.16}groundingOccurrence}{62}{subsubsection.B.2.16}
-\contentsline {subsubsection}{\numberline {B.2.17}hasDeprecatedRepresentation}{62}{subsubsection.B.2.17}
-\contentsline {subsubsection}{\numberline {B.2.18}hasFolder}{63}{subsubsection.B.2.18}
-\contentsline {subsubsection}{\numberline {B.2.19}hasLocation}{63}{subsubsection.B.2.19}
-\contentsline {subsubsection}{\numberline {B.2.20}hasOrganizationMember}{63}{subsubsection.B.2.20}
-\contentsline {subsubsection}{\numberline {B.2.21}hasOtherConceptualization}{63}{subsubsection.B.2.21}
-\contentsline {subsubsection}{\numberline {B.2.22}hasOtherRepresentation}{64}{subsubsection.B.2.22}
-\contentsline {subsubsection}{\numberline {B.2.23}hasOtherSlot}{64}{subsubsection.B.2.23}
-\contentsline {subsubsection}{\numberline {B.2.24}hasPart}{64}{subsubsection.B.2.24}
-\contentsline {subsubsection}{\numberline {B.2.25}hasTopic}{65}{subsubsection.B.2.25}
-\contentsline {subsubsection}{\numberline {B.2.26}isDefinedBy}{65}{subsubsection.B.2.26}
-\contentsline {subsubsection}{\numberline {B.2.27}isLocationOf}{65}{subsubsection.B.2.27}
-\contentsline {subsubsection}{\numberline {B.2.28}isOrganizationMemberOf}{66}{subsubsection.B.2.28}
-\contentsline {subsubsection}{\numberline {B.2.29}isRelated}{66}{subsubsection.B.2.29}
-\contentsline {subsubsection}{\numberline {B.2.30}isTopicOf}{66}{subsubsection.B.2.30}
-\contentsline {subsubsection}{\numberline {B.2.31}isWriteable}{66}{subsubsection.B.2.31}
-\contentsline {subsubsection}{\numberline {B.2.32}jabberId}{67}{subsubsection.B.2.32}
-\contentsline {subsubsection}{\numberline {B.2.33}locatedWithin}{67}{subsubsection.B.2.33}
-\contentsline {subsubsection}{\numberline {B.2.34}narrower}{67}{subsubsection.B.2.34}
-\contentsline {subsubsection}{\numberline {B.2.35}objectProperty}{67}{subsubsection.B.2.35}
-\contentsline {subsubsection}{\numberline {B.2.36}occurrence}{68}{subsubsection.B.2.36}
-\contentsline {subsubsection}{\numberline {B.2.37}organization}{68}{subsubsection.B.2.37}
-\contentsline {subsubsection}{\numberline {B.2.38}partOf}{68}{subsubsection.B.2.38}
-\contentsline {subsubsection}{\numberline {B.2.39}referencingOccurrence}{69}{subsubsection.B.2.39}
-\contentsline {subsubsection}{\numberline {B.2.40}roleContext}{69}{subsubsection.B.2.40}
-\contentsline {subsubsection}{\numberline {B.2.41}roleHolder}{69}{subsubsection.B.2.41}
-\contentsline {subsubsection}{\numberline {B.2.42}subTopic}{69}{subsubsection.B.2.42}
-\contentsline {subsubsection}{\numberline {B.2.43}superTopic}{70}{subsubsection.B.2.43}
-\contentsline {subsubsection}{\numberline {B.2.44}taskDueTime}{70}{subsubsection.B.2.44}
-\contentsline {subsubsection}{\numberline {B.2.45}wikiText}{70}{subsubsection.B.2.45}
diff --git a/pimo/doc/handbook_latex/pimo.tps b/pimo/doc/handbook_latex/pimo.tps deleted file mode 100644 index 9b75a9f..0000000 --- a/pimo/doc/handbook_latex/pimo.tps +++ /dev/null @@ -1,183 +0,0 @@ -[FormatInfo]
-Type=TeXnicCenterProjectSessionInformation
-Version=2
-
-[SessionInfo]
-ActiveTab=0
-FrameCount=6
-ActiveFrame=0
-
-[Frame0]
-Columns=1
-Rows=1
-Flags=2
-ShowCmd=3
-MinPos.x=-1
-MinPos.y=-1
-MaxPos.x=-4
-MaxPos.y=-34
-NormalPos.left=66
-NormalPos.top=99
-NormalPos.right=926
-NormalPos.bottom=450
-Class=CLatexEdit
-Document=pimo.tex
-
-[Frame0_Row0]
-cyCur=491
-cyMin=10
-
-[Frame0_Col0]
-cxCur=951
-cxMin=10
-
-[Frame0_View0,0]
-Cursor.row=135
-Cursor.column=37
-TopSubLine=217
-
-[Frame1]
-Columns=1
-Rows=1
-Flags=0
-ShowCmd=1
-MinPos.x=-1
-MinPos.y=-1
-MaxPos.x=-4
-MaxPos.y=-34
-NormalPos.left=22
-NormalPos.top=33
-NormalPos.right=991
-NormalPos.bottom=405
-Class=CLatexEdit
-Document=pimo.bib
-
-[Frame1_Row0]
-cyCur=311
-cyMin=10
-
-[Frame1_Col0]
-cxCur=938
-cxMin=10
-
-[Frame1_View0,0]
-Cursor.row=88
-Cursor.column=18
-TopSubLine=77
-
-[Frame2]
-Columns=1
-Rows=1
-Flags=0
-ShowCmd=1
-MinPos.x=-1
-MinPos.y=-1
-MaxPos.x=-4
-MaxPos.y=-34
-NormalPos.left=44
-NormalPos.top=66
-NormalPos.right=1013
-NormalPos.bottom=452
-Class=CLatexEdit
-Document=openissues.tex
-
-[Frame2_Row0]
-cyCur=325
-cyMin=10
-
-[Frame2_Col0]
-cxCur=938
-cxMin=10
-
-[Frame2_View0,0]
-Cursor.row=5
-Cursor.column=0
-TopSubLine=0
-
-[Frame3]
-Columns=1
-Rows=1
-Flags=0
-ShowCmd=1
-MinPos.x=-1
-MinPos.y=-1
-MaxPos.x=-4
-MaxPos.y=-34
-NormalPos.left=66
-NormalPos.top=99
-NormalPos.right=1035
-NormalPos.bottom=485
-Class=CLatexEdit
-Document=nonissues.tex
-
-[Frame3_Row0]
-cyCur=325
-cyMin=10
-
-[Frame3_Col0]
-cxCur=938
-cxMin=10
-
-[Frame3_View0,0]
-Cursor.row=112
-Cursor.column=0
-TopSubLine=103
-
-[Frame4]
-Columns=1
-Rows=1
-Flags=0
-ShowCmd=1
-MinPos.x=-1
-MinPos.y=-1
-MaxPos.x=-4
-MaxPos.y=-34
-NormalPos.left=88
-NormalPos.top=132
-NormalPos.right=1057
-NormalPos.bottom=518
-Class=CLatexEdit
-Document=solvedissues.tex
-
-[Frame4_Row0]
-cyCur=325
-cyMin=10
-
-[Frame4_Col0]
-cxCur=938
-cxMin=10
-
-[Frame4_View0,0]
-Cursor.row=275
-Cursor.column=0
-TopSubLine=332
-
-[Frame5]
-Columns=1
-Rows=1
-Flags=0
-ShowCmd=1
-MinPos.x=-1
-MinPos.y=-1
-MaxPos.x=-4
-MaxPos.y=-34
-NormalPos.left=110
-NormalPos.top=165
-NormalPos.right=1079
-NormalPos.bottom=587
-Class=CLatexEdit
-Document=sections\pimo.tex
-
-[Frame5_Row0]
-cyCur=361
-cyMin=10
-
-[Frame5_Col0]
-cxCur=938
-cxMin=10
-
-[Frame5_View0,0]
-Cursor.row=623
-Cursor.column=0
-TopSubLine=1055
-
diff --git a/pimo/doc/handbook_latex/pimo_v0.9.pdf b/pimo/doc/handbook_latex/pimo_v0.9.pdf Binary files differdeleted file mode 100644 index b3b2867..0000000 --- a/pimo/doc/handbook_latex/pimo_v0.9.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/pimo_v1.0.pdf b/pimo/doc/handbook_latex/pimo_v1.0.pdf Binary files differdeleted file mode 100644 index a92f3c3..0000000 --- a/pimo/doc/handbook_latex/pimo_v1.0.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/pimo_v1.1.pdf b/pimo/doc/handbook_latex/pimo_v1.1.pdf Binary files differdeleted file mode 100644 index ee10114..0000000 --- a/pimo/doc/handbook_latex/pimo_v1.1.pdf +++ /dev/null diff --git a/pimo/doc/handbook_latex/sections/pimo.tex b/pimo/doc/handbook_latex/sections/pimo.tex deleted file mode 100644 index 14125b9..0000000 --- a/pimo/doc/handbook_latex/sections/pimo.tex +++ /dev/null @@ -1,988 +0,0 @@ -\subsection{Ontology Classes Description} -\subsubsection{Agent} -\label{pimo:Agent} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & {\it pimo:}Organization \ref{pimo:Organization} p. \pageref{pimo:Organization}\newline {\it pimo:}Person \ref{pimo:Person} p. \pageref{pimo:Person}\newline {\it pimo:}PersonGroup \ref{pimo:PersonGroup} p. \pageref{pimo:PersonGroup}\\ \hline -In domain of: & {\it pimo:}createdPimo \ref{pimo:createdPimo} p. \pageref{pimo:createdPimo}\newline {\it pimo:}isOrganizationMemberOf \ref{pimo:isOrganizationMemberOf} p. \pageref{pimo:isOrganizationMemberOf}\\ \hline -In range of: & {\it pimo:}creator \ref{pimo:creator} p. \pageref{pimo:creator}\newline {\it pimo:}hasOrganizationMember \ref{pimo:hasOrganizationMember} p. \pageref{pimo:hasOrganizationMember}\\ \hline -Description & An agent (eg. person, group, software or physical artifact). The Agent class is the class of agents; things that do stuff. A well known sub-class is Person, representing people. Other kinds of agents include Organization and Group. -(inspired by FOAF). -Agent is not a subclass of NAO:Party.\\ \hline -\end{longtable} - - -\subsubsection{Association} -\label{pimo:Association} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\\ \hline -Subclasses & {\it pimo:}Attendee \ref{pimo:Attendee} p. \pageref{pimo:Attendee}\newline {\it pimo:}OrganizationMember \ref{pimo:OrganizationMember} p. \pageref{pimo:OrganizationMember}\newline {\it pimo:}PersonRole \ref{pimo:PersonRole} p. \pageref{pimo:PersonRole}\\ \hline -In domain of: & {\it pimo:}associationEffectual \ref{pimo:associationEffectual} p. \pageref{pimo:associationEffectual}\newline {\it pimo:}associationMember \ref{pimo:associationMember} p. \pageref{pimo:associationMember}\\ \hline -In range of: & --\\ \hline -Description & An association between two or more pimo-things. This is used to model n-ary relations and metadata about relations. For example, the asociation of a person being organizational member is only effectual within a period of time (after the person joined the organization and before the person left the organization). There can be multiple periods of time when associations are valid.\\ \hline -\end{longtable} - - -\subsubsection{Attendee} -\label{pimo:Attendee} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}Association \ref{pimo:Association} p. \pageref{pimo:Association}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}PersonRole \ref{pimo:PersonRole} p. \pageref{pimo:PersonRole}\newline {\it rdfs:}Resource\\ \hline -Subclasses & --\\ \hline -In domain of: & {\it pimo:}attendingMeeting \ref{pimo:attendingMeeting} p. \pageref{pimo:attendingMeeting}\\ \hline -In range of: & --\\ \hline -Description & The role of someone attending a social event.\\ \hline -\end{longtable} - - -\subsubsection{BlogPost} -\label{pimo:BlogPost} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Document \ref{pimo:Document} p. \pageref{pimo:Document}\newline {\it pimo:}LogicalMediaType \ref{pimo:LogicalMediaType} p. \pageref{pimo:LogicalMediaType}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & A blog note. You just want to write something down right now and need a place to do that. Add a blog-note! This is an example class for a document type, there are more detailled ontologies to model Blog-Posts (like SIOC).\\ \hline -\end{longtable} - - -\subsubsection{Building} -\label{pimo:Building} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Location \ref{pimo:Location} p. \pageref{pimo:Location}\newline {\it rdfs:}Resource\newline {\it geo:}SpatialThing\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & A structure that has a roof and walls and stands more or less permanently in one place; "there was a three-story building on the corner"; "it was an imposing edifice". (Definition from SUMO).\\ \hline -\end{longtable} - - -\subsubsection{City} -\label{pimo:City} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Location \ref{pimo:Location} p. \pageref{pimo:Location}\newline {\it rdfs:}Resource\newline {\it geo:}SpatialThing\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & A large and densely populated urban area; may include several independent administrative districts; "Ancient Troy was a great city". (Definition from SUMO)\\ \hline -\end{longtable} - - -\subsubsection{ClassOrThing} -\label{pimo:ClassOrThing} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\\ \hline -Subclasses & {\it pimo:}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\newline {\it pimo:}BlogPost \ref{pimo:BlogPost} p. \pageref{pimo:BlogPost}\newline {\it pimo:}Building \ref{pimo:Building} p. \pageref{pimo:Building}\newline {\it pimo:}City \ref{pimo:City} p. \pageref{pimo:City}\newline {\it pimo:}Collection \ref{pimo:Collection} p. \pageref{pimo:Collection}\newline {\it pimo:}Contract \ref{pimo:Contract} p. \pageref{pimo:Contract}\newline {\it pimo:}Country \ref{pimo:Country} p. \pageref{pimo:Country}\newline {\it pimo:}Document \ref{pimo:Document} p. \pageref{pimo:Document}\newline {\it pimo:}Event \ref{pimo:Event} p. \pageref{pimo:Event}\newline {\it pimo:}Locatable \ref{pimo:Locatable} p. \pageref{pimo:Locatable}\newline {\it pimo:}Location \ref{pimo:Location} p. \pageref{pimo:Location}\newline {\it pimo:}LogicalMediaType \ref{pimo:LogicalMediaType} p. \pageref{pimo:LogicalMediaType}\newline {\it pimo:}Meeting \ref{pimo:Meeting} p. \pageref{pimo:Meeting}\newline {\it pimo:}Note \ref{pimo:Note} p. \pageref{pimo:Note}\newline {\it pimo:}Organization \ref{pimo:Organization} p. \pageref{pimo:Organization}\newline {\it pimo:}Person \ref{pimo:Person} p. \pageref{pimo:Person}\newline {\it pimo:}PersonGroup \ref{pimo:PersonGroup} p. \pageref{pimo:PersonGroup}\newline {\it pimo:}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\newline {\it pimo:}Project \ref{pimo:Project} p. \pageref{pimo:Project}\newline {\it pimo:}Room \ref{pimo:Room} p. \pageref{pimo:Room}\newline {\it pimo:}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\newline {\it pimo:}State \ref{pimo:State} p. \pageref{pimo:State}\newline {\it pimo:}Task \ref{pimo:Task} p. \pageref{pimo:Task}\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\newline {\it pimo:}Topic \ref{pimo:Topic} p. \pageref{pimo:Topic}\\ \hline -In domain of: & {\it pimo:}hasFolder \ref{pimo:hasFolder} p. \pageref{pimo:hasFolder}\newline {\it pimo:}wikiText \ref{pimo:wikiText} p. \pageref{pimo:wikiText}\\ \hline -In range of: & --\\ \hline -Description & Superclass of class and thing. To add properties to both class and thing.\\ \hline -\end{longtable} - - -\subsubsection{ClassOrThingOrPropertyOrAssociation} -\label{pimo:ClassOrThingOrPropertyOrAssociation} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it rdfs:}Resource\\ \hline -Subclasses & {\it pimo:}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\newline {\it pimo:}Association \ref{pimo:Association} p. \pageref{pimo:Association}\newline {\it pimo:}Attendee \ref{pimo:Attendee} p. \pageref{pimo:Attendee}\newline {\it pimo:}BlogPost \ref{pimo:BlogPost} p. \pageref{pimo:BlogPost}\newline {\it pimo:}Building \ref{pimo:Building} p. \pageref{pimo:Building}\newline {\it pimo:}City \ref{pimo:City} p. \pageref{pimo:City}\newline {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}Collection \ref{pimo:Collection} p. \pageref{pimo:Collection}\newline {\it pimo:}Contract \ref{pimo:Contract} p. \pageref{pimo:Contract}\newline {\it pimo:}Country \ref{pimo:Country} p. \pageref{pimo:Country}\newline {\it pimo:}Document \ref{pimo:Document} p. \pageref{pimo:Document}\newline {\it pimo:}Event \ref{pimo:Event} p. \pageref{pimo:Event}\newline {\it pimo:}Locatable \ref{pimo:Locatable} p. \pageref{pimo:Locatable}\newline {\it pimo:}Location \ref{pimo:Location} p. \pageref{pimo:Location}\newline {\it pimo:}LogicalMediaType \ref{pimo:LogicalMediaType} p. \pageref{pimo:LogicalMediaType}\newline {\it pimo:}Meeting \ref{pimo:Meeting} p. \pageref{pimo:Meeting}\newline {\it pimo:}Note \ref{pimo:Note} p. \pageref{pimo:Note}\newline {\it pimo:}Organization \ref{pimo:Organization} p. \pageref{pimo:Organization}\newline {\it pimo:}OrganizationMember \ref{pimo:OrganizationMember} p. \pageref{pimo:OrganizationMember}\newline {\it pimo:}Person \ref{pimo:Person} p. \pageref{pimo:Person}\newline {\it pimo:}PersonGroup \ref{pimo:PersonGroup} p. \pageref{pimo:PersonGroup}\newline {\it pimo:}PersonRole \ref{pimo:PersonRole} p. \pageref{pimo:PersonRole}\newline {\it pimo:}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\newline {\it pimo:}Project \ref{pimo:Project} p. \pageref{pimo:Project}\newline {\it pimo:}Room \ref{pimo:Room} p. \pageref{pimo:Room}\newline {\it pimo:}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\newline {\it pimo:}State \ref{pimo:State} p. \pageref{pimo:State}\newline {\it pimo:}Task \ref{pimo:Task} p. \pageref{pimo:Task}\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\newline {\it pimo:}Topic \ref{pimo:Topic} p. \pageref{pimo:Topic}\\ \hline -In domain of: & {\it pimo:}isDefinedBy \ref{pimo:isDefinedBy} p. \pageref{pimo:isDefinedBy}\\ \hline -In range of: & --\\ \hline -Description & Superclass of resources that can be generated by the user.\\ \hline -\end{longtable} - - -\subsubsection{ClassRole} -\label{pimo:ClassRole} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it rdfs:}Resource\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & {\it pimo:}classRole \ref{pimo:classRole} p. \pageref{pimo:classRole}\\ \hline -Description & Roles of classes in PIMO: concrete instances are Abstract and Concrete.\\ \hline -Instances & {\it pimo:}AbstractClass\newline {\it pimo:}ConcreteClass\\ \hline -\end{longtable} - - -\subsubsection{Collection} -\label{pimo:Collection} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & {\it pimo:}PersonGroup \ref{pimo:PersonGroup} p. \pageref{pimo:PersonGroup}\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & A collection of Things, independent of their class. The items in the collection share a common property. Which property may be modelled explicitly or mentioned in the description of the Collection. The requirement of explicit modelling the semantic meaning of the collection is not mandatory, as collections can be created ad-hoc. Implizit modelling can be applied by the system by learning the properties. For example, a Collection of "Coworkers" could be defined as that all elements must be of class "Person" and have an attribute "work for the same Organization as the user". Further standards can be used to model these attributes.\\ \hline -\end{longtable} - - -\subsubsection{Contract} -\label{pimo:Contract} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Document \ref{pimo:Document} p. \pageref{pimo:Document}\newline {\it pimo:}LogicalMediaType \ref{pimo:LogicalMediaType} p. \pageref{pimo:LogicalMediaType}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & A binding agreement between two or more persons that is enforceable by law. (Definition from SUMO). This is an example class for a document type, there are more detailled ontologies to model Contracts.\\ \hline -\end{longtable} - - -\subsubsection{Country} -\label{pimo:Country} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Location \ref{pimo:Location} p. \pageref{pimo:Location}\newline {\it rdfs:}Resource\newline {\it geo:}SpatialThing\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & The territory occupied by a nation; "he returned to the land of his birth"; "he visited several European countries". (Definition from SUMO)\\ \hline -\end{longtable} - - -\subsubsection{Document} -\label{pimo:Document} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}LogicalMediaType \ref{pimo:LogicalMediaType} p. \pageref{pimo:LogicalMediaType}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & {\it pimo:}BlogPost \ref{pimo:BlogPost} p. \pageref{pimo:BlogPost}\newline {\it pimo:}Contract \ref{pimo:Contract} p. \pageref{pimo:Contract}\newline {\it pimo:}Note \ref{pimo:Note} p. \pageref{pimo:Note}\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & A generic document. This is a placeholder class for document-management domain ontologies to subclass. Create more and specified subclasses of pimo:Document for the document types in your domain. Documents are typically instances of both NFO:Document (modeling the information element used to store the document) and a LogicalMediaType subclass. Two examples are given for what to model here: a contract for a business domain, a BlogPost for an informal domain.\\ \hline -\end{longtable} - - -\subsubsection{Event} -\label{pimo:Event} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & {\it pimo:}Meeting \ref{pimo:Meeting} p. \pageref{pimo:Meeting}\newline {\it pimo:}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & Something that happens -An Event is conceived as compact in time. (Definition from Merriam-Webster)\\ \hline -\end{longtable} - - -\subsubsection{Locatable} -\label{pimo:Locatable} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & {\it pimo:}Meeting \ref{pimo:Meeting} p. \pageref{pimo:Meeting}\newline {\it pimo:}Organization \ref{pimo:Organization} p. \pageref{pimo:Organization}\newline {\it pimo:}Person \ref{pimo:Person} p. \pageref{pimo:Person}\newline {\it pimo:}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\\ \hline -In domain of: & {\it pimo:}hasLocation \ref{pimo:hasLocation} p. \pageref{pimo:hasLocation}\\ \hline -In range of: & --\\ \hline -Description & Things that can be at a location. Abstract class, use it as a superclass of things that can be placed in physical space.\\ \hline -\end{longtable} - - -\subsubsection{Location} -\label{pimo:Location} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\newline {\it geo:}SpatialThing\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & {\it pimo:}Building \ref{pimo:Building} p. \pageref{pimo:Building}\newline {\it pimo:}City \ref{pimo:City} p. \pageref{pimo:City}\newline {\it pimo:}Country \ref{pimo:Country} p. \pageref{pimo:Country}\newline {\it pimo:}Room \ref{pimo:Room} p. \pageref{pimo:Room}\newline {\it pimo:}State \ref{pimo:State} p. \pageref{pimo:State}\\ \hline -In domain of: & {\it pimo:}containsLocation \ref{pimo:containsLocation} p. \pageref{pimo:containsLocation}\newline {\it pimo:}isLocationOf \ref{pimo:isLocationOf} p. \pageref{pimo:isLocationOf}\newline {\it pimo:}locatedWithin \ref{pimo:locatedWithin} p. \pageref{pimo:locatedWithin}\\ \hline -In range of: & {\it pimo:}containsLocation \ref{pimo:containsLocation} p. \pageref{pimo:containsLocation}\newline {\it pimo:}hasLocation \ref{pimo:hasLocation} p. \pageref{pimo:hasLocation}\newline {\it pimo:}locatedWithin \ref{pimo:locatedWithin} p. \pageref{pimo:locatedWithin}\\ \hline -Description & A physical location. Subclasses are modeled for the most common locations humans work in: Building, City, Country, Room, State. This selection is intended to be applicable cross-cultural and cross-domain. City is a prototype that can be further refined for villages, etc. Subclass of a WGS84:SpatialThing, can have geo-coordinates.\\ \hline -\end{longtable} - - -\subsubsection{LogicalMediaType} -\label{pimo:LogicalMediaType} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & {\it pimo:}BlogPost \ref{pimo:BlogPost} p. \pageref{pimo:BlogPost}\newline {\it pimo:}Contract \ref{pimo:Contract} p. \pageref{pimo:Contract}\newline {\it pimo:}Document \ref{pimo:Document} p. \pageref{pimo:Document}\newline {\it pimo:}Note \ref{pimo:Note} p. \pageref{pimo:Note}\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & Logical media types represent the content aspect of information elements e.g. a flyer, a contract, a promotional video, a todo list. The user can create new logical media types dependend on their domain: a salesman will need MarketingFlyer, Offer, Invoice while a student might create Report, Thesis and Homework. This is independent from the information element and data object (NIE/NFO) in which the media type will be stored. The same contract can be stored in a PDF file, a text file, or an HTML website. -The groundingOccurrence of a LogicalMediaType is the Document that stores the content.\\ \hline -\end{longtable} - - -\subsubsection{Meeting} -\label{pimo:Meeting} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Event \ref{pimo:Event} p. \pageref{pimo:Event}\newline {\it pimo:}Locatable \ref{pimo:Locatable} p. \pageref{pimo:Locatable}\newline {\it pimo:}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\newline {\it rdfs:}Resource\newline {\it pimo:}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & The social act of assembling for some common purpose; "his meeting with the salesman was the high point of his day". (Definition from SUMO)\\ \hline -\end{longtable} - - -\subsubsection{Note} -\label{pimo:Note} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Document \ref{pimo:Document} p. \pageref{pimo:Document}\newline {\it pimo:}LogicalMediaType \ref{pimo:LogicalMediaType} p. \pageref{pimo:LogicalMediaType}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & A note. The textual contents of the note should be expressed in the nao:description value of the note.\\ \hline -\end{longtable} - - -\subsubsection{Organization} -\label{pimo:Organization} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\newline {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Locatable \ref{pimo:Locatable} p. \pageref{pimo:Locatable}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & {\it pimo:}hasOrganizationMember \ref{pimo:hasOrganizationMember} p. \pageref{pimo:hasOrganizationMember}\\ \hline -In range of: & {\it pimo:}isOrganizationMemberOf \ref{pimo:isOrganizationMemberOf} p. \pageref{pimo:isOrganizationMemberOf}\newline {\it pimo:}organization \ref{pimo:organization} p. \pageref{pimo:organization}\\ \hline -Description & An administrative and functional structure (as a business or a political party). (Definition from Merriam-Webster)\\ \hline -\end{longtable} - - -\subsubsection{OrganizationMember} -\label{pimo:OrganizationMember} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}Association \ref{pimo:Association} p. \pageref{pimo:Association}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}PersonRole \ref{pimo:PersonRole} p. \pageref{pimo:PersonRole}\newline {\it rdfs:}Resource\\ \hline -Subclasses & --\\ \hline -In domain of: & {\it pimo:}organization \ref{pimo:organization} p. \pageref{pimo:organization}\\ \hline -In range of: & --\\ \hline -Description & The role of one or multiple persons being a member in one or multiple organizations. Use pimo:organization and pimo:roleHolder to link to the organizations and persons.\\ \hline -\end{longtable} - - -\subsubsection{Person} -\label{pimo:Person} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\newline {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Locatable \ref{pimo:Locatable} p. \pageref{pimo:Locatable}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & {\it pimo:}attends \ref{pimo:attends} p. \pageref{pimo:attends}\newline {\it pimo:}jabberId \ref{pimo:jabberId} p. \pageref{pimo:jabberId}\\ \hline -In range of: & {\it pimo:}attendee \ref{pimo:attendee} p. \pageref{pimo:attendee}\newline {\it pimo:}roleHolder \ref{pimo:roleHolder} p. \pageref{pimo:roleHolder}\\ \hline -Description & Represents a person. Either living, dead, real or imaginary. (Definition from foaf:Person)\\ \hline -\end{longtable} - - -\subsubsection{PersonGroup} -\label{pimo:PersonGroup} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\newline {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Collection \ref{pimo:Collection} p. \pageref{pimo:Collection}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & A group of Persons. They are connected to each other by sharing a common attribute, for example they all belong to the same organization or have a common interest. Refer to pimo:Collection for more information about defining collections.\\ \hline -\end{longtable} - - -\subsubsection{PersonRole} -\label{pimo:PersonRole} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}Association \ref{pimo:Association} p. \pageref{pimo:Association}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\\ \hline -Subclasses & {\it pimo:}Attendee \ref{pimo:Attendee} p. \pageref{pimo:Attendee}\newline {\it pimo:}OrganizationMember \ref{pimo:OrganizationMember} p. \pageref{pimo:OrganizationMember}\\ \hline -In domain of: & {\it pimo:}roleContext \ref{pimo:roleContext} p. \pageref{pimo:roleContext}\newline {\it pimo:}roleHolder \ref{pimo:roleHolder} p. \pageref{pimo:roleHolder}\\ \hline -In range of: & --\\ \hline -Description & A person takes a certain role in a given context. The role can be that of "a mentor or another person" or "giving a talk at a meeting", etc.\\ \hline -\end{longtable} - - -\subsubsection{PersonalInformationModel} -\label{pimo:PersonalInformationModel} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it nrl:}Data\newline {\it nrl:}Graph\newline {\it nrl:}InstanceBase\newline {\it nrl:}KnowledgeBase\newline {\it nrl:}Ontology\newline {\it rdfs:}Resource\newline {\it nrl:}Schema\\ \hline -Subclasses & --\\ \hline -In domain of: & {\it pimo:}creator \ref{pimo:creator} p. \pageref{pimo:creator}\\ \hline -In range of: & {\it pimo:}createdPimo \ref{pimo:createdPimo} p. \pageref{pimo:createdPimo}\newline {\it pimo:}isDefinedBy \ref{pimo:isDefinedBy} p. \pageref{pimo:isDefinedBy}\\ \hline -Description & A Personal Information Model (PIMO) of a user. Represents the sum of all information from the personal knowledge workspace (in literature also referred to as Personal Space of Information (PSI)) which a user needs for Personal Information Management (PIM).\\ \hline -\end{longtable} - - -\subsubsection{ProcessConcept} -\label{pimo:ProcessConcept} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & {\it pimo:}Event \ref{pimo:Event} p. \pageref{pimo:Event}\newline {\it pimo:}Meeting \ref{pimo:Meeting} p. \pageref{pimo:Meeting}\newline {\it pimo:}Project \ref{pimo:Project} p. \pageref{pimo:Project}\newline {\it pimo:}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\newline {\it pimo:}Task \ref{pimo:Task} p. \pageref{pimo:Task}\\ \hline -In domain of: & {\it pimo:}dtend \ref{pimo:dtend} p. \pageref{pimo:dtend}\newline {\it pimo:}dtstart \ref{pimo:dtstart} p. \pageref{pimo:dtstart}\\ \hline -In range of: & --\\ \hline -Description & Concepts that relate to a series of actions or operations conducing to an end. Abstract class. Defines optional start and endtime properties, names taken from NCAL.\\ \hline -\end{longtable} - - -\subsubsection{Project} -\label{pimo:Project} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & Any piece of work that is undertaken or attempted (Wordnet). An enterprise carefully planned to achieve a particular aim (Oxford Dictionary).\\ \hline -\end{longtable} - - -\subsubsection{Room} -\label{pimo:Room} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Location \ref{pimo:Location} p. \pageref{pimo:Location}\newline {\it rdfs:}Resource\newline {\it geo:}SpatialThing\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & A properPart of a Building which is separated from the exterior of the Building and/or other Rooms of the Building by walls. Some Rooms may have a specific purpose, e.g. sleeping, bathing, cooking, entertainment, etc. (Definition from SUMO).\\ \hline -\end{longtable} - - -\subsubsection{SocialEvent} -\label{pimo:SocialEvent} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Event \ref{pimo:Event} p. \pageref{pimo:Event}\newline {\it pimo:}Locatable \ref{pimo:Locatable} p. \pageref{pimo:Locatable}\newline {\it pimo:}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & {\it pimo:}Meeting \ref{pimo:Meeting} p. \pageref{pimo:Meeting}\\ \hline -In domain of: & {\it pimo:}attendee \ref{pimo:attendee} p. \pageref{pimo:attendee}\newline {\it pimo:}duration \ref{pimo:duration} p. \pageref{pimo:duration}\\ \hline -In range of: & {\it pimo:}attendingMeeting \ref{pimo:attendingMeeting} p. \pageref{pimo:attendingMeeting}\newline {\it pimo:}attends \ref{pimo:attends} p. \pageref{pimo:attends}\\ \hline -Description & A social occasion or activity. (Definition from Merriam-Webster)\\ \hline -\end{longtable} - - -\subsubsection{State} -\label{pimo:State} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}Location \ref{pimo:Location} p. \pageref{pimo:Location}\newline {\it rdfs:}Resource\newline {\it geo:}SpatialThing\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & --\\ \hline -In range of: & --\\ \hline -Description & Administrative subdivisions of a Nation that are broader than any other political subdivisions that may exist. This Class includes the states of the United States, as well as the provinces of Canada and European countries. (Definition from SUMO).\\ \hline -\end{longtable} - - -\subsubsection{Task} -\label{pimo:Task} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it pimo:}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & {\it pimo:}taskDueTime \ref{pimo:taskDueTime} p. \pageref{pimo:taskDueTime}\\ \hline -In range of: & --\\ \hline -Description & A (usually assigned) piece of work (often to be finished within a certain time). (Definition from Merriam-Webster)\\ \hline -\end{longtable} - - -\subsubsection{Thing} -\label{pimo:Thing} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\\ \hline -Subclasses & {\it pimo:}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\newline {\it pimo:}BlogPost \ref{pimo:BlogPost} p. \pageref{pimo:BlogPost}\newline {\it pimo:}Building \ref{pimo:Building} p. \pageref{pimo:Building}\newline {\it pimo:}City \ref{pimo:City} p. \pageref{pimo:City}\newline {\it pimo:}Collection \ref{pimo:Collection} p. \pageref{pimo:Collection}\newline {\it pimo:}Contract \ref{pimo:Contract} p. \pageref{pimo:Contract}\newline {\it pimo:}Country \ref{pimo:Country} p. \pageref{pimo:Country}\newline {\it pimo:}Document \ref{pimo:Document} p. \pageref{pimo:Document}\newline {\it pimo:}Event \ref{pimo:Event} p. \pageref{pimo:Event}\newline {\it pimo:}Locatable \ref{pimo:Locatable} p. \pageref{pimo:Locatable}\newline {\it pimo:}Location \ref{pimo:Location} p. \pageref{pimo:Location}\newline {\it pimo:}LogicalMediaType \ref{pimo:LogicalMediaType} p. \pageref{pimo:LogicalMediaType}\newline {\it pimo:}Meeting \ref{pimo:Meeting} p. \pageref{pimo:Meeting}\newline {\it pimo:}Note \ref{pimo:Note} p. \pageref{pimo:Note}\newline {\it pimo:}Organization \ref{pimo:Organization} p. \pageref{pimo:Organization}\newline {\it pimo:}Person \ref{pimo:Person} p. \pageref{pimo:Person}\newline {\it pimo:}PersonGroup \ref{pimo:PersonGroup} p. \pageref{pimo:PersonGroup}\newline {\it pimo:}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\newline {\it pimo:}Project \ref{pimo:Project} p. \pageref{pimo:Project}\newline {\it pimo:}Room \ref{pimo:Room} p. \pageref{pimo:Room}\newline {\it pimo:}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\newline {\it pimo:}State \ref{pimo:State} p. \pageref{pimo:State}\newline {\it pimo:}Task \ref{pimo:Task} p. \pageref{pimo:Task}\newline {\it pimo:}Topic \ref{pimo:Topic} p. \pageref{pimo:Topic}\\ \hline -In domain of: & {\it pimo:}datatypeProperty \ref{pimo:datatypeProperty} p. \pageref{pimo:datatypeProperty}\newline {\it pimo:}groundingOccurrence \ref{pimo:groundingOccurrence} p. \pageref{pimo:groundingOccurrence}\newline {\it pimo:}hasDeprecatedRepresentation \ref{pimo:hasDeprecatedRepresentation} p. \pageref{pimo:hasDeprecatedRepresentation}\newline {\it pimo:}hasOtherRepresentation \ref{pimo:hasOtherRepresentation} p. \pageref{pimo:hasOtherRepresentation}\newline {\it pimo:}hasPart \ref{pimo:hasPart} p. \pageref{pimo:hasPart}\newline {\it pimo:}hasTopic \ref{pimo:hasTopic} p. \pageref{pimo:hasTopic}\newline {\it pimo:}isRelated \ref{pimo:isRelated} p. \pageref{pimo:isRelated}\newline {\it pimo:}isTopicOf \ref{pimo:isTopicOf} p. \pageref{pimo:isTopicOf}\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\newline {\it pimo:}occurrence \ref{pimo:occurrence} p. \pageref{pimo:occurrence}\newline {\it pimo:}partOf \ref{pimo:partOf} p. \pageref{pimo:partOf}\newline {\it pimo:}referencingOccurrence \ref{pimo:referencingOccurrence} p. \pageref{pimo:referencingOccurrence}\\ \hline -In range of: & {\it pimo:}associationMember \ref{pimo:associationMember} p. \pageref{pimo:associationMember}\newline {\it pimo:}hasPart \ref{pimo:hasPart} p. \pageref{pimo:hasPart}\newline {\it pimo:}hasTopic \ref{pimo:hasTopic} p. \pageref{pimo:hasTopic}\newline {\it pimo:}isLocationOf \ref{pimo:isLocationOf} p. \pageref{pimo:isLocationOf}\newline {\it pimo:}isRelated \ref{pimo:isRelated} p. \pageref{pimo:isRelated}\newline {\it pimo:}isTopicOf \ref{pimo:isTopicOf} p. \pageref{pimo:isTopicOf}\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\newline {\it pimo:}partOf \ref{pimo:partOf} p. \pageref{pimo:partOf}\newline {\it pimo:}roleContext \ref{pimo:roleContext} p. \pageref{pimo:roleContext}\\ \hline -Description & Entities that are in the direct attention of the user when doing knowledge work.\\ \hline -\end{longtable} - - -\subsubsection{Topic} -\label{pimo:Topic} - -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Superclasses & {\it pimo:}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\newline {\it pimo:}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\newline {\it rdfs:}Resource\newline {\it pimo:}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Subclasses & --\\ \hline -In domain of: & {\it pimo:}subTopic \ref{pimo:subTopic} p. \pageref{pimo:subTopic}\newline {\it pimo:}superTopic \ref{pimo:superTopic} p. \pageref{pimo:superTopic}\\ \hline -In range of: & {\it pimo:}subTopic \ref{pimo:subTopic} p. \pageref{pimo:subTopic}\newline {\it pimo:}superTopic \ref{pimo:superTopic} p. \pageref{pimo:superTopic}\\ \hline -Description & A topic is the subject of a discussion or document. Topics are distinguished from Things in their taxonomic nature, examples are scientific areas such as "Information Science", "Biology", or categories used in content syndication such as "Sports", "Politics". They are specific to the user's domain.\\ \hline -\end{longtable} - - -\subsection{Ontology Properties Description} - -\subsubsection{associationEffectual} -\label{pimo:associationEffectual} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Association \ref{pimo:Association} p. \pageref{pimo:Association}\\ \hline -Range & {\it rdfs}\hspace{1pt}Resource\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & During which time is this association effective? If omitted, the association is always effective. Start time and end-time may be left open, an open start time indicates that the fact is unknown, an open end-time indicates that the end-date is either unknown or the association has not ended. -There can be multiple effectual periods.\\ \hline -\end{longtable} - - -\subsubsection{associationMember} -\label{pimo:associationMember} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Association \ref{pimo:Association} p. \pageref{pimo:Association}\\ \hline -Range & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Superproperties & --\\ \hline -Subproperties & {\it pimo:}attendingMeeting \ref{pimo:attendingMeeting} p. \pageref{pimo:attendingMeeting}\newline {\it pimo:}organization \ref{pimo:organization} p. \pageref{pimo:organization}\newline {\it pimo:}roleContext \ref{pimo:roleContext} p. \pageref{pimo:roleContext}\newline {\it pimo:}roleHolder \ref{pimo:roleHolder} p. \pageref{pimo:roleHolder}\\ \hline -Description & An super-property of all roles that an entity can have in an association. Member is the generic role of a thing in an association. Association subclasses should define sub-properties of this property. Associations can have Things as\\ \hline -\end{longtable} - - -\subsubsection{attendee} -\label{pimo:attendee} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\\ \hline -Range & {\it pimo}\hspace{1pt}Person \ref{pimo:Person} p. \pageref{pimo:Person}\\ \hline -Superproperties & {\it nao:}annotation\newline {\it nao:}isRelated\newline {\it pimo:}isRelated \ref{pimo:isRelated} p. \pageref{pimo:isRelated}\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & --\\ \hline -Description & A social event is attended by a person.\\ \hline -\end{longtable} - - -\subsubsection{attendingMeeting} -\label{pimo:attendingMeeting} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Attendee \ref{pimo:Attendee} p. \pageref{pimo:Attendee}\\ \hline -Range & {\it pimo}\hspace{1pt}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\\ \hline -Superproperties & {\it pimo:}associationMember \ref{pimo:associationMember} p. \pageref{pimo:associationMember}\newline {\it pimo:}roleContext \ref{pimo:roleContext} p. \pageref{pimo:roleContext}\\ \hline -Subproperties & --\\ \hline -Description & the attended meeting\\ \hline -\end{longtable} - - -\subsubsection{attends} -\label{pimo:attends} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Person \ref{pimo:Person} p. \pageref{pimo:Person}\\ \hline -Range & {\it pimo}\hspace{1pt}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\\ \hline -Superproperties & {\it nao:}annotation\newline {\it nao:}isRelated\newline {\it pimo:}isRelated \ref{pimo:isRelated} p. \pageref{pimo:isRelated}\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & --\\ \hline -Description & A person attends a social event.\\ \hline -\end{longtable} - - -\subsubsection{broader} -\label{pimo:broader} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & \\ \hline -Range & \\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & \\ \hline -\end{longtable} - - -\subsubsection{classRole} -\label{pimo:classRole} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & \\ \hline -Range & {\it pimo}\hspace{1pt}ClassRole \ref{pimo:ClassRole} p. \pageref{pimo:ClassRole}\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & Annotating abstract and concrete classes. Implementations may offer the feature to hide abstract classes. By default, classes are concrete. Classes can be declared abstract by setting their classRole to abstract. Instances should not have an abstract class as type (if not inferred).\\ \hline -\end{longtable} - - -\subsubsection{containsLocation} -\label{pimo:containsLocation} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Location \ref{pimo:Location} p. \pageref{pimo:Location}\\ \hline -Range & {\it pimo}\hspace{1pt}Location \ref{pimo:Location} p. \pageref{pimo:Location}\\ \hline -Superproperties & {\it pimo:}hasPart \ref{pimo:hasPart} p. \pageref{pimo:hasPart}\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & --\\ \hline -Description & The subject location contains the object location. For example, a building contains a room or a country contains a city.\\ \hline -\end{longtable} - - -\subsubsection{createdPimo} -\label{pimo:createdPimo} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\\ \hline -Range & {\it pimo}\hspace{1pt}PersonalInformationModel \ref{pimo:PersonalInformationModel} p. \pageref{pimo:PersonalInformationModel}\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & The creator of the Personal Information Model. The human being whose mental models are represented in the PIMO.\\ \hline -\end{longtable} - - -\subsubsection{creator} -\label{pimo:creator} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}PersonalInformationModel \ref{pimo:PersonalInformationModel} p. \pageref{pimo:PersonalInformationModel}\\ \hline -Range & {\it pimo}\hspace{1pt}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\\ \hline -Superproperties & {\it nao:}annotation\newline {\it x:}creator\newline {\it nao:}creator\\ \hline -Subproperties & --\\ \hline -Description & The creator of the Personal Information Model. A subproperty of NAO:creator. The human being whose mental models are represented in the PIMO. Range is an Agent.\\ \hline -\end{longtable} - - -\subsubsection{datatypeProperty} -\label{pimo:datatypeProperty} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & \\ \hline -Superproperties & --\\ \hline -Subproperties & {\it geo:}alt\newline {\it pimo:}dtend \ref{pimo:dtend} p. \pageref{pimo:dtend}\newline {\it pimo:}dtstart \ref{pimo:dtstart} p. \pageref{pimo:dtstart}\newline {\it pimo:}duration \ref{pimo:duration} p. \pageref{pimo:duration}\newline {\it geo:}lat\newline {\it geo:}long\newline {\it pimo:}taskDueTime \ref{pimo:taskDueTime} p. \pageref{pimo:taskDueTime}\\ \hline -Description & The object of statements is a literal, resource, or datatype value describing the subject thing. Users should be able to edit statements defined with this property. Abstract super-property.\\ \hline -\end{longtable} - - -\subsubsection{dtend} -\label{pimo:dtend} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\\ \hline -Range & {\it xsd}\hspace{1pt}dateTime\\ \hline -Superproperties & {\it pimo:}datatypeProperty \ref{pimo:datatypeProperty} p. \pageref{pimo:datatypeProperty}\\ \hline -Subproperties & --\\ \hline -Description & This property specifies the date and time when a process ends. Inspired by NCAL:dtend.\\ \hline -\end{longtable} - - -\subsubsection{dtstart} -\label{pimo:dtstart} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}ProcessConcept \ref{pimo:ProcessConcept} p. \pageref{pimo:ProcessConcept}\\ \hline -Range & {\it xsd}\hspace{1pt}dateTime\\ \hline -Superproperties & {\it pimo:}datatypeProperty \ref{pimo:datatypeProperty} p. \pageref{pimo:datatypeProperty}\\ \hline -Subproperties & --\\ \hline -Description & This property specifies when the process begins. Inspired by NCAL:dtstart.\\ \hline -\end{longtable} - - -\subsubsection{duration} -\label{pimo:duration} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}SocialEvent \ref{pimo:SocialEvent} p. \pageref{pimo:SocialEvent}\\ \hline -Range & {\it rdfs}\hspace{1pt}Resource\\ \hline -Superproperties & {\it pimo:}datatypeProperty \ref{pimo:datatypeProperty} p. \pageref{pimo:datatypeProperty}\\ \hline -Subproperties & --\\ \hline -Description & The duration of the meeting. Begin and end time.\\ \hline -\end{longtable} - - -\subsubsection{groundingForDeletedThing} -\label{pimo:groundingForDeletedThing} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & \\ \hline -Range & {\it rdfs}\hspace{1pt}Resource\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & This NIE Information Element was used as a grounding occurrence for the object Thing. The Thing was then deleted by the user manually, indicating that this Information Element should not cause an automatic creation of another Thing in the future. The object resource has no range to indicate that it was completely removed from the user's PIMO, including the rdf:type statement. Relevant for data alignment and enrichment algorithms.\\ \hline -\end{longtable} - - -\subsubsection{groundingOccurrence} -\label{pimo:groundingOccurrence} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it nie}\hspace{1pt}InformationElement \ref{nie:InformationElement} p. \pageref{nie:InformationElement}\\ \hline -Superproperties & {\it pimo:}occurrence \ref{pimo:occurrence} p. \pageref{pimo:occurrence}\\ \hline -Subproperties & --\\ \hline -Description & The subject Thing represents the entity that is described in the object InformationElement. The subject Thing is the canonical, unique representation in the personal information model for the entity described in the object. Multiple InformationElements can be the grounding occurrence of the same Thing, one InformationElement can be the groundingOccurrence of only one Thing.\\ \hline -\end{longtable} - - -\subsubsection{hasDeprecatedRepresentation} -\label{pimo:hasDeprecatedRepresentation} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it rdfs}\hspace{1pt}Resource\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & The subject Thing was represented previously using the object resource. This indicates that the object resource was a duplicate representation of the subject and merged with the subject. Implementations can use this property to resolve dangling links in distributed system. When encountering resources that are deprecated representations of a Thing, they should be replaced with the Thing. The range is not declared as we assume all knowledge about the object is gone, including its rdf:type.\\ \hline -\end{longtable} - - -\subsubsection{hasFolder} -\label{pimo:hasFolder} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\\ \hline -Range & {\it nfo}\hspace{1pt}Folder \ref{nfo:Folder} p. \pageref{nfo:Folder}\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & Folders can be used to store information elements related to a Thing or Class. This property can be used to connect a Class or Thing to existing Folders. Implementations can suggest annotations for documents stored inside these folders or suggest the folder for new documents related to the Thing or Class.\\ \hline -\end{longtable} - - -\subsubsection{hasLocation} -\label{pimo:hasLocation} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Locatable \ref{pimo:Locatable} p. \pageref{pimo:Locatable}\\ \hline -Range & {\it pimo}\hspace{1pt}Location \ref{pimo:Location} p. \pageref{pimo:Location}\\ \hline -Superproperties & {\it nao:}annotation\newline {\it nao:}isRelated\newline {\it pimo:}isRelated \ref{pimo:isRelated} p. \pageref{pimo:isRelated}\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & --\\ \hline -Description & The subject thing is currently located at the object location.\\ \hline -\end{longtable} - - -\subsubsection{hasOrganizationMember} -\label{pimo:hasOrganizationMember} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Organization \ref{pimo:Organization} p. \pageref{pimo:Organization}\\ \hline -Range & {\it pimo}\hspace{1pt}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\\ \hline -Superproperties & {\it pimo:}hasPart \ref{pimo:hasPart} p. \pageref{pimo:hasPart}\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & --\\ \hline -Description & The subject organization has the object person or organization (Agent) as a member.\\ \hline -\end{longtable} - - -\subsubsection{hasOtherConceptualization} -\label{pimo:hasOtherConceptualization} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it rdfs}\hspace{1pt}Class\\ \hline -Range & {\it rdfs}\hspace{1pt}Class\\ \hline -Superproperties & {\it pimo:}occurrence \ref{pimo:occurrence} p. \pageref{pimo:occurrence}\newline {\it rdfs:}subClassOf\\ \hline -Subproperties & --\\ \hline -Description & Short: hasOtherRepresentation points from a Class in your PIMO to a class in a domain ontology that represents the same class. Longer: hasOtherConceptualization means that a class of real world objects O represented by a concept C1 in the ontology has additional conceptualizations (as classes C2-Cn in different domain ontologies). -This means: IF (O\_i is conceptialized by C\_j in Ontology\_k) AND (O\_l is conceptialized by C\_m in Ontology\_n) THEN (O\_i and O\_l is the same set of objects). -hasOtherConceptualization is an transitive relation, but not equivalent (not symmetric nor reflexive).\\ \hline -\end{longtable} - - -\subsubsection{hasOtherRepresentation} -\label{pimo:hasOtherRepresentation} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it rdfs}\hspace{1pt}Resource\\ \hline -Superproperties & {\it pimo:}occurrence \ref{pimo:occurrence} p. \pageref{pimo:occurrence}\\ \hline -Subproperties & --\\ \hline -Description & hasOtherRepresentation points from a Thing in your PIMO to a thing in an ontology that represents the same real world thing. -This means that the real world object O represented by an instance I1 has additional representations (as instances I2-In of different conceptualizations). -This means: IF (I\_i represents O\_j in Ontology\_k) AND (I\_m represents O\_n in Ontology\_o) THEN (O\_n and O\_j are the same object). -hasOtherRepresentation is a transitive relation, but not equivalent (not symmetric nor reflexive). - -For example, the URI of a foaf:Person representation published on the web is a hasOtherRepresentation for the person. This property is inverse functional, two Things from two information models having the same hasOtherRepresentation are considered to be representations of the same entity from the real world. - -TODO: rename this to subjectIndicatorRef to resemble topic maps ideas?\\ \hline -\end{longtable} - - -\subsubsection{hasOtherSlot} -\label{pimo:hasOtherSlot} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it rdf}\hspace{1pt}Property\\ \hline -Range & {\it rdf}\hspace{1pt}Property\\ \hline -Superproperties & {\it rdfs:}subPropertyOf\\ \hline -Subproperties & --\\ \hline -Description & hasOtherSlot points from a clot in your PIMO to a slot in a domain ontology that represents the same connection idea.\\ \hline -\end{longtable} - - -\subsubsection{hasPart} -\label{pimo:hasPart} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Superproperties & {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & {\it pimo:}containsLocation \ref{pimo:containsLocation} p. \pageref{pimo:containsLocation}\newline {\it pimo:}hasOrganizationMember \ref{pimo:hasOrganizationMember} p. \pageref{pimo:hasOrganizationMember}\newline {\it pimo:}subTopic \ref{pimo:subTopic} p. \pageref{pimo:subTopic}\\ \hline -Description & The object is part of the subject. Like a page is part of a book or an engine is part of a car. You can make sub-properties of this to reflect more detailed relations.\\ \hline -\end{longtable} - - -\subsubsection{hasTopic} -\label{pimo:hasTopic} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Superproperties & {\it nao:}annotation\newline {\it nao:}hasTopic\newline {\it nao:}isRelated\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & --\\ \hline -Description & The subject's contents describes the object. Or the subject can be seen as belonging to the topic described by the object. Similar semantics as skos:subject.\\ \hline -\end{longtable} - - -\subsubsection{isDefinedBy} -\label{pimo:isDefinedBy} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}ClassOrThingOrPropertyOrAssociation \ref{pimo:ClassOrThingOrPropertyOrAssociation} p. \pageref{pimo:ClassOrThingOrPropertyOrAssociation}\\ \hline -Range & {\it pimo}\hspace{1pt}PersonalInformationModel \ref{pimo:PersonalInformationModel} p. \pageref{pimo:PersonalInformationModel}\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & Each element in a PIMO must be connected to the PIMO, to be able to track multiple PIMOs in a distributed scenario. Also, this is the way to find the user that this Thing belongs to.\\ \hline -\end{longtable} - - -\subsubsection{isLocationOf} -\label{pimo:isLocationOf} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Location \ref{pimo:Location} p. \pageref{pimo:Location}\\ \hline -Range & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Superproperties & {\it nao:}annotation\newline {\it nao:}isRelated\newline {\it pimo:}isRelated \ref{pimo:isRelated} p. \pageref{pimo:isRelated}\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & --\\ \hline -Description & The subject location is the current location of the object.\\ \hline -\end{longtable} - - -\subsubsection{isOrganizationMemberOf} -\label{pimo:isOrganizationMemberOf} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Agent \ref{pimo:Agent} p. \pageref{pimo:Agent}\\ \hline -Range & {\it pimo}\hspace{1pt}Organization \ref{pimo:Organization} p. \pageref{pimo:Organization}\\ \hline -Superproperties & {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\newline {\it pimo:}partOf \ref{pimo:partOf} p. \pageref{pimo:partOf}\\ \hline -Subproperties & --\\ \hline -Description & The subject person or organozation (Agent) is member of the object organization.\\ \hline -\end{longtable} - - -\subsubsection{isRelated} -\label{pimo:isRelated} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Superproperties & {\it nao:}annotation\newline {\it nao:}isRelated\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & {\it pimo:}attendee \ref{pimo:attendee} p. \pageref{pimo:attendee}\newline {\it pimo:}attends \ref{pimo:attends} p. \pageref{pimo:attends}\newline {\it pimo:}hasLocation \ref{pimo:hasLocation} p. \pageref{pimo:hasLocation}\newline {\it pimo:}isLocationOf \ref{pimo:isLocationOf} p. \pageref{pimo:isLocationOf}\\ \hline -Description & The thing is related to the other thing. Similar in meaning to skos:related. Symmetric but not transitive.\\ \hline -\end{longtable} - - -\subsubsection{isTopicOf} -\label{pimo:isTopicOf} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Superproperties & {\it nao:}annotation\newline {\it nao:}isRelated\newline {\it nao:}isTopicOf\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & --\\ \hline -Description & This thing is described further in the object thing. Similar semantics as skos:isSubjectOf.\\ \hline -\end{longtable} - - -\subsubsection{isWriteable} -\label{pimo:isWriteable} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & \\ \hline -Range & {\it rdfs}\hspace{1pt}Literal\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & Defines if this information model can be modified by the user of the system. This is usually false for imported ontologies and true for the user's own PersonalInformationModel.\\ \hline -\end{longtable} - - -\subsubsection{jabberId} -\label{pimo:jabberId} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Person \ref{pimo:Person} p. \pageref{pimo:Person}\\ \hline -Range & {\it rdfs}\hspace{1pt}Literal\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & Jabber-ID of the user. Used to communicate amongst peers in the social scenario of the semantic desktop. Use the xmpp node identifier as specified by RFC3920, see http://www.xmpp.org/specs/rfc3920.html\#addressing-node. The format is the same as e-mail addresses: username@hostname.\\ \hline -\end{longtable} - - -\subsubsection{locatedWithin} -\label{pimo:locatedWithin} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Location \ref{pimo:Location} p. \pageref{pimo:Location}\\ \hline -Range & {\it pimo}\hspace{1pt}Location \ref{pimo:Location} p. \pageref{pimo:Location}\\ \hline -Superproperties & {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\newline {\it pimo:}partOf \ref{pimo:partOf} p. \pageref{pimo:partOf}\\ \hline -Subproperties & --\\ \hline -Description & The subject location is contained within the object location. For example, a room is located within a building or a city is located within a country.\\ \hline -\end{longtable} - - -\subsubsection{narrower} -\label{pimo:narrower} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & \\ \hline -Range & \\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & \\ \hline -\end{longtable} - - -\subsubsection{objectProperty} -\label{pimo:objectProperty} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Superproperties & --\\ \hline -Subproperties & {\it pimo:}attendee \ref{pimo:attendee} p. \pageref{pimo:attendee}\newline {\it pimo:}attends \ref{pimo:attends} p. \pageref{pimo:attends}\newline {\it pimo:}containsLocation \ref{pimo:containsLocation} p. \pageref{pimo:containsLocation}\newline {\it pimo:}hasLocation \ref{pimo:hasLocation} p. \pageref{pimo:hasLocation}\newline {\it pimo:}hasOrganizationMember \ref{pimo:hasOrganizationMember} p. \pageref{pimo:hasOrganizationMember}\newline {\it pimo:}hasPart \ref{pimo:hasPart} p. \pageref{pimo:hasPart}\newline {\it pimo:}hasTopic \ref{pimo:hasTopic} p. \pageref{pimo:hasTopic}\newline {\it pimo:}isLocationOf \ref{pimo:isLocationOf} p. \pageref{pimo:isLocationOf}\newline {\it pimo:}isOrganizationMemberOf \ref{pimo:isOrganizationMemberOf} p. \pageref{pimo:isOrganizationMemberOf}\newline {\it pimo:}isRelated \ref{pimo:isRelated} p. \pageref{pimo:isRelated}\newline {\it pimo:}isTopicOf \ref{pimo:isTopicOf} p. \pageref{pimo:isTopicOf}\newline {\it pimo:}locatedWithin \ref{pimo:locatedWithin} p. \pageref{pimo:locatedWithin}\newline {\it pimo:}partOf \ref{pimo:partOf} p. \pageref{pimo:partOf}\newline {\it pimo:}subTopic \ref{pimo:subTopic} p. \pageref{pimo:subTopic}\newline {\it pimo:}superTopic \ref{pimo:superTopic} p. \pageref{pimo:superTopic}\\ \hline -Description & The object of statements is another Thing. Users should be able to edit statements defined with this property. Abstract super-property.\\ \hline -\end{longtable} - - -\subsubsection{occurrence} -\label{pimo:occurrence} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it rdfs}\hspace{1pt}Resource\\ \hline -Superproperties & --\\ \hline -Subproperties & {\it pimo:}groundingOccurrence \ref{pimo:groundingOccurrence} p. \pageref{pimo:groundingOccurrence}\newline {\it pimo:}hasOtherConceptualization \ref{pimo:hasOtherConceptualization} p. \pageref{pimo:hasOtherConceptualization}\newline {\it pimo:}hasOtherRepresentation \ref{pimo:hasOtherRepresentation} p. \pageref{pimo:hasOtherRepresentation}\\ \hline -Description & The subject Thing is represented also in the object resource. All facts added to the object resource are valid for the subject thing. The subject is the canonical represtation of the object. In particual, this implies when (?object ?p ?v) -> (?subject ?p ?v) and (?s ?p ?object) -> (?s ?p ?subject). The class of the object is not defined, but should be compatible with the class of the subject. Occurrence relations can be inferred through same identifiers or referencingOccurrence relations.\\ \hline -\end{longtable} - - -\subsubsection{organization} -\label{pimo:organization} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}OrganizationMember \ref{pimo:OrganizationMember} p. \pageref{pimo:OrganizationMember}\\ \hline -Range & {\it pimo}\hspace{1pt}Organization \ref{pimo:Organization} p. \pageref{pimo:Organization}\\ \hline -Superproperties & {\it pimo:}associationMember \ref{pimo:associationMember} p. \pageref{pimo:associationMember}\\ \hline -Subproperties & --\\ \hline -Description & relation to the organization in an OrganizationMember association.\\ \hline -\end{longtable} - - -\subsubsection{partOf} -\label{pimo:partOf} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Superproperties & {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & {\it pimo:}isOrganizationMemberOf \ref{pimo:isOrganizationMemberOf} p. \pageref{pimo:isOrganizationMemberOf}\newline {\it pimo:}locatedWithin \ref{pimo:locatedWithin} p. \pageref{pimo:locatedWithin}\newline {\it pimo:}superTopic \ref{pimo:superTopic} p. \pageref{pimo:superTopic}\\ \hline -Description & This is part of the object. Like a page is part of a book or an engine is part of a car. You can make sub-properties of this to reflect more detailed relations.\\ \hline -\end{longtable} - - -\subsubsection{referencingOccurrence} -\label{pimo:referencingOccurrence} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Range & {\it nie}\hspace{1pt}InformationElement \ref{nie:InformationElement} p. \pageref{nie:InformationElement}\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & The subject thing is described in the object document. Ideally, the document is public and its primary topic is the thing. Although this property is not inverse-functional (because the Occurrences are not canonical elements of a formal ontology) this property allows to use public documents, such as wikipedia pages, as indicators identity. The more formal hasOtherRepresentation property can be used when an ontology about the subject exists.\\ \hline -\end{longtable} - - -\subsubsection{roleContext} -\label{pimo:roleContext} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}PersonRole \ref{pimo:PersonRole} p. \pageref{pimo:PersonRole}\\ \hline -Range & {\it pimo}\hspace{1pt}Thing \ref{pimo:Thing} p. \pageref{pimo:Thing}\\ \hline -Superproperties & {\it pimo:}associationMember \ref{pimo:associationMember} p. \pageref{pimo:associationMember}\\ \hline -Subproperties & {\it pimo:}attendingMeeting \ref{pimo:attendingMeeting} p. \pageref{pimo:attendingMeeting}\\ \hline -Description & The context where the role-holder impersonates this role. For example, the company where a person is employed.\\ \hline -\end{longtable} - - -\subsubsection{roleHolder} -\label{pimo:roleHolder} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}PersonRole \ref{pimo:PersonRole} p. \pageref{pimo:PersonRole}\\ \hline -Range & {\it pimo}\hspace{1pt}Person \ref{pimo:Person} p. \pageref{pimo:Person}\\ \hline -Superproperties & {\it pimo:}associationMember \ref{pimo:associationMember} p. \pageref{pimo:associationMember}\\ \hline -Subproperties & --\\ \hline -Description & the person taking the role\\ \hline -\end{longtable} - - -\subsubsection{subTopic} -\label{pimo:subTopic} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Topic \ref{pimo:Topic} p. \pageref{pimo:Topic}\\ \hline -Range & {\it pimo}\hspace{1pt}Topic \ref{pimo:Topic} p. \pageref{pimo:Topic}\\ \hline -Superproperties & {\it pimo:}hasPart \ref{pimo:hasPart} p. \pageref{pimo:hasPart}\newline {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\\ \hline -Subproperties & --\\ \hline -Description & The object topic is more specific in meaning than the subject topic. Transitive. Similar in meaning to skos:narrower\\ \hline -\end{longtable} - - -\subsubsection{superTopic} -\label{pimo:superTopic} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Topic \ref{pimo:Topic} p. \pageref{pimo:Topic}\\ \hline -Range & {\it pimo}\hspace{1pt}Topic \ref{pimo:Topic} p. \pageref{pimo:Topic}\\ \hline -Superproperties & {\it pimo:}objectProperty \ref{pimo:objectProperty} p. \pageref{pimo:objectProperty}\newline {\it pimo:}partOf \ref{pimo:partOf} p. \pageref{pimo:partOf}\\ \hline -Subproperties & --\\ \hline -Description & The object topic is more general in meaning than the subject topic. Transitive. Similar to skos:broader.\\ \hline -\end{longtable} - - -\subsubsection{taskDueTime} -\label{pimo:taskDueTime} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}Task \ref{pimo:Task} p. \pageref{pimo:Task}\\ \hline -Range & {\it xsd}\hspace{1pt}dateTime\\ \hline -Superproperties & {\it pimo:}datatypeProperty \ref{pimo:datatypeProperty} p. \pageref{pimo:datatypeProperty}\\ \hline -Subproperties & --\\ \hline -Description & when is this task due? Represented in ISO 8601, example: 2003-11-22T17:00:00\\ \hline -\end{longtable} - - -\subsubsection{wikiText} -\label{pimo:wikiText} -\begin{longtable}{|p{0.30\textwidth}|p{0.62\textwidth}|} - \hline -Domain & {\it pimo}\hspace{1pt}ClassOrThing \ref{pimo:ClassOrThing} p. \pageref{pimo:ClassOrThing}\\ \hline -Range & {\it rdfs}\hspace{1pt}Literal\\ \hline -Superproperties & --\\ \hline -Subproperties & --\\ \hline -Description & A wiki-like free-text description of a Thing or a Class. The text can be formatted using a limited set of HTML elements and can contain links to other Things. The format is described in detail in the WIF specification (http://semanticweb.org/wiki/Wiki\_Interchange\_Format).\\ \hline -\end{longtable} - - - diff --git a/pimo/doc/handbook_latex/solvedissues.aux b/pimo/doc/handbook_latex/solvedissues.aux deleted file mode 100644 index 3e4ceef..0000000 --- a/pimo/doc/handbook_latex/solvedissues.aux +++ /dev/null @@ -1,56 +0,0 @@ -\relax
-\@writefile{toc}{\contentsline {section}{\numberline {C}Issues solved by Agreement}{41}{appendix.C}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.1}Relation between PIMO:Thing and NIE:InformationElement}{41}{subsection.C.1}}
-\@writefile{toc}{\contentsline {paragraph}{Background}{41}{section*.26}}
-\@writefile{toc}{\contentsline {paragraph}{Problem}{41}{section*.27}}
-\@writefile{toc}{\contentsline {paragraph}{Solution pimo:Thing rdfs:isSubClassOf nie:InformationElement}{41}{section*.28}}
-\@writefile{toc}{\contentsline {paragraph}{Solution nie:InformationElement rdfs:isSubClassOf pimo:Thing}{41}{section*.29}}
-\@writefile{toc}{\contentsline {paragraph}{Solution instances are then both pimo:Things and nie:InformationElements}{41}{section*.30}}
-\@writefile{toc}{\contentsline {paragraph}{Intermediate Status}{41}{section*.31}}
-\@writefile{toc}{\contentsline {paragraph}{Picked Solution}{41}{section*.32}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.2}object property, datatype property, annotation-property}{41}{subsection.C.2}}
-\@writefile{toc}{\contentsline {paragraph}{Proposed Solution:}{42}{section*.33}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.3}Abstract classes}{42}{subsection.C.3}}
-\@writefile{toc}{\contentsline {paragraph}{Proposed Solution:}{42}{section*.34}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.4}Abstract object}{43}{subsection.C.4}}
-\newlabel{issue:abstractobject}{{C.4}{43}{Abstract object\relax }{subsection.C.4}{}}
-\@writefile{toc}{\contentsline {paragraph}{Solution:}{43}{section*.35}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.5}Work Context / Multiple Domains (related to CDS?)}{43}{subsection.C.5}}
-\@writefile{toc}{\contentsline {paragraph}{Proposed Solution:}{43}{section*.36}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.6}Naming of properties: x vs hasX}{43}{subsection.C.6}}
-\@writefile{toc}{\contentsline {paragraph}{Proposed Solution:}{43}{section*.37}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.7}Incorporate Relations from AS}{44}{subsection.C.7}}
-\@writefile{toc}{\contentsline {paragraph}{Proposed Solution:}{44}{section*.38}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.8}Representation of Time}{44}{subsection.C.8}}
-\@writefile{toc}{\contentsline {paragraph}{Solution:}{44}{section*.39}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.9}Ludger, Michael, can't we drop hasOther* ?}{44}{subsection.C.9}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.10}How to connect a Thing to the user - what are the Things of the user?}{44}{subsection.C.10}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.11}hasOtherRepresentation, hasOtherConceptualization, hasOtherSlot}{45}{subsection.C.11}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.12}How do we relate to NAO?}{45}{subsection.C.12}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.13}Semantic Relations and inference, how to untie hasPart, Collections, and Topics.}{45}{subsection.C.13}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.14}Equivalence}{46}{subsection.C.14}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.15}pimo:user or pimo:isDefinedBy}{46}{subsection.C.15}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {C.16}What classes and instances appear in a user interface?}{46}{subsection.C.16}}
-\@setckpt{solvedissues}{
-\setcounter{page}{47}
-\setcounter{equation}{0}
-\setcounter{enumi}{2}
-\setcounter{enumii}{0}
-\setcounter{enumiii}{0}
-\setcounter{enumiv}{0}
-\setcounter{footnote}{29}
-\setcounter{mpfootnote}{0}
-\setcounter{part}{0}
-\setcounter{section}{3}
-\setcounter{subsection}{16}
-\setcounter{subsubsection}{0}
-\setcounter{paragraph}{0}
-\setcounter{subparagraph}{0}
-\setcounter{figure}{7}
-\setcounter{table}{1}
-\setcounter{Item}{2}
-\setcounter{Hfootnote}{29}
-\setcounter{LT@tables}{0}
-\setcounter{LT@chunks}{0}
-\setcounter{section@level}{1}
-}
diff --git a/pimo/doc/handbook_latex/solvedissues.tex b/pimo/doc/handbook_latex/solvedissues.tex deleted file mode 100644 index 8daa603..0000000 --- a/pimo/doc/handbook_latex/solvedissues.tex +++ /dev/null @@ -1,275 +0,0 @@ -
-\section{Issues solved by Agreement}
-\subsection{Relation between PIMO:Thing and NIE:InformationElement}
-\paragraph{Background} PIMO:Things are unique representations of concepts, such as a person, a book,
- a product, a company. For these, often ontologies exist already in NIE,
- for example nco:PersonContact models people and a bibtex ontology for NIE may be soon available.
- To identify and distinguish pimo:Thing, an instance needs to have all identifying properties of occurrences attached, so for example a pimo:Event should get the NCAL ncal:uid as a property to match it and a pimo:Person should have the nco:contactUID as property. This helps finding them in the various databases available.
- So ncal:uid and nco:contactUID should be possible properties for a pimo:Thing (or subclasses). Using a property from NIE with domain nie:InformationElement on a pimo:Thing infers that the Thing is a NIE:InformationElement. Also, the user may want to use the ontologies defined in NIE to annotate people and events, for example NIE defines a relation that a person can attend a meeting, this does not necessarily be remodeled again in PIMO.
- \paragraph{Problem} The properties defined in NIE should not be modeled again in PIMO. Sometimes properties from NIE should be usable on PIMO:Things.
- \paragraph{Solution pimo:Thing rdfs:isSubClassOf nie:InformationElement}
- This solution would allow us to reuse properties from NIE within PIMO without any problems. Also, as NIE properties are all optional, Things are not invalid because they miss some properties. For specialized classes, it is possible to make them subclasses of the specialized NIE classes (pimo:Person rdfs:subClassOf nco:PersonContact).
- Advantage: we reuse NIE completly for modelling in PIMO.
- Disadvantage: this would bind the PIMO classes with NIE.
- \paragraph{Solution nie:InformationElement rdfs:isSubClassOf pimo:Thing}
- This was a rather bad idea, that came up when we didn't want the first solution.
- The trouble here is, that suddenly all InformationElements would be Things,
- even if they are only extracted by DataWrapper, and then all data in the store
- is suddenly invalid because all InformationElements miss the required properties
- of pimo:Thing.
- \paragraph{Solution instances are then both pimo:Things and nie:InformationElements}
- A pimo:Person, before annotated with an identifier comign from NIE, would then
- also have a type of nie:ContactElement and have as only property the identifier.
- \paragraph{Intermediate Status} 8.1.2008: Knud, Leo discussed it, also looking at https://dev.nepomuk.semanticdesktop.org/repos/trunk/ontologies-public/2007/11/01/nietopimomapping.rdf
- \paragraph{Picked Solution} instances are both pimo:Things and nie:InformationElements.
- This was agreed by best practice and written down here on 30.7.2008.
-
-\subsection{object property, datatype property, annotation-property}
-In general applications, we have noticed that we need to distinguish
-between object properties (relating a Thing with another Thing),
-datatype properties (annotating a Thing with a literal),
-and meta-properties that are generally not visible nor
-editable by the user.
-
-These are present in OWL and we may want to copy their modelling
-approach.
-Then, \texttt{pimo:isRelated}, \texttt{hasTopic}, \texttt{isTopicOf}, \texttt{hasPart} and \texttt{isPartOf} must be modelled as ``object property''.
-At the moment, datatype properties are the duration of a meeting and the geo-position of a location.
-
-There are two ways to express this modelling:
-\note{Knud: 07.01.08: They must be sub-properties? Would they not be instances?}
-\note{Leo: meta-modelling: I want to avoid creating new subclasses of rdfs:property and instead use sub-properties.
-Although both is possible in Protege, some Aimplementations will have hickups on resources being a pimo:DatatypeProperty while they expect a rdfs:Property.
-Also, we then have trees of sub-properties nicely refining the three roots}
-\begin{enumerate}
- \item using rdf:type and adding the rdf:type pimo:ObjectProperty to a property in question
- \item using rdfs:subPropertyOf and adding the rdfs:subPropertyOf pimo:objectProperty to a property in question.
-\end{enumerate}
-Both express the same semantic meaning, but have different implications.
-
-We have chosen (2) (rdfs:subPropertyOf pimo:objectProperty) because of:
-\begin{itemize}
- \item Using (1), you would have to add the rdfs:subPropertyOf annotation to any property in addition to RDF:type (speaking against 1)
- \item Using (1) you would have to make pimo:ObjectProperty a rdfs:subClassOf rdf:Property, and this would practically enforce that you have to add (x) rdf:type rdf:Property to any (x) that is marked as rdf:type pimo:ObjectProperty. In practice, you need the rdf:type rdf:Property because otherwise most command-line tools (for generating ontology mapping files, etc) and other tools which don't have inference won't work then anymore.
- \item Using (1) you can end up with sub-properties of pimo:isRelated which are not declared as pimo:ObjectProperty. This is semantically wrong, any sub-property of a object property is also an objct property, and the same with datatype properties
-\end{itemize}
-
-
-
-The \texttt{nao:prefLabel}/\texttt{nao:altLabel}/\texttt{nao:personalIdentifier} are borderline,
-they should be meta-properties (implementors have to treat them specially anyway, no marking needed).
-They should be, as any other nao property, marked as annotation-properties.
-
-In the meaning and interpretation of owl, annotation properties must not be part of property axioms (subproperty relations), this will not hold for us.
-But OWL also defines \texttt{rdfs:label} and \texttt{rdfs:comment} as annotation properties,
-we would probably do the same.
-\url{http://www.w3.org/TR/owl-ref/#Annotations}
-
-\paragraph{Proposed Solution:} define \texttt{pimo:ObjectProperty}, \texttt{pimo:DatatypeProperty}, and leave out \texttt{pimo:AnnotationProperty}. Every property in an ontology that is meant to be editable by a user must be a sub-property of one of those.
-Gunnar, Leo, Knud like this.
-
-\subsection{Abstract classes}
-Some classes in PIMO are abstract and only used for meta-modelling, they should not be shown in user interfaces.
-Agent, Locatable, LogicalMediatype, ProcessConcept.
-
-We need a property to mark them. Protege has something like this:
-\begin{verbatim}
-<rdfs:Class rdf:about="&pimo;ClassOrThingOrAssociation"
- a:role="abstract">
-\end{verbatim}
-
-\paragraph{Proposed Solution:} pimo:role = pimo:Abstract or pimo:Concrete
-Gunnar, Leo, Knud agree.
-
-
-\subsection{Abstract object}
-\label{issue:abstractobject}
-Status: (Knud and Leo skype on 12th September.)
-Knud suggests that this may already be represneted in the Thing class.
-
-Knud: If there is a physical object in pimo:Upper, how about an abstract object?
-Leo: we may want to consult Ludger and SUMO about this
-
-\paragraph{Solution:} delete PhysicalObject, forget AbstractObject
-Gunnar, Leo, Knud agree.
-
-\subsection{Work Context / Multiple Domains (related to CDS?)}
-In general modeling on the level of Tags and
-Things that occur throughout the whole PIMO of the user,
-the given structures of Thing and its subclasses are good.
-Everything is related to everything.
-
-There are cases when one single Thing has to be modeled
-in a very detailled way, such as a single Document that
-contains references to other documents, a list of people
-and a list of topics.
-The knowledge expressed here is interconnected and focused
-on one topic/domain. The quality of the information
-may be on the level of a brainstorm, including
-false information or wild ideas.
-Also, there may be multiple documents about the same domain,
-or multiple documents that express similar concepts, but
-intentionally different.
-
-The idea of a work context (or work domain) is to
-provide a container for knowledge articulation.
-The user can create such domains to model knowledge
-that is only valid within the domain, but not
-within his other PIM activities.
-
-The work context can be used for smaller domains such
-as writing one brainstorm document, or for larger domains
-such as separating private life and business information.
-
-\paragraph{Proposed Solution:} postpone the details,
-suggested solution is to use pimo:Topics and ``HasTopic'' relations
-of Things.
-Agreed by Leo, Gunnar, Knud (8.1.2008)
-
-\subsection{Naming of properties: x vs hasX}
-
-Simon Scerri in email on 14.11.2007 to tf-ont:
-
-May I remind why we could not stick to just one of the formats in the existing ontologies.
-
-* Problem with the 'X format':
-Property: nrl:semantics; Class: nrl:Semantics; ===> In this case its much more useful to have the property as nrl:hasSemantics for the difference between the two to be clearer.
-
-* Problem with the 'hasX format':
-Property: nao:prefLabel is a subproperty of rdfs:label. ===> Given the 'X format' of the rdfs super-property, a 'hasX format' for the sub-property is not the 'natural' guess. (This is the same in skos:prefLabel)
-
-And so we had agreed that although sticking to just one standard format is nicer, there's no 'best practice' for these given reasons. But if I remember correctly, the 'hasX format' should be the first choice!
-
-\paragraph{Proposed Solution:} no changes to the ontology now, this has been going on forever without any final decision, short names are preferred though.
-Agreed by Leo, Gunnar, Knud (8.1.2008)
-
-\subsection{Incorporate Relations from AS}
-Status: Knud looks at this and sees if it can be used
-for the Organizational ontology.
-If this cannot be done, no problem. This is a bonus level.
-
-Benjamin Horak from DFKI made a multi-lingual ontology,
-including alt-labels, for some common properties.
-They are inspired by FOAF.
-
-Leo: Perhaps we should move this to a domain ontology
-based on FOAF/FoafCorp?
-
-http://www.dfki.uni-kl.de/~horak/2007/ontologies/docutag/as.owl\#
-
-\paragraph{Proposed Solution:} leave it out,
-maybe publish later
-Agreed by Leo, Gunnar, Knud (8.1.2008)
-
-\subsection{Representation of Time}
-Status: (Knud and Leo skype on 12th September.)
-Ludger had a representation of Time in the original PIMO-Upper,
-I would propose we reuse the approach of NIE/NCAL for duration, point in time,
-recurring events.
-Then, we would delete ``TimeConcept'' from the ontology and copy the properties
-from NIE to ProcessConcept. Any arguments if this is good or bad?
-
-The decision was taken on the August TF-Ont meeting, we stick to XSD and provide a simple class for durations without further going into details.
-
-\paragraph{Solution:} Remove TimeConcept and PeriodOfTime altogether.
-Remove them from the chapter above ``representing time''. leave processconcept in.
-Agreed by Leo, Gunnar, Knud (8.1.2008)
-
-
-\subsection{Ludger, Michael, can't we drop hasOther* ?}
-Leo thought on 12.9.2007, that we may not need hasOtherconceptualization and
-hasOtherRepresentation anymore:
-
-HasOtherConceptualization is captured already by subclass relations, external ontologies
-can define subclasses of pimo:Upper classes. When a user creates a class in his PIMO,
-it can be matched against any class from pimo:Upper or mid-level ontologies,
-by annotating personal classes as subclasses of them. The semantics of hasOtherConceptualization does not affect the data in any way, changing it to subClassOf would have a clear semantics.
-
-hasOtherRepresentation is already captured by the groundingOccurrence and occurrence relation. On itself, hasOtherRepresentation has the semantics of being a subproperty of pimo:occurrence. Maybe it is not needed and pimo:occurrence is enough.
-
-Ludger supports both, they stay in.
-
-\subsection{How to connect a Thing to the user - what are the Things of the user?}
-The problem is: where does the PIMO of the user start and end?
-Which Things are created by him and should be suggested for annotations,
-which not?
-
-There are two competing goals here, both contradict each other:
-\begin{itemize}
- \item (A) Things used by the user should be in the attention of the user, created in an ordered process and formally well described. The list of ``all Things of the user'' should be exact. This implies that the Things are marked somehow.
- \item (B) Mid-level ontologies can contain Things shared across users, they should be
- integrated without effort.
-\end{itemize}
-
-The solution to support A would be to add a pimo:definedBy annotation to each Thing connecting it to the PIMO of the user.
-The solution to support B would be to use any resource that has type PIMO:Thing as a Thing used by the user.
-
-Discussions were done many times, the last and final with Leo Sauermann, Michael Sintek and Sebastian Trüg on 21.11.2007 in Kaiserslautern.
-Solution: use NRL:imports to define what elements are ``in the scope of the user''.
-See also Section~\ref{sec:nrlgraphs}.
-
-For pragmatic reasons, Leo added the recommendation to use pimo:isDefinedBy as NRL
-is not fully available and its not clear how resources relate to graphs.
-
-
-\subsection{hasOtherRepresentation, hasOtherConceptualization, hasOtherSlot}
-\textbf{Agreement}: (Leo and Knud skype on 12.9.2007):
-we make them subclasses/subproperty/grounding and see if trouble comes.
-
-These could be subproperties of groudningOccurrence, rdfs:subClassOf and rdfs:subPropertyOf.
- But other ontologies not conformant to NRL would then cause trouble with our inference
- engine. So, what to do.
-
-\subsection{How do we relate to NAO?} The identification properties are also in NAO.
- NAO was started by using the core properties of the old PIMO, what to do now?
-\textbf{Suggestion Leo}: we subclass/subproperty from NAO, once NAO is in a usable state. We wait until NAO is finished and update PIMO then.
-
-\textbf{This is done, as far as known. On review, hopefully some bugs are found}.
-
-
-\subsection{Semantic Relations and inference, how to untie hasPart, Collections, and Topics.}
-Agreement: (Leo and Knud skype on 12.9.2007) This has to be done with rules, using an inference engine.
-For rules, refer to the RIF group.
-HasPart is not transitive, because there are papers that have proven that
-hasPart is not always transitive. In some application domains, specific
-subproperties of hasPart can be declared transitive.
-
- One Thing can both be a Topic of another Thing (hasTopic) or part of it (hasPart).
- A project can be the topic of a document, and the document can be part of the project.
- The project can also be seen as a collection, namely a collection of Things that are part of the project or have the project as topic. This would be interesting to somehow represent in a way that would make use of transitive closures, for example when searching for ``documents that have the topic nepomuk'' users may expect to find documents that have the topic ``NRL'' which is a part of NEPOMUK. But actually, the topic of the NRL document is NRL, and it does not describe facts about NEPOMUK. But all these generic terms are - generic - so using them for inference may open a can of worms. Perhaps we should make hasPart transitive and see what happens.
- We then also should say that: CONSTRUCT {?x pimo:hasTopic ?B}
-WHERE {?x pimo:hasTopic ?A. ?A pimo:partOf ?B.}
-
-\subsection{Equivalence}
-When using hasOtherRepresentation and hasOtherConceptualization
- we did assert equivalence (transitive, reflexive, symmetric). This sounds like it could
- cause trouble. Equivalence relations cause many triples to be inferred,
- if A and B are equivalent, Statements like (A p o) imply (B p o).
- \textbf{Agreement} by LeoSauermann, LudgerVanElst, MichaelSintek on 6.7.2007: we need transitivity to benefit from multiple hasOtherRepresentation, to find any hasOtherRep that is connected to a PIMO Thing. Reflexive/symmetric are open and not decided as ``must have''.
-
-\subsection{pimo:user or pimo:isDefinedBy}
- One of the main ideas of PIMO is to get all Things (and their titles and types)
- of a user with the simplest query possible. We have to clearly decide how we
- mark which Things are part of a user's PIMO and which not.
- One way is to connect Things to the PIMO-model, using the pimo:isDefinedBy
- property. This is similar to rdfs:isDefinedBy (which is discouraged by NRL,
- but we don't have to subproperty it).
- Or we use the property pimo:user, a subproperty of nco:creator,
- this has the advantage that automatically a creator is set.
- But the disadvantage that the user is not exactly the creator, but
- more his system is. Next disadvantage is that this triple
- asks for trouble when inserting it and validation is on,
- because pimo:user has many restrictions (claudia:Claudia pimo:user claudia:Claudia)
- Both solves the problem, we should decide for one.
- \textbf{Agreement} by LeoSauermann, LudgerVanElst, MichaelSintek on 6.7.2007:
- we use pimo:isDefinedBy and connect Things to the PIMO of the user, and the user to his/her pimo.
-
-\subsection{What classes and instances appear in a user interface?}
- Assumed that many classes and instances are stored in an available RDF data store,
- what classes and instances should be shown to the user? Are all of them of interest?
- When applying filter rules, should the filter rules be excluding
- (not wanted classes are filtered out) or including (wanted classes are filtered in).
- \textbf{Agreement} by LeoSauermann, LudgerVanElst, MichaelSintek on 6.7.2007:
- This is what NRL views were made for, we can give a recommendation how to do this
- using NRL.
-
diff --git a/pimo/doc/pimo-header.html b/pimo/doc/pimo-header.html deleted file mode 100644 index e53fb48..0000000 --- a/pimo/doc/pimo-header.html +++ /dev/null @@ -1,109 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
- <title>Personal Information Model (PIMO)</title>
-
-</head>
-<body>
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org">
-<img class="nepomuklogo" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
-
-<h1>Personal Information Model (PIMO)</h1>
-
-<h2>OSCAF Recommendation 2.2.2009</h2>
-
-</big>
-<dl>
- <dt>Latest Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/pimo">http://www.semanticdesktop.org/ontologies/pimo</a>
- </dd>
-
- <dt>This Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2007/11/01/pimo">http://www.semanticdesktop.org/ontologies/2007/11/01/pimo</a>
- <br/>This file refers to the Revision 1.1 of PIMO. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.</dd>
-
- <dt>Previous Version:</dt>
- <dd><a href="http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/v1.0/">http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/v1.0/</a>
-
- <dt>Authors:</dt>
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
-
- <dd>Ludger van Elst, DFKI, <a href="mailto:Ludger.van_Elst@dfki.de">Ludger.van_Elst@dfki.de</a></dd>
-
- <dd>Knud Möller, DERI, <a href="mailto:elst@dfki.uni-kl.de">knud.moeller@deri.org</a></dd>
-
- <dt></dt>
-
- <dt>Editor:</dt>
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
-
- <dt></dt>
-
- <dt>Contributors:</dt>
-
- <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
-
- <dt id="ontology">Ontology:</dt>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/pimo_data.rdfs">PIMO
-(Data Graph Only)</a></dd>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/pimo_metadata.rdfs">PIMO
-(Metadata Graph Only)</a></dd>
-
- <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/pimo.trig">PIMO
-(Graph Set)</a></dd>
-
-</dl>
-
-</div>
-
-<hr />
-<p class="copyright"> Copyright © 2007-2009 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>®</sup>
-The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
-</p>
-<hr />
-
-<h2 id="abstract">Abstract</h2>
-<p>
- The PIMO Ontology can be used to express Personal Information Models of individuals.
- It is based on RDF and NRL, the NEPOMUK Representational Language and other Semantic Web ontologies.
- This document describes the principle elements of the language and how to use them.
-</p>
-
-<h2 id="status">Status of this document</h2>
-<p>
- This section describes the status of this document at the time of its publication.
- The form used for this status message and document is inspired by the W3C process.
-</p>
-<p>
- This document describes an <a href="http://www.oscaf.org">OSCAF ontology recommendation</a> describing an ontology for Personal Information Models (PIMO).
- It was edited first within the NEPOMUK project and is now maintained by OSCAF members.
- The listed editor is responsible to bring in feedback from the other authors, contributors,
- and the community at large.
- This document and the PIMO ontology as such is based on various other publications by the authors, and is a continuation of existing work.
- Other documents may supersede this document.
- Parts of this document will be published in other documents, such as scientific publications.
-</p>
-<p>
- This recommendation is <a href="#ontology">accompanied by a RDFS/NRL ontology</a>, which is the authorative formal
- description of the ontology.</b>
-</p>
-<p>
- Additional to this document, a <a href="http://dev.nepomuk.semanticdesktop.org/wiki/PimoFaq">PIMO FAQ</a>
- is maintained and a <a href="http://dev.nepomuk.semanticdesktop.org/wiki/PimoOntology">detailled PIMO information page</a>.
-</p>
-<h2>PIMO Recommendation Document</h2>
-<p>The rest of the PIMO Recommendation is published as <a href="https://dev.nepomuk.semanticdesktop.org/repos/trunk/ontologies/pimo/latex/pimo_v1.1.pdf">PDF document</a>.
-Please refer to this PDF document, or the latest<a href="http://dev.nepomuk.semanticdesktop.org/repos/trunk/ontologies/pimo/latex/pimo.tex">LaTex sources</a> of the PDF document.
-</p>
diff --git a/pimo/doc/presentations/2007_09_06_pimo_i_semantics.ppt b/pimo/doc/presentations/2007_09_06_pimo_i_semantics.ppt Binary files differdeleted file mode 100644 index 8f58af2..0000000 --- a/pimo/doc/presentations/2007_09_06_pimo_i_semantics.ppt +++ /dev/null diff --git a/pimo/doc/presentations/SummerSchool_PIMO.pdf b/pimo/doc/presentations/SummerSchool_PIMO.pdf Binary files differdeleted file mode 100644 index 81e76a1..0000000 --- a/pimo/doc/presentations/SummerSchool_PIMO.pdf +++ /dev/null diff --git a/pimo/doc/presentations/SummerSchool_PIMO.ppt b/pimo/doc/presentations/SummerSchool_PIMO.ppt Binary files differdeleted file mode 100644 index 31aec8f..0000000 --- a/pimo/doc/presentations/SummerSchool_PIMO.ppt +++ /dev/null diff --git a/pimo/doc/presentations/pimo_introduction.ppt b/pimo/doc/presentations/pimo_introduction.ppt Binary files differdeleted file mode 100644 index 8107194..0000000 --- a/pimo/doc/presentations/pimo_introduction.ppt +++ /dev/null diff --git a/tmo/doc/tmo-header.html b/tmo/doc/tmo-header.html deleted file mode 100644 index 8db62de..0000000 --- a/tmo/doc/tmo-header.html +++ /dev/null @@ -1,225 +0,0 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-<head>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <link rel="stylesheet" type="text/css" href="nepomuk-ontology-docs.css" />
- <title>Task Model Ontology (TMO)</title>
-
-</head>
-<body>
-
-<div class="head">
-<div class="nav"> <a href="http://nepomuk.semanticdesktop.org"> <img style="border: 0px solid ; width: 180px; height: 88px;" alt="NEPOMUK Logo" src="nepomuk.png" /> </a> </div>
-
-<h1>Task Model Ontology (TMO)</h1>
-
-<big style="color: rgb(0, 90, 156);">Task-Force Ontologies<br />
-
-</big>
-<dl>
-
- <dt>Latest Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/tmo">http://www.semanticdesktop.org/ontologies/tmo</a>
- </dd>
-
- <dt></dt>
-
- <dt>This Version:</dt>
-
- <dd><a href="http://www.semanticdesktop.org/ontologies/2008/05/20/tmo">http://www.semanticdesktop.org/ontologies/2008/05/20/tmo</a>
- <br/>This file refers to the Revision 1.0 of TMO. Minor changes may be implemented in future revisions.
- With each new revision, the documentation and all serializations of the ontology will be updated.</dd>
-
- <dt></dt>
-
- <dt>Authors:</dt>
-
- <dd>Marko Brunzel, DFKI, <a href="mailto:marko.brunzel@dfki.de">marko.brunzel@dfki.de</a></dd>
-
- <dd>Olaf Grebner, SAP, <a href="mailto:olaf.grebner@sap.com">olaf.grebner@sap.com</a></dd>
-
- <dt></dt>
-
- <dt>Editors:</dt>
-
- <dd>Marko Brunzel, DFKI, <a href="mailto:marko.brunzel@dfki.de">marko.brunzel@dfki.de</a></dd>
-
- <dd>Olaf Grebner, SAP, <a href="mailto:olaf.grebner@sap.com">olaf.grebner@sap.com</a></dd>
-
- <dt></dt>
-
- <dt>Contributors:</dt>
-
- <dd>Leo Sauermann, DFKI, <a href="mailto:leo.sauermann@dfki.de">leo.sauermann@dfki.de</a></dd>
- <dd>Michael Sintek, DFKI, <a href="mailto:michael.sintek@dfki.de">michael.sintek@dfki.de</a></dd>
- <dd>Ludger van Elst, DFKI, <a href="mailto:elst@dfki.de">elst@dfki.de</a></dd>
- <dd>Ansgar Bernardi, DFKI, <a href="mailto:ansgar.bernardi@dfki.de">ansgar.bernardi@dfki.de </a></dd>
- <dd>Uwe Riss, SAP, <a href="mailto:uwe.riss@sap.com">uwe.riss@sap.com</a></dd>
-
- <dt><span style="font-weight: bold;">Ontology:</span></dt>
-
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2008/05/20/tmo/tmo_data.rdfs">TMO (Data Graph Only)</a></dd>
- <dd>XML/RDFS Serialization: <a href="http://www.semanticdesktop.org/ontologies/2008/05/20/tmo/tmo_metadata.rdfs">TMO (Metadata Graph Only)</a></dd>
- <dd>TriG Serialization: <a href="http://www.semanticdesktop.org/ontologies/2008/05/20/tmo#/tmo.trig">TMO (Graph Set)</a></dd>
-
-</dl>
-
-</div>
-
-<p class="copyright"> Copyright © 2007-2008 <a href="http://www.dfki.de/"><acronym title="Deutsches Forschungszentrum fuer Kuenstliche Intelligenz">DFKI</acronym></a><sup>®</sup>
-The ontologies are made available under the terms of NEPOMUK <a href="LICENSE.txt">software license</a>
-</p>
-
-<hr />
-<h2 id="sec:abstract">Abstract</h2>
-<p>
- The TMO Ontology can be used to describe personal tasks of individuals, also known as to-do lists. It is based on RDF and <a href="http://www.semanticdesktop.org/ontologies/nrl/"> NRL</a>, the NEPOMUK Representational Language and other Semantic Web ontologies. This document describes the fundamental elements of the language and how to use them.
- </p>
-
-<h2 id="sec:status">Status of this document</h2>
-
-<p>
- This section describes the status of this document at the time of its publication. The form used for this status message and document is inspired by the W3C process.
-</p>
-<p>
- This document is an Editors Draft produced by Olaf Grebner and Marko Brunzel as part of the work package task management in the <a href="http://nepomuk.semanticdesktop.org/">NEPOMUK</a> project. The task-force intends this document to become a NEPOMUK standard. The editors of this document value feedback from the public and from NEPOMUK members. Please add comments as tickets in the NEPOMUK tracker using the category ontology-tmo. This document is accompanied by a RDFS/NRL ontology, which should be read in parallel to learn more about TMO.
-</p>
-<p>
- This document and the TMO ontology as such are a continuation and improvement of existing work. Other documents may supersede this document. Parts of this document will be published in other documents, such as scientific publications. This document is based on various other publications by the authors, and is a continuation of existing work. Some formulations from the RDFS primer and SKOS primer documents were reused.<br/>
-</p>
-
-<h2 id="sec:introduction">1. Introduction</h2>
-
-<p>
-The Task Management Model Ontology (TMO) is a conceptual representation of tasks for use in personal task management applications for knowledge workers.<br/>
-</p>
-<p>
-Knowledge workers perform knowledge work. For example, managers, researchers and sales representatives are knowledge workers. Knowledge work is goal driven, i.e., a knowledge worker strives to achieve a goal with the execution of her work. Knowledge work can be broken down into tasks where each task has a goal that the knowledge worker needs to achieve in order to complete the task. Knowledge workers can reach their goals using different approaches and methods which can differ individually from knowledge worker to knowledge worker. Knowledge is thus rather characterized by variety than by routine.
-</p>
-<p>
-Tasks are units of work. We address a kind of tasks which often arise during performing the work, compared to task which are apriory given. Or in other words, the modelling of tasks is also done during task execution. Workflows are usually not enforced upon those tasks. Such tasks can form flexible workflows where recommendations regarding the execution of particular tasks are made.
-</p>
-<p>
-In the NEPOMUK environment, information chunks are expressed by the NAO, NIE and PIMO ontologies. In principle, every piece of information can have the character of a task.
-</p>
-
-<p>
-Personal Task Management (PTM) helps knowledge workers to manage their personal, scarce work capacity to achieve their given goals in the desired quality. PTM focuses a personal process perspective, i.e., to manage the activities the knowledge worker performs to get the work done. Tackling information and task overload, the knowledge worker can manage the task workload so that the tasks can be executed on time, scope and budget. A core part of task management is thus enabling prioritization decisions that allow the knowledge worker to decide on what tasks to execute when, to what extent and to what cost.
-</p>
-<p>
-PTM applications support knowledge workers in performing efficient task management to achieve their goals in the best possible way. PTM applications offer functionality to help the knowledge worker to manage the whole set of tasks that the knowledge worker has to accomplish. This happens in the form of a task list, as well known as to-do lists. Task lists here use lists of explicit task representations, i.e., for each task in the list, a dedicated task representation exists and contains the task information needed for the knowledge worker to identify, use and prioritize the task.
-</p>
-
-<p>
-Bringing together PTM and PIM, the TMO is an ontology that enables the knowledge worker to organize lists of tasks in conjunction with organizing information needed to execute these tasks. Foremost, the TMO captures the knowledge worker's tasks and applications using it enable the knowledge worker to get on overview on what needs to be done and how the knowledge worker can prioritize this. In addition, the TMO supports applications to manage the information that is needed from a knowledge worker's perspective to fulfil the task. This includes for example information on who else is involved in the task and what category the task belongs to.
-</p>
-<p>
-Further information on the TMO going beyond this document can be found at <a href="#ref:taskmodel">[TASKMODEL]</a>. This includes background information on task management, state of the art in task modelling, modelling considerations in the personal task space and explains modelling decisions taken for the TMO.
-</p>
-
-
-<h2 id="sec:scope_and_usecases">2. Scope and Covered Use Cases</h2>
-
-<p>
-The TMO is designed for use as part the of PIM platform Nepomuk. The respective Nepomuk Ontology framework provides ontologies for conducting personal information management in particular on the desktop, see <a href="#ref:pimo">[PIMO]</a>, <a href="#ref:nie">[NIE]</a>. The TMO is an extension of the PIMO ontology focusing on tasks and the support of PTM applications. However, applications can use the TMO as well without accessing this Nepomuk ontology framework to support personal task management. Using Nepomuk, the knowledge worker and application developer gain the support for desktop integration, i.e., the integration with information models that represent the entities of a desktop, like e.g. emails and files.
-</p>
-
-
-<p>
-The TMO covers with its task model a number of task management use cases that can be implemented in task management applications. The TMO provides the conceptual basis for these use cases. These use cases are:
-<ul>
-<li>Personal Task Management - Personal Task Management consists of several parts.</li>
- <ul>
- <li>Basic task handling - Basic task handling deals with organizing a knowledge workers task, e.g., creating and populating a task.</li>
- <li>Task list management - Task list management deals with the knowledge worker handling a personal to-do list where the Knowledge worker manages a list of personal tasks that are due for execution or are already executed.</li>
- <li>Task priority management - Task priority management helps the knowledge worker to maintain the priorities coming with a task.</li>
- <li>Task time management - Task time management focuses on the time needed to execute a task and the knowledge worker can assign a task due date to manage the time-related aspects of work.</li>
- <li>Task planning - Task planning helps the knowledge worker to structure the workload and perform work decomposition, i.e., breaking down and categorizing tasks.</li>
- </ul>
-<li>Task Information Management - Task Information Management helps the knowledge worker to collect and associate information needed for executing a task. This includes task tags to group tasks, information object attachments to connect tasks to, e.g., emails and files, and as social aspect persons involved in a task.</li>
-<li>Social Task Management - Social Task Management focuses on collaboration in the task domain. This means, that knowledge workers can delegate tasks to each other, can perform and task tracking and conduct information sharing.</li>
-</ul>
-
-
-
-In addition, knowledge workers and application developers can extend the TMO to cover further use cases. These TMO extensions (TMOE) can for example support experience and knowledge management for tasks with task patterns <a href="#ref:taskmodel">[TASKMODEL]</a>.
-</p>
-
-<h2 id="sec:modelling">3. TMO Modelling</h2>
-
-<p>
-The core class of the TMO is the class tmo:Task. The tmo:Task is a subclass of pimo:ProcessConcept. The inheritance hierarchy of the tmo:Task is shown in the figure below.
-<br/>
-<img alt="tmo class and ist super-classes" src="img/tmo_task_pimo_subclass_part1.gif" />
-<img alt="tmo class and ist super-classes" src="img/tmo_task_pimo_subclass_part2.gif" />
-</p>
-
-<p>
-Details of a task are represented by attributes modelled as shown in the figure below. Tasks can be grouped by means of the tmo:TaskCollection class.<br/>
-<img alt="overview on tmo" src="img/tmo_overview_part1.gif" /><br/>
-<img alt="overview on tmo" src="img/tmo_overview_part2.gif" /><br/>
-<img alt="overview on tmo" src="img/tmo_overview_part3.gif" /><br/>
-</p>
-
-
-
-
-
-
-<p>
-There are some classes that have been modelled according to a role based modelling approach. Hereby it is possible to model n-ary relations. In particular attachments, the involvement of persons and of actors and resource (furthermore referred as AbilityCarriers) and task dependencies have been modelled this way. The overviews on those four circumstances are shown in the figures below:
-
-<h3>tmo:PersonInvolvement</h3>
-<p>
-<img alt="Role based modelling of tmo:PersonInvolvement" src="img/tmo_personinvolvement.gif" /><br/>
-<img alt=" Role based modelling of tmo:Attachment " src="img/tmo_attachment.gif" />
-<br/>
-</p>
-
-<h3>tmo:AbilityCarrierInvolvement</h3>
-<p>
-<img alt="Role based modelling of tmo:AbilityCarrierInvolvement" src="img/tmo_abilitycarrierinvolvement.gif" />
-<br/>
-</p>
-
-<h3>tmo:Attachment</h3>
-<p>
-<img alt="Role based modelling of tmo:Attachment" src="img/tmo_attachment.gif" />
-<br/>
-</p>
-
-<h3>tmo: TaskDependency</h3>
-<p>
-<img alt="Role based modelling of tmo:TaskDependency" src="img/tmo_dependencies.gif" />
-<br/>
-
-</p>
-
-
-<p> The transmission of tasks is represented by the tmo:TaskTransmission class.
-<br/>
-<img alt="tmo:TaskTransmission" src="img\tmo_transmission.gif" />
-<br/>
-</p>
-
-
-
-
-<h2 id="sec:references">References</h2>
-
-<dl>
- <dt><a name="ref:pimo"></a>[PIMO]</dt>
- <dd><cite><a href="http://www.semanticdesktop.org/ontologies/pimo">Personal Information Model ontology (PIMO)</a> </cite>, Leo Sauermann, Ludger van Elst, Knud Möller, http://www.semanticdesktop.org/ontologies/pimo</dd>
-
- <dt><a name="ref:nie"></a>[NIE]</dt>
- <dd><cite><a href="http://www.semanticdesktop.org/ontologies/nie">NEPOMUK Information Element Ontology (NIE)</a> </cite>, Antoni Mylka, Leo Sauermann, Michael Sintek, Ludger van Elst, http://www.semanticdesktop.org/ontologies/nie</dd>
-
- <dt><a name="ref:taskmodel"></a>[TASKMODEL]</dt>
- <dd><cite><a href="http://nepomuk.semanticdesktop.org/xwiki/bin/download/Main1/D3-1/D3.1_v10_NEPOMUK_Task_Management_Model.pdf">Task Management Model (TMO)</a> </cite>, Olaf Grebner, Ernie Ong, Uwe Riss, Marko Brunzel, Ansgar Bernardi, Thomas Roth-Berghofer, http://nepomuk.semanticdesktop.org/xwiki/bin/download/Main1/D3-1/D3.1_v10_NEPOMUK_Task_Management_Model.pdf</dd>
-
-</dl>
-
-
-
|
