Recommended URIs

In Nepomuk, URIs are used for different resource types, each needing a different schema and approach. This page gives a list of all recommendations about how to generate URIs

Ontologies

Ontologies are identified by the Ontology URI. Ontologies are also stored in the RdfRepository in contexts named the same as the Ontology URI (= context used for provenance). The Ontology URI should be determined in best-practice steps:

Storing the ontologies using their namespace is considered to increase readability. Contexts of metadata graphs for ontologies are detected from the ontology itself (if it is a NRL compliant ontology), or by adding the suffix "-metadata".

DataWrapper: Data Sources

Data Sources (instances of nie:DataSource) should be identified using a randomly generated URI with a fixed prefix.

urn:nepomuk:datasource:<UUID>

Example
urn:nepomuk:datasource:bf5f8810-c6a7-11dd-ad8b-0800200c9a66

The UUID is encoded lowercase in five groups.

Extracted Information Elements and Data Objects

 Data Objects represent 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 standardized URI should be taken:

file://home/claudia/doc/tripplan.pdf
imap://claudia@sap.com/INBOX/1

If no standard URI is available, the desktop:// URI scheme may be used. The  Desktop URI Scheme is a draft recommendation that needs some work. Any new URI schemes and best practices must be documented here in the RecommendedUris.

For InformationElements no clear standard is given. In the ApertureDataWrapper implementation, the URI of the InformationElement and the DataObject are the same. This was a pragmatic decision that has not backfired so far.

storing the data is described in RecommendationStoringInformationElements.

Contexts of Information Elements and Data Objects

Recommended graph URIs for contexts for extracted Information Elements and Data Objects are based on a fixed prefix and a random UUID.

urn:nepomuk:context:<UUID>

Example
urn:nepomuk:context:256f95c0-c6ab-11dd-ad8b-0800200c9a66

The UUID is encoded lowercase in five groups.

The metadata graph URI for data object contexts is generated by adding the suffix "-metadata"

urn:nepomuk:context:<UUID>-metadata

Example
urn:nepomuk:context:256f95c0-c6ab-11dd-ad8b-0800200c9a66-metadata

PIMO Things

When creating PIMO Things, use the user's personal namespace and the Semdesk URI scheme:

semdesk://bob@example.com/things/Alice

Contexts of PIMO data

Data generated as part of the user's Personal Information Model (using PimoOntology) must be stored in contexts. The context URIs should be taken from the user's personal namespace. PIMO Elements can be synchronized between multiple computers and must be traceable to the user who created them. See Semdesk URI scheme:

semdesk://bob@example.com/things/context<random string, may be a UUID>

semdesk://bob@example.com/things/context256f95c0-c6ab-11dd-ad8b-0800200c9a66

URI conformance

Please only create URIs which are conforming to  RFC 2396 and  RFC 1808. Always parse your URIs using the java.net.URI class (and for file: URIs also with "new File(URI)"). Do not just assume that they are valid.

Common mistakes:

The second variant is incomplete. It misses the "path" component completely. It is justified to assume that an empty path equals the root path "/"

  • Initial Backslashes in file:-URLs

Examples: file:/home/claudia_stern/ file://home/claudia_stern/ file:///home/claudia_stern/

The first and third are correct, whereas the second is not. In the first case, the host part is missing completely (notably, URIs like http:/cgi-bin/something are valid as well, but not very useful on the web -- they point to a path on the current host). In the third case, the host part is given, but no host is mentioned. This means "current host", but more explicitly. You could also have  file://localhost/home/claudia_stern/,  file://example.com/var/tmp/foo.txt and so on.

Recommendation: For Windows, use "one slash", i.e. "file:/" + local path. If you are running windows, you could get paths like "file:/C:/foo/bar.txt". In Java, you get this by calling file.toURI().toString(). In KDE, use three slashes as in file:///home/claudia/bar.txt