This document describes in depth how URIs are stored in Nepomuk, and their significance.

This document describes in depth how URIs are stored in Nepomuk, and their significance.

−

== What is a URI? ==

+

= What is a URI? =

−

A URI or Uniform Resource Identifier is a string of characters used to identify or locate a resource. URIs can be of two types, or both - URNs and URLs. A URN, Uniform Resource Name, is a unique way of identifying a resource. It does not provide any information about how the resource can be found, example - <tt>urn:isbn:0374193681</tt>. A URL, Uniform Resource Locator, provides a way to access the resource. Example - <tt>file:///home/user/file</tt>. This url clearly dictates that the 'file' protocol should be used along with the path <tt>/home/user/file</tt>. It does not give a unique way of identifying the resource. It just provides one way to access the resource.

+

A URI or Uniform Resource Identifier is a string of characters used to identify or locate a resource. URIs can be of two types, or both -

+

* URN - Uniform Resources Names

+

* URL - Uniform Resource Locator.

−

== So what does Nepomuk use? ==

+

A URN is a unique way of identifying a resource. It does not provide any information about how the resource can be found> Rather it provides a way to uniquely identify a resource. For example - <tt>urn:isbn:037584614X</tt>. This urn tells you nothing about how to find the book that it just mentions a unique identifier. You can take the ISBN and somehow locate [http://www.amazon.com/Nick-Norahs-Infinite-Playlist-Rachel/dp/037584614X the book]

−

Nepomuk URIs are in a way URNs, though unlike conventional URNs which provide a globally unique way of identifying a resource, they provide a unique way of identifying a resource '''on one machine'''. This is important - Nepomuk URIs are NOT machine independent. The same resource can have different URIs on different systems. This is because all URIs in Nepomuk are randomly generated. They follow a pattern -

+

A URL, in contrast, provides a way to access the resource. For example - <tt>file:///home/user/file</tt>. This url clearly dictates that the <tt>file</tt> protocol should be used along with the path <tt>/home/user/file</tt>. It does not give a unique way of identifying the resource. It just provides one way to access the resource.

−

<blockquote>`nepomuk:/TYPE/uuid`</blockquote>

+

= So what does Nepomuk use? =

−

where -

+

Nepomuk URIs are in a way URNs, though unlike conventional URNs which provide a globally unique way of identifying a resource, they provide a unique way of identifying a resource '''on one machine'''. This is important - Nepomuk URIs are NOT machine independent. The same resource can have different URIs on different systems. This is because all URIs in Nepomuk are randomly generated. They follow a pattern -

−

TYPE is either '''res''' or '''ctx'''. ''res'' is an abbreviation for Resource, while ''ctx'' is an abbreviation for Context or Graph.

+

<blockquote>nepomuk:/res/uuid</blockquote>

UUID stands for a ''Universally Unique Identifier''. In Nepomuk this UUID is guaranteed to be unique on one system. A resource with the same UUID can exist as completely different resources on different systems.

UUID stands for a ''Universally Unique Identifier''. In Nepomuk this UUID is guaranteed to be unique on one system. A resource with the same UUID can exist as completely different resources on different systems.

−

== Doesn't Nepomuk need the location of the Resourcce? ==

+

= Doesn't Nepomuk need the location of the Resourcce? =

−

Yes, we do! But just like "A rose by any other name would smell as sweet", the location of a resource is independent of its name. Its name ( UUID ) never changes. If the resource has a location then the location is stored as a URL using the property nie:url.

+

Yes, we do! But the location of a resource is independent of its name. Its name ( UUID ) never changes. If the resource has a location then the location is stored as a URL using the property [http://oscaf.sourceforge.net/nie.html#nie:url <code>nie:url</code>].

−

Not all resource have a location. Nepomuk is used to store abstract stuff like Contacts, Events and People, they do not have a location. Concrete stuff like pictures, videos and files do have locations.

+

Not all resource have a location. Nepomuk is also used to store abstract stuff like Contacts, Events and People, they do not have a location. Concrete stuff like pictures, videos and files do have locations.

−

== Tell me more about these URLS ==

+

= Tell me more about these URLS =

A URL is like the physical representation of an object. In Nepomuk all URLs must have a proper scheme that KDE supports. Example <tt>smb:/192.168.1.50/Multimedia/</tt> or <tt>akonadi:?item=21</tt>. These all are stored in the nie:url property of the resource.

A URL is like the physical representation of an object. In Nepomuk all URLs must have a proper scheme that KDE supports. Example <tt>smb:/192.168.1.50/Multimedia/</tt> or <tt>akonadi:?item=21</tt>. These all are stored in the nie:url property of the resource.

−

== You're lying! I see resource URIs like <tt>akonadi:?item=21</tt> ==

+

= You're lying! I see resource URIs like <tt>akonadi:?item=21</tt> =

−

This URI nomenclature was decided in June 2011. We're still in the process of making sure all URIs follow our naming convention. Hopefully we can automate this process.

+

This URI nomenclature was decided in June 2011. We're still in the process of making sure all URIs follow our naming convention. With KDE 4.10, there will be a data migration client which will make sure the old data is converted to this new uri format.

−

== Why go through all this trouble? ==

+

= Why go through all this trouble? =

The rationale in having random UUID based URIs in Nepomuk is two fold. One, we have a guarantee that the URI is random, and means nothing. This is important when restoring backups or synchronization or when sharing resource among different systems. If you're restoring a resource and its URI already exists, no problem, just generate another one. It's not like they have any concrete meaning. The URL however does have a concrete meaning, and that we need to respect.

The rationale in having random UUID based URIs in Nepomuk is two fold. One, we have a guarantee that the URI is random, and means nothing. This is important when restoring backups or synchronization or when sharing resource among different systems. If you're restoring a resource and its URI already exists, no problem, just generate another one. It's not like they have any concrete meaning. The URL however does have a concrete meaning, and that we need to respect.

−

The second reason is that all URIs follow one naming convention? ( vHanda: What was the second reason? )

+

The second reason is that all URIs follow one naming convention.

−

== What about the Semantic Web? ==

+

= What about the Semantic Web? =

−

Nepomuk is the Semantic Desktop, while we acknowledge the existence of the Semantic Web, we currently do not go out of our way to support it. It's a messy situation, and we don't have a solution right now. If you have any ideas on how we can have better interoperability with the Semantic Web, then please let us on the Nepomuk Mailing List.

+

Nepomuk is the Semantic Desktop, while we acknowledge the existence of the Semantic Web, we currently do not go out of our way to support it. It's a messy situation, and we don't have a solution right now. If you have any ideas on how we can have better interoperability with the Semantic Web, then please come talk to us.

Revision as of 10:33, 24 August 2012

This document describes in depth how URIs are stored in Nepomuk, and their significance.

What is a URI?

A URI or Uniform Resource Identifier is a string of characters used to identify or locate a resource. URIs can be of two types, or both -

URN - Uniform Resources Names

URL - Uniform Resource Locator.

A URN is a unique way of identifying a resource. It does not provide any information about how the resource can be found> Rather it provides a way to uniquely identify a resource. For example - urn:isbn:037584614X. This urn tells you nothing about how to find the book that it just mentions a unique identifier. You can take the ISBN and somehow locate the book

A URL, in contrast, provides a way to access the resource. For example - file:///home/user/file. This url clearly dictates that the file protocol should be used along with the path /home/user/file. It does not give a unique way of identifying the resource. It just provides one way to access the resource.

So what does Nepomuk use?

Nepomuk URIs are in a way URNs, though unlike conventional URNs which provide a globally unique way of identifying a resource, they provide a unique way of identifying a resource on one machine. This is important - Nepomuk URIs are NOT machine independent. The same resource can have different URIs on different systems. This is because all URIs in Nepomuk are randomly generated. They follow a pattern -

nepomuk:/res/uuid

UUID stands for a Universally Unique Identifier. In Nepomuk this UUID is guaranteed to be unique on one system. A resource with the same UUID can exist as completely different resources on different systems.

Doesn't Nepomuk need the location of the Resourcce?

Yes, we do! But the location of a resource is independent of its name. Its name ( UUID ) never changes. If the resource has a location then the location is stored as a URL using the property nie:url.

Not all resource have a location. Nepomuk is also used to store abstract stuff like Contacts, Events and People, they do not have a location. Concrete stuff like pictures, videos and files do have locations.

Tell me more about these URLS

A URL is like the physical representation of an object. In Nepomuk all URLs must have a proper scheme that KDE supports. Example smb:/192.168.1.50/Multimedia/ or akonadi:?item=21. These all are stored in the nie:url property of the resource.

You're lying! I see resource URIs like akonadi:?item=21

This URI nomenclature was decided in June 2011. We're still in the process of making sure all URIs follow our naming convention. With KDE 4.10, there will be a data migration client which will make sure the old data is converted to this new uri format.

Why go through all this trouble?

The rationale in having random UUID based URIs in Nepomuk is two fold. One, we have a guarantee that the URI is random, and means nothing. This is important when restoring backups or synchronization or when sharing resource among different systems. If you're restoring a resource and its URI already exists, no problem, just generate another one. It's not like they have any concrete meaning. The URL however does have a concrete meaning, and that we need to respect.

The second reason is that all URIs follow one naming convention.

What about the Semantic Web?

Nepomuk is the Semantic Desktop, while we acknowledge the existence of the Semantic Web, we currently do not go out of our way to support it. It's a messy situation, and we don't have a solution right now. If you have any ideas on how we can have better interoperability with the Semantic Web, then please come talk to us.