# rdfs:Resource

rdfs:label: Coverage
rdfs:comment:
  The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant.


rdfs:comment:
  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 the desktop


rdfs:label: deprecated
rdfs:comment:
  If this property is assigned, the subject class, property, or resource, is deprecated and should not be used in production systems any longer. It may be removed without further notice.


rdfs:label: Is related
rdfs:comment:
  This property defines a symmetric relation between any two resources. In order for this property to be used legally, the relationship must be symmetric.


rdfs:label: Data Object
rdfs:comment:
  A unit of data that is created, annotated and processed on the user desktop. It represents a native structure the user works with. The usage of the term 'native'	is important. It means that a DataObject can be directly mapped to a data structure maintained by a native application.	This may be a file, a set of files or a part of a file. The granularity depends on the user. This class is not intended to be instantiated by itself. Use more specific subclasses.


rdfs:label: Data Source
rdfs:comment:
  A superclass for all entities from which DataObjects can be extracted. Each entity represents a native application or some other system that manages information that may be of interest to the user of the Semantic Desktop. Subclasses may include FileSystems, Mailboxes, Calendars, websites etc. The exact choice of subclasses and their properties is considered application-specific. Each data extraction application is supposed to provide it's own DataSource ontology. Such an ontology should contain supported data source types coupled with properties necessary for the application to gain access to the data sources. (paths, urls, passwords etc...)


rdfs:label: Information Element
rdfs:comment:
  A unit of content the user works with. This is a superclass for all interpretations of a DataObject.


rdfs:label: URL
rdfs:comment:
  URL pointing at the location of the resource. 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:label: Language
rdfs:comment:
  Language the InformationElement is expressed in. Users are encouraged to use the two-letter code specified in the RFC 3066


rdfs:label: Plain-text content
rdfs:comment:
  Plain-text representation of the content of a InformationElement with all markup removed. The main purpose of this property is full-text indexing and search. Its exact content is considered application-specific. The user can make no assumptions about what is and what is not contained within. Applications should use more specific properties wherever possible.


rdfs:comment:
  A common superproperty for all properties that point at legal information about an Information Element


rdfs:comment:
  A common superproperty for all relations between a piece of content and other pieces of data (which may be interpreted as other pieces of content).


rdfs:label: Role
rdfs:comment:
  A role played by a contact. Contacts that denote people, can have many roles (e.g. see the hasAffiliation property and Affiliation class). Contacts that denote Organizations or other Agents usually have one role.  Each role can introduce additional contact media.


rdfs:label: Affiliation
rdfs:comment:
  Aggregates three properties defined in RFC2426. Originally all three were attached directly to a person. One person could have only one title and one role within one organization. This class is intended to lift this limitation.


rdfs:label: ContactGroup
rdfs:comment:
  A group of Contacts. Could be used to express a group in an addressbook or on a contact list of an IM application. One contact can belong to many groups.


rdfs:label: ContactList
rdfs:comment:
  A contact list, this class represents an addressbook or a contact list of an IM application. Contacts inside a contact list can belong to contact groups.


rdfs:label: ContactMedium
rdfs:comment:
  A superclass for all contact media - ways to contact an entity represented by a Contact instance. Some of the subclasses of this class (the various kinds of telephone numbers and postal addresses) have been inspired by the values of the TYPE parameter of ADR and TEL properties defined in RFC 2426 sec. 3.2.1. and 3.3.1 respectively. Each value is represented by an appropriate subclass with two major exceptions TYPE=home and TYPE=work. They are to be expressed by the roles these contact media are attached to i.e. contact media with TYPE=home parameter are to be attached to the default role (nco:Contact or nco:PersonContact), whereas media with TYPE=work parameter should be attached to nco:Affiliation or nco:OrganizationContact.


rdfs:label: PostalAddress
rdfs:comment:
  A postal address. A class aggregating the various parts of a value for the 'ADR' property as defined in RFC 2426 Sec. 3.2.1.


rdfs:label: ModemNumber
rdfs:comment:
  A modem phone number. Inspired by the (TYPE=modem) parameter of the TEL property as defined in RFC 2426 sec  3.3.1.


rdfs:label: PagerNumber
rdfs:comment:
  A pager phone number. Inspired by the (TYPE=pager) parameter of the TEL property as defined in RFC 2426 sec  3.3.1.


rdfs:label: VoicePhoneNumber
rdfs:comment:
  A telephone number with voice communication capabilities. Class inspired by the TYPE=voice parameter of the TEL property defined in RFC 2426 sec. 3.3.1


rdfs:label: VideoTelephoneNumber
rdfs:comment:
  A Video telephone number. A class inspired by the TYPE=video parameter of the TEL property defined in RFC 2426 sec. 3.3.1


rdfs:label: IsdnNumber
rdfs:comment:
  An ISDN phone number. Inspired by the (TYPE=isdn) parameter of the TEL property as defined in RFC 2426 sec  3.3.1.


rdfs:label: ParcelDeliveryAddress
rdfs:comment:
  Parcel Delivery Addresse. Class inspired by TYPE=parcel parameter of the ADR property defined in RFC 2426 sec. 3.2.1


rdfs:label: FaxNumber
rdfs:comment:
  A fax number. Inspired by the (TYPE=fax) parameter of the TEL property as defined in RFC 2426 sec  3.3.1.


rdfs:label: CarPhoneNumber
rdfs:comment:
  A car phone number. Inspired by the (TYPE=car) parameter of the TEL property as defined in RFC 2426 sec  3.3.1.


rdfs:label: PcsNumber
rdfs:comment:
  Personal Communication Services Number. A class inspired by the TYPE=pcs parameter of the TEL property defined in RFC 2426 sec. 3.3.1


rdfs:label: InternationalDeliveryAddress
rdfs:comment:
  International Delivery Addresse. Class inspired by TYPE=intl parameter of the ADR property defined in RFC 2426 sec. 3.2.1


rdfs:label: BbsNumber
rdfs:comment:
  A Bulletin Board System (BBS) phone number. Inspired by the (TYPE=bbsl) parameter of the TEL property as defined in RFC 2426 sec  3.3.1.


rdfs:label: CellPhoneNumber
rdfs:comment:
  A cellular phone number. Inspired by the (TYPE=cell) parameter of the TEL property as defined in RFC 2426 sec  3.3.1. Usually a cellular phone can accept voice calls as well as textual messages (SMS), therefore this class has two superclasses.


rdfs:label: DomesticDeliveryAddress
rdfs:comment:
  Domestic Delivery Addresse. Class inspired by TYPE=dom parameter of the ADR property defined in RFC 2426 sec. 3.2.1


rdfs:label: nameFamily
rdfs:comment:
  The family name of an Object represented by this Contact. These applies to people that have more than one given name. The 'first' one is considered 'the' given name (see nameGiven) property. All additional ones are considered 'additional' names. The name inherited from parents is the 'family name'. e.g. For Dr. John Phil Paul Stevenson Jr. M.D. A.C.P. we have contact with: honorificPrefix: 'Dr.', nameGiven: 'John', nameAdditional: 'Phil', nameAdditional: 'Paul', nameFamily: 'Stevenson', honorificSuffix: 'Jr.', honorificSuffix: 'M.D.', honorificSuffix: 'A.C.P.'. These properties form an equivalent of the compound 'N' property as defined in RFC 2426 Sec. 3.1.2


rdfs:label: nameGiven
rdfs:comment:
  The given name for the object represented by this Contact. See documentation for 'nameFamily' property for details.


