diff -Nru shared-desktop-ontologies-0.8.1/ChangeLog shared-desktop-ontologies-0.9.0/ChangeLog --- shared-desktop-ontologies-0.8.1/ChangeLog 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/ChangeLog 2012-02-10 21:02:59.000000000 +0000 @@ -1,3 +1,29 @@ +0.9.0 + 01/05/2012 - trueg + Added properties nfo:depicts and nfo:depiction + Made nmm:artwork a subproperty of nfo:depiction + + 12/13/2011 - trueg + Added nrl:DefiningProperty and nrl:NonDefiningProperty + + 12/12/2011 - trueg + Set nao:userVisible on the following classes and properties: + nao:score + nao:hasSubResource + nao:hasSuperResource + nrl:Graph + rdf:Property + rdfs:Class + rdfs:Resource + nie:hasPart + nie:isPartOf + nfo:hasHash + nuao:Event + + 08/23/2011 - trueg + Added class nfo:LocalFileDataObject + + 0.8.1 11/25/2011 - trueg Fixed domain of nmm:setSize to nmm:MusicAlbum diff -Nru shared-desktop-ontologies-0.8.1/CMakeLists.txt shared-desktop-ontologies-0.9.0/CMakeLists.txt --- shared-desktop-ontologies-0.8.1/CMakeLists.txt 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/CMakeLists.txt 2012-02-10 21:02:59.000000000 +0000 @@ -7,8 +7,8 @@ # set the version to be used by SharedDesktopOntologiesConfig.cmake # =============================================================================================== set(SHAREDDESKTOPONTOLOGIES_VERSION_MAJOR 0) -set(SHAREDDESKTOPONTOLOGIES_VERSION_MINOR 8) -set(SHAREDDESKTOPONTOLOGIES_VERSION_RELEASE 1) +set(SHAREDDESKTOPONTOLOGIES_VERSION_MINOR 9) +set(SHAREDDESKTOPONTOLOGIES_VERSION_RELEASE 0) set(SHAREDDESKTOPONTOLOGIES_VERSION "${SHAREDDESKTOPONTOLOGIES_VERSION_MAJOR}.${SHAREDDESKTOPONTOLOGIES_VERSION_MINOR}.${SHAREDDESKTOPONTOLOGIES_VERSION_RELEASE}") @@ -100,7 +100,8 @@ # Caution: we need to put this command at the end since it depends on the ontology_docbook_references variable which # is only populated by the install_ontology calls above # =============================================================================================== -file(GLOB_RECURSE _doc_files_the_hacky_way_ "${CMAKE_CURRENT_SOURCE_DIR}/*.png") +# TODO: how about adding the additional files required for the docs to the install_ontology macro instead of this hack? +file(GLOB_RECURSE _doc_files_the_hacky_way_ "${CMAKE_CURRENT_SOURCE_DIR}/*.png" "${CMAKE_CURRENT_SOURCE_DIR}/*.ttl") configure_file(${CMAKE_CURRENT_SOURCE_DIR}/docs/ontology.docbook.template ${CMAKE_CURRENT_BINARY_DIR}/docs/ontology.docbook.template @ONLY) configure_file(${CMAKE_CURRENT_SOURCE_DIR}/docs/sdo.docbook ${CMAKE_CURRENT_BINARY_DIR}/docs/sdo.docbook) configure_file(${CMAKE_CURRENT_SOURCE_DIR}/docs/sdo-docbook.xsl.cmake ${CMAKE_CURRENT_BINARY_DIR}/docs/sdo-docbook.xsl) @@ -114,7 +115,7 @@ ) add_custom_target( docrefs - COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/docs/build-ontology-reference.py ${ontology_trig_sources} + COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/docs/build-ontology-reference.py ${CMAKE_CURRENT_BINARY_DIR}/docs ${ontology_trig_sources} COMMENT "Writing Ontology References..." WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/docs ) diff -Nru shared-desktop-ontologies-0.8.1/debian/changelog shared-desktop-ontologies-0.9.0/debian/changelog --- shared-desktop-ontologies-0.8.1/debian/changelog 2011-11-27 09:47:42.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/debian/changelog 2012-03-11 13:55:07.000000000 +0000 @@ -1,3 +1,22 @@ +shared-desktop-ontologies (0.9.0-2~ppa1) precise; urgency=low + + * Upload to ppa + + -- Jonathan Kolberg Sun, 11 Mar 2012 14:54:49 +0100 + +shared-desktop-ontologies (0.9.0-2) unstable; urgency=low + + * Upload to unstable. + + -- Pino Toscano Sun, 04 Mar 2012 21:19:20 +0100 + +shared-desktop-ontologies (0.9.0-1) experimental; urgency=low + + * New upstream release. + * Update copyright. + + -- Pino Toscano Mon, 13 Feb 2012 00:55:52 +0100 + shared-desktop-ontologies (0.8.1-1) experimental; urgency=low * New upstream release. diff -Nru shared-desktop-ontologies-0.8.1/debian/copyright shared-desktop-ontologies-0.9.0/debian/copyright --- shared-desktop-ontologies-0.8.1/debian/copyright 2011-09-01 14:06:14.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/debian/copyright 2012-02-12 23:53:29.000000000 +0000 @@ -11,7 +11,7 @@ Copyright 2007, NEPOMUK Consortium Copyright 2009-2010, Evgeny Egorochkin Copyright 2009, Leo Sauermann - Copyright 2009-2011, Sebastian Trueg + Copyright 2009-2012, Sebastian Trueg Copyright 2010, Andrew Lake License: BSD-3-clause-ontologies or CC-BY-SA-3.0 @@ -39,7 +39,7 @@ Files: debian/* Copyright: Copyright 2009, Jonathan Thomas Copyright 2009, Sune Vuorela - Copyright 2010-2011, Pino Toscano + Copyright 2010-2012, Pino Toscano License: BSD-3-clause diff -Nru shared-desktop-ontologies-0.8.1/docs/build-ontology-reference.py shared-desktop-ontologies-0.9.0/docs/build-ontology-reference.py --- shared-desktop-ontologies-0.8.1/docs/build-ontology-reference.py 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/docs/build-ontology-reference.py 2012-02-10 21:02:59.000000000 +0000 @@ -20,6 +20,7 @@ from PyKDE4 import soprano import sys import codecs +import glob # our tree, maps URIs to EntityContainer objects @@ -52,6 +53,15 @@ return s.left(maxLen) + "..." +def resolveAbbreviatedUri(abbrevUri): + abbr = abbrevUri.left(abbrevUri.indexOf(':')) + name = abbrevUri.mid(abbr.length()+1) + for ns in allNamespaces.keys(): + if abbr == allNamespaces[ns]['abbr']: + return ns + name + return '' + + def buildDocBookEntity(entityUri): if entityUri in entityTree: return entityTree[entityUri].createDocBookLink() @@ -69,6 +79,13 @@ return s.join(', ') +def buildXRefList(linkends): + s = QtCore.QStringList() + for link in linkends: + s.append('' % link) + return s.join(', ') + + class EntityContainer(object): """ A container for a class or a property with members @@ -131,7 +148,11 @@ def toDocBook(self): entityId = "%s:%s" % (allNamespaces[self.namespace()]["abbr"], self.name()) - s = '
%s' % (entityId, entityId) + s = '
' % entityId + s += entityId + if self.deprecated: + s += ' <emphasis>(deprecated)</emphasis>' + s += '' s += '' s += 'Label%s' % self.label s += 'Description' % self.comment() @@ -157,6 +178,8 @@ s += 'In range of%s' % buildDocBookEntityList(self.inRangeOf) if len(self.instances) > 0: s += 'Instances%s' % buildDocBookEntityList(self.instances) + if len(self.backlinks) > 0: + s += 'Mentioned in%s' % buildXRefList(self.backlinks) s += '
' return s @@ -181,6 +204,8 @@ self.maxCardinality = -1 self.m_comment = QtCore.QString() self.inverseProperty = QtCore.QString(); + self.backlinks = set() + self.deprecated = False def __cmp__(self, other): if self.name() < other.name(): return -1 @@ -220,6 +245,13 @@ if uri in entityTree: entityTree[uri].m_comment = it.current().object().toString() + # mark deprecated classes and properties + it = graph.listStatements(soprano.Soprano.Node(), soprano.Soprano.Node(soprano.Soprano.Vocabulary.NAO.deprecated()), soprano.Soprano.Node()) + while(it.next()): + uri = it.current().subject().uri().toString() + if uri in entityTree: + entityTree[uri].deprecated = it.current().object().literal().toBool() + # add hierarchy subRelations = {} superRelations = {} @@ -311,6 +343,39 @@ allNamespaces.setdefault(ns, {})["desc"] = it.current().object().literal().toString() +def extractEntityBacklinks(docbookFolder): + "Extracts links from documentation to classes and properties. The backlinks are stored in the entityTree as string ids to be used in xref docbook links." + # Parse each docbook file and find xref links which relate to a class or a property + # for each xref find the containing section and store its id in the entity's backlinks list + for filename in glob.glob(docbookFolder + '/*-main.docbook'): + # + # We need a well-formed docbook document for the stream reader. + # Thus we fake one by putting the file contents into an article + # + file = QtCore.QFile(filename) + file.open(QtCore.QIODevice.ReadOnly) + content = file.readAll() + content.prepend('
') + content.append('
') + + xml = QtCore.QXmlStreamReader(content) + sectionStack = [] + while not xml.atEnd(): + tokenType = xml.readNext() + if tokenType == QtCore.QXmlStreamReader.StartElement: + if xml.name() == 'section': + if xml.attributes().hasAttribute('id'): + sectionStack.append(xml.attributes().value('id').toString()) + elif xml.name() == 'xref': + linkend = xml.attributes().value('linkend').toString() + resolvedUri = resolveAbbreviatedUri(linkend) + if resolvedUri in entityTree: + entityTree[resolvedUri].backlinks.add(sectionStack[-1]) + elif tokenType == QtCore.QXmlStreamReader.EndElement: + if xml.name() == 'section': + sectionStack.pop() + + def printEntityTree(): for e in entityTree.values(): print "%s (%s) (%s)" % (e.label, e.uri, e.isProperty) @@ -352,14 +417,20 @@ filename = '%s-reference.docbook' % name f = codecs.open(filename, 'w', 'utf-8') f.write('
%s Vocabulary Summary' % name.toUpper()) - f.write('
Description of Classes') - for a in getSortedClasses(ns): - f.write(a.toDocBook()) - f.write('
') - f.write('
Description of Properties') - for a in getSortedProperties(ns): - f.write(a.toDocBook()) - f.write('
') + + sortedClasses = getSortedClasses(ns) + if len(sortedClasses) > 0: + f.write('
Description of Classes') + for a in sortedClasses: + f.write(a.toDocBook()) + f.write('
') + + sortedProperties = getSortedProperties(ns) + if len(sortedProperties) > 0: + f.write('
Description of Properties') + for a in sortedProperties: + f.write(a.toDocBook()) + f.write('
') f.write('
') @@ -386,20 +457,26 @@ name = allNamespaces[ns]["abbr"] filename = '%s-overview.docbook' % name f = open(filename, 'w') - f.write('
') - f.write('Classes Overview') - f.write('') - for a in getSortedClasses(ns): - f.write('%s' % a.toShortDocBook()) - f.write('') - f.write('
') - f.write('
') - f.write('Properties Overview') - f.write('') - for a in getSortedProperties(ns): - f.write('%s' % a.toShortDocBook()) - f.write('') - f.write('
') + + sortedClasses = getSortedClasses(ns) + if len(sortedClasses) > 0: + f.write('
') + f.write('Classes Overview') + f.write('') + for a in sortedClasses: + f.write('%s' % a.toShortDocBook()) + f.write('') + f.write('
') + + sortedProperties = getSortedProperties(ns) + if len(sortedProperties) > 0: + f.write('
') + f.write('Properties Overview') + f.write('') + for a in getSortedProperties(ns): + f.write('%s' % a.toShortDocBook()) + f.write('') + f.write('
') def writeOntologyToc(): "Writes a TOC file which lists links to all ontologies" @@ -415,7 +492,7 @@ def writeClassIndex(): "Writes one docbook file containing an index of all classes" f = open('classindex.docbook', 'w') - f.write('
') + f.write('') f.write('All Classes') currentChar = '' for a in getSortedClasses(): @@ -429,14 +506,14 @@ f.write('') f.write('%s' % a.toShortDocBook()) f.write('
') - f.write('
') + f.write('') f.close() def writePropertyIndex(): "Writes one docbook file containing an index of all properties" f = open('propertyindex.docbook', 'w') - f.write('
') + f.write('') f.write('All Properties') currentChar = '' for a in getSortedProperties(): @@ -450,12 +527,13 @@ f.write('') f.write('%s' % a.toShortDocBook()) f.write('
') - f.write('') + f.write('') f.close() def main(): - buildEntityTree(sys.argv[1:]) + buildEntityTree(sys.argv[2:]) + extractEntityBacklinks(sys.argv[1]) # write an index of all classes writeClassIndex() writePropertyIndex() diff -Nru shared-desktop-ontologies-0.8.1/docs/README shared-desktop-ontologies-0.9.0/docs/README --- shared-desktop-ontologies-0.8.1/docs/README 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/docs/README 1970-01-01 00:00:00.000000000 +0000 @@ -1,8 +0,0 @@ -The documentation of the ontologies is build as follows: - -- Each ontology comes with a docbook file which contains the authors and copyright info and any documentation and howtos that might be of interest. -- Each ontology docbook contains an xinclude like "" -- build-ontology-reference.py creates one reference file like "nie-reference.docbook" for each ontology in the working dir (TODO: add a parameter to change the target - folder) -- All docbooks are processed with the modififed XSLT stylesheet: "xsltproc --output nie.html --xinclude sdo-docbook.xls nie.docbook" to generate the final - web pages diff -Nru shared-desktop-ontologies-0.8.1/docs/sdo.docbook shared-desktop-ontologies-0.9.0/docs/sdo.docbook --- shared-desktop-ontologies-0.8.1/docs/sdo.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/docs/sdo.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -6,7 +6,7 @@ Nepomuk Ontologies - Introduction + The Shared Desktop Ontologies The vision of the Social Semantic Desktop defines a user’s personal information environment as a source and end-point of the Semantic Web: Knowledge workers comprehensively express their information and data with @@ -27,7 +27,7 @@ community in general.
- The Shared Desktop Ontologies + Ontology Documentation Version @SHAREDDESKTOPONTOLOGIES_VERSION@ The ontologies described in this document are developed as an open-source project called Shared-Desktop-Ontologies (SDO). @@ -39,12 +39,8 @@
- - - - - - + + Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nao/nao-basic-annotations.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nao/nao-basic-annotations.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nao/nao-data-properties.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nao/nao-data-properties.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nao/nao-document-graph.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nao/nao-document-graph.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nao/nao-lower-level.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nao/nao-lower-level.png differ diff -Nru shared-desktop-ontologies-0.8.1/nao/nao-main.docbook shared-desktop-ontologies-0.9.0/nao/nao-main.docbook --- shared-desktop-ontologies-0.8.1/nao/nao-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nao/nao-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1 +1,897 @@ - + +
+ Ontology Visualization + + +
+ + + + + + + +
+ +
+ +
+ Introduction + + 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. + + 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 . + + 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 + , where the resource being annotated is a + graph role (instance of ) 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 by . Graph Metadata + Vocabulary is introduced in . +
+ +
+ Generic Annotation Vocabulary + + In this section we introduce vocabulary that serves generic + annotation, i.e., vocabulary that models general, common relationships + between things. presents the + basic annotation vocabulary. All other vocabulary in the annotation + ontology will require or derive from these basic terms. introduces richer annotation + relationships that derive from the basic annotation properties presented + in . In we discuss how we also model + tagging as a form of annotation and finally in we present a concise + example of how the vocabulary presented in this section can be + employed. + +
+ Basic Annotation + + 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 . + + 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. + + These and other annotation properties and required classes are + specified below. The annotation properties defined in this section are + also illustrated in the figure below. + +
+ + + + + Basic annotation properties + +
+ + + + nao:annotation + + + 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. + + + + + rdfs:label + + + 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 and . + + + + + rdfs:comment + + + 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, . + + + + + nao:hasSymbol + + + A resource can be annotated with an instance of via subproperties of this abstract + property, and . + + + + + nao:rating + + + 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 + (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). + + + + + nao:identifier + + + 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, . Although this property is not + applied any form of restriction, all its subproperties, including + , are meant to be inverse + functional. + + + + + nao:Symbol + + + 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 , and . + Any such graphical symbol that is in this way used to annotate a + resource automatically becomes an instance of this class. + + + + + nao:Tag + + + 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 . For more on tagging as annotation see + . + + + + + nao:Party + + + 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 ). 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. + + + +
+ +
+ More Specific Annotation + + 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 . An overview of these properties + is illustrated in . The specifications for this + vocabulary are given below. + +
+ + + + + Figure 2. Basic annotation properties + +
+ + + + + nao:isRelated + + + This property defines a symmetric relation between any two + resources. A subproperty of , 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. + + + + + nao:hasTopic + + + A subproperty of , 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, . + + + + + nao:isTopicOf + + + This property is also a subproperty of and is the inverse property of . 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. + + + + + nao:hasTag + + + Used to model conventional tagging practices, this property + annotates a resource with a tag, represented by an instance of + . For more on tagging as annotation see + . + + + + + nao:isTagFor + + + This property is the inverse of . It links an instance of to resources that are tagged with it. For + more on tagging as annotation see . + + + + + nao:prefLabel + + + This property is one of two provided by this ontology to + handle custom user labels. Alternative labels can be provided via + . Both properties are subproperties + of rdfs:label 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. + + + + + nao:altLabel + + + Via this property a user can provide further custom labels + for resources on their desktop, alongside the required, unique + value given by . Both properties + are subproperties of rdfs:label and expect a + literal as value. + + + + + nao:pluralPrefLabel + + + This property supplements + 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 rdfs:label and + expects a literal as value. No cardinality restrictions are + imposed. + + + + + nao:prefSymbol + + + A subproperty of , this + property specifies a preferred symbol for resource annotation, + given by an instance of . Resources + can be annotated with alternative symbols via + . + + + + + nao:altSymbol + + + This property is used to annotate a resource with + alternative symbols, given by instances of , alongside the preferred symbol that is + linked via . It is a subproperty + of . + + + + + nao:description + + + A subproperty of rdfs:comment, the + purpose of this property is similar to and . + However this property is also a subproperty of . Whereas in the context of the social + semantic desktop the textual annotation provided via rdfs:comment 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. + + + + + nao:personalIdentifier + + + This property should be used to provide alternative values + that identify a resource alongside the default URI. A subproperty + of the abstract , 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. + + + + + nao:numericRating + + + This property extends , 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. + + + + + nao:creator + + + 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 class. + + + + + nao:contributor + + + This property refers to additional contributors for a + resource and is otherwise similar to . + + + + + nao:modified + + + Represents the modification date/time [xsd:dateTime] for a resource. More of an abstract class, its subproperties and prove to be more useful. + + + + + nao:created + + + Via this property the creation date/time for a resource can be defined. A subproperty of nao:modified, the expected value is of type [xsd:dateTime] and a typical value is of the form "2007-08-15T23:59:55.329Z". The maximum cardinality for this property is set to 1. + + + + + nao:lastModified + + + This property defines the date/time when a resource was most recently modified. It is a subproperty of . The maximum cardinality for this property is also set to 1. + + + + + nao:score + + + 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 . Allowed values for this property are of the [xsd:float] + datatype. + + + + + nao:scoreParameter + + + Multiple score parameters (e.g. nao:numericRating, nao:lastModified) can be input to a mathematical algorithm that computes an overall for a resource. The score parameters in question need to be defined as a subproperty of this property - thus effectively is a marker property. Ranking algorithms will compute the values of multiple subproperties of scoreParameter and then compute the 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 [xsd:float] datatype. + + + + + nao:FreeDesktopIcon + + + This class represents a desktop icon as defined in the + FreeDesktop Icon Naming standard and it is a subclass of . is a required property referring to the name of the icon. + + + + + nao:iconName + + + Values of this property contain the FreeDesktop standard icon name (literal) as defined in the FreeDesktop Naming Specification. The use of the property is required for every instance of since its minimum cardinality is set to 1. + + + + + nao:hasSubResource + + + 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 . This property is transitive in + nature. + + + + + nao:hasSuperResource + + + This property is the inverse of nao:hasSubResource. 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. + + + +
+ +
+ Tagging as Annotation + + 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. shows how can be used as a special case of the relation given in . The unique default name given by the user when creating a tag is defined by . Other custom names for the tag can be defined using while a custom user description can be provided via nao:description. A custom default icon or image can be attached to the tag via , making the icon in question an instance of . 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 . An automatic inverse relationship is created to link the new tag with the resource via . + +
+ + + + + + Figure 3. Modelling conventional tagging + +
+
+ +
+ Generic Annotation Example + + 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: + + + + [1] a resource representing Claudia on the user's desktop + (ex:Claudia) + + + + [2] a resource representing the organisation SAP on the user's + desktop (ex:SAP) + + + + Furthermore, the user states that the photo 'is about' (via + nao:hasTopic) the following resources: + + [3] a concept from a Work ontology defining a colleague at + work (work:Colleague) + + + + [4] a concept from a Work ontology defining a working office + (work:Office) + + [5] The user defines a custom personal identifier for + the photo, 'ClaudiaOffice20070815'. + + [6] Finally, the user also tags the photo with an instance of + nao:Tag they create: + + + + + [7],[8] The user labels the new tag 'Work', with the + alternative labels 'SAP' and 'WorkPlace'. + + + + [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. + + + The resulting statements are generated and stored within a named graph 'ex:i1'. Apart from the obvious statements, note the following automatically generated statements + + + + + [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. + + + + [12] The icon used as a symbol for the tag (ex:WorkIcon) is + now also an instance of nao:Symbol. + + + + 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. + + + + +ex:i1 { +[1] ex:DSCF001 nao:isRelated ex:Claudia , +[2] ex:SAP ; +[3] nao:hasTopic work:Colleague , +[4] work:Office ; +[5] nao:personalIdentifier "ClaudiaOffice20070815" ; +[6] nao:hasTag ex:Work . + + ex:Work a nao:Tag ; +[7] nao:prefLabel "Work" ; +[8] nao:altLabel "WorkPlace" , + "SAP" ; +[9] nao:hasSymbol ex:WorkIcon ; +[10] nao:description "Represents all about my work, workplace, workmates etc" ; +[11] nao:isTagFor ex:DSCF001 . + +[12] ex:WorkIcon a nao:Symbol . + +[13] ex:SAP nao:isRelated ex:DSCF001 . + +[14] ex:Claudia nao:isRelated ex:DSCF001 . } + +
+
+ +
+ Graph Metadata Vocabulary + + 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 [NRL SPECIFICATION]. 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 . + + NRL already provides vocabulary that is used to define essential graph metadata [See ], including graph role speficiation and whether the graph is a document graph (see ), whether a graph is updatable or otherwise (via ) and specification of the declarative semantics for a graph (via ). + + Generic annotation vocabulary given in this ontology is also applicable to named graphs (which are in fact special cases of a resource). In particular, , , and 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 . + + In contrast to vocabularies like the Ontology Metadata Vocabulary [OMV Report], which was a major source of inspiration for this vocabulary, our vocabulary is applicable to all Graph Roles as defined in NRL (), and not just ontologies. The majority of graph metadata properties thus have as their domain. Other properties apply specifically to (documents that encode named graphs). + +
+ + + + + + Figure 4. Graph Roles Hierarchy + +
+ + 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. These special graphs are marked using the [] role, also shown in and linked to their respective graphs via []. 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 []. + +
+ General Graph Metadata + + 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 and are listed here, since their + common superclass is . 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 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. + +
+ + + + + + Figure 5. General Graph Metadata properties + +
+ + + + nao:hasDefaultNamespace + + + 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. + + + + + nao:hasDefaultNamespaceAbbreviation + + + 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. + + + + + nao:engineeringTool + + + 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. + + + + + nao:version + + + 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 [xsd:float] + datatype. A graph can have at most one version, hence the maximum + cardinality is 1. + + + + + nao:status + + + Tracking information for the contents of a graph can be + specified via this property. Typical values, of type string, + include "Stable", "Unstable" and "Testing". + + + +
+ +
+ Document Graph Metadata + + A special class in the NRL specifications, [], 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 , applies only to instances of such graphs. + +
+ + + + + + Figure 6. Graph Metadata for Graphs encoded in documents + +
+ + + + nao:serializationLanguage + + + This property states the graph serialization language for + the document, e.g. XML/RDFS, RDFS/N3, TriG etc. + + + +
+ +
+ Graph Metadata Example + + The following example demonstrates the use and best practice for + the Graph Metadata Vocabulary given in this section. + + [1] In this example we assume that a named graph with the role of + an ontology exists and is given by ex:o1. + + [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. + + [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 . + + [5] Metadata for the actual graph being described is then + provided. This metadata includes the following: + + + + [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 (usually not within this + graph) that ex:SAP, ex:Dirk and ex:Claudia are annotators and + therefore instances of nao:Party. + + + + [7] The ontology is defined to be 'Stable' at version 1.2. The + last modified time is also represented. + + + + [8] A static, standard namespace and namespace abbreviation + are defined. + + + + [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 . + + + + +[1] ex:o1 { + # Work Ontology provided in this named graph + } + +[2] ex:o1/metadata { +[3] ex:o1/metadata a nrl:GraphMetadata ; +[4] nrl:coreGraphMetadataFor ex:o1 . } + +[5] ex:o1 a nrl:Ontology ; +[6] nao:creator ex:SAP ; + nao:contributor ex:Dirk , + ex:Claudia ; +[7] nao:version "1.2" ; + nao:lastModified "2007-08-15T23:59:55.329Z" . + nao:status "Stable" ; +[8] nao:hasNamespace "http://www.example.org/ontologies/work#" ; + nao:hasNamespaceAbbreviation "work" ; +[9] nrl:updatable "0" . } + +
+
+ +
+ References + + + NRL SPECIFICATIONS + + + NEPOMUK Representation Language (NRL) Vocabulary Specification. NEPOMUK., Task-Force Ontologies. http://www.semanticdesktop.org/ontologies/nrl. + + + + + OMV Report + + + Ontology Metadata Vocabulary for the Semantic. Web. Jens Hartmann (University of Karlsruhe), Raul Palma (Universidad Politecnica de Madrid) and Elena Paslaru Bontas (Free University of Berlin). http://ontoware.org/projects/omv/ + + + +
Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nao/nao-named-graphs.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nao/nao-named-graphs.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nao/nao-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nao/nao-ontology-visualization.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nao/nao-tag-class.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nao/nao-tag-class.png differ diff -Nru shared-desktop-ontologies-0.8.1/nao/nao.trig.in shared-desktop-ontologies-0.9.0/nao/nao.trig.in --- shared-desktop-ontologies-0.8.1/nao/nao.trig.in 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nao/nao.trig.in 2012-02-10 21:02:59.000000000 +0000 @@ -51,7 +51,7 @@ rdfs:label "has default namespace abbreviation" ; rdfs:range rdfs:Literal ; rdfs:subPropertyOf ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdfs:Class ; @@ -81,7 +81,8 @@ rdfs:label "score" ; rdfs:range xsd:float ; rdfs:subPropertyOf ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 ; + nao:userVisible false . a rdf:Property ; @@ -106,7 +107,8 @@ rdfs:label "has Subresource" ; rdfs:range rdfs:Resource ; rdfs:subPropertyOf ; - nrl:inverseProperty nao:hasSuperResource . + nrl:inverseProperty nao:hasSuperResource ; + nao:userVisible false . a rdf:Property ; @@ -114,7 +116,8 @@ rdfs:label "has Superresource" ; rdfs:range rdfs:Resource ; rdfs:subPropertyOf ; - nrl:inverseProperty nao:hasSubResource . + nrl:inverseProperty nao:hasSubResource ; + nao:userVisible false . a rdf:Property ; @@ -139,7 +142,7 @@ rdfs:label "version" ; rdfs:range xsd:float ; rdfs:subPropertyOf ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdf:Property ; @@ -162,7 +165,7 @@ rdfs:label "preferred symbol" ; rdfs:subPropertyOf ; rdfs:range ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdf:Property ; @@ -186,7 +189,7 @@ rdfs:domain nrl:DocumentGraph ; rdfs:label "serialization language" ; rdfs:range rdfs:Literal ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdf:Property ; @@ -195,7 +198,7 @@ rdfs:label "creator" ; rdfs:range ; rdfs:subPropertyOf , dc:creator ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger. + nrl:maxCardinality 1 . a rdf:Property ; @@ -205,6 +208,7 @@ a rdf:Property ; + a nrl:NonDefiningProperty ; rdfs:subPropertyOf ; rdfs:comment "Annotation for a resource in the form of an unrestricted rating" ; rdfs:domain rdfs:Resource ; @@ -218,7 +222,7 @@ rdfs:domain rdfs:Resource ; rdfs:label "numeric rating" ; rdfs:range xsd:integer ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdfs:Class ; @@ -241,7 +245,7 @@ rdfs:label "has default namespace" ; rdfs:range rdfs:Literal ; rdfs:subPropertyOf ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdf:Property ; @@ -258,7 +262,7 @@ rdfs:label "created at" ; rdfs:range xsd:dateTime ; rdfs:subPropertyOf ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdf:Property ; @@ -267,7 +271,7 @@ rdfs:label "last modified at" ; rdfs:range xsd:dateTime ; rdfs:subPropertyOf ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdf:Property ; @@ -282,7 +286,7 @@ rdfs:label "status" ; rdfs:range rdfs:Literal ; rdfs:subPropertyOf ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdf:Property ; @@ -298,7 +302,7 @@ rdfs:label "preferred label" ; rdfs:range rdfs:Literal ; rdfs:subPropertyOf rdfs:label ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdf:Property ; @@ -306,7 +310,7 @@ rdfs:label "preferred label plural form" ; rdfs:range rdfs:Literal ; rdfs:subPropertyOf rdfs:label ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger . + nrl:maxCardinality 1 . a rdf:Property ; @@ -351,7 +355,7 @@ rdfs:label "deprecated" ; rdfs:domain rdfs:Resource ; rdfs:range rdfs:Resource ; - nrl:maxCardinality "1"^^xsd:nonNegativeInteger. + nrl:maxCardinality 1 . nao:userVisible a rdf:Property ; @@ -375,6 +379,11 @@ rdfs:domain rdfs:Resource ; rdfs:range nao:Agent ; rdfs:subPropertyOf nao:annotation . + + rdf:Property nao:userVisible false . + rdfs:Class nao:userVisible false . + rdfs:Resource nao:userVisible true . + nrl:Graph nao:userVisible false . } { @@ -387,7 +396,7 @@ a nrl:Ontology , nrl:DocumentGraph ; nao:hasDefaultNamespace "http://www.semanticdesktop.org/ontologies/2007/08/15/nao#" ; nao:hasDefaultNamespaceAbbreviation "nao" ; - nao:lastModified "2011-07-13T15:38:43Z" ; + nao:lastModified "2011-12-13T12:30:43Z" ; nao:serializationLanguage "TriG" ; nao:status "Unstable" ; nrl:updatable "0" ; diff -Nru shared-desktop-ontologies-0.8.1/ncal/ncal-main.docbook shared-desktop-ontologies-0.9.0/ncal/ncal-main.docbook --- shared-desktop-ontologies-0.8.1/ncal/ncal-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/ncal/ncal-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,10 +1,27 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ + +
+
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 []. This section begins with an + in 2002 as RFC 2445 [RFC2445]. 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 @@ -18,7 +35,7 @@ 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 [ - ]. + TIMBLICAL].
@@ -30,11 +47,11 @@ Interest Group. 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 [] mentions earlier attempts by Tim - Berners-Lee ([]), Arick and Miller ([ - ]) and Dan Connoly ([ - ], [ - ]). + workshop [SWAD37] mentions earlier attempts by Tim + Berners-Lee ([TIMBLICAL]), Arick and Miller ([ + HYBRIDICAL]) and Dan Connoly ([ + ANOTHERICAL ], [ + PALMICAL]). 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 @@ -45,7 +62,7 @@ here. After three years of research the group has produced two ontologies in OWL and a W3C Interest Group Note ([ - ]) describing the design + ICALNOTE]) describing the design decisions that have been made. The first ontology, hosted under @@ -84,7 +101,7 @@ 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 [ - ] for details). This process + ICALNOTE] 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 @@ -119,7 +136,7 @@ This is against the recomendations for using property domains and ranges within Nepomuk Representational Language (See [ - ] sec. 2.3.1). The + NRLSPEC] 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. @@ -403,7 +420,7 @@ - + @@ -550,7 +567,7 @@ Differences between NCAL and ICALTZD The overall structure of NCAL is in most respects similar to ICALTZD, which is thoroughly described in [ - ]. NCAL only tries to clarify + ICALNOTE]. 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. @@ -631,12 +648,12 @@
-
+
References - [ICALNOTE] + [ICALNOTE] @@ -651,7 +668,7 @@ - [HYBRIDICAL] + [HYBRIDICAL] @@ -665,7 +682,7 @@ - [TIMBLICAL] + [TIMBLICAL] @@ -678,7 +695,7 @@ - [ANOTHERICAL] + [ANOTHERICAL] @@ -691,7 +708,7 @@ - [PALMICAL] + [PALMICAL] @@ -704,7 +721,7 @@ - [RFC2445] + [RFC2445] @@ -718,7 +735,7 @@ - [SWAD37] + [SWAD37] @@ -732,7 +749,7 @@ - [NRLSPEC] + [NRLSPEC] Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/ncal/ncal-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/ncal/ncal-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nco/nco-contact.ttl shared-desktop-ontologies-0.9.0/nco/nco-contact.ttl --- shared-desktop-ontologies-0.8.1/nco/nco-contact.ttl 1970-01-01 00:00:00.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nco/nco-contact.ttl 2012-02-10 21:02:59.000000000 +0000 @@ -0,0 +1,38 @@ +@prefix rdf: . +@prefix xsd: . +@prefix nco: . +@prefix : . + + +:UweContact a nco:Contact; + nco:nameGiven "Uwe" ; + nco:nameFamily "Schmidt" ; + nco:hasPostalAddress [ + a nco:PostalAddress ; + nco:country "Germany" ; + nco:region "Rheinland-Pfalz" ; + nco:locality "Kaiserslautern" ; + nco:postalcode "67663" ; + nco:streetAddress "Trippstadter Strasse 122" + ] ; + nco:hasEmailAddress [ + a nco:EmailAddress ; + nco:emailAddress "uwe@schmidt.de" ; + nco:contactMediumComment "Private Email" + ] ; + nco:hasAffiliation [ + a nco:Affiliation ; + nco:role "Software Developer" ; + nco:title "Senior Software Developer" ; + nco:org [ + a nco:OrganizationContact ; + nco:fullname "Deutsches Forschungszentrum fuer Kuenstliche Intelligenz" + ] ; + nco:hasEmailAddress [ + a nco:EmailAddress ; + nco:emailAddress "schmidt@dfki.de" ; + nco:contactMediumComment "Work email, only for business mail" + ] + ] . + + diff -Nru shared-desktop-ontologies-0.8.1/nco/nco-key.ttl shared-desktop-ontologies-0.9.0/nco/nco-key.ttl --- shared-desktop-ontologies-0.8.1/nco/nco-key.ttl 1970-01-01 00:00:00.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nco/nco-key.ttl 2012-02-10 21:02:59.000000000 +0000 @@ -0,0 +1,26 @@ +@prefix rdf: . +@prefix xsd: . +@prefix nco: . +@prefix nfo: . +@prefix : . + + +:JohnContact a nco:Contact; + nco:nameGiven "John" ; + nco:nameFamily "Smith" ; + nco:hasPostalAddress [ + a nco:PostalAddress ; + nco:country "UK" ; + nco:region "Greater London" ; + nco:locality "London" ; + nco:streetAddress "Oxford Street 5" + ] ; + nco:hasEmailAddress [ + a nco:EmailAddress ; + nco:emailAddress "john@smith.co.uk" ; + nco:contactMediumComment "Private Email" + ] ; + nco:key [ + a nfo:Attachment ; + nfo:fileName "john-public-key.pub" ; + ] . diff -Nru shared-desktop-ontologies-0.8.1/nco/nco-main.docbook shared-desktop-ontologies-0.9.0/nco/nco-main.docbook --- shared-desktop-ontologies-0.8.1/nco/nco-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nco/nco-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,14 +1,28 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ +
+
Introduction 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 [ - ]. The first attempt to convert + specification published in [RFC2426]. The first attempt to convert RFC 2426 to RDF was made by Renato Ianella and published in a - W3C working group note [ - ]. This ontology doesn't meet + W3C working group note[VCARDRDF]. 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 @@ -169,14 +183,14 @@ - A simple NCO Contact. + A simple NCO Contact. It represents an individual, with some contact media affiliated with an organization. His work address and telephone is also expressed. - Demonstrates how to attach + 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 @@ -184,7 +198,7 @@ - Demonstrates how + 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 @@ -193,12 +207,11 @@
-
+
References - - [VCARDRDF] + VCARDRDF Representing @@ -210,8 +223,7 @@ - - [RFC2426] + RFC2426 vcard Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nco/nco-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nco/nco-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nco/nco-photossounds.ttl shared-desktop-ontologies-0.9.0/nco/nco-photossounds.ttl --- shared-desktop-ontologies-0.8.1/nco/nco-photossounds.ttl 1970-01-01 00:00:00.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nco/nco-photossounds.ttl 2012-02-10 21:02:59.000000000 +0000 @@ -0,0 +1,47 @@ +@prefix rdf: . +@prefix xsd: . +@prefix nco: . +@prefix nfo: . +@prefix nie: . +@prefix nexif: . +@prefix nid3: . +@prefix : . + + +:JanContact a nco:Contact; + nco:nameGiven "Jan" ; + nco:nameFamily "Kowalski" ; + nco:hasPostalAddress [ + a nco:PostalAddress ; + nco:country "Poland" ; + nco:region "woj. zachodniopomorskie" ; + nco:locality "Szczecin" ; + nco:postalcode "70-507" ; + nco:streetAddress "ul. Poboznego 2" + ] ; + nco:photo [ + a nfo:Attachment ; + nfo:fileName "jan.jpg" ; + nfo:fileSize "342342"^^xsd:integer ; + nie:mimeType "image/jpeg" ; + nie:interpretedAs [ + a nexif:Photo + ] + ] ; + nco:sound [ + a nfo:Attachment ; + nfo:fileName "jan-says-helo.mp3" ; + nfo:fileSize "342342"^^xsd:integer ; + nie:mimeType "audio/mpeg" ; + nie:interpretedAs [ + a nid3:ID3Audio ; + nfo:bitsPerSample "16"^^xsd:integer ; + nfo:channels "2"^^xsd:integer ; + nfo:sampleRate "44100"^^xsd:integer ; + nfo:sampleCount "683550"^^xsd:integer + ] + ] . + + + + diff -Nru shared-desktop-ontologies-0.8.1/nco/nco.trig.in shared-desktop-ontologies-0.9.0/nco/nco.trig.in --- shared-desktop-ontologies-0.8.1/nco/nco.trig.in 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nco/nco.trig.in 2012-02-10 21:02:59.000000000 +0000 @@ -79,7 +79,7 @@ rdfs:range xsd:string . nco:url - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "A uniform resource locator associated with the given role of a Contact. Inspired by the 'URL' property defined in RFC 2426 Sec. 3.6.8." ; rdfs:domain nco:Role ; rdfs:label "url" ; @@ -115,7 +115,7 @@ nrl:maxCardinality "1" . nco:publisher - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "An entity responsible for making the InformationElement available." ; rdfs:domain nie:InformationElement ; rdfs:label "publisher" ; @@ -166,7 +166,7 @@ rdfs:subClassOf nco:VoicePhoneNumber . nco:creator - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "Creator of an information element, an entity primarily responsible for the creation of the content of the data object." ; rdfs:domain nie:InformationElement ; rdfs:label "creator" ; @@ -196,7 +196,7 @@ rdfs:range xsd:string . nco:imStatus - a rdf:Property ; + a rdf:Property, nrl:NonDefiningProperty ; rdfs:comment "Current status of the given IM account. When this property is set, the nco:imStatusType should also always be set. Applications should attempt to parse this property to determine the presence, only falling back to the nco:imStatusType property in the case that this property's value is unrecognised. Values for this property may include 'available', 'offline', 'busy' etc. The exact choice of them is unspecified, although it is recommended to follow the guidance of the Telepathy project when choosing a string identifier http://telepathy.freedesktop.org/spec/Connection_Interface_Simple_Presence.html#description" ; rdfs:domain nco:IMAccount ; rdfs:label "imStatus" ; @@ -245,7 +245,7 @@ rdfs:label "unknown" . nco:containsContact - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment """A property used to group contacts into contact groups. This property was NOT defined in the VCARD standard. See documentation for the 'ContactList' class for details""" ; @@ -270,7 +270,7 @@ rdfs:subPropertyOf nao:identifier . nco:addressLocation - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "The geographical location of a postal address." ; rdfs:domain nco:PostalAddress ; rdfs:label "addressLocation" ; @@ -286,7 +286,7 @@ rdfs:subPropertyOf nie:description . nco:representative - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "An object that represent an object represented by this Contact. Usually this property is used to link a Contact to an organization, to a contact to the representative of this organization the user directly interacts with. An equivalent for the 'AGENT' property defined in RFC 2426 Sec. 3.5.4" ; rdfs:domain nco:Contact ; rdfs:label "representative" ; @@ -407,7 +407,7 @@ rdfs:subPropertyOf nie:hasPart . nco:contributor - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "An entity responsible for making contributions to the content of the InformationElement." ; rdfs:domain nie:InformationElement ; rdfs:label "contributor" ; @@ -479,7 +479,7 @@ rdfs:subClassOf nco:PhoneNumber . nco:org - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "Name of an organization or a unit within an organization the object represented by a Contact is associated with. An equivalent of the 'ORG' property defined in RFC 2426 Sec. 3.5.5" ; rdfs:domain nco:Affiliation ; rdfs:label "org" ; @@ -535,7 +535,7 @@ rdfs:range nco:ContactGroup . nco:hasContactMedium - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "A superProperty for all properties linking a Contact to an instance of a contact medium." ; rdfs:domain nco:Role ; rdfs:label "hasContactMedium" ; @@ -643,7 +643,7 @@ rdfs:range xsd:string . nco:blogUrl - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "A Blog url." ; rdfs:domain nco:Role ; rdfs:label "blogUrl" ; @@ -699,7 +699,7 @@ nrl:maxCardinality "1". nco:hasAffiliation - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "Links a PersonContact with an Affiliation." ; rdfs:domain nco:PersonContact ; rdfs:label "hasAffiliation" ; @@ -714,7 +714,7 @@ nrl:maxCardinality 1 . nco:imStatusMessage - a rdf:Property ; + a rdf:Property, nrl:NonDefiningProperty ; rdfs:comment "A feature common in most IM systems. A message left by the user for all his/her contacts to see." ; rdfs:domain nco:IMAccount ; rdfs:label "imStatusMessage" ; @@ -747,7 +747,7 @@ nco:imCapabilityVideo a nco:IMCapability . nco:hasIMCapability - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "Indicates that an IMAccount has a certain capability." ; rdfs:domain nco:IMAccount ; rdfs:label "hasIMCapability" ; @@ -789,7 +789,7 @@ "http://www.semanticdesktop.org/ontologies/2007/03/22/nco#" ; nao:hasDefaultNamespaceAbbreviation "nco" ; - nao:lastModified "2011-07-15T09:00:58Z" ; + nao:lastModified "2011-12-13T12:44:58Z" ; nao:status "Unstable" ; nao:updatable "0 " ; nao:version "${SHAREDDESKTOPONTOLOGIES_VERSION}" ; diff -Nru shared-desktop-ontologies-0.8.1/ndo/ndo-main.docbook shared-desktop-ontologies-0.9.0/ndo/ndo-main.docbook --- shared-desktop-ontologies-0.8.1/ndo/ndo-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/ndo/ndo-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,8 +1,25 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ + +
+
Introduction The Nepomuk Download Ontology provides classes and properties to describe file downloads.
-
+
File Downloads A typical use case for NDO is file downloads. The resources involved in a file download are typically the source , the local , and optionally @@ -12,7 +29,7 @@ - A file download event including referrer web page + A file download event including referrer web page
Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/ndo/ndo-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/ndo/ndo-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nexif/nexif-main.docbook shared-desktop-ontologies-0.9.0/nexif/nexif-main.docbook --- shared-desktop-ontologies-0.8.1/nexif/nexif-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nexif/nexif-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,3 +1,20 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ + +
+
Introduction Exchangeable Image Format (EXIF) is a specification of image metadata vocabulary published by the Japan Electronics and Information Technology Industries Association . It has gained wide acceptance within the digital photography community. Most of today's digital cameras annotate the pictures with EXIF annotations. Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nexif/nexif-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nexif/nexif-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nfo/nfo-main.docbook shared-desktop-ontologies-0.9.0/nfo/nfo-main.docbook --- shared-desktop-ontologies-0.8.1/nfo/nfo-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nfo/nfo-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,3 +1,20 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ + +
+
Introduction Nepomuk File Ontology (NFO) is one of the fundamental Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nfo/nfo-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nfo/nfo-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nfo/nfo.trig.in shared-desktop-ontologies-0.9.0/nfo/nfo.trig.in --- shared-desktop-ontologies-0.8.1/nfo/nfo.trig.in 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nfo/nfo.trig.in 2012-02-10 21:02:59.000000000 +0000 @@ -1,6 +1,6 @@ # # Copyright (c) 2007 NEPOMUK Consortium -# Copyright (c) 2011 Sebastian Trueg +# Copyright (c) 2011-2012 Sebastian Trueg # All rights reserved, licensed under either CC-BY or BSD. # # You are free: @@ -765,11 +765,12 @@ rdfs:subClassOf nfo:DataContainer . nfo:hasHash - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "Links the file with it's hash value." ; rdfs:domain nfo:FileDataObject ; rdfs:label "hasHash" ; - rdfs:range nfo:FileHash . + rdfs:range nfo:FileHash ; + nao:userVisible false . nfo:codec a rdf:Property ; @@ -934,6 +935,27 @@ rdfs:subClassOf nie:DataObject ; rdfs:label "web data object" ; rdfs:comment "An information resources of which representations (files, streams) can be retrieved through a web server. They may be generated at retrieval time. Typical examples are pages served by PHP or AJAX or mp3 streams." . + + nfo:LocalFileDataObject a rdfs:Class ; + rdfs:subClassOf nfo:FileDataObject ; + rdfs:label "local file" ; + rdfs:comment "A local file data object which is stored on a local file system. Its nie:url always uses the file:/ protocol. The main use of this class is to distinguish local and non-local files." . + + nfo:depiction + a rdf:Property ; + rdfs:comment "Relates an information element to an image which depicts said element." ; + rdfs:domain rdfs:Resource ; + rdfs:label "depiction" ; + rdfs:range nfo:Image ; + nrl:inverseProperty nfo:depicts . + + nfo:depicts + a rdf:Property ; + rdfs:comment "Relates an image to the information elements it depicts." ; + rdfs:domain nfo:Image ; + rdfs:label "depicts" ; + rdfs:range rdfs:Resource ; + nrl:inverseProperty nfo:depiction . } {nfo: a nrl:Ontology ; @@ -942,7 +964,7 @@ "http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#" ; nao:hasDefaultNamespaceAbbreviation "nfo" ; - nao:lastModified "2011-08-22T12:26:40.500Z" ; + nao:lastModified "2012-01-05T11:54:40.500Z" ; nao:status "Unstable" ; nao:updatable "0 " ; nao:version "${SHAREDDESKTOPONTOLOGIES_VERSION}" ; Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nid3/nid3-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nid3/nid3-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nie/nie-main.docbook shared-desktop-ontologies-0.9.0/nie/nie-main.docbook --- shared-desktop-ontologies-0.8.1/nie/nie-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nie/nie-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,3 +1,19 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ +
+
Introduction @@ -38,12 +54,11 @@ The problem is a difficult one given the multitude of applications and data formats. Previous semantic desktop projects (e.g. - Haystackor + Haystack or Gnowsis) had to develop their solutions. Some attempts at standardization have - been made ( - Adobe - XMPor + been made (Adobe + XMP or Freedesktop.org XESAM) but a definite standard hasn't emerged yet. @@ -172,7 +187,7 @@ NIE is expressed in the NEPOMUK Representational Language as defined in the recently published - specification (). This means, that whenever some + specification ([NRLSPEC]). 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: @@ -218,12 +233,9 @@ 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. [ - ]) Apart from that many - well-established ontologies (like Dublin Core [ - ], Kanzaki EXIF [ - ] or important parts of ICAL [ - ] don't have the domains and + rules that entail facts. [RDFSEMANTICS]) Apart from that many + well-established ontologies (like Dublin Core [DCSPEC], Kanzaki EXIF [EXIFRDF] or important parts of ICAL + [ICALRDF] don't have the domains and ranges specified at all, so there is nothing to check. @@ -287,7 +299,7 @@ In domains where there are many competing 'de facto standard' ontologies - for NIE either one of them is chosen (and adapted - see - ) or both are merged into a third one, + [NRLSPEC]) 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 @@ -310,9 +322,9 @@ 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. [ - ], or [ - ]). Even if they succeeded in + non-rdf data format. (e.g. + [ICALRDF], or + [VCARDRDF]). 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 @@ -591,12 +603,11 @@ for them (subclasses and subproperties).
-
+
References - - [NRLSPEC] + [NRLSPEC] NEPOMUK Representational Language (NRL) Vocabulary Specification., @@ -607,8 +618,7 @@ - - [RDFSEMANTICS] + [RDFSEMANTICS] RDF @@ -619,8 +629,7 @@ - - [DCSPEC] + [DCSPEC] @@ -632,8 +641,7 @@ - - [ICALRDF] + [ICALRDF] Rdf calendar - an @@ -646,8 +654,7 @@ - - [VCARDRDF] + [VCARDRDF] Representing @@ -658,8 +665,7 @@ - - [EXIFRDF] + [EXIFRDF] Exif data Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nie/nie-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nie/nie-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nie/nie.trig.in shared-desktop-ontologies-0.9.0/nie/nie.trig.in --- shared-desktop-ontologies-0.8.1/nie/nie.trig.in 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nie/nie.trig.in 2012-02-10 21:02:59.000000000 +0000 @@ -186,13 +186,14 @@ rdfs:range xsd:string . nie:isPartOf - a rdf:Property, nrl:FunctionalProperty ; + a rdf:Property, nrl:FunctionalProperty, nrl:DefiningProperty ; rdfs:comment "Generic property used to express containment relationships between DataObjects. NIE extensions are encouraged to provide more specific subproperties of this one. It is advisable for actual instances of DataObjects to use those specific subproperties. Note to the developers: Please be aware of the distinction between containment relation and provenance. The isPartOf relation models physical containment, a nie:DataObject (e.g. an nfo:Attachment) is a 'physical' part of an nie:InformationElement (a nmo:Message). Also, please note the difference between physical containment (isPartOf) and logical containment (isLogicalPartOf) the former has more strict meaning. They may occur independently of each other." ; rdfs:domain nie:DataObject ; rdfs:label "isPartOf" ; rdfs:range nie:InformationElement ; rdfs:subPropertyOf dcterms:isPartOf ; - nrl:inverseProperty nie:hasPart . + nrl:inverseProperty nie:hasPart ; + nao:userVisible false . nie:disclaimer a rdf:Property ; @@ -288,7 +289,7 @@ rdfs:range xsd:string . nie:isLogicalPartOf - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "Generic property used to express 'logical' containment relationships between DataObjects. NIE extensions are encouraged to provide more specific subproperties of this one. It is advisable for actual instances of InformationElement to use those specific subproperties. Note the difference between 'physical' containment (isPartOf) and logical containment (isLogicalPartOf)" ; rdfs:domain nie:InformationElement ; rdfs:label "isLogicalPartOf" ; @@ -373,7 +374,8 @@ rdfs:label "hasPart" ; rdfs:range nie:DataObject ; rdfs:subPropertyOf nie:relatedTo , dcterms:hasPart ; - nrl:inverseProperty nie:isPartOf . + nrl:inverseProperty nie:isPartOf ; + nao:userVisible false . nie:licenseType a rdf:Property ; @@ -400,7 +402,7 @@ nrl:inverseProperty nie:isLogicalPartOf . nie:url - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:comment "URL of a DataObject. It points to the location of the object. A typial usage is FileDataObject. In cases where creating a simple file:// or http:// URL for a file is difficult (e.g. for files inside compressed archives) the applications are encouraged to use conventions defined by Apache Commons VFS Project at http://jakarta.apache.org/ commons/ vfs/ filesystems.html." ; rdfs:domain nie:DataObject ; rdfs:label "url" ; @@ -414,7 +416,7 @@ "http://www.semanticdesktop.org/ontologies/2007/01/19/nie#" ; nao:hasDefaultNamespaceAbbreviation "nie" ; - nao:lastModified "2011-06-05T10:36:58Z" ; + nao:lastModified "2011-12-13T12:36:58Z" ; nao:status "Unstable" ; nao:updatable "0 " ; nao:version "${SHAREDDESKTOPONTOLOGIES_VERSION}" ; diff -Nru shared-desktop-ontologies-0.8.1/nmm/nmm-main.docbook shared-desktop-ontologies-0.9.0/nmm/nmm-main.docbook --- shared-desktop-ontologies-0.8.1/nmm/nmm-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nmm/nmm-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,3 +1,19 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ +
+
Introduction The Nepomuk Multimedia Ontology defines metadata properties and classes for multimedia files. TODO: write a few sentences regarding usage. Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nmm/nmm-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nmm/nmm-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nmm/nmm.trig.in shared-desktop-ontologies-0.9.0/nmm/nmm.trig.in --- shared-desktop-ontologies-0.8.1/nmm/nmm.trig.in 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nmm/nmm.trig.in 2012-02-10 21:02:59.000000000 +0000 @@ -1,6 +1,6 @@ # # Copyright (c) 2009-2010 Evgeny Egorochkin -# Copyright (c) 2010-2011 Sebastian Trueg +# Copyright (c) 2010-2012 Sebastian Trueg # Copyright (c) 2010 Andrew Lake # All rights reserved, licensed under either CC-BY or BSD. # @@ -70,7 +70,7 @@ rdfs:range xsd:integer . nmm:performer - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:subPropertyOf nco:contributor ; rdfs:label "performer" ; rdfs:comment "Performer" ; @@ -78,7 +78,7 @@ rdfs:range nco:Contact . nmm:composer - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:subPropertyOf nco:contributor ; rdfs:label "composer" ; rdfs:comment "Composer" ; @@ -86,7 +86,7 @@ rdfs:range nco:Contact . nmm:lyricist - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:subPropertyOf nco:contributor ; rdfs:label "lyricist"; rdfs:comment "Lyricist"; @@ -187,7 +187,8 @@ rdfs:label "artwork" ; rdfs:comment "Associated Artwork" ; rdfs:domain nfo:Media ; - rdfs:range nfo:Image . + rdfs:range nfo:Image ; + rdfs:subPropertyOf nfo:depiction . nmm:Movie a rdfs:Class ; @@ -208,7 +209,7 @@ rdfs:comment "A TV Series has multiple seasons and episodes" . nmm:series - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:label "series" ; rdfs:comment "series" ; nrl:maxCardinality 1 ; @@ -254,7 +255,7 @@ rdfs:subPropertyOf nao:rating . nmm:writer - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:subPropertyOf nco:contributor ; rdfs:label "writer" ; rdfs:comment "Writer" ; @@ -262,7 +263,7 @@ rdfs:range nco:Contact . nmm:director - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:subPropertyOf nco:contributor ; rdfs:label "director" ; rdfs:comment "Director" ; @@ -270,7 +271,7 @@ rdfs:range nco:Contact . nmm:producer - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:subPropertyOf nco:contributor ; rdfs:label "producer" ; rdfs:comment "Producer" ; @@ -278,7 +279,7 @@ rdfs:range nco:Contact . nmm:actor - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:subPropertyOf nco:contributor ; rdfs:label "actor" ; rdfs:comment "Actor" ; @@ -286,14 +287,14 @@ rdfs:range nco:Contact . nmm:cinematographer - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:subPropertyOf nco:contributor ; rdfs:label "cinematographer" ; rdfs:domain nfo:Video ; rdfs:range nco:Contact . nmm:assistantDirector - a rdf:Property ; + a rdf:Property, nrl:DefiningProperty ; rdfs:subPropertyOf nco:contributor ; rdfs:label "assistant director" ; rdfs:domain nfo:Video ; @@ -339,7 +340,7 @@ a nrl:DocumentGraph , nrl:Ontology ; nao:hasDefaultNamespace "http://www.semanticdesktop.org/ontologies/2009/02/19/nmm#" ; nao:hasDefaultNamespaceAbbreviation "nmm" ; - nao:lastModified "2011-11-25T15:05:29" ; + nao:lastModified "2012-01-05T09:13:29" ; nao:serializationLanguage "TriG" ; nao:status "Testing" ; nrl:updatable "0" ; diff -Nru shared-desktop-ontologies-0.8.1/nmo/nmo-main.docbook shared-desktop-ontologies-0.9.0/nmo/nmo-main.docbook --- shared-desktop-ontologies-0.8.1/nmo/nmo-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nmo/nmo-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,3 +1,20 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ + +
+
Introduction Messages - the domain of the Nepomuk Message Ontology (NMO) Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nmo/nmo-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nmo/nmo-ontology-visualization.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nrl/nrl-dataflow.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nrl/nrl-dataflow.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nrl/nrl-graph-views.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nrl/nrl-graph-views.png differ diff -Nru shared-desktop-ontologies-0.8.1/nrl/nrl-main.docbook shared-desktop-ontologies-0.9.0/nrl/nrl-main.docbook --- shared-desktop-ontologies-0.8.1/nrl/nrl-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nrl/nrl-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1 +1,1862 @@ - + +
+ Ontology Visualization + + +
+ + + + + + + +
+ +
+ +
+ Introduction + + 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 RDF triple, Named Graph and Graph Views and they are introduced in this section. + + The basic concept is the RDF triple and the definition is fundamentally similar to the one given in [RDF Specification - CONCEPTS] where a triple consists of three components: + + + a subject - in the form of a URI Reference + a predicate - in the form of a URI Reference + an object - in the form of either a URI Reference or a literal + + + 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 ]. + + An RDF Graph consists of a set of triples. The definition is similar to the one given in [RDF Specification - CONCEPTS]. A Named Graph 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 []. 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 [NAMED GRAPHS] but excludes the open-world assumption [See ]. Named graphs differ in content and purpose, and for this reason Graph Roles have been introduced, representing general roles like simple data, ontology, knowledge base, plus other less generic roles. Graph roles carry Declarative Semantics, 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 Named Graph Extensions []. + + 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 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. 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 Graph Views and they are formally defined in Graph Views Extensions []. Graph views are themselves named graphs, so it is possible for a view to be applied on top of another graph view. View Specifications define how a view 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 Procedural Semantics of a graph, and the result is a Semantic View, having both declarative and procedural semantics. Conceptually, a graph gcan be given a semantics by applying a semantic realizing view v,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 are transitive (e.g. rdfs:subClass) this would imply that vwill be the extension of g with the inferred triples generated by performing the transitive closure. + + The following figure 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. 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 []. 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 the schema language (NRL Schema) provides the means to define schemas (especially information models and ontologies). The semantics partition mainly distinguishes between abstract declarative semantics, and realized procedural semantics. + +
+ + + + + Figure 1: Overview of NRL - Abstract Syntax, Concepts and Semantics + +
+ + 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 rdfs:subClassOf 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. + + 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 [] and the Graph Views extensions [] present examples that model the dataflow in this figure in TriG syntax [TRIG]. TriG is a straight-forward extension of Turtle [TURTLE]. Turtle itself is an extension of N-Triples [N-TRIPLES] which carefully takes the most useful and appropriate things added from Notation3 [NOTATION3] while keeping it in the RDF model. TriG is a plain text format created for serializing NGs and RDF Datasets. + + The dataflow is based on four existing named graphs, two having the role of [] (ontologies O1 and O2) and the other two that of [] (instance bases I1 and I2). A new named graph, O, is also defined as having the role of [] and by using the property [] it is defined as being the supergraph of both O1 and O2. This constitutes an ontology merge for O1 and O2 into O. Similarly, a new named graph, KB, is defined to have the role of [] and  is defined as the supergraph of O, I1 and I2. Therefore, KB consists of all RDF triples in O1, O2, I1 and I2. + +
+ + + + + + Figure 2: NRL Dataflow diagram +
+ + An RDF programmer would like to work with an extension of KB that includes also the realized semantics that KB is implicitly carrying. To generate this extension, or view, the RDF programmer can define an instance of [] that computes and returns the procedural semantics for KB. The view specification uses a rule language of choice that provides a number of rules, one of which computes the transitive closure of rdfs:subClassOf, as defined in the RDFS semantics, for a set of RDF triples. Executing the chosen rules over the triples in KB result in a semantic view RDFS(KB) consisting of the RDF triples in KB plus the generated entailment triples. + + 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 RDFS(KB). 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, E1, 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, E1(RDFS(KB)), 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 viewis generated upon are still intact and they have not been modified by any of the operations. + +
+ Requirements + + 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. + + The following requirements have been satisfied: + + Tool support for inferencing, interpretation, manipulation and storage. + NRL should allow for validation of ontologies. + Basic subClassOf, type, and inverseProperty inference has to be computable efficiently. + Domain and Range properties must be adhered to and verified. [See domain and range usage ] + Properties must support cardinality requirements. [See , and ] + Representation of ontology models. [See graph role ] + Ontology imports must be possible. Ontology management must be provided. [See named graph property [] + Support for Quads/Named Graphs to record provenance. [See ] + + + The following requirements are no longer in the scope of the NRL but in that of lower-level ontologies: + + The language must differentiate between concepts and web-resources. [See nrl:Thing and nrl:ResourceManifestation] + Meta-modeling needs to be supported. [See nrl:NRLClass and nrl:NRLProperty] + Support for alternative labels (thesauri helpers) alongside labels is required. [See alternative labels property nrl:altLabel + n-ary relations should be supported. [See nrl:relationProperty] + It must provide some basic semantic relations. [See nrl:partOf, nrl:hasTopic and nrl:relationProperty] + Typing on reifications and contexts. + + + The following requirements have not been satisfied: + + Support for imprecise/fuzzy/probabilistic representations. + + + Note: The fulfillment of this requirement will be postponed until a non-imprecise version of NRL is stable. + The following requirement has been retracted: + + Typing on container contents. Containers are to be avoided altogether. [See Recommendation + +
+ +
+ RDF/S and NRL Compatibility + This specification provides some recommendations as to the use of some RDF/S elements or constructs []. It must be noted that if these recommendations are not followed, this still results in legal RDF/S data and therefore legal NRL data. However this does not imply that such data would be valid 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. + + Since NRL is based on the Named Graph paradigm [See ], NRL data cannot be directly represented with plain RDF/S since NG's are an extension on top 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 [SPARQL-QUERY]. +
+ +
+ Naming + The URI for the NRL Vocabulary is http://www.semanticdesktop.org/ontologies/yyyy/mm/dd/nrl# subject to the date of the latest stable version. + + 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. + + + Examples + + + + + + + http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#Classhttp://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#ExampleClass + http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#propertyhttp://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#exampleProperty + + + + + + +
+ +
+ Persistence + The NRL Vocabulary specification defined here and any previous or later versions, plus the NRL ontology itself [http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#] will be provided as persistent resources. +
+ +
+ Social Semantic Desktop Ontologies + + 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. + + 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 instances of the representational ontology. + + 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: + + Information Element Ontology [NIE] - to handle physical resource (e.g. documents, web pages, files etc.) + Annotation Ontology [NAO] - to handle general annotation (e.g. Data annotation, Linking abstract to physical resources) as well as graph annotation (e.g. Data authorship. etc.) + Personal Information Modelling Ontology [PIMO] - to model things and relationships on the user's desktop. + +
+ +
+ External Ontology Synchronisation + 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 [OWL Overview] and [OMV Documentation]. 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: + + Re-define semantics for use within NEPOMUK ontologies. + 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 [] in the case of NRL. + + + Re-create new elements with required semantics and ignore the existing ones. + 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. + + + Re-create new elements with required semantics and provide a mapping between them and the existing elements. + 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. 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 [] 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. + + +
+ +
+ NRL and Closed World Vs. Open World Assumptions + 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. + 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 and TriG [TRIG]. We will consider the implications of importing the given three graphs g1, g2 and g3 into an external graph g. + +@prefix nrl: <http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> . +@prefix dom: <http://www.example.org/ontology/domainOntology#> . +@prefix ex: <http://www.example.org/vocabulary#> . +@prefix ex2: <http://www.example.org/vocabulary#> . +@prefix : <http://www.example.org/vocabulary#> . +[1] :g1 { +    dom:Person rdf:type rdfs:Class . +    dom:Man rdf:type rdfs:Class ; +            rdfs:subClassOf dom:Person . +    dom:Woman rdf:type rdfs:Class ; +             rdf:subClassOf dom:Person . +    dom:hasFather rdf:type rdf:Property , +                            nrl:FunctionalProperty ; +                   rdfs:domain rdf:Person ; +                   rdfs:range rdf:Man . } +[2] :g2 { +    ex:Peter rdf:type dom:Man . +    ex:Jill rdf:type dom:Person ; +             dom:hasFather ex:Peter . } +[3] :g3 { +    ex2:Jack rdf:type dom:Man . +    ex:Jill dom:hasFather ex2:Jack . } + + [1] The first graph consists of an ontology and presents three classes and a property. The classes are dom:Person and its two subclasses dom:Woman and dom:Man. The property dom:hasFather is a applicable to class dom:Person and taking as values instances of dom:Man. + [2] The second named graph is an instance base consisting of two instances, Peter as a dom:Man and Jill as a dom:Person. In addition, the dom:hasFather relation between Jill and Peter says that Peter is Jill's father. Question: Is Jill a dom:Woman? + OWA: Unknown - It is only known that Jill is a dom:Person. OWA cannot determine whether the statement is true or false. CWA: No - Jill is nowhere defined to be a dom:Woman. Therefore the statement is false. + Question: Is Peter a dom:Person? + OWA: Yes - Peter is a dom:Man, and this is a subclass of dom:Person. + CWA: Yes - Peter is a dom:Man, and this is a subclass of dom:Person. + [3] The third graph is also an instance base and presents another instance, Jack as a dom:Man. The same Jill defined in graph two, is said to have Jack as her father. + Since dom:hasFather is a functional property, Jill can have only one person related to her by that property. + OWA: It results that Jack and Peter are the same person. This statement is implicitly added to the data. + CWA: There is conflicting data in g2 and g3. An error is generated. The RDF language itself assumes an open-world and so does the definition for Named Graphs in [NAMED GRAPHS]. 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. + 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 Jill is a woman to be true. However it might not make sense to assume that the fact Jack is Peter is intentional. Under CWA, the truth of the statements is subject to explicitally stating them. + For this reason, NRL does not assume an Open World View 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 []. Therefore Open World Views 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.  +
+
+ +
+ Representing Domain Knowledge: RDF(S) and NRL Extensions to RDF(S) + + The NRL Vocabulary is an application of the [Resource Description Framework] (RDF) and the associated [RDF Schema] (RDFS). The NRL vocabulary therefore implicitly includes elements from the RDF/RDFS vocabularies. Consequently the specifications for RDF [RDF Specification] and RDFS should be regarded as part of this specification document. However, the NRL vocabulary defines some 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 [] 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. + + 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. + +
+ Resource Description Framework (RDF) Elements + 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 [] +
+ Classes + + + + + + + + Class + Superclass + Notes + + + rdf:Property + rdfs:Resource + No + + + rdf:Statement + rdfs:Resource + No + + + rdf:XMLLiteral* + rdfs:Literal + No + + + rdf:Bag + rdfs:Container + Yes + + + rdf:Seq + rdfs:Container + Yes + + + rdf:Alt + rdfs:Container + Yes + + + rdf:List + rdfs:Resource + No + + + + + *rdf:XMLLiteral is also an instance of rdfs:Datatype (see ) +
+
+ Properties + + + + + + + + + Property + Domain + Range + Notes + + + rdf:type + rdfs:Resource + rdfs:Class + No + + + rdf:subject + rdf:Statement + rdfs:Resource + No + + + rdf:predicate + rdf:Statement + rdfs:Resource + No + + + rdf:object + rdf:Statement + rdfs:Resource + No + + + rdf:value + rdfs:Resource + rdfs:Resource + No + + + rdf:first + rdf:List + rdfs:Resource + No + + + rdf:rest + rdf:List + rdf:List + No + + + + +
+
+ Other Vocabulary + + + + + + + + Name + Type + Notes + + + rdf:nil + rdfs:List + No + + + rdf:XMLLiteral + rdfs:Datatype + No + + + + +
+
+
+ RDF Schema (RDFS) Elements + 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 [] +
+ Classes + + + + + + + + Class + Superclass + Notes + + + rdfs:Resource + rdfs:Resource + No + + + rdfs:Class + rdfs:Resource + No + + + rdfs:Datatype + rdfs:Class + No + + + rdfs:Container + rdfs:Resource + Yes + + + rdfs:Literal + rdfs:Resource + No + + + rdfs:ContainerMembershipProperty + rdf:Property + Yes + + + + +
+
+ Properties + + + + + + + + + Property + Domain + Range + Notes + + + rdfs:domain + rdf:Property + rdfs:Class + Yes + + + rdfs:range + rdf:Property + rdfs:Class + Yes + + + rdfs:subClassOf + rdfs:Class + rdfs:Class + No + + + rdfs:subPropertyOf + rdf:Property + rdf:Property + No + + + rdfs:member + rdfs:Resource + rdfs:Resource + Yes + + + rdfs:isDefinedBy* + rdfs:Resource + rdfs:Resource + Yes + + + rdfs:label + rdfs:Resource + rdfs:Literal + No + + + rdfs:comment + rdfs:Resource + rdfs:Literal + No + + + rdfs:seeAlso + rdfs:Resource + rdfs:Resource + No + + + + + *rdfs:isDefinedBy is a sub property of rdfs:seeAlso +
+
+
+ Recommendations for and against the use of RDF/S elements + As discussed earlier [] 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. +
+ rdfs:domain, rdfs:range + 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. + + Recommendation: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. + + Examples In these examples and the ones that follow throughout the document, we use the example namespace for user-generated data http://mydesktop.org/mydesktop#. 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. + + +@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/ontology/yyyy/mm/dd/nrl#> . +@prefix voc: <http://www.semanticdesktop.org/ontology/desktop#> . +... +@prefix desktop: <http://mydesktop.org/mydesktop#> +... + + [1] Within the Ontology Desktop the property voc:depicts is assigned a domain of voc:ImageFile and a range of voc:Person. + [2] desktop:Myself is defined as an instance of voc:Person. + [3] desktop:MyFriend is defined as an instance of voc:Friend. + [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. + [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. + + +[1] :o1 { + ... + voc:depicts rdf:type rdf:Property ; + rdf:domain voc:ImageFile ; + rdf:range voc:Person . } + :ib1 { + ... + [2] desktop:Myself rdf:type voc:Person . + [3] desktop:MyFriend rdf:type voc:Friend . + [4] desktop:PassportPhoto rdf:type voc:ImageFile; + voc:depicts desktop:Myself . + [5] desktop:Friend20060613 rdf:type voc:ImageFile ; + voc:depicts desktop:MyFriend . } + +
+ +
+ Blank Nodes + 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. + Recommendation: The use of blank nodes is strongly discouraged. Data containing blank nodes is legal but not valid NRL data. +
+ +
+ Collections and Containers + + 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. + + + rdf:Bag is a container class whose use is discouraged. + rdf:Alt is a container class whose use is discouraged. + rdf:Seq is a container class whose use is discouraged. + 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. + 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. + rdfs:member is a super property of the container membership properties, and is not applicable to any other RDF/S or NRL element. + + + Recommendation: The use elements numbered [1] through [6] is strongly discouraged. + + Although the use of container classes and properties is discouraged, resources can still be grouped using [RDFS Collections] constructs. + + + rdf:List is a class that can be used to build descriptions of collections. A collection typically is composed of one or more lists. + rdf:first is a property that relates a list to its first element. + 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. + rdf:nil is a property that can be used to create an empty list. This is usually the last list in a collection. + + Recommendation: The combined use of elements numbered [1] through [4] is encouraged as an alternative to container elements +
+ +
+ rdfs:isDefinedBy + 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. + Recommendation: The use of rdfs:isDefinedBy is strongly discouraged. Data containing statements using this property is legal but not valid NRL data. +
+ +
+ Reification + 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. + Recommendation:The use of reification is strongly discouraged. +
+
+
+ Constraint Extensions + + 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 [rdfs:domain] and [rdfs:range]. The latter two constraints place a limitation on the class type of the resources that a property can relate (class typeconstraints).The NRL constraint extensions in turn place a limitation on the amount of values that a property can take (range cardinality constraints) and on actual pairs of resources that the property should or should not, through inference, relate (resource relation constraints). These three categories are summarized in []. 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. + + + + + + + + + Class Type Constraints + Range Cardinality Constraints + Resource Relation Constraints + + + rdfs:domain + + + + + rdfs:range + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Table 1: NRL Constraints + + It should be noted, that the recommendation given for the RDFS constraints in [] is extended to the NRL constraint extensions. 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. + + The following are the classes ([] - [) and properties ([] - []) provided in NRL as constraint extensions to RDF/S.  + + + + nrl:TransitiveProperty + + 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 [owl:TransitiveProperty]. + + Note: 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. + + Note: Transitive properties should not be defined as [] 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. + + Note: Transitive properties should not be defined as [] 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. + + Example + [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 [] + [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. + [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. + Since containsFolder is a transitive property, a reasoner can easily deduce that since MyPapers - containsFolder - PublishedPapers and PublishedPapers - containsFolder - ShortPapers, then MyPapers - containsFolder - ShortPapers as well. + + +:o1 { + ... + voc:containsFolder rdf:type rdf:Property ; + rdf:domain voc:Folder ; + rdf:range voc:Folder ; + [1] rdf:type nrl:TransitiveProperty . } + +:ib1 { + ... + desktop:MyPapers rdf:type voc:Folder ; + [2] voc:containsFolder desktop:PublishedPapers . + [3] desktop:PublishedPapers rdf:type voc:Folder ; + voc:containsFolder desktop:ShortPapers . } + + + + + + + nrl:SymmetricProperty + + 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 []. This class is similar to [owl:SymmetricProperty]. + + + + + nrl:AsymmetricProperty + + 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. + + + + + nrl:ReflexiveProperty + + + 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. + Examples + [1] voc:relatedTopic is defined as an instance of rdf:Property, applicable to instances of voc:Folder and taking instances of voc:Folder as values. relatedTopic is defined to be an instance of []. + [2] voc:hasTopic is defined as an instance of rdf:Property, applicable to instances of voc:Folder and taking instances of voc:Topic as values. hasTopic is defined to be an instance of []. + [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. + Since relatedTopic is a symmetric property, it can be inferred that Publications is a relatedTopic of Research. + [4] desktop:PublishedPapers is defined to be an instance of class voc:Folder. desktop:PublishedPapers is also stated to have topic desktop:Publications. Since hasTopic is an asymmetric property, a reasoner would know that it is not possible to say that thetopic Publications has as topic thefolder PublishedPapers. + + +:o1 { + .. + voc:relatedTopic rdf:type rdf:Property ; + rdf:domain voc:Topic ; + rdf:range voc:Topic ; + [1] rdf:type nrl:SymmetricProperty . + voc:hasTopic rdf:type rdf:Property ; + rdf:domain voc:Folder ; + rdf:range voc:Topic ; + [2] rdf:type nrl:AsymmetricProperty . } +:ib1 { + ... + [3] desktop:Publications rdf:type voc:Topic ; + voc:relatedTopic desktop:Research . + [4] desktop:PublishedPapers rdf:type voc:Folder ; + voc:hasTopic desktop:Publications . } + + + + + + nrl:FunctionalProperty + + Properties can be defined to be functional. This translates into the property having a minimum cardinality of zero and a maximum cardinality of one for each 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 []. This class is similar to [owl:FunctionalProperty]. + + + + + nrl:InverseFunctionalProperty + + 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 []. This translates into the property having a minimum cardinality of zero and a maximum cardinality of one for each 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 [owl:InverseFunctionalProperty]. + Examples + [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 []. + [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 [. + [3] desktop:MyPersonalDesktop is defined to be an instance of class voc:Desktop. It is related to Person desktop:MyUserName by the property voc:user. Since user is a functional property, it can be concluded that this instance of Desktop has only that unique particular instance of Person as user. No other instances of Person can be defined as the user of this Desktop. Under the closed-world assumption this would generate warning over conflicting data.  + [4] desktop:MyUserName is defined to be an instance of class voc:Person with a voc:email value of user.name@host.com. Since email is an  inverse functional property, it follows that  user.name@host.com cannot belong to other instances of Person. Doing so might result in conflicting data due to NRL's closed-world assumption. + + +:o1 { + ... + voc:user rdf:type rdf:Property ; + rdf:domain voc:Desktop ; + rdf:range voc:Person ; + [1] rdf:type nrl:FunctionalProperty . + voc:email rdf:type rdf:Property ; + rdf:domain voc:Person ; + rdf:range <http://www.w3.org/2001/XMLSchema#string> ; + [2] rdf:type nrl:InverseFunctionalProperty . } +:ib1 { + ... + [3] desktop:MyPersonalDesktop rdf:type voc:Desktop ; + voc:user desktop:MyUsername . + [4] desktop:MyUserName rdf:type voc:Person ; + voc:email "user.name@host.com" . } + + + + + + nrl:cardinality + + This property is a cardinality restriction property. It can be applied to instances of rdf:Property to specify a constraint on the number n of values that the property can have for each 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 n semantically distinct values. In order to correctly use the NRL vocabulary, this restriction must be always strictly respected. This property is similar to [owl:cardinality]. + + + + + nrl:minCardinality + + This property is a cardinality restriction property. It can be applied to instances of rdf:Property to specify a constraint on the minimum number n 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 n (n 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 [owl:minCardinality]. + + + + + nrl:maxCardinality + + This property is a cardinality restriction property. It can be applied to instances of rdf:Property to specify a constraint on the maximum number n 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 n (n 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 [owl:maxCardinality]. + Examples + 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 ContactPerson instances must be assigned at least one EmailAddress. + + +:o1 { + ... + voc:contactEmail rdf:type rdf:Property ; + rdf:domain voc:ContactPerson ; + rdf:range voc:EmailAddress ; + [1] nrl:minCardinality "1" . } + + + 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 ContactPerson instances must be assigned exactly one firstName. +   +:o1 { + ... + voc:firstName rdf:type rdf:Property ; + rdf:domain voc:ContactPerson ; + rdf:range <http://www.w3.org/2001/XMLSchema#string> ; + [2] nrl:minCardinality "1" ; + [3] nrl:maxCardinality "1" . } + + + + + + nrl:inverseProperty + + + 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 []. 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 [owl:inverseOf]. + Example + [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. + [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. + [2,4] This implicit inverse relationship is explicitly stated in both properties. + +:o1 { + ... + [1] voc:hasFile rdf:type rdf:Property ; + rdf:domain voc:Folder ; + rdf:range voc:File ; + [2] nrl:inverseProperty voc:inFolder . + [3] voc:inFolder rdf:type rdf:Property ; + rdf:domain voc:File ; + rdf:range voc:Folder ; + [4] nrl:inverseProperty voc:hasFile . } + + + + + + +
+
+
+ Handling Multiple Models: NRL Named Graph Extensions + + 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 [] is identified by a name. NGs provide useful additional functionality on top of RDF, particulary with respect to metametadata (data about metadata), provenance and data (in)equivalence issues. This approach is based on the workdescribed in [NAMED GRAPHS] excluding the open-world assumption described there. However, one should note that our definitions for a closed-world and open-world assumption (See Section ) differ slightly from the ones given in [NAMED GRAPHS]. 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. + + A named graph is a pair (n,g), where n is a unique URI reference denoting the assigned name for the graph g. Such a mappingfixes the graph g corresponding to n in a rigid, non-extensible way. The URI representing n can then be used from any location to refer to the corresponding set of triples belonging to the graph g. In other words, graph names, like namespaces, should be globally unique. A graph g' consistent with a different graph g named n cannot be assigned the same name n. Two different datasets asserting graphs g and g' having the same URI for a name contradict one another.  + + 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 []. 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 [SPARQL-QUERY]. An RDF dataset is composed of a default graph and an unlimited number of distinct named graphs. It is formally defined as the set {g, (n1, g1), (n2, g2), . . ., (nn, gn) } comprising of the default graph g and zero or more named graphs (n,g). + + NRL distinguishes between Graphs and Graph Roles, 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. The NEPOMUK Annotation Ontology (Refer to the NAO) includes vocabulary for providing metadata about graph roles. 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. 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 g will be contained within a separate metadata graph gm dedicated for g. A special graph role, [] is used to mark such metadata graphs. + + General graph vocabulary is defined in [] while [] is dedicated entirely to graph roles. depicts the class hierearchy supporting NGs in NRL. Graph Roles(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 ]. + +
+ + + + + Figure 3: NRL Named Graph class hierarchy + +
+ +
+ Graph Core Vocabulary + 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 []. + + + + nrl:Graph + + 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 [] are subclasses of this element [See ]. As such, there will generally be instances of specific graph roles rather than this more generic graph representation. This class is similar to [rdfg:Graph]. + + + + + nrl:DocumentGraph + 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.  + + + + nrl:subGraphOf + 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 []. This property is the inverse of []. When a graph g is defined to be a subgraph of another graph g', the latter is understood to be the supergraph of g. This property is similar to [rdfg:subGraphOf].  + + + nrl:superGraphOf + 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 []. When a graph g' is defined to be a supergraph of another graph g, the latter is understood to be a supgraph of g'. The property [] is a subproperty of this property. + + + nrl:equivalentGraph + 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 [rdfg:equivalentGraph]. + Note: 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 . When a graph g having a role R is defined to be equivalent to a graph g' having a superrole R', then g' is understood to have the more specific role R. For example, if graph g having role [] is defined as equivalent to graph g' having role [], then it can be said that graph g'has a role of []. However not all graphs can be defined to be equivalent.  For example, graph g1having role [] cannot be defined as equivalent to graph g2  if this graph has the role []. + + + + nrl:imports + This special subproperty of [] models graph imports and can be used to state that an existing named graph g' should be considered as part of graph g. This is akin to saying that g' is a subgraph of g or inversely that g is a supergraph of g'. 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. Such modelling is transitive. If graph g is imported into graph g', and g' is imported into graph g'', then g'' also includes the data represented byg. Two graphs g and g' are equivalent if they import each other. When applied to the [] role this property can be used to model ontology imports and in this case this property is similar to [owl:imports]. 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. + + + + nrl:DefaultGraph + 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 graph. This default graph instance is provided by NRL to serve this requirement. All triples existing outside any named graph (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. + + + + +
+ +
+ Graph Roles Vocabulary + This section introduces classes and properties provided in NRL that deal with Graph Roles as described in the introduction of  and depicted in . This vocabulary is closely tied with the Graph Metadata Vocabulary provided in [NAO]. 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. + + + + nrl:Data + + 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 [] alongside [] and []. + + + + + nrl:Schema + 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 [], and therefore also a subclass of []; and it is a superclass of []. + + + + nrl:InstanceBase + 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 [], and therefore also a subclass of []. + + + + nrl:Ontology + 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 [owl:Ontology]. This class is a subclass of [] and therefore also a subclass of [] and []. + + + + nrl:KnowledgeBase + 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 [] and [] roles, and is in fact defined as a subclass of both these roles. + + + + nrl:Configuration + 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 []. + + + + nrl:GraphMetadata + 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. + + + + nrl:graphMetadataFor + 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.  + + + + nrl:coreGraphMetadataFor + 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 . + Note: 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. + + + + nrl:Semantics + 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. + + + + nrl:hasSemantics + 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 []. 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 and ). However this property has a declarative rather than a procedural role. + Note:A graph role with (virtual) declarative semantics should never be assumed to also carry (realized) procedural semantics.  + + + + nrl:semanticsDefinedBy + This property links instances of the [] class to a URL for a document that defines the formal, non-machine-readable semantics that the instance is representing. + + + + nrl:semanticsLabel + This trivial property assigns a string label to instances of the [] class, in order to more easily identify and refer to different semantics. + + + + nrl:updatable + 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. + + + + +
+ +
+ Named Graph Example + The following example demonstrates the use of NG extensions and is based on TriG [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: + + + + + + + :G {Triple Set} + + + + + + This example and the one that follows in [] model the dataflow represented in . This example demonstrates how one can make use of the named graph paradigm and the syntax for named graphs presented in this section.  + + [1] The example starts by defining the required namespaces. + [2-7] Metadata about six different graphs is represented within four metadata graphs. + [3] The metadata graph describing graph ex:o1 given in [8] states that ex:o1 is an ontology (graph with role ontology). [4] ex:o1 is defined to have the declarative semantics defined by the instance RDFS. + [5] RDFS 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#'. + [6] ex:o1_metadata itself is marked as being graph metadata. + [7] ex:o2_metadata says that ex:o2 is graph equivalent to http://www.domain.com/o2.rdfs. + [8] ex:o2_metadata states also that ex:o is an ontology represented by the union of graphs ex:o1 and ex:o2. ex:o is now a supergraph of ex:o1 and ex:o2 (or http://www.domain.com/o2.rdfs). Inversely the named graphs are subgraphs of ex:o. + [9] ex:ib1_metadata states that ex:ib1 is an instance base defined in [9]. + [10] ex:kb1_metadata states that ex:kb1 is a knowledge base graph represented by the union of graphs ex:o, ex:ib1 andhttp://www.anotherdomain.com/ib2.rdfs. Alternatively, through the definition of ex:o [5], one can say that ex:kb1 is represented by the union of graphs ex:o1, ex:o2 (orhttp://www.domain.com/o2.rdfs), ex:ib1 and http://www.anotherdomain.com/ib2.rdfs, where the latter graphs are all subgraphs of ex:kb1. + [12] The representation for graph ex:o1 (an ontology) is composed of the definition of a class ex:Person, a class ex:DesktopUser which is also a subclass of ex:Person, and a symmetric property ex:knows which relates instances of ex:Person to other instansces of ex:Person. + [12] The representation for graph ex:ib1 (an instance base) is composed of the definition of an instance of ex:DesktopUser called ex:User1, and two instances of ex:Person called ex:Contact1 and ex:Contact2. ex:Contact1 'knows' ex:Contact2 and ex:User1 while ex:Contact2 'knows' ex:User1. However since ex:knows is a symmetric property, all three instances of ex:Person (or its subclass ex:DesktopUser) 'know' each other. + + +[1] @prefix nrl: <http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> . + @prefix ex: <http://www.example.org/vocabulary#> . + +[2] ex:o1_metadata { + [3] ex:o1 a nrl:Ontology ; + [4] nrl:hasSemantics ex:RDFS . + [5] ex:RDFS a nrl:Semantics ; + nrl:semanticsDefinedBy "http://www.w3.org/TR/rdf-schema#" ; + nrl:semanticsLabel "RDF/S" . + [6] ex:o1_metadata rdf:type nrl:GraphMetadata . } + + ex:o2_metadata { + [7] ex:o2 rdf:type nrl:Ontology ; + nrl:equivalentGraph <http://www.domain.com/o2.rdfs> . + [8] ex:o rdf:type nrl:Ontology ; + nrl:imports ex:o1 , + ex:o2 . + ex:o2_metadata rdf:type nrl:GraphMetadata . } + +[9] ex:ib1_metdata { + ex:ib1 rdf:type nrl:InstanceBase . + ex:ib1_metadata rdf:type nrl:GraphMetadata . } + +[10] ex:kb1_metadata { + ex:kb1 rdf:type nrl:KnowledgeBase ; + nrl:imports ex:o , + ex:ib1 , + <http://www.anotherdomain.com/ib2.rdfs> . + ex:kb1_metadata rdf:type nrl:GraphMetadata . } + +[11] ex:o1 { + ex:Person rdf:type rdfs:Class . + ex:DesktopUser rdf:type rdfs:Class ; + rdfs:subClassOf ex:Person . + ex:knows rdf:type rdf:Property , + nrl:SymmetricProperty ; + rdfs:domain ex:Person ; + rdfs:range ex:Person . } + +[12] ex:ib1 { + ex:User1 rdf:type ex:DesktopUser . + ex:Contact1 rdf:type ex:Person ; + ex:knows ex:User1 , + ex:Contact1 . + ex:Contact2 rdf:type ex:Person ; + ex:knows ex:User1 . } + + The RDF/S Ontology accesible at http://www.domain.com/o2.rdfs and serialized as RDF/XML is given and described as follows. + [1] Required namespaces are defined. + [2] The [] 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. + Note: 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 []. + [3] A class Desktop is defined. + [4] A property user is defined as relating instances of Desktop to instances of http://www.example.org/vocabulary#DesktopUser defined in ex:g1 in the example above. + +[1] <rdf:RDF + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" + xmlns:nrl="http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#"> + xmlns="http://www.domain.com/o2#"> + + [2] <nrl:Ontology rdf:about=""> + <rdf:type rdfs:resource="nrl#DocumentGraph"/> + <!--Other Graph Metadata---> + </nrl:Ontology> + + [3] <rdfs:Class rdf:ID="Desktop"/> + [4] <rdf:Property rdf:ID="user"> + <rdfs:domain rdf:resource="#Desktop"/> + <rdfs:range rdf:resource="http://www.example.org/vocabulary#DesktopUser/> + </rdf:Property> + </rdf:RDF> + + The following is the RDF/S instance base serialized as RDF/XML and accessible at http://www.anotherdomain.com/ib2.rdfs: + [1] Required namespaces are defined. + [2] Metadata about the instance base graph represented by this RDF/S document is defined through the use of []. + Note: 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 []. + [3] DesktopA is defined as an instance of o2:Desktop and related to http://www.example.org/vocabulary#User1 through the o2:user property. + +[1] <rdf:RDF + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" + xmlns:nrl="http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#" + xmlns:o2="http://www.domain.com/o2#" + xmlns="http://www.anotherdomain.com/ib2#"> + + [2] <nrl:InstanceBase rdf:about=""> + <rdf:type rdfs:resource="nrl#DocumentGraph"/> + <!--Other Graph Metadata---> + </nrl:InstanceBase> + + [3] <o2:Desktop rdf:ID="DesktopA"> + <o2:user http://www.example.org/vocabulary#User1> + </o2:Desktop> + </rdf:RDF> + +
+ +
+ Imposing Semantics on and Tailoring of Graphs: NRL Graph Views Extensions + 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 Graph Views. + + 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. depicts graph view support in NRL. As can be seen in the figure, views are themselves named graphs (subclass of ). 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 ) and so on. + +
+ + + + + Figure 4: Graph Views in NRL + +
+ + Views are defined through View Specifications 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 View Realization 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 Semantic View and in these are represented by the intersection of [] and Graph Roles. Therefore a semantic view is an instance of graph view that also carries a particular graph role. Semantic views are also depicted in , and one can quite easily draw a parallel between the two figures. One must note that the property [] 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 Declarative Semantics defined through the [] property, semantic views also carry Procedural Semantics, since the semantics of these graphs are always realized and not simply assumed.  + +
+ Views Core Vocabulary + 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. + + + + nrl:GraphView + 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 []. The view is linked its view specification through the [] property whereas the named graph that the view applies to is linked by []. 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. + + + + nrl:viewOn + This property attaches a view realisation to the respective interpreted named graph by linking instances of [] to respective instances of []. 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. + + + + nrl:hasSpecification + Views are realized according to a given view specification. This property determines the specification for a view by linking instances of [] to instances of []. View specifications are defined through instances of []. This class, its subclasses, attributes and general characteristics are introduced and defined in the following section.  + + + + +
+ +
+ Views Specification Vocabulary + This section presents the vocabulary supporting graph view specification. These specification are essentially the instructions to how a view is to be realized. + + + + nrl:ViewSpecification + 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 [] and []. 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 [] property. + + + + nrl:realizes + This property applies only to subset of views introduced as semantic views (see 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 and also in ) between graph roles and views refers to these semantic views which carry both procedural (through this property) and declarative (through []) semantics. This property should be distinguished from the [] property since this property has only a declarative role when it comes to specifying the semantics for a graph. + + Note: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 [], should also be linked to the same semantics by []. 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. + + + + nrl:RuleViewSpecification + 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 [] and [] properties, presented below. + + + + nrl:ruleLanguage + 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. + + + + nrl:rule + 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. + + + + nrl:ExternalViewSpecification + 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. + + + + nrl:externalRealizer + 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. + + + + +
+ +
+ Graph Views Example + The following example is a continuation to that given in [] and it completes the dataflow diagram presented in the introduction []. 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 []. + [1] ex:kb2_metadata states that a new graph with the role of knowledge base, ex:kb2, is a graph view over graph ex:kb1 defined in the example earlieraccording to a view specification ex:rvs.  + [2] ex:rvs is the view specification required to realize ex:kb2. It is a rule view specification, and it requires executing two rules from the SPARQL language over the graph that ex:kb2 is interpreting, namely ex:kb1. The view is defined as a semantic realizing view, which semantics are given by ex:RDFSSemantics. + [3] ex:RDFSemantics 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, RDFS. + [4] ex:kb3_metadata states that the graph ex:kb3 having role []is a graph view over ex:kb2 according to a view specification ex:evs.  + [5] The view specification for ex:kb3 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, GraphTaxonomyExtractor will return the required realized view as the graph ex:kb3. + +@prefix nrl: <http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> . +@prefix ex: <http://www.example.org/vocabulary#> . +[1] ex:kb2_metadata { + ex:kb2 rdf:type nrl:KnowledgeBase , + nrl:GraphView ; + nrl:viewOn ex:kb1 ; + nrl:hasSpecification ex:rvs . + [2] ex:rvs rdf:type nrl:RuleViewSpecification ; + nrl:realizes ex:RDFSSemantics ; + nrl:ruleLanguage "SPARQL" ; + nrl:rule "CONSTRUCT {?s ?rdfs:subClassOf ?v} WHERE ..." ; + nrl:rule "CONSTRUCT {?s ?rdf:type ?v} WHERE ..." . + [3] ex:RDFSSemantics rdf:type nrl:Semantics ; + nrl:semanticsDefinedBy "http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ ; + nrl:semanticsLabel "RDFS" . } +[4] ex:kb3_metadata { + ex:kb3 rdf:type nrl:GraphView , + nrl:KnowledgeBase ; + nrl:viewOn ex:kb2 ; + nrl:hasSpecification ex:evs . + [5] ex:evs rdf:type nrl:ExternalViewSpecification ; + nrl:externalRealizer "GraphTaxonomyExtractor" . } + +
+
+ +
+ Deprecated Elements + In general there are three criteria for excluding elements from NRL: + + Elements with no clear formal semantics. + Elements whose complexity cannot be handled. + Elements that are NEPOMUK project-specific. + Elements that do not belong to the Representation Language layer but rather to lower ontology levels. + Elements that have become redundant after introduction of the NRL concepts. + + 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. + + + + + + + nrl:Thing + Description + + +   + The superclass of all conceptual classes. See also [SKOS Concept] and [OWL Thing] + + + Reason + + + rdfs:Resource satisfies the requirements for a top Resource representation. + + + Action + + + Exclude. + + + nrl:ResourceManifestation + Description + + +   + The superclass of all files or web resources. See also [RDFS Resource] + + + Reason + + + Distinction between abstract resource and information resource not required at this level. + + + Action + + + Move to upper-level (foundational) ontology. + + + nrl:Association + Description + + +   + The superclass of n-ary relations. See also [Topic Maps Association] + + + Reason + + + Not required at this level. + + + Action + + + Move to upper-level (foundational) ontology. + + + nrl:AssociationRole + Description + + +   + The superclass of relations for N-ary associations. See also [Topic Maps Association] + + + Reason + + + Not required at this level. + + + Action + + + Move to upper-level (foundational) ontology. + + + nrl:NRLClass + Description + + +   + The NRL's own class to enable specific extensions. + + + Reason + + + No specific restrictions in this ontology requiring an extra class representation. + + + Action + + + Move to upper-level(foundational) ontology if required. + + + nrl:NRLProperty + Description + + +   + The NRL's own property to enable specific extensions. + + + Reason + + + No specific restrictions in this ontology requiring an extra property representation. + + + Action + + + Move to upper-level(foundational) ontology if required. + + + nrl:DescribingProperty + Description + + +   + This class defines a class instance to be descriptive rather than relational. Descriptive properties cannot have an inverse. See also [OWL DatatypeProperty] + + + Reason + + + Distinction between descriptive and relational properties not required at this level. + + + Action + + + Move to upper-level (foundational) ontology. + + + nrl:RelatingProperty + Description + + +   + This class defines a class instance to be relational rather than descriptive. Only relational properties can have an inverse. See also [OWL ObjectProperty] + + + Reason + + + Distinction between descriptive and relational properties not required at this level. + + + Action + + + Move to upper-level (foundational) ontology. + + + nrl:hasNamespace + Description + + +   + Specifies the standard namespace for an ontology with particular attention to the hash or slash problem. + + + Reason + + + Not required at this level. + + + Action + + + Move to Ontology Metadata Layer provided semantics are clear. + + + nrl:hasNamespaceAbbreviation + Description + + +   + Provides a means to specify the standard abbreviation for an ontology's namespace. + + + Reason + + + Not required at this level. + + + Action + + + Move to Ontology Metadata Layer provided semantics are clear. + + + nrl:isDefinedBy + Description + + +   + A standard for stating which ontology defines a ontology element, to enable more efficient queries. + + + Reason + + + Not required at this level. + + + Action + + + Move to Ontology Metadata Layer provided semantics are clear. + + + nrl:directType + Description + + +   + Specifies that a type is a direct type and not a type resulting from transitivity. + + + Reason + + + Not required since the introduction of Graph Views. + + + Action + + + Unclear + + + nrl:directSubClass + Description + + +   + Specifies a direct subclass of some class and not a subclass resulting from transitivity. + + + Reason + + + Not required since the introduction of Graph Views. + + + Action + + + Unclear + + + nrl:directSubProperty + Description + + +   + Specifies a direct subproperty of some property and not a subproperty resulting from transitivity. + + + Reason + + + Not required since the introduction of Graph Views. + + + Action + + + Unclear + + + nrl:altLabel + Description + + +   + The alternative labels for a resource. A thesauri requirement in conjunction with [rdfs:label]. See also [skos:altLabel] + + + Reason + + + This is an annotation property. + + + Action + + + Move to annotation ontology. + + + nrl:defaultValues + Description + + +   + The default value/s for a property assigned to instances of a class. Comparable to Protégé's defaultValues slot attribute. + + + Reason + + + Not required at this level. + + + Action + + + Move to general view ontology. + + + nrl:hasPart + Description + + +   + This defines a resource as having a subset resource.  + + + Reason + + + No clear formal semantics. + + + Action + + + Exclude. + + + nrl:partOf + Description + + +   + This defines a resource as being a subset of another.  + + + Reason + + + No clear formal semantics. + + + Action + + + Exclude. + + + nrl:hasTopic + Description + + +   + This states the topic of a resource. See also [SKOS isSubejctOf] + + + Reason + + + Not required at this level. + + + Action + + + Move to annotation ontology. + + + + nrl:isTopicOf + Description + + +   + This states the resource attributed to a topic. See also [SKOS isSubjectOf] + + + Reason + + + Not required at this level. + + + Action + + + Move to annotation ontology. + + + nrl:occurrence + Description + + +   + This points to an instance of a specific resource. See also [Topic Maps Occurences] and [SKOS hasSubject] + + + Reason + + + No formal semantics. + + + Action + + + Exclude. + + + nrl:isOccurenceOf + Description + + +   + This points to a resource classifying this and other similar instances. See also [Topic Maps Occurences] and [SKOS hasSubject] + + + Reason + + + No formal semantics. + + + Action + + + Exclude. + + + + +
+
+
+ NRL Semantics + Note: The Semantics of NRL will be formally specified at a later version of the language. +
+
+ References + [NAMED GRAPHS] + + + + + Named Graphs, Provenance and Trust,  J. J. Carroll, C. Bizer, P. Hayes and P. Stickler, Proceedings of WWW2005, May 2005, Japan. + + + + + + http://www.w3.org/2004/03/trix/. + + + + + + [NOTATION3] + + A readable language for data on the Web. Tim Berners-Lee, Editor. + http://www.w3.org/DesignIssues/Notation3. + + + + + + [N-TRIPLES] + + N-Triples section in [RDF Specification - Tests]  + + + + [OMV Report] + Ontology Metadata Vocabulary for the Semantic. Web + . Jens Hartmann (University of Karlsruhe), Raul Palma (Universidad Politecnica de Madrid) and Elena Paslaru Bontas (Free University of Berlin). + http://ontoware.org/projects/omv/. [OWL Overview] OWL Web Ontology Language Overview.Deborah L. McGuinness and Frank van Harmelen, Editors, W3C Recommendation, 10 February 2004, + http://www.w3.org/TR/owl-features/. + + + [RDF] + + Resource Description Framework + + + + + + + + + + [RDF Specification - PRIMER] + + RDF Primer, Frank Manola and Eric Miller, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. + + + + + + + + + + [RDF Specification - SYNTAX] + + RDF/XML Syntax Specification, Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. + + + + + + + + + + [RDF Specification - CONCEPTS] + + Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne and Jeremy J. Carroll, Editors, W3C Recommendation, 10 February 2004,  + http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. + + + + + + + + + + [RDF Specification - SEMANTICS] + + RDF Semantics, Patrick Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. + + + + + + + + + + [RDF Specification - MS] + + Resource Description Framework (RDF) Model and Syntax, W3C Recommendation, 22 February 1999 + http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/. + + + + + + + + + + [RDF Specification - TESTS] + + RDF Test Cases, Jan Grant and Dave Beckett, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/. + + + + + + [RDFS Specification] + + RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley, R.V. Guga, Brian McBride, W3C Recommendation, 10 February 2004,  + http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. + + + +[SPARQL-QUERY]SPARQL Query Language for RDF, 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/. http://www.w3.org/TR/rdf-sparql-query/. + [TRIG]TriG Syntax, Chris Bizer, Freie Universität Berlin extends Turtle to serialise [NAMED GRAPHS] http://sites.wiwiss.fu-berlin.de/suhl/bizer/TriG/. + + [TURTLE] + + Terse - RDF Triple language. Dave Beckett, Editor. 04 December 2004. + http://www.dajobe.org/2004/01/turtle/. + + + + + + + + + + + + + + + + + + + + + + + + + +
Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nrl/nrl-named-graphs.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nrl/nrl-named-graphs.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nrl/nrl-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nrl/nrl-ontology-visualization.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nrl/nrl-overview.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nrl/nrl-overview.png differ diff -Nru shared-desktop-ontologies-0.8.1/nrl/nrl.trig.in shared-desktop-ontologies-0.9.0/nrl/nrl.trig.in --- shared-desktop-ontologies-0.8.1/nrl/nrl.trig.in 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nrl/nrl.trig.in 2012-02-10 21:02:59.000000000 +0000 @@ -1,5 +1,6 @@ # # Copyright (c) 2007 NEPOMUK Consortium +# Copyright (c) 2011 Sebastian Trueg # All rights reserved, licensed under either CC-BY or BSD. # # You are free: @@ -309,6 +310,27 @@ rdfs:comment "Represents a named graph containing schematic data" ; rdfs:label "Schema" ; rdfs:subClassOf nrl:Data . + + nrl:DefiningProperty + a rdfs:Class ; + rdfs:subClassOf rdf:Property ; + rdfs:label "defining property" ; + rdfs:comment """A defining property's value is part of what defines a resource, changing it means + means chaning the identity of the resource. The set of values of all defining + properties of a resource make up its identify. + Whenever comparing resources or sharing them the value of this property should + be taken into account. By default all properties with a literal range are to be + treated as defining properties unless they are marked as nrl:NonDefiningProperty.""" . + + nrl:NonDefiningProperty + a rdfs:Class ; + rdfs:subClassOf rdf:Property ; + rdfs:label "non-defining property" ; + rdfs:comment """A non-defining property's value is not part of what defines a resource, it rather + is part of the resource's state or expresses an opinion about the resource. Whenever + comparing resources or sharing them the value of this property should not be taken into + account. By default all properties with a resource range are to be treated as + non-defining properties unless they are marked as nrl:DefiningProperty.""" . } @@ -317,7 +339,7 @@ a nrl:DocumentGraph , nrl:KnowledgeBase ; nao:hasDefaultNamespace "http://www.semanticdesktop.org/ontologies/2007/08/15/nrl#" ; nao:hasDefaultNamespaceAbbreviation "nrl" ; - nao:lastModified "2007-08-22T13:38:32.866Z" ; + nao:lastModified "2011-12-13T12:02:32.866Z" ; nao:serializationLanguage "TriG" ; nao:status "Testing" ; nrl:updatable "0" ; diff -Nru shared-desktop-ontologies-0.8.1/nso/nso-main.docbook shared-desktop-ontologies-0.9.0/nso/nso-main.docbook --- shared-desktop-ontologies-0.8.1/nso/nso-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nso/nso-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1 +1,17 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ + +
Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nso/nso-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nso/nso-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nuao/nuao-main.docbook shared-desktop-ontologies-0.9.0/nuao/nuao-main.docbook --- shared-desktop-ontologies-0.8.1/nuao/nuao-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nuao/nuao-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,3 +1,20 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ + +
+
Basic Usage NUAO provides a hierarchy of event classes all derived from . Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/nuao/nuao-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/nuao/nuao-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/nuao/nuao.trig.in shared-desktop-ontologies-0.9.0/nuao/nuao.trig.in --- shared-desktop-ontologies-0.8.1/nuao/nuao.trig.in 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/nuao/nuao.trig.in 2012-02-10 21:02:59.000000000 +0000 @@ -49,7 +49,8 @@ a rdfs:Class ; rdfs:comment "An event: activity that have a specific start datetime and possibly a duration" ; rdfs:label "event" ; - rdfs:subClassOf rdfs:Resource . + rdfs:subClassOf rdfs:Resource ; + nao:userVisible false . nuao:start a rdf:Property ; @@ -246,7 +247,7 @@ a nrl:DocumentGraph , nrl:KnowledgeBase ; nao:hasDefaultNamespace "http://www.semanticdesktop.org/ontologies/2010/01/25/nuao#" ; nao:hasDefaultNamespaceAbbreviation "nuao" ; - nao:lastModified "2011-07-15T09:52:36" ; + nao:lastModified "2011-12-12T06:51:36" ; nao:serializationLanguage "TriG" ; nao:status "Testing" ; nrl:updatable "0" ; diff -Nru shared-desktop-ontologies-0.8.1/pimo/pimo-main.docbook shared-desktop-ontologies-0.9.0/pimo/pimo-main.docbook --- shared-desktop-ontologies-0.8.1/pimo/pimo-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/pimo/pimo-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1,3 +1,20 @@ +
+ Ontology Visualization + + +
+ + + + + + + +
+ + +
+
PIMO Recommendation Document The rest of the PIMO Recommendation is published as Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/pimo/pimo-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/pimo/pimo-ontology-visualization.png differ diff -Nru shared-desktop-ontologies-0.8.1/pimo/pimo.trig.in shared-desktop-ontologies-0.9.0/pimo/pimo.trig.in --- shared-desktop-ontologies-0.8.1/pimo/pimo.trig.in 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/pimo/pimo.trig.in 2012-02-10 21:02:59.000000000 +0000 @@ -207,10 +207,10 @@ pimo:duration a rdf:Property ; - rdfs:comment "The duration of the meeting. Begin and end time." ; - rdfs:domain pimo:SocialEvent ; + rdfs:comment "The duration of the process (meeting, event, etc). Difference between start and end time." ; + rdfs:domain pimo:ProcessConcept ; rdfs:label "duration" ; - rdfs:range rdfs:Resource ; + rdfs:range xsd:duration ; rdfs:subPropertyOf pimo:datatypeProperty ; nrl:maxCardinality "1" . Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_abilitycarrierinvolvement.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_abilitycarrierinvolvement.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_attachment.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_attachment.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_dependencies.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_dependencies.png differ diff -Nru shared-desktop-ontologies-0.8.1/tmo/tmo-main.docbook shared-desktop-ontologies-0.9.0/tmo/tmo-main.docbook --- shared-desktop-ontologies-0.8.1/tmo/tmo-main.docbook 2011-11-25 16:06:31.000000000 +0000 +++ shared-desktop-ontologies-0.9.0/tmo/tmo-main.docbook 2012-02-10 21:02:59.000000000 +0000 @@ -1 +1,204 @@ - + +
+ Ontology Visualization + + +
+ + + + + + + +
+ + +
+ +
+ Introduction + + The Task Management Model Ontology (TMO) is a conceptual representation of tasks for use in personal task management applications for knowledge workers. + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + Further information on the TMO going beyond this document can be found at [TASKMODEL]. 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. +
+ +
+ Scope and Covered Use Cases + + 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 [PIMO], [NIE]. 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. + + 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: + + + + Personal Task Management - Personal Task Management consists of several parts. + + Basic task handling - Basic task handling deals with organizing a knowledge workers task, e.g., creating and populating a task. + 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. + Task priority management - Task priority management helps the knowledge worker to maintain the priorities coming with a task. + 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. + Task planning - Task planning helps the knowledge worker to structure the workload and perform work decomposition, i.e., breaking down and categorizing tasks. + + + 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. + 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. + + + 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 [TASKMODEL]. +
+ +
+ TMO Modelling + + 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 is shown in the figure below. + + + + + + + + + + + + + + + + + + + + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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: + +
+ tmo:PersonInvolvement + + + + + + + +
+ +
+ tmo:AbilityCarrierInvolvement + + + + + + + +
+ +
+ tmo:Attachment + + + + + + + +
+ +
+ tmo:TaskDependency + + + + + + + +
+ + The transmission of tasks is represented by the class + +
+ + + + + + + +
+
+ +
+ References + + + + PIMO + + Personal Information Model ontology (PIMO), Leo Sauermann, Ludger van Elst, Knud Moller, http://www.semanticdesktop.org/ontologies/pimo + + + + + NIE + + NEPOMUK Information Element Ontology (NIE), Antoni Mylka, Leo Sauermann, Michael Sintek, Ludger van Elst, http://www.semanticdesktop.org/ontologies/nie + + + + + TASKMODEL + + Task Management Model (TMO), 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 + + + +
\ No newline at end of file Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo-ontology-visualization.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo-ontology-visualization.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_overview_part1.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_overview_part1.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_overview_part2.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_overview_part2.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_overview_part3.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_overview_part3.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_personinvolvement.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_personinvolvement.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_task_pimo_subclass_part1.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_task_pimo_subclass_part1.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_task_pimo_subclass_part2.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_task_pimo_subclass_part2.png differ Binary files /tmp/eEMbXMjC8Q/shared-desktop-ontologies-0.8.1/tmo/tmo_transmission.png and /tmp/9oXGiRMT8B/shared-desktop-ontologies-0.9.0/tmo/tmo_transmission.png differ