Copyright © 2013 OSCAF® The ontologies are made available under the terms of OSCAF software license
The Nepomuk Sharing Ontology defines basic classes and properties for defining permissions with respect to sharing information in a network.
This document arose from the work done in KDE and di.me, acting upon the work done within the di.me project.
The Nepomuk Sharing Ontology defines basic classes and properties for defining permissions with respect to sharing information in a network.
Type | rdf:Property, rdfs:Resource |
Domain | rdfs:Resource |
Range | nco:Contact |
Superproperties | -- |
Subproperties | -- |
Description | The subject resource is shared with the object contact. The resource and its subresources are transferred to the receiver. An existing sharedWithContact relation implies that updates on the resource should be transferred to the contact. The contact may ask for updates actively, then the sharing party's software should send a new copy of the shared resource to the contact. Domain should be either a nie:InformationElement or a pimo:Thing but no DataObject. This includes ncal:Event instances and other resources we find on a desktop. DataObjects are the specific binary stream where an Information Element is stored, and can't be shared because the recipient will form a new binary stream to store the data object. As there is no superclass of both nie:InformationElement and pimo:Thing, the domain is rdfs:Resource. One resource can be shared to multiple contacts, the cardinality is 0..n. |
Type | rdf:Property, rdfs:Resource |
Domain | rdfs:Resource |
Range | nco:ContactGroup |
Superproperties | -- |
Subproperties | -- |
Description | The subject resource is shared with all contacts belonging to the object contact group. The resource and its subresources are transferred to the receivers. An existing sharedWithGroup relation implies that updates on the resource should be transferred to the members belonging to the group. The contact may ask for updates actively, then the sharing party's software should send a new copy of the shared resource to the contact. Domain should be either a nie:InformationElement or a pimo:Thing but no DataObject. This includes ncal:Event instances and other resources we find on a desktop. DataObjects are the specific binary stream where an Information Element is stored, and can't be shared because the recipient will form a new binary stream to store the data object. As there is no superclass of both nie:InformationElement and pimo:Thing, the domain is rdfs:Resource. One resource can be shared to multiple contact groups, the cardinality is 0..n. |
Superclasses | ppo:AccessSpace, rdfs:Resource |
Subclasses | -- |
In domain of: | nso:excludes, nso:includes, nso:sharedThrough |
In range of: | -- |
Description | A subclass of ppo:AccessSpace, this class enables the regulation of access to a space containing resources. Resource membership is still defined through the PPO properties, e.g. ppo:appliesToResource. However, within the context of this ontology, access is given to agents using the local nso:includes and nso:excludes relationships. In addition, multiple access spaces can be defined for a privacy preference, each regulating access to different agents through different access means (e.g. personal accounts). This relationship is defined using the nso:sharedThrough property. |
Type | rdf:Property, rdfs:Resource |
Domain | nso:AccessSpace |
Range | pimo:Agent |
Superproperties | ppo:hasAccessAgent |
Subproperties | -- |
Description | Enables a 'blacklist' membership property for agents with respect to privacy preferences as defined by the PPO Ontology. This is useful for the logical computation of privacy preference exclusion, e.g. sharing an access space with a predefined agent group, except for agent x. |
Type | rdf:Property, rdfs:Resource |
Domain | pimo:Agent |
Range | ppo:PrivacyPreference |
Inverse property | nso:isPrivacyPreferenceOf |
Superproperties | -- |
Subproperties | -- |
Description | Enables the possibility of creating and maintaining privacy preferences regulating an agent's (typically only the current system user) access to third parties. For more information refer to the PPO Ontology, and the pimo:excludes, pimo:includes properties below. |
Type | rdf:Property, rdfs:Resource |
Domain | nso:AccessSpace |
Range | pimo:Agent |
Minimal cardinality | 1 |
Superproperties | ppo:hasAccessAgent |
Subproperties | -- |
Description | Enables a 'whitelist' membership property for agents with respect to privacy preferences as defined by the PPO Ontology. If included within the access space of a privacy preference, an agent will have access to the resources within. At least one agent must be defined for whitelist membership in an access space. |
Type | rdf:Property, rdfs:Resource |
Domain | ppo:PrivacyPreference |
Range | pimo:Agent |
Inverse property | nso:hasPrivacyPreference |
Superproperties | -- |
Subproperties | -- |
Description | Links privacy preferences to the agent that owns them. Inverse of hasPrivacyPreference. |
Type | rdf:Property, rdfs:Resource |
Domain | rdfs:Resource |
Range | pimo:Agent |
Superproperties | -- |
Subproperties | -- |
Description | This property establishes a provenance relationship between a resource(pimo:Thing or nie:InformationElement) and the pimo:Agent (individual, or group) through which it was acquired. |
Type | rdf:Property, rdfs:Resource |
Domain | rdfs:Resource |
Range | xsd:dateTime |
Superproperties | -- |
Subproperties | -- |
Description | Records the time and date of when a resource was shared. Effectively, this could also coincide with the creation time of a local copy of the shared resource. This does not conflict with the original resource and content creation times, as defined by nao:created, nao:modified, nao:lastMofied and the subproperties nie:created, nie:modified, nie:lastModified, nie:contentCreated,nie:contentModified and nie:contentLastModified. |
Type | rdf:Property, rdfs:Resource |
Domain | nso:AccessSpace |
Range | dao:Account |
Cardinality | 1 |
Superproperties | -- |
Subproperties | -- |
Description | Determines the means (exactly one, required) that enable the access regulation for an access space. The supported access mean needs to be an instance of a dao:Account (e.g. a personal online account). |
Type | rdf:Property, rdfs:Resource |
Domain | rdfs:Resource |
Range | pimo:Agent |
Superproperties | -- |
Subproperties | nso:sharedWithContact, nso:sharedWithGroup |
Description | An alternative to nso:sharedWithContact/Group which enables the establishment of a 'shared with' relationship between a resource (pimo:Thing or nie:InformationElement) with a pimo:Agent (individual, or group). |
Type | rdf:Property, rdfs:Resource |
Domain | rdfs:Resource |
Range | nco:Contact |
Superproperties | nso:sharedWith |
Subproperties | -- |
Description | The subject resource is shared with the object contact. The resource and its subresources are transferred to the receiver. An existing sharedWithContact relation implies that updates on the resource should be transferred to the contact. The contact may ask for updates actively, then the sharing party's software should send a new copy of the shared resource to the contact. Domain should be either a nie:InformationElement or a pimo:Thing but no DataObject. This includes ncal:Event instances and other resources we find on a desktop. DataObjects are the specific binary stream where an Information Element is stored, and can't be shared because the recipient will form a new binary stream to store the data object. As there is no superclass of both nie:InformationElement and pimo:Thing, the domain is rdfs:Resource. One resource can be shared to multiple contacts, the cardinality is 0..n. |
Type | rdf:Property, rdfs:Resource |
Domain | rdfs:Resource |
Range | nco:ContactGroup |
Superproperties | nso:sharedWith |
Subproperties | -- |
Description | The subject resource is shared with all contacts belonging to the object contact group. The resource and its subresources are transferred to the receivers. An existing sharedWithGroup relation implies that updates on the resource should be transferred to the members belonging to the group. The contact may ask for updates actively, then the sharing party's software should send a new copy of the shared resource to the contact. Domain should be either a nie:InformationElement or a pimo:Thing but no DataObject. This includes ncal:Event instances and other resources we find on a desktop. DataObjects are the specific binary stream where an Information Element is stored, and can't be shared because the recipient will form a new binary stream to store the data object. As there is no superclass of both nie:InformationElement and pimo:Thing, the domain is rdfs:Resource. One resource can be shared to multiple contact groups, the cardinality is 0..n. |