rdfs:label: nameAdditional
rdfs:comment:
  Additional given name of an object represented by this contact. See documentation for 'nameFamily' property for details.


rdfs:label: fullname
rdfs:comment:
  To specify the formatted text corresponding to the name of the object the Contact represents. An equivalent of the FN property as defined in RFC 2426 Sec. 3.1.1.


rdfs:label: url
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:label: creator
rdfs:comment:
  Creator of a data object, an entity primarily responsible for the creation of the content of the data object.


rdfs:label: region
rdfs:comment:
  Region. Inspired by the fifth part of the value of the 'ADR' property as defined in RFC 2426, sec. 3.2.1


rdfs:label: key
rdfs:comment:
  An encryption key attached to a contact. Inspired by the KEY property defined in RFC 2426 sec. 3.7.2


rdfs:label: nameHonorificSuffix
rdfs:comment:
  A suffix for the name of the Object represented by the given object. See documentation for the 'nameFamily' for details.


rdfs:label: contactUID
rdfs:comment:
  A value that represents a globally unique  identifier corresponding to the individual or resource associated with the Contact. An equivalent of the 'UID' property defined in RFC 2426 Sec. 3.6.7


rdfs:label: country
rdfs:comment:
  A part of an address specifying the country. Inspired by the seventh part of the value of the 'ADR' property as defined in RFC 2426, sec. 3.2.1


rdfs:label: nameHonorificPrefix
rdfs:comment:
  A prefix for the name of the object represented by this Contact. See documentation for the 'nameFamily' property for details.


rdfs:label: extendedAddress
rdfs:comment:
  An extended part of an address. This field might be used to express parts of an address that aren't include in the name of the Contact but also aren't part of the actual location. Usually the streed address and following fields are enough for a postal letter to arrive. Examples may include ('University of California Campus building 45', 'Sears Tower 34th floor' etc.) Inspired by the second part of the value of the 'ADR' property as defined in RFC 2426, sec. 3.2.1


rdfs:label: hasIMAccount
rdfs:comment:
  Indicates that this Instant Messaging account has the specified Instant Messaging address in the contact list.


rdfs:label: hasLocation
rdfs:comment:
  Geographical location of the contact. Inspired by the 'GEO' property specified in RFC 2426 Sec. 3.4.2


rdfs:label: nickname
rdfs:comment:
  A nickname of the Object represented by this Contact. This is an equivalen of the 'NICKNAME' property as defined in RFC 2426 Sec. 3.1.3.


rdfs:label: containsContact
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


rdfs:label: imID
rdfs:comment:
  Identifier of the IM account. Examples of such identifier might include ICQ UINs, Jabber IDs, Skype names etc.


rdfs:label: imAccountAddress
rdfs:comment:
  Instant Messaging address of this IM account. The user 'me' can send and receive messages from this IM address.


rdfs:label: note
rdfs:comment:
  A note about the object represented by this Contact. An equivalent for the 'NOTE' property defined in RFC 2426 Sec. 3.6.2


rdfs:label: representative
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:label: streetAddress
rdfs:comment:
  The streed address. Inspired by the third part of the value of the 'ADR' property as defined in RFC 2426, sec. 3.2.1


rdfs:label: hasPhoneNumber
rdfs:comment:
  A number for telephony communication with the object represented by this Contact. An equivalent of the 'TEL' property defined in RFC 2426 Sec. 3.3.1


rdfs:label: photo
rdfs:comment:
  Photograph attached to a Contact. The DataObject refered to by this property is usually interpreted as an nfo:Image. Inspired by the PHOTO property defined in RFC 2426 sec. 3.1.4


rdfs:label: birthDate
rdfs:comment:
  Birth date of the object represented by this Contact. An equivalent of the 'BDAY' property as defined in RFC 2426 Sec. 3.1.5.


rdfs:label: hasEmailAddress
rdfs:comment:
  An address for electronic mail communication with the object specified by this contact. An equivalent of the 'EMAIL' property as defined in RFC 2426 Sec. 3.3.1.


rdfs:label: postalcode
rdfs:comment:
  Postal Code. Inspired by the sixth part of the value of the 'ADR' property as defined in RFC 2426, sec. 3.2.1


rdfs:label: org
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:label: voiceMail
rdfs:comment:
  Indicates if the given number accepts voice mail. (e.g. there is an answering machine). Inspired by TYPE=msg parameter of the TEL property defined in RFC 2426 sec. 3.3.1


rdfs:label: contactGroupName
rdfs:comment:
  The name of the contact group. This property was NOT defined in the VCARD standard. See documentation of the 'ContactGroup' class for details


rdfs:label: locality
rdfs:comment:
  Locality or City. Inspired by the fourth part of the value of the 'ADR' property as defined in RFC 2426, sec. 3.2.1


rdfs:label: sound
rdfs:comment:
  Sound clip attached to a Contact. The DataObject refered to by this property is usually interpreted as an nfo:Audio. Inspired by the SOUND property defined in RFC 2425 sec. 3.6.6.


rdfs:label: hobby
rdfs:comment:
  A hobby associated with a PersonContact. This property can be used to express hobbies and interests.


rdfs:label: hasPostalAddress
rdfs:comment:
  The default Address for a Contact. An equivalent of the 'ADR' property as defined in RFC 2426 Sec. 3.2.1.


rdfs:label: imAccountType
rdfs:comment:
  Type of the IM account. This may be the name of the service that provides the IM functionality. Examples might include Jabber, ICQ, MSN etc


rdfs:label: pobox
rdfs:comment:
  Post office box. This is the first part of the value of the 'ADR' property as defined in RFC 2426, sec. 3.2.1


rdfs:label: displayname
rdfs:comment:
  The user-visible name of this account. This SHOULD be chosen by the user at account creation time. The account creation user interface is responsible for setting a reasonable default value in the user's locale; something like	'Jabber (bob@example.com)' would be sensible.


rdfs:label: FileDataObject
rdfs:comment:
  A resource containing a finite sequence of bytes with arbitrary information, that is available to a computer program and is usually based on some kind of durable storage. A file is durable in the sense that it remains available for programs to use after the current program has finished.


rdfs:label: Software
rdfs:comment:
  A piece of software. Examples may include applications and the operating system. This interpretation most commonly applies to SoftwareItems.


rdfs:label: Media
rdfs:comment:
  A piece of media content. This class may be used to express complex media containers with many streams of various media content (both aural and visual).


rdfs:label: DataContainer
rdfs:comment:
  A superclass for all entities, whose primary purpose is to serve as containers for other data object. They usually don't have any 'meaning' by themselves. Examples include folders, archives and optical disc images.


rdfs:label: RemotePortAddress
rdfs:comment:
  An address specifying a remote host and port. Such an address can be interpreted in many ways (examples of such interpretations include mailboxes, websites, remote calendars or filesystems), depending on an interpretation, various kinds of data may be extracted from such an address.


rdfs:label: MediaFileListEntry
rdfs:comment:
  A single node in the list of media files contained within an MediaList instance. This class is intended to provide a type all those links have. In valid NRL untyped resources cannot be linked. There are no properties defined for this class but the application may expect rdf:first and rdf:last links. The former points to the DataObject instance, interpreted as Media the latter points at another MediaFileListEntr. At the end of the list there is a link to rdf:nil.


rdfs:label: CompressionType
rdfs:comment:
  Type of compression. Instances of this class represent the limited set of values allowed for the nfo:compressionType property.


rdfs:label: Icon
rdfs:comment:
  An Icon (regardless of whether it's a raster or a vector icon. A resource representing an icon could have two types (Icon and Raster, or Icon and Vector) if required.


rdfs:label: PlainTextDocument
rdfs:comment:
  A file containing plain text (ASCII, Unicode or other encodings). Examples may include TXT, HTML, XML, program source code etc.


rdfs:label: Folder
rdfs:comment:
  A folder/directory. Examples of folders include folders on a filesystem and message folders in a mailbox.


rdfs:label: Filesystem
rdfs:comment:
  A filesystem. Examples of filesystems include hard disk partitions, removable media, but also images thereof stored in files.


rdfs:label: SoftwareService
rdfs:comment:
  A service published by a piece of software, either by an operating system or an application. Examples of such services may include calendar, addresbook and mailbox managed by a PIM application. This category is introduced to distinguish between data available directly from the applications (Via some Interprocess Communication Mechanisms) and data available from files on a disk. In either case both DataObjects would receive a similar interpretation (e.g. a Mailbox) and wouldn't differ on the content level.


rdfs:label: SoftwareItem
rdfs:comment:
  A DataObject representing a piece of software. Examples of interpretations of a SoftwareItem include an Application and an OperatingSystem.


rdfs:label: Presentation
rdfs:comment:
  A Presentation made by some presentation software (Corel Presentations, OpenOffice Impress, MS Powerpoint etc.)


rdfs:label: RemoteDataObject
rdfs:comment:
  A file data object stored at a remote location. Don't confuse this class with a RemotePortAddress. This one applies to a particular resource, RemotePortAddress applies to an address, that can have various interpretations.


rdfs:label: PaginatedTextDocument
rdfs:comment:
  A file containing a text document, that is unambiguously divided into pages. Examples might include PDF, DOC, PS', DVI etc.


rdfs:label: Spreadsheet
rdfs:comment:
  A spreadsheet, created by a spreadsheet application. Examples might include Gnumeric, OpenOffice Calc or MS Excel.


rdfs:label: EmbeddedFileDataObject
rdfs:comment:
  A file embedded in another data object. There are many ways in which a file may be embedded in another one. Use this class directly only in cases if none of the subclasses gives a better description of your case.


rdfs:label: Attachment
rdfs:comment:
  A file attached to another data object. Many data formats allow for attachments: emails, vcards, ical events, id3 and exif...


rdfs:label: MediaStream
rdfs:comment:
  A stream of multimedia content, usually contained within a media container such as a movie (containing both audio and video) or a DVD (possibly containing many streams of audio and video). Most common interpretations for such a DataObject include Audio and Video.


rdfs:label: Bookmark Folder
rdfs:comment:
  A folder with bookmarks of a webbrowser. Use nfo:containsBookmark to relate Bookmarks. Folders can contain subfolders, use containsBookmarkFolder to relate them.


rdfs:label: FilesystemImage
rdfs:comment:
  An image of a filesystem. Instances of this class may include CD images, DVD images or hard disk partition images created by various pieces of software (e.g. Norton Ghost)


rdfs:label: Bookmark
rdfs:comment:
  A bookmark of a webbrowser. Use nie:title for the name/label, nie:contentCreated to represent the date when the user added the bookmark, and nie:contentLastModified for modifications. nfo:bookmarks to store the link.


rdfs:label: DeletedResource
rdfs:comment:
  A file entity that has been deleted from the original source. Usually such entities are stored within various kinds of 'Trash' or 'Recycle Bin' folders.


rdfs:label: Website
rdfs:comment:
  A website, usually a container for remote resources, that may be interpreted as HTMLDocuments, images or other types of content.


rdfs:label: count
rdfs:comment:
  A common superproperty for all properties signifying the amount of atomic media data units. Examples of subproperties may include sampleCount and frameCount.


rdfs:label: channels
rdfs:comment:
  Number of channels. This property is to be used directly if no detailed information is necessary. Otherwise use more detailed subproperties.


rdfs:label: Heading
rdfs:comment:
  Specifies the direction of travelling while capturing image/video. The range of values from 0.00 to 359.99 (where 0 is due North, 90 is East, 180 South and 270 is West)


rdfs:label: Tilt
rdfs:comment:
  Vertical inclination of the camera while capturing the image, in angles starting on 0 as horizontal, positive numbers pointing up, negative angles pointing down


rdfs:label: fileSize
rdfs:comment:
  The size of the file in bytes. For compressed files it means the size of the packed file, not of the contents. For folders it means the aggregated size of all contained files and folders


rdfs:label: permissions
rdfs:comment:
  A string containing the permissions of a file. A feature common in many UNIX-like operating systems.


rdfs:label: hashAlgorithm
rdfs:comment:
  Name of the algorithm used to compute the hash value. Examples might include CRC32, MD5, SHA, TTH etc.


rdfs:label: bitDepth
rdfs:comment:
  A common superproperty for all properties signifying the amount of bits for an atomic unit of data. Examples of subproperties may include bitsPerSample and bitsPerPixel


rdfs:label: averageBitrate
rdfs:comment:
  The average overall bitrate of a media container. (i.e. the size of the piece of media in bits, divided by it's duration expressed in seconds).


rdfs:label: Media list entry
rdfs:comment:
  A certain item belongs to a media list. This can reflect that a song is in a playlist, an image or video in an Album


rdfs:label: last played position
rdfs:comment:
  Position in the media (in seconds) where the play was paused. Positive number, being 0 the beginning of the media.


rdfs:label: Time offset within media container (seconds)
rdfs:comment:
  Specifies the start offset of this resource within a larger file, such as a single song within a recording of a radio broadcast or a CD rip.


rdfs:label: Region of interest X
rdfs:comment:
  Coordinate X where the region starts. It is normalized (values between 0 and 1) to the width of the picture. Starting in the upper left corner.


rdfs:label: Region of interest Y
rdfs:comment:
  Coordinate y where the region starts. It is normalized (values between 0 and 1) to the height of the picture. Starting in the upper left corner.


rdfs:label: Region of interest type
rdfs:comment:
  Content in the area. There is a predefined set of contents in the spec: http://www.metadataworkinggroup.org


rdfs:label: Region of interest refers to
rdfs:comment:
  Link to an item that is represented in the region. The 'type' of the region can give a clue of what exact content is linked in this property


rdfs:label: Message header
rdfs:comment:
  Pairs key=value to store arbitrary message header. Note that if a property exists already in the ontology for those headers it should be used. This is just a safe guard mechanism.


rdfs:comment:
  A conversation. An exchange of one or multiple messages within a time frame or about a specific topic.


rdfs:comment:
  A communication channel. The container for all messages between participants of a specific group or in a persistent channel.


rdfs:comment:
  Well-known stable channel like an IRC room in a specific server. Predefined URL schema for the instances is recommended


rdfs:comment:
  True when the user has removed the Email in the UI but still exists in the DB. Usually a purge or confirmation from the user will actually remove the data.


rdfs:label: Phone message Folder
rdfs:comment:
  Folder for phone message (SMS and MMS). Not a subclass of nfo:Folder because it would confuse filesystem folders


rdfs:label: Report read
rdfs:comment:
  The message has been send with a flag indicating that we want to receive a confirmation when the recipient reads it


rdfs:label: reportReadStatus
rdfs:comment:
  If the message was sent with report read enable, this property stores the status of that message: if the recipient has read it, delete it, or we are still waiting for an answer


rdfs:label: Report read requested
rdfs:comment:
  The message came with the report-read flag enabled, and somebody must be send the answer back. Once the report is sent, this property goes to False.


rdfs:label: MMS Message
rdfs:comment:
  An MMS message is basically a Email with different envelop. It inherits also from SMS the folders and delivery status


rdfs:label: RecurrenceIdentifier
rdfs:comment:
  Recurrence Identifier. Introduced to provide a structure for the value of ncal:recurrenceId property. See the documentation of ncal:recurrenceId for details.


rdfs:label: AttachmentEncoding
rdfs:comment:
  Attachment encoding. This class has been introduced to express the limited vocabulary of values for the ncal:encoding property. See the documentation of ncal:encoding for details.


rdfs:label: EventStatus
rdfs:comment:
  A status of an event. This class has been introduced to express the limited set of values for the ncal:status property. The user may use the instances provided with this ontology or create his/her own. See the documentation for ncal:eventStatus for details.


rdfs:label: RecurrenceFrequency
rdfs:comment:
  Frequency of a recurrence rule. This class has been introduced to express a limited set of allowed values for the ncal:freq property. See the documentation of ncal:freq for details.


rdfs:label: Attachment
rdfs:comment:
  An object attached to a calendar entity. This class has been introduced to serve as a structured value of the ncal:attach property. See the documentation of ncal:attach for details.


rdfs:label: AccessClassification
rdfs:comment:
  Access classification of a calendar component. Introduced to express the set of values for the ncal:class property. The user may use instances provided with this ontology or create his/her own with desired semantics. See the documentation of ncal:class for details.


rdfs:label: CalendarDataObject
rdfs:comment:
  A DataObject found in a calendar. It is usually interpreted as one of the calendar entity types (e.g. Event, Journal, Todo etc.)


rdfs:label: JournalStatus
rdfs:comment:
  A status of a journal entry. This class has been introduced to express the limited set of values for the ncal:status property. The user may use the instances provided with this ontology or create his/her own. See the documentation for ncal:journalStatus for details.


rdfs:label: RecurrenceIdentifierRange
rdfs:comment:
  Recurrence Identifier Range. This class has been created to provide means to express the limited set of values for the ncal:range property. See documentation for ncal:range for details.


rdfs:label: AlarmAction
rdfs:comment:
  Action to be performed on alarm. This class has been introduced to express the limited set of values of the ncal:action property. Please refer to the documentation of ncal:action for details.


rdfs:label: TodoStatus
rdfs:comment:
  A status of a calendar entity. This class has been introduced to express the limited set of values for the ncal:status property. The user may use the instances provided with this ontology or create his/her own. See the documentation for ncal:todoStatus for details.


rdfs:label: TimeTransparency
rdfs:comment:
  Time transparency. Introduced to provide a way to express the limited vocabulary for the values of ncal:transp property. See documentation of ncal:transp for details.


rdfs:label: NcalTimeEntity
rdfs:comment:
  A time entity. Conceived as a common superclass for NcalDateTime and NcalPeriod. According to RFC 2445 both DateTime and Period can be interpreted in different timezones. The first case is explored in many properties. The second case is theoretically possible in ncal:rdate property. Therefore the timezone properties have been defined at this level.


rdfs:label: CalendarScale
rdfs:comment:
  A calendar scale. This class has been introduced to provide the limited vocabulary for the ncal:calscale property.


rdfs:label: AttendeeRole
rdfs:comment:
  A role the attendee is going to play during an event. This class has been introduced to express the limited vocabulary for the values of ncal:role property. Please refer to the documentation of ncal:role for details.


rdfs:label: BydayRulePart
rdfs:comment:
  Expresses the compound value of a byday part of a recurrence rule. It stores the weekday and the integer modifier. Inspired by RFC 2445 sec. 4.3.10


rdfs:label: Weekday
rdfs:comment:
  Day of the week. This class has been created to provide the limited vocabulary for ncal:byday property. See the documentation for ncal:byday for details.


rdfs:label: Trigger
rdfs:comment:
  An alarm trigger. This class has been created to serve as the range of ncal:trigger property. See the documentation for ncal:trigger for more details.


rdfs:label: FreebusyType
rdfs:comment:
  Type of a Freebusy indication. This class has been introduced to serve as a limited set of values for the ncal:fbtype property. See the documentation of ncal:fbtype for details.


rdfs:label: CalendarUserType
rdfs:comment:
  A calendar user type. This class has been introduced to express the limited vocabulary for the ncal:cutype property. See documentation of ncal:cutype for details.


rdfs:label: ParticipationStatus
rdfs:comment:
  Participation Status. This class has been introduced to express the limited vocabulary of values for the ncal:partstat property. See the documentation of ncal:partstat for details.


rdfs:label: RequestStatus
rdfs:comment:
  Request Status. A class that was introduced to provide a structure for the value of ncal:requestStatus property. See documentation for ncal:requestStatus for details.


rdfs:label: Organizer
rdfs:comment:
  An organizer of an event. This class has been introduced to serve as a range of ncal:organizer property. See documentation of ncal:organizer for details.


rdfs:label: Attendee
rdfs:comment:
  An attendee of an event. This class has been introduced to serve as the range for ncal:attendee property. See documentation of ncal:attendee for details.


rdfs:label: Calendar
rdfs:comment:
  A calendar. Inspirations for this class can be traced to the VCALENDAR component defined in RFC 2445 sec. 4.4, but it may just as well be used to represent any kind of Calendar.


rdfs:label: FreebusyPeriod
rdfs:comment:
  An aggregate of a period and a freebusy type. This class has been introduced to serve as a range of the ncal:freebusy property. See documentation for ncal:freebusy for details. Note that the specification of freebusy property states that the period is to be expressed using UTC time, so the timezone properties should NOT be used for instances of this class.


rdfs:label: TriggerRelation
rdfs:comment:
  The relation between the trigger and its parent calendar component. This class has been introduced to express the limited vocabulary for the ncal:related property. See the documentation for ncal:related for more details.


rdfs:label: Freebusy
rdfs:comment:
  Provide a grouping of component properties that describe either a request for free/busy time, describe a response to a request for free/busy time or describe a published set of busy time.


rdfs:label: attach
rdfs:comment:
  The property provides the capability to associate a document object with a calendar component. Defined in the RFC 2445 sec. 4.8.1.1


rdfs:label: percentComplete
rdfs:comment:
  This property is used by an assignee or delegatee of a to-do to convey the percent completion of a to-do to the Organizer. Inspired by RFC 2445 sec. 4.8.1.8


rdfs:label: delegatedTo
rdfs:comment:
  To specify the calendar users to whom the calendar user specified by the property has delegated participation. Inspired by RFC 2445 sec. 4.2.5. Originally the value type for this parameter was CAL-ADDRESS. This has been expressed as nco:Contact to promote integration between NCAL and NCO.


rdfs:label: action
rdfs:comment:
  This property defines the action to be invoked when an alarm is triggered. Inspired by RFC 2445 sec 4.8.6.1. Originally this property had a limited set of values. They are expressed as instances of the AlarmAction class.


rdfs:label: ncalTimezone
rdfs:comment:
  The timezone instance that should be used to interpret an NcalDateTime. The purpose of this property is similar to the TZID parameter specified in RFC 2445 sec. 4.2.19


rdfs:label: lastModified
rdfs:comment:
  The property specifies the date and time that the information associated with the calendar component was last revised in the calendar store. Note: This is analogous to the modification date and time for a file in the file system. Inspired by RFC 2445 sec. 4.8.7.3. Note that the RFC allows ONLY UTC time values for this property.


rdfs:label: delegatedFrom
rdfs:comment:
  To specify the calendar users that have delegated their participation to the calendar user specified by the property. Inspired by RFC 2445 sec. 4.2.4. Originally the value type for this property was CAL-ADDRESS. This has been expressed as nco:Contact to promote integration between NCAL and NCO.


rdfs:label: trigger
rdfs:comment:
  This property specifies when an alarm will trigger. Inspired by RFC 2445 sec. 4.8.6.3 Originally the value of this property could accept two types : duration and date-time. To express this fact a Trigger class has been introduced. It also has a related property to account for the RELATED parameter.


rdfs:label: related
rdfs:comment:
  To specify the relationship of the alarm trigger with respect to the start or end of the calendar component. Inspired by RFC 2445 4.2.14. The RFC has specified two possible values for this property ('START' and 'END') they have been expressed as instances of the TriggerRelation class.


rdfs:label: until
rdfs:comment:
  The UNTIL rule part defines a date-time value which bounds the recurrence rule in an inclusive manner. If the value specified by UNTIL is synchronized with the specified recurrence, this date or date-time becomes the last instance of the recurrence. If specified as a date-time value, then it MUST be specified in an UTC time format. If not present, and the COUNT rule part is also not present, the RRULE is considered to repeat forever.


rdfs:label: created
rdfs:comment:
  This property specifies the date and time that the calendar information was created by the calendar user agent in the calendar store. Note: This is analogous to the creation date and time for a file in the file system. Inspired by RFC 2445 sec. 4.8.7.1. Note that this property is a subproperty of nie:created. The domain of nie:created is nie:DataObject. It is not a superclass of UnionOf_Vevent_Vjournal_Vtodo, but since that union is conceived as an 'abstract' class, and in real-life all resources referenced by this property will also be DataObjects, than this shouldn't cause too much of a problem. Note that RFC allows ONLY UTC time values for this property.


rdfs:label: url
rdfs:comment:
  This property defines a Uniform Resource Locator (URL) associated with the iCalendar object. Inspired by the RFC 2445 sec. 4.8.4.6. Original range had been specified as URI.


rdfs:label: comment
rdfs:comment:
  Non-processing information intended to provide a comment to the calendar user. Inspired by RFC 2445 sec. 4.8.1.4 with the following reservations:  the LANGUAGE parameter has been discarded. Please use xml:lang literals to express language. For the ALTREP parameter use the commentAltRep property.


rdfs:label: summaryAltRep
rdfs:comment:
  Alternate representation of the comment. Introduced to cover the ALTREP parameter of the SUMMARY property. See documentation of ncal:summary for details.


rdfs:label: completed
rdfs:comment:
  This property defines the date and time that a to-do was actually completed. Inspired by RFC 2445 sec. 4.8.2.1. Note that the RFC allows ONLY UTC time values for this property.


rdfs:label: component
rdfs:comment:
  Links the Vcalendar instance with the calendar components. This property has no direct equivalent in the RFC specification. It has been introduced to express the containmnent relations.


rdfs:label: cutype
rdfs:comment:
  To specify the type of calendar user specified by the property. Inspired by RFC 2445 sec. 4.2.3. This parameter has a limited vocabulary. The terms that may serve as values for this property have been expressed as instances of CalendarUserType class. The user may use instances provided with this ontology or create his own.


rdfs:label: priority
rdfs:comment:
  The property defines the relative priority for a calendar component. Inspired by RFC 2445 sec. 4.8.1.9


rdfs:label: resources
rdfs:comment:
  Defines the equipment or resources anticipated for an activity specified by a calendar entity. Inspired by RFC 2445 sec. 4.8.1.10 with the following reservations:  the LANGUAGE parameter has been discarded. Please use xml:lang literals to express language. For the ALTREP parameter use the resourcesAltRep property. This property specifies multiple resources. The order is not important. it is recommended to introduce a separate triple for each resource.


rdfs:label: wkst
rdfs:comment:
  The day that's counted as the start of the week. It is used to disambiguate the byweekno rule. Defined in RFC 2445 sec. 4.3.10


rdfs:label: tzurl
rdfs:comment:
  The TZURL provides a means for a VTIMEZONE component to point to a network location that can be used to retrieve an up-to- date version of itself. Inspired by RFC 2445 sec. 4.8.3.5. Originally the range of this property had been specified as URI.


rdfs:label: statusDescription
rdfs:comment:
  Longer return status description. Inspired by the second part of the structured value of the REQUEST-STATUS property defined in RFC 2445 sec. 4.8.8.2


rdfs:label: location
rdfs:comment:
  Defines the intended venue for the activity defined by a calendar component. Inspired by RFC 2445 sec 4.8.1.7 with the following reservations:  the LANGUAGE parameter has been discarded. Please use xml:lang literals to express language.  For the ALTREP parameter use the locationAltRep property.


rdfs:label: status
rdfs:comment:
  Defines the overall status or confirmation for an Event. Based on the STATUS property defined in RFC 2445 sec. 4.8.1.11.


rdfs:label: bydayModifier
rdfs:comment:
  A n integer modifier for the BYDAY rule part. Each BYDAY value can also be preceded by a positive (+n) or negative  (-n) integer. If present, this indicates the nth occurrence of the specific day within the MONTHLY or YEARLY RRULE. For example, within a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday within the month, whereas -1MO represents the last Monday of the month. If an integer modifier is not present, it means all days of this type within the specified frequency. For example, within a MONTHLY rule, MO represents all Mondays within the month. Inspired by RFC 2445 sec. 4.3.10


rdfs:label: uid
rdfs:comment:
  This property defines the persistent, globally unique identifier for the calendar component. Inspired by the RFC 2445 sec 4.8.4.7


rdfs:label: standard
rdfs:comment:
  Links the timezone with the standard timezone observance. This property has no direct equivalent in the RFC 2445. It has been inspired by the structure of the Vtimezone component defined in sec.4.6.5


rdfs:label: method
rdfs:comment:
  This property defines the iCalendar object method associated with the calendar object. Defined in RFC 2445 sec. 4.7.2


rdfs:label: triggerDateTime
rdfs:comment:
  The exact date and time of the trigger. This property has been created to express the VALUE=DATE, and VALUE=DATE-TIME parameters of the TRIGGER property. See the documentation for ncal:trigger for more details


rdfs:label: dir
rdfs:comment:
  Specifies a reference to a directory entry associated with the calendar user specified by the property. Inspired by RFC 2445 sec. 4.2.6. Originally the data type of the value of this parameter was URI (Usually an LDAP URI). This has been expressed as rdfs:resource.


rdfs:label: interval
rdfs:comment:
  The INTERVAL rule part contains a positive integer representing how often the recurrence rule repeats. The default value is '1', meaning every second for a SECONDLY rule, or every minute for a MINUTELY rule, every hour for an HOURLY rule, every day for a DAILY rule, every week for a WEEKLY rule, every month for a MONTHLY rule andevery year for a YEARLY rule. Defined in RFC 2445 sec. 4.3.10


rdfs:label: requestStatus
rdfs:comment:
  This property defines the status code returned for a scheduling request. Inspired by RFC 2445 sec. 4.8.8.2. Original value of this property was a four-element structure. The RequestStatus class has been introduced to express it. In RFC 2445 this property could have the LANGUAGE parameter. This has been discarded in this ontology. Use xml:lang literals to express it if necessary.


rdfs:label: attachmentUri
rdfs:comment:
  The uri of the attachment. Created to express the actual value of the ATTACH property defined in RFC 2445 sec. 4.8.1.1. This property expresses the default URI datatype of that property. see ncal:attachmentContents for the BINARY datatype.


rdfs:label: periodBegin
rdfs:comment:
  Beginng of a period. Inspired by the first part of a structured value of the PERIOD datatype specified in RFC 2445 sec. 4.3.9


rdfs:label: member
rdfs:comment:
  To specify the group or list membership of the calendar user specified by the property. Inspired by RFC 2445 sec. 4.2.11. Originally this parameter had a value type of CAL-ADDRESS. This has been expressed as nco:Contact to promote integration between NCAL and NCO


rdfs:label: periodDuration
rdfs:comment:
  Duration of a period of time. Inspired by the second part of a structured value of the PERIOD datatype specified in RFC 2445 sec. 4.3.9. Note that a single NcalPeriod instance shouldn't have the periodEnd and periodDuration properties specified simultaneously.


rdfs:label: dtstamp
rdfs:comment:
  The property indicates the date/time that the instance of the iCalendar object was created. Inspired by RFC 2445 sec. 4.8.7.1. Note that the RFC allows ONLY UTC values for this property.


rdfs:label: tzoffsetfrom
rdfs:comment:
  This property specifies the offset which is in use prior to this time zone observance. Inspired by RFC 2445 sec. 4.8.3.3. The original domain was underspecified. It said that this property must appear within a Timezone component. In this ontology a TimezoneObservance class has been introduced to clarify this specification. The original range was UTC-OFFSET. There is no equivalent among the XSD datatypes so plain string was chosen.


rdfs:label: triggerDuration
rdfs:comment:
  The duration of a trigger. This property has been created to express the VALUE=DURATION parameter of the TRIGGER property. See documentation for ncal:trigger for more details.


rdfs:label: class
rdfs:comment:
  Defines the access classification for a calendar component. Inspired by RFC 2445 sec. 4.8.1.3 with the following reservations:  this property has limited vocabulary. Possible values are:  PUBLIC, PRIVATE and CONFIDENTIAL. The default is PUBLIC. Those values are expressed as instances of the AccessClassification class. The user may create his/her own if necessary.


rdfs:label: organizer
rdfs:comment:
  The property defines the organizer for a calendar component. Inspired by RFC 2445 sec. 4.8.4.3. Originally this property accepted many parameters. The Organizer class has been introduced to express them all. Note that NCAL is aligned with NCO. The actual value (of the CAL-ADDRESS type) is expressed as an instance of nco:Contact. Remember that the CN parameter has been removed from NCAL. Instead that value should be expressed using nco:fullname property of the above mentioned nco:Contact instance.


rdfs:label: calscale
rdfs:comment:
  This property defines the calendar scale used for the calendar information specified in the iCalendar object. Defined in RFC 2445 sec. 4.7.1


rdfs:label: periodEnd
rdfs:comment:
  End of a period of time. Inspired by the second part of a structured value of a PERIOD datatype specified in RFC 2445 sec. 4.3.9. Note that a single NcalPeriod instance shouldn't have the periodEnd and periodDuration properties specified simultaneously.


rdfs:label: transp
rdfs:comment:
  Defines whether an event is transparent or not  to busy time searches. Inspired by RFC 2445 sec.4.8.2.7. Values for this property can be chosen from a limited vocabulary. To express this a TimeTransparency class has been introduced.


rdfs:label: attendee
rdfs:comment:
  The property defines an 'Attendee' within a calendar component. Inspired by RFC 2445 sec. 4.8.4.1. Originally this property accepted many parameters. The Attendee class has been introduced to express them all. Note that NCAL is aligned with NCO. The actual value (of the CAL-ADDRESS type) is expressed as an instance of nco:Contact. Remember that the CN parameter has been removed from NCAL. Instead that value should be expressed using nco:fullname property of the above mentioned nco:Contact instance. The RFC stated that whenever this property is attached to a Valarm instance', 'the Attendee cannot have any parameters apart from involvedContact.']


rdfs:label: date
rdfs:comment:
  Date an instance of NcalDateTime refers to. It was conceived to express values in DATE datatype specified in RFC 2445 4.3.4


rdfs:label: rrule
rdfs:comment:
  This property defines a rule or repeating pattern for recurring events, to-dos, or time zone definitions. sec. 4.8.5.4


rdfs:label: dtend
rdfs:comment:
  This property specifies the date and time that a calendar component ends. Inspired by RFC 2445 sec. 4.8.2.2


rdfs:label: dateTime
rdfs:comment:
  Representation of a date an instance of NcalDateTime actually refers to. It's purpose is to express values in DATE-TIME datatype, as defined in RFC 2445 sec. 4.3.5


rdfs:label: tzoffsetto
rdfs:comment:
  This property specifies the offset which is in use in this time zone observance. nspired by RFC 2445 sec. 4.8.3.4. The original domain was underspecified. It said that this property must appear within a Timezone component. In this ontology a TimezoneObservance class has been introduced to clarify this specification. The original range was UTC-OFFSET. There is no equivalent among the XSD datatypes so plain string was chosen.


rdfs:label: prodid
rdfs:comment:
  This property specifies the identifier for the product that created the iCalendar object. Defined in RFC 2445 sec. 4.7.2


rdfs:label: exdate
rdfs:comment:
  This property defines the list of date/time exceptions for a recurring calendar component. Inspired by RFC 2445 sec. 4.8.5.1


rdfs:label: summary
rdfs:comment:
  Defines a short summary or subject for the calendar component. Inspired by RFC 2445 sec 4.8.1.12 with the following reservations: the LANGUAGE parameter has been discarded. Please use xml:lang literals to express language. For the ALTREP parameter use the summaryAltRep property.


rdfs:label: role
rdfs:comment:
  To specify the participation role for the calendar user specified by the property. Inspired by the RFC 2445 sec. 4.2.16. Originally this property had a limited vocabulary for values. The terms of that vocabulary have been expressed as instances of the AttendeeRole class.


rdfs:label: fbtype
rdfs:comment:
  To specify the free or busy time type. Inspired by RFC 2445 sec. 4.2.9. The RFC specified a limited vocabulary for the values of this property. The terms of this vocabulary have been expressed as instances of the FreebusyType class. The user can use instances provided with this ontology or create his own.


rdfs:label: tzname
rdfs:comment:
  Specifies the customary designation for a timezone description. Inspired by RFC 2445 sec. 4.8.3.2 The LANGUAGE parameter has been discarded. Please xml:lang literals to express languages. Original specification for the domain of this property stated that it must appear within the timezone component. In this ontology the TimezoneObservance class has been itroduced to clarify this specification.


rdfs:label: descriptionAltRep
rdfs:comment:
  Alternate representation of the calendar entity description. Introduced to cover the ALTREP parameter of the DESCRIPTION property. See documentation of ncal:description for details.


rdfs:label: commentAltRep
rdfs:comment:
  Alternate representation of the comment. Introduced to cover the ALTREP parameter of the COMMENT property. See documentation of ncal:comment for details.


rdfs:label: freebusy
rdfs:comment:
  The property defines one or more free or busy time intervals. Inspired by RFC 2445 sec. 4.8.2.6. Note that the periods specified by this property can only be expressed with UTC times. Originally this property could have many comma-separated values. Please use a separate triple for each value.


rdfs:label: version
rdfs:comment:
  This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to interpret the iCalendar object. Defined in RFC 2445 sec. 4.7.4


rdfs:label: range
rdfs:comment:
  To specify the effective range of recurrence instances from the instance specified by the recurrence identifier specified by the property. It is intended to express the RANGE parameter specified in RFC 2445 sec. 4.2.13. The set of possible values for this property is limited. See also the documentation for ncal:recurrenceId for more details.


rdfs:label: status
rdfs:comment:
  Defines the overall status or confirmation for a todo. Based on the STATUS property defined in RFC 2445 sec. 4.8.1.11.


rdfs:label: status
rdfs:comment:
  Defines the overall status or confirmation for a journal entry. Based on the STATUS property defined in RFC 2445 sec. 4.8.1.11.


rdfs:label: sequence
rdfs:comment:
  This property defines the revision sequence number of the calendar component within a sequence of revisions. Inspired by RFC 2445 sec. 4.8.7.4


rdfs:label: contact
rdfs:comment:
  The property is used to represent contact information or alternately a reference to contact information associated with the calendar component. Inspired by RFC 2445 sec. 4.8.4.2 with the following reservations: the LANGUAGE parameter has been discarded. Please use xml:lang literals to express language. For the ALTREP parameter use the contactAltRep property.RFC doesn't define any format for the string.


rdfs:label: repeat
rdfs:comment:
  This property defines the number of time the alarm should be repeated, after the initial trigger. Inspired by RFC 2445 sec. 4.8.6.2


rdfs:label: bysetpos
rdfs:comment:
  The BYSETPOS rule part specify values which correspond to the nth occurrence within the set of events specified by the rule. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another BYxxx rule part. For example 'the last work day of the month' could be represented as: RRULE: FREQ=MONTHLY; BYDAY=MO', 'TU', 'WE', 'TH', 'FR; BYSETPOS=-1. Each BYSETPOS value can include a positive (+n) or negative (-n)  integer. If present, this indicates the nth occurrence of the  specific occurrence within the set of events specified by the rule. Defined in RFC 2445 sec. 4.3.10


rdfs:label: due
rdfs:comment:
  This property defines the date and time that a to-do is expected to be completed. Inspired by RFC 2445 sec. 4.8.2.3


rdfs:label: contactAltRep
rdfs:comment:
  Alternate representation of the contact property. Introduced to cover the ALTREP parameter of the CONTACT property. See documentation of ncal:contact for details.


rdfs:label: rdate
rdfs:comment:
  This property defines the list of date/times for a recurrence set. Inspired by RFC 2445 sec. 4.8.5.3. Note that RFC allows both DATE, DATE-TIME and PERIOD values for this property. That's why the range has been set to NcalTimeEntity.


rdfs:label: recurrenceIdDateTime
rdfs:comment:
  The date and time of a recurrence identifier. Provided to express the actual value of the ncal:recurrenceId property. See documentation for ncal:recurrenceId for details.


rdfs:label: returnStatus
rdfs:comment:
  Short return status. Inspired by the first element of the structured value of the REQUEST-STATUS property described in RFC 2445 sec. 4.8.8.2.


rdfs:label: daylight
rdfs:comment:
  Links a timezone with it's daylight observance. This property has no direct equivalent in the RFC 2445. It has been inspired by the structure of the Vtimezone component defined in sec.4.6.5


rdfs:label: locationAltRep
rdfs:comment:
  Alternate representation of the event or todo location. Introduced to cover the ALTREP parameter of the LOCATION property. See documentation of ncal:location for details.


rdfs:label: involvedContact
rdfs:comment:
  A contact of the Attendee or the organizer involved in an event or other calendar entity. This property has been introduced to express the actual value of the ATTENDEE and ORGANIZER properties. The contact will also represent the CN parameter of those properties. See documentation of ncal:attendee or ncal:organizer for more details.


rdfs:label: hasAlarm
rdfs:comment:
  Links an event or a todo with a DataObject that can be interpreted as an alarm. This property has no direct equivalent in the RFC 2445. It has been provided to express this relation.


rdfs:label: exrule
rdfs:comment:
  This property defines a rule or repeating pattern for an exception to a recurrence set. Inspired by RFC 2445 sec. 4.8.5.2.


rdfs:label: rsvp
rdfs:comment:
  To specify whether there is an expectation of a favor of a reply from the calendar user specified by the property value. Inspired by RFC 2445 sec. 4.2.17


rdfs:label: geo
rdfs:comment:
  This property specifies information related to the global position for the activity specified by a calendar component. Inspired by RFC 2445 sec. 4.8.1.6


rdfs:label: resourcesAltRep
rdfs:comment:
  Alternate representation of the resources needed for an event or todo. Introduced to cover the ALTREP parameter of the resources property. See documentation for ncal:resources for details.


rdfs:label: fmttype
rdfs:comment:
  To specify the content type of a referenced object. Inspired by RFC 2445 sec. 4.2.8. The value of this property should be an IANA-registered content type (e.g. application/binary)


rdfs:label: description
rdfs:comment:
  A more complete description of the calendar component, than that provided by the ncal:summary property.Inspired by RFC 2445 sec. 4.8.1.5 with following reservations:  the LANGUAGE parameter has been discarded. Please use xml:lang literals to express language. For the ALTREP parameter use the descriptionAltRep property.


rdfs:label: encoding
rdfs:comment:
  To specify an alternate inline encoding for the property value. Inspired by RFC 2445 sec. 4.2.7. Originally this property had a limited vocabulary. ('8BIT' and 'BASE64'). The terms of this vocabulary have been expressed as instances of the AttachmentEncoding class


rdfs:label: requestStatusData
rdfs:comment:
  Additional data associated with a request status. Inspired by the third part of the structured value for the REQUEST-STATUS property defined in RFC 2445 sec. 4.8.8.2 ('Textual exception data. For example, the offending property name and value or complete property line')


rdfs:label: partstat
rdfs:comment:
  To specify the participation status for the calendar user specified by the property. Inspired by RFC 2445 sec. 4.2.12. Originally this parameter had three sets of allowed values. Which set applied to a particular case - depended on the type of calendar entity this parameter occured in. (event, todo, journal entry). This would be awkward to model in RDF so a single ParticipationStatus class has been introduced. Terms of the values vocabulary are expressed as instances of this class. Users are advised to pay attention which instances they use.


rdfs:label: relatedToSibling
rdfs:comment:
  The property is used to represent a relationship or reference between one calendar component and another. Inspired by RFC 2445 sec. 4.8.4.5. Originally this property had a RELTYPE parameter. It has been decided that it is more natural to introduce three different properties to express the values of that parameter. This property expresses the RELATED-TO property with RELTYPE=SIBLING parameter.


rdfs:label: tzid
rdfs:comment:
  This property specifies the text value that uniquely identifies the 'VTIMEZONE' calendar component. Inspired by RFC 2445 sec 4.8.3.1


rdfs:label: bymonth
rdfs:comment:
  Number of the month of the recurrence. Valid values are integers from 1 (January) to 12 (December). Defined in RFC 2445 sec. 4.3.10


rdfs:label: categories
rdfs:comment:
  Categories for a calendar component. Inspired by RFC 2445 sec 4.8.1.2 with the following reservations: The LANGUAGE parameter has been discarded. Please use xml:lang literals to express multiple languages. This property can specify multiple comma-separated categories. The order of categories doesn't matter. Please use a separate triple for each category.


rdfs:label: sentBy
rdfs:comment:
  To specify the calendar user that is acting on behalf of the calendar user specified by the property. Inspired by RFC 2445 sec. 4.2.18. The original data type of this property was a mailto: URI. This has been changed to nco:Contact to promote integration between NCO and NCAL.


rdfs:label: attachmentContent
rdfs:comment:
  The uri of the attachment. Created to express the actual value of the ATTACH property defined in RFC 2445 sec. 4.8.1.1. This property expresses the BINARY datatype of that property. see ncal:attachmentUri for the URI datatype.


rdfs:label: relatedToChild
rdfs:comment:
  The property is used to represent a relationship or reference between one calendar component and another. Inspired by RFC 2445 sec. 4.8.4.5. Originally this property had a RELTYPE parameter. It has been decided to introduce three different properties to express the values of that parameter. This property expresses the RELATED-TO property with RELTYPE=CHILD parameter.


rdfs:label: relatedToParent
rdfs:comment:
  The property is used to represent a relationship or reference between one calendar component and another. Inspired by RFC 2445 sec. 4.8.4.5. Originally this property had a RELTYPE parameter. It has been decided that it is more natural to introduce three different properties to express the values of that parameter. This property expresses the RELATED-TO property with no RELTYPE parameter (the default value is PARENT), or with explicit RELTYPE=PARENT parameter.


rdfs:label: Reference time zone
rdfs:comment:
  Timezone in the OLSON DB used as reference in the time. Use 'floating' for floating times or study the convenience of a boolean 'isFloating' attribute.


rdfs:label: Access level
rdfs:comment:
  Access classification for a calendar item: public, private or confidential. Use the predefined instances in the ontology


rdfs:label: Recurrence pattern
rdfs:comment:
  Recurrence pattern enforcing all (14) the fields in RFC2445/4.3.10, with ';' as separator: freq;until;count;interval;bysecond;byminute;byhour;byday;bymonthday;byyearday;byweekno;bymonth;bysetpos;wkst 


rdfs:label: Recurrence pattern start date
rdfs:comment:
  Reuse here the start-date instance of the base event for this recurrence rule. This property makes possible to retrieve all required data to expand the recurrence rule in one short query


rdfs:label: Recurrence date
rdfs:comment:
  One of more concrete ocurrences of the calendar item using ';' as separator. Included for backward compatibility. Use rrule instead


rdfs:label: Recurrence date exception
rdfs:comment:
  One of more concrete exceptions of the calendar item using ';' as separator. Included for backward compatibility. Use rrule with exception='true' instead


rdfs:label: Music CD identifier
rdfs:comment:
  Music CD identifier to for databases like FreeDB.org. This frame is intended for music that comes from a CD, so that the CD can be identified in databases such as the CDDB. The frame consists of a binary dump of the Table Of Contents, TOC, from the CD, which is a header of 4 bytes and then 8 bytes/track on the CD plus 8 bytes for the 'lead out' making a maximum of 804 bytes. The offset to the beginning of every track on the CD should be described with a four bytes absolute CD-frame address per track, and not with absolute time.


rdfs:label: Radio station
rdfs:comment:
  The Radio station in user terms: BBC3, Radio5, YLEX, ... It is linked with 1 or more carriers (different FM frenquencies, online sources in different qualities, etc.). Some RDS information is represented with nie properties, nie:identifier for PI, nie:title for PS


rdfs:label: PTY
rdfs:comment:
  PTY Code (content description) as integer. RDS specs define the translations into human readable descriptions for various languages


rdfs:label: Encoding of the radio
rdfs:comment:
  Encoding of the radio. It is a property of the streaming, that it is known before hand, so the applications can choose the encoding they understand.


rdfs:label: Alternative media
rdfs:comment:
  Link between to different version of the same media. This is used for instances in uPnp where the server can provide the same video in different resolutions and codecs


rdfs:label: Transfer element
rdfs:comment:
  Gives information about the transfer of a single element - typically a file. The properties in this class would need to be changed if it has to handle sync elements as well


rdfs:label: Upload
rdfs:comment:
  Handles transfers of files/data present on the device to some place outside the device. Upload methods include uploading to a website, sending via BlueTooth etc. 


rdfs:label: Download
rdfs:comment:
  Handles transfers of files outside the device into the device. This class will only refer to files downloaded from a website or recieved using BlueTooth etc. Files recieved with messages are not considered here. Those would be handled seperately using nmo:Message


rdfs:label: Source
rdfs:comment:
  The source for the transfer. If the transfer is an upload, it would be the URI for a file on the device. If the transfer is a (web) download, it will be a URL. Question: Does it make more sense to have two fields: uploadSource and downloadSource?


rdfs:label: Destination
rdfs:comment:
  The destination of the transfer. If the transfer is an download, it would be the URI for a file on the device. If the transfer is a (web) upload, it will be a URL, which will be filled once the upload is completed.


rdfs:label: Completed
rdfs:comment:
  Captures the date and time when the transfer ended. It must be set only when the trasfer element is completed succesfully


rdfs:label: State
rdfs:comment:
  Captures the current state of the transfer element: Pending (not started), In Progress, Paused, Cancelled, Done


rdfs:label: Transfer state
rdfs:comment:
  Captures the state of the transfer. This is derived from the cumulative states of the transfer elements of this transfer. Applications are responsible to keep it up-to-date


rdfs:label: Account
rdfs:comment:
  A reference to the account to which the web upload is to be done. This should at least contain information about the account and the service which is being used. For instance, Google/YouTube or Google/Picassa


rdfs:label: Privacy level
rdfs:comment:
  It will contain an string with the privacy level in the service. The exact string and its interpretation is service specific


rdfs:label: Bounding box
rdfs:comment:
  Bounding box for a region in the space, defined with 2 points in 2D. We assume that the box is always aligned with parallels and meridians.


rdfs:label: Is removable
rdfs:comment:
  Flag to indicate if this instance is removable. This restriction is not enforced by tracker; it is API responsability to honor the value


rdfs:label: Radius
rdfs:comment:
  Radius from the center to define an area. Some applications can use it in 2D sense, making then a circle instead of a sphere


rdfs:label: Feed channel
rdfs:comment:
  Represents feed channel transfer, typically a download of RSS or ATOM. It is also a communication channel of Nepomuk Messaging Ontology so that feed sources could be treated as message sources


rdfs:label: Feed entry
rdfs:comment:
  Represents feed entry on top of Nepomuk Messaging Ontology's message. May have enclosures attached and certain settings that allow deviation from feed channel's setup


rdfs:label: Resource settings
rdfs:comment:
  Represents settings applied to a feed channel or a feed entry. How often it is updated, through which connection type it is delivered, when data expires and so on


rdfs:label: Default in group
rdfs:comment:
  Different enclosures can represent the same resource in different formats/resolutions. This representations are grouped using the nie:identifier property and this property identify the default between them.


rdfs:label: Expiry Interval
rdfs:comment:
  Expiry interval for feed channel, it tells time that a message in a channel can live. Interpreted as minutes


rdfs:label: MTP fourCC code
rdfs:comment:
  These codes are used to uniquely identify video formats, and are used in various legacy and current software development kits (SDKs), including those for Microsoft Video for Windows (VfW), Microsoft DirectShow, and Microsoft Windows Media Format.


rdfs:label: Wave format
rdfs:comment:
  the WAVE formats reserved with Microsoft as of June 1, 2003. These codes are used to uniquely identify audio formats, and are used in various legacy and current software development kits (SDKs), including MCI, Microsoft Video for Windows, Microsoft DirectShow, Microsoft DirectSound, and Microsoft Windows Media Format.


rdfs:label: PostalAddress
rdfs:comment:
  Postal Address. Class inspired by TYPE=postal parameter of the ADR property defined in RFC 2426 sec. 3.2.1


# nie:InformationElement

nie:title: GNOME Shell integration
nie:mimeType: application/x-desktop
nie:comment:
  Provides integration with GNOME Shell and the corresponding extensions repository https://extensions.gnome.org.


nie:title: LibreOffice
nie:mimeType: application/x-desktop
nie:comment:
  The office productivity suite compatible to the open and standardized ODF document format. Supported by The Document Foundation.


