From: Max V. <vo...@fz...> - 2007-07-31 12:03:27
|
Hi Leo, Nepomuk, Aperture, (i re-format leos mail in IBAW [20] issue: On the semantic desktop, we need URIs to identify and locate, and possibly retrieve RDF information, about every resource on the desktop. * example: identifying e-mails stored in the desktop e-mail client * example: identifying contacts, appointments, todos from the local PIM app= lication L> We have repeatedly tried to come up with hacks to identify desktop L> resources, and have discussed this longer [5] but now, given the=20 L> pressure of nepomuks standardization effort, we should not continue with= =20 L> a hack but standardize and recommend our practice[4] in an RFC at IETF [= 3]. Very good idea! Thanks Leo for taking the initiative. L> This may seem a big effort, but I think it could be an outcome of our=20 L> current work that lasts a little longer. And its concise, the scheme=20 L> could start with identification, and leaves retrieval and opening the=20 L> resource to the operating system. In the end, this seems like the only way to go. Unless we use intermediat= e RDF crawled from the resources. L> Nepomuk people have asked about desktop URIs, I talked with Antoni about= =20 L> this for longer, and have been pondering on this since 4 years myself.= =20 L> Its time now to start a broader discussion. Otherwise, we may end up=20 L> with a hack that is crappily implemented for nepomuk and does not last. L> For this, I have updated the [LocalId] wiki page in the internal Nepomuk= =20 L> wiki and started writing an example RFC. [2] L> please give feedback: L> * would you like to join the task-force TF-Ont-Id to work on this? Yes. L> Feedback that is not helpful: L> * "please use http URIs" - this is not possible, because desktops have= =20 L> changing DNS names, so the URI will change once you switch network. And= =20 L> HTTP uris are not retrievable for desktop pcs. Even with the hacks we=20 L> thought of, it is not clean. I would not give this up so easily. Let's collect the pros and cons in= IBAW style and get a clear picture. I agree, we have not found a good soluti= on so far. Maybe we can ask the REST-freaks at the REST-discussion lists. L> and the HTTP port is not fixed, for each user there may be a different= =20 L> port. Also, L> opening an http server on the desktop may be a security risk in many=20 L> environments. And, there is the file:// uri scheme L> standardized by IETF. http is not the silver bullet on the desktop, I=20 L> have to admit. I agree, it's not the silver bullet. Nothing is. L> I also think that creating this standard within Nepomuk, and later=20 L> asking W3C or OASIS to bless it will not work. I think this might very well work. L> This discussion should=20 L> rather be hosted on the W3C semantic web deployment WG in the first=20 L> place. This would give the operating system developers and the desktop= =20 L> search engine people at W3C (apple, microsoft, google are W3 members)=20 L> the chance to work on it, and if they work on it, they may even=20 L> implement it. Indeed, very good reason to be open in the beginning. L> With NIE and NRL we have the problem that its "our standard" and=20 L> W3C-frenzy people may stick to the vCard/iCal/exif work done by W3C=20 L> "just because its W3C". So I would rather host this discussion on a=20 L> broader level. I believe the same. L> I am well aware that this is an ugly job and will take a year to get to= =20 L> somewhere, but - we have a year - and I am really eager to get this done= =20 L> right. Cool. And now some feedback: L> The Semantic Desktop URI scheme=20 L> We cannot use HTTP URIs, because desktops have L> changing DNS names, so the URI will change once you switch network. We have to consider the pro and con between: - adding a new URI scheme - adding something to DNS, i.e. it is not by accident that most OS allow= very easily to tweak DNS resolving. Using http://somename.localhost/ where som= ename identifies the user might not bew such a bad solution. Let's kill it= with arguments, not emotions :-) L> And L> HTTP uris are not retrievable for desktop pcs. They are, if they are on localhost. L> Even with the hacks we L> thought of, it is not clean. The HTTP port for a desktop may be blocked true! L> or multiple users on one machine may collide ports. aha, a deployment problem: this would mean, one cannot install several NEP= OMUKs on one machine. Really? How do other http-server application handle this,= e.g. Google Desktop search? Eclipse help system? L> Also, opening an http server on the desktop may be a security risk in # L> many environments. On the other hand, its a risk that can be controlled by accepting only = local connections or whatever. Traffic can be monitored. L> And, there is the file:// uri scheme L> standardized by IETF that shows how to do it. I don'T see the relation to HTTP. L> http is not the silver bullet on the desktop, I have to admit. Agree. L> 1. The "semdesk" URI scheme L> Semantic Desktop URIs have several parts, including an application speci= fic part, L> hostname information and a path within the application's namespace. From=20this i derive the requirement to adress: machine x user x application x application-object L> The name "semdesk" stems from the requirement to identify resources for L> further annotations using the RDF technology. On desktops that are not L> aware of annotations or semantic databases, a way of uniquely identifyin= g=20 L> resources is also handy, thus it is not required to run RDF applications= =20 L> to use the semdesk URI scheme.=20 Good! L> The scheme is intended to be used by desktop search engines to identify= =20 L> resources from desktop applications. This allows resources to be=20 L> identified independent of implementation. Not *only by dekstop search. > [..] all makes sense L> 2 Retrieval and opening of resources L> Operating systems or services running on the OS have to provide ways to= =20 L> retrieve a description of the identified resource. L> The retrieval method is similar to HTTP-GET. L> We cannot propose a definitive standard, as each operating system has di= fferent L> approaches, but the protocol should somehow go like this: L> GET semdesk:///email/messageid:239...@ex... L> accept: application/rdf+xml L> Implementations use existing protocols (operating system calls, DLLs,=20 L> DBUS messages, etc) to L> provide this functionality, but are platform dependent. From=20an implementation standpoint, how can I invoke this protocol via - Java - Ruby - C - C# - Python - shell scripts - ... L> An operating system service may implement methods to open resources L> identified L> using the semdesk URI scheme: L> START semdesk:///email/messageid:239...@ex... Such a functionality certainly makes sense. To clarify, I really see the problem you try to solve, Leo. I don't know w= hat a good solution is. I guess, we should try to list the requirements, filter= them and think of the best solution. I wouldn't kick HTTP to easily, mainly be= cause implementation can be very easy (at least it *seems* right now). [20] http://xam.de/2006/02-ibaw.html Kind Regards, Max -- Max V=F6lkel office: +49 721 9654-854 http://Xam.de mobile: +49 171 8359678 FZI Forschungszentrum Informatik http://www.FZI.de an der Universit=E4t Karlsruhe telephone: +49-721-9654-0 Haid-und-Neu-Str. 10-14 fax: +49-721-9654-959 D-76131 Karlsruhe Stiftung des b=FCrgerlichen Rechts. Az: 14-0563.1 Regierungspr=E4sidium Kar= lsruhe. Vorstand: Prof. Dr.-Ing. R=FCdiger Dillmann, Dipl. Wi.-Ing. Michael Flor, Prof. Dr. Dr.-Ing. Jivka Ovtcharova, Prof. Dr. rer. nat. Rudi Studer. Vorsitzender des Kuratoriums: Ministerialdirigent G=FCnther Le=DFnerkraus. |