[Xesam] Meaning of xesam:url

[Mikkel Kamstrup Erlandsen]

2008/8/6 Michael Albinus <michael.albinus at gmx.de>:
> "Ivan Frade" <ivan.frade at gmail.com> writes:
>
>> Hi all,
>
> Hi,
>
>>> A xesam field, like xesam:url, shall NOT contain engine specific
>>> interpretations. If it is really needed for whatever reason, they might
>>> set up an own ontology, with fields like strigi:url or beagle:url.
>>
>> That interpretation is not engine specific, but _application_
>> specific. I mean, It is the problem of the client to choose the right
>> application to open/interpret that URL.
>>
>>  The client will call the "Email" application in the system, and if
>> you have evolution mails, probably you will have evolution installed
>> :)
>
> My default "Email" application is emacs/gnus. Occasionally, I also use
> evolution or thunderbird. How shall a poor xesam client know, which of
> them to apply, when it sees an email hit?
>
> Likely there must be information, which application fits best for a
> given hit. But a xesam engine shall not present xesam:url in a way which
> fits best to *one* of the possible candidates only - maybe such
> information shall be passed via the convenience ontology, which is
> already kind of application specific information, IIUC.

Maybe the indexer could store a field hinting the .desktop file of the
app that are likely to be able to open the file? Or more specifically
just the vendor id. For the sake of the discussion lets call that
field xesam:urlScheme.

If we later decide to standardize the urls for, say, files embedded in
archives, then we could add a Xesam-specific value to xesam:urlScheme,
like "xesam.ArchivedFile".

This way indexers could still stuff most things they wanted to into
xesam:url. And honestly I don't see that big a problem with it yet.
I've done my share of integrating exotic search engines here and there
and I've somehow always managed to open the urls in some way or other.
Not always fun or elegant code, but working.

-- 
Cheers,
Mikkel