Re: [Aperture-devel] Aperture URIs

[Antoni M. <ant...@df...>]

Leo Sauermann pisze:
> no, if we do that we have to file in a request for registration for 
> every new uri scheme at ICANN.
> Together with the request, usually an IETF RFC has to be written.
> 
> thats a lot of work, we should definitly avoid that.
> 
> If we don't use standardized uris, we get requests from our users "what 
> are these uris, why do they not work, etc...."
> 
> for e-mails, I see some reason to write an RFC (email:|<messageid>)

Such a URI doesn't contain any information how to access such a 
resource. An email could be in Outlook, or on an IMAP mailbox, or any 
other place. It would be impossible to write an accessor for that 
scheme. From Aperture implementation point of view a more useful one 
would be something like

urn:semdesk:outlookemail:messageID or
urn:semdesk:outlook:OutlookItemUUID (even easier)

A remark: It turns out that there may be some misconception when talking 
about accessors and openers for URI schemes. They are in fact for URL 
schemes.

> for the semanticdesktop, we could register an URI scheme at ICAN like this:
> urn:aperture:....
> urn:semdesk:...
> 
> and then do things like:
> urn:semdesk:macaddressbook:
> urn:semdesk:outlook:

Very well, but then if we want to have an accessor that would work with 
urn:semdesk:macaddressbook, we have two options:

1. redefine the concept of an URI scheme: The scheme name consist of a 
letter followed by any combination of letters, digits, and the plus 
("+"), period ("."), or hyphen ("-") characters; and is terminated by a 
colon (":"). (from Wikipedia).

2. change the definition of the accessor registry, so that new factories 
are not registered with uri schemes but with arbitrary URI prefixes.

The second one seems the only possibility to me.

This issue could be solved when the content and representation have two 
URIS, (a representation URL (urn:semdesk:outlook:outlookUUID), for which 
we could have an accessor and an opener and the content URI which could 
be email:messageId) but this would bring milion other issues and would 
turn the Aperture architecture upside down... :) It would be a nice 
thing to think about though if anyone ever wants to write Aperture 2.0.

Until then there are three options:

1. Use URLs for everything we want to be available with an Accessor or 
an Opener. (and register factories with arbitrary prefixes, not with 
schemes)

2. Introduce some coupling between data sources, accessors and openers. 
Something along the lines I wrote some time ago. So that when we have an 
email:messageId we can trace it to a particular mbox file and call a 
ThunderbirdOpener.

3. Leave it as it is and accept the fact the way URIs are created limits 
the growth of Aperture.

Antoni Mylka
ant...@df...