Hi!

Please look into the XRI standard. "XRI open standards developed at OASIS by: Visa International, The Boeing Company, AMD, Nomura Research Institute, NeuStar, AmSoft, Booz Allen Hamilton, Epok, PlaNetwork, Cordance..."
This  standard allows you to uniquely identify resources (XRI), to create corresponding names (inames) and resolve these names afterwards. Please note that this is ALREADY a working standard, there are already working implementations for that, there is already integration with Yadis/OpenID and so on.
Some (random) references:
Please note that I don't propose to use all this stuff as is, but it would be definitely interesting to understand how it works and see if it CAN be used for our goals or not. From my personal point of view, if Nepomuk will develop something new in this field then we should (at least) clearly reference existing standards and mark why they cannot be used in our case.

Best regards,
Mikhail



On 7/27/07, Leo Sauermann <leo.sauermann@dfki.de> wrote:
Hi Nepomuk, Aperture,

On the semantic desktop, we need URIs to identify and locate, and
possibly retrieve RDF information, about every resource on the desktop.
For the "file" uri scheme, this works perfectly, but there are resources
stored in databases, often managed by applications, that are, even using
the dirtiest hacks, not accessible using an existing URI scheme.

two examples to illustrate the problem:
* identifying e-mails stored in the desktop e-mail client
* identifying contacts, appointments, todos from the local PIM application

although each application may expose a way to identify these resources
uniquely, this is neither standardized nor captured by the file:// uri
scheme.

We have repeatedly tried to come up with hacks to identify desktop
resources, and have discussed this longer [5] but now, given the
pressure of nepomuks standardization effort, we should not continue with
a hack but standardize and recommend our practice[4] in an RFC at IETF [3].

This may seem a big effort, but I think it could be an outcome of our
current work that lasts a little longer. And its concise, the scheme
could start with identification, and leaves retrieval and opening the
resource to the operating system.

Nepomuk people have asked about desktop URIs, I talked with Antoni about
this for longer, and have been pondering on this since 4 years myself.
Its time now to start a broader discussion. Otherwise, we may end up
with a hack that is crappily implemented for nepomuk and does not last.
For this, I have updated the [LocalId] wiki page in the internal Nepomuk
wiki and started writing an example RFC. [2]

please give feedback:
* if there is another standardized way to solve this - how does KDE
solve it?
* would you like to join the task-force TF-Ont-Id to work on this?

Feedback that is not helpful:
* "please use http URIs" - this is not possible, because desktops have
changing DNS names, so the URI will change once you switch network. And
HTTP uris are not retrievable for desktop pcs. Even with the hacks we
thought of, it is not clean.
and the HTTP port is not fixed, for each user there may be a different
port. Also,
opening an http server on the desktop may be a security risk in many
environments. And, there is the file:// uri scheme
standardized by IETF. http is not the silver bullet on the desktop, I
have to admit.

I also think that creating this standard within Nepomuk, and later
asking W3C or OASIS to bless it will not work. This discussion should
rather be hosted on the W3C semantic web deployment WG in the first
place. This would give the operating system developers and the desktop
search engine people at W3C (apple, microsoft, google are W3 members)
the chance to work on it, and if they work on it, they may even
implement it.

With NIE and NRL we have the problem that its "our standard" and
W3C-frenzy people may stick to the vCard/iCal/exif work done by W3C
"just because its W3C". So I would rather host this discussion on a
broader level.

I am well aware that this is an ugly job and will take a year to get to
somewhere, but - we have a year - and I am really eager to get this done
right.

best
Leo

[LocalId] http://nepomuk.semanticdesktop.org/xwiki/bin/view/Main/LocalId
[2]
http://svn.nepomuk.semanticdesktop.org/repos/trunk/paper/2007/semanticdesktop_urischeme/RFC_semdesk_urischeme.txt

because this is only accessible for nepomukians, here is the plaintext
of my humble start:
[3] http://www.iana.org/assignments/uri-schemes.html
[4] http://tools.ietf.org/html/rfc4395#page-9
[5]
http://sourceforge.net/mailarchive/forum.php?thread_name=46766527.70907%40dfki.uni-kl.de&forum_name=aperture-devel

Network Working Group
Request for Comments:
Category:



                    The Semantic Desktop URI scheme

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document specifies defines the "semdesk" Uniform Resource Identifier (URI)
   scheme for desktop resources, used to
   identify resources on desktop operating systems within RDF.
   The scheme is used to identify resources within databases or desktop
   applications, that are not captured by file:// ([RFC1738])
   Ways to retrieve RDF representations via a desktop resolving protocol are suggested.


Introduction
we cannot use RFC1738 because they are not capture there, we cannot use "info:"
http://www.rfc-editor.org/rfc/rfc4452.txt because they are not to be registered,
and we cannot use "urn:" http://www.rfc-editor.org/rfc/rfc2141.txt because our
identifiers are location dependent.

We cannot use HTTP URIs, because desktops have
changing DNS names, so the URI will change once you switch network. And
HTTP uris are not retrievable for desktop pcs. Even with the hacks we
thought of, it is not clean. The HTTP port for a desktop may be blocked
or multiple users on one machine may collide ports.
Also, opening an http server on the desktop may be a security risk in #
many environments. And, there is the file:// uri scheme
standardized by IETF that shows how to do it.
http is not the silver bullet on the desktop, I have to admit.


1. The "semdesk" URI scheme
Semantic Desktop URIs have several parts, including an application specific part,
hostname information and a path within the application's namespace.
The name "semdesk" stems from the requirement to identify resources for
further annotations using the RDF technology. On desktops that are not
aware of annotations or semantic databases, a way of uniquely identifying
resources is also handy, thus it is not required to run RDF applications
to use the semdesk URI scheme.

The scheme is intended to be used by desktop search engines to identify
resources from desktop applications. This allows resources to be
identified independent of implementation.

This RFC uses a similar approach to URIs as the HTTP RFC:

   URIs in HTTP can be represented in absolute form or relative to some
   known base URI [11], depending upon the context of their use. The two
   forms are differentiated by the fact that absolute URIs always begin
   with a scheme name followed by a colon. For definitive information on
   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
   Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
   1738 [4] and RFC 1808 [11]). This specification adopts the
   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
   "host","abs_path", "rel_path", and "authority" from that
   specification.

The elements of a semdesk uri are:

semdesk://[host]/[application]/[abs_path]

[host] identifies the desktop computer using the DNS name or the IP address.
This part is optional, as most personal computers have changing names and
users are not aware of their name, also when users switch their network the
IP address or hostname may change (especially with dialup connections)
Use the [host] part only when the hostname is a registered DNS name and
statically configured for the desktop computer.

[application] - a unique string identifying the application that manages
the resource. only alphanumeric characters allowed, no punctuation or other
delimiters. An Informal registry of application names is hosted at
http://www.semanticdesktop.org . It is possible to use non-standard
application identifiers.

registered application identifers are (experimental, under frequent change):
* kde - items within the K Desktop environment, KAddressBook, etc
* msoutlook - resources within microsoft outlook
* email - identifying e-mails within local desktop e-mail clients.
  Each client has to register at the operating system, one scheme is used

[abs_path] the Path identifies the resource uniquely within the application.
The same restrictions apply as within RFC 2396 and RFC 2616.

1.1 Examples

For msoutlook:
semdesk:///msoutlook/item/00000000ECD4B99358B9814B9DAFE2255CD8AE9A44B42F00
semdesk:///msoutlook/folder/00000000ECD4B99358B9814B9DAFE2255CD8AE9A44B42F00

for e-mails:
The emails can either be identified by their message-id, their folder,
or their standardized IMAP URI.

semdesk:///email/messageid:23979723@example.com
semdesk:///email/imap://joe@example.com/INBOX;45


2 Retrieval and opening of resources

Operating systems or services running on the OS have to provide ways to
retrieve a description of the identified resource.
The retrieval method is similar to HTTP-GET.
We cannot propose a definitive standard, as each operating system has different
approaches, but the protocol should somehow go like this:

GET semdesk:///email/messageid:23979723@example.com
accept: application/rdf+xml

Implementations use existing protocols (operating system calls, DLLs,
DBUS messages, etc) to
provide this functionality, but are platform dependent.

An operating system service may implement methods to open resources
identified
using the semdesk URI scheme:

START semdesk:///email/messageid:23979723@example.com

This call will invoke a desktop application to show the identified
resource to the user


--
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann

Deutsches Forschungszentrum fuer
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann@dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________