- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 10 Feb 2014 17:52:37 -0500
- To: public-vocabs@w3.org
- Message-ID: <52F95835.9080203@openlinksw.com>
On 2/10/14 5:13 PM, Markus Lanthaler wrote: > Re-adding public-hydra (and including Kingsley's complete message below) > > > On Monday, February 10, 2014 10:27 PM, Kingsley Idehen wrote: >> On 2/10/14 3:00 PM, Sam Goto wrote: >>> Thus we probably need an alternative for the time being. One option >>> would be (as I mentioned to you in another mail) to separately >>> describe Web resources and "app resources". >> How about distinguishing Web Resources and Web Services (instead of >> "app resources") ? > An "app resource" in this context means a deeplink into a native app. For > example a deeplink into an iOS, Android, Windows, etc. app. Yes, but all of the items you've just references are in fact services that have addressing via links (pointers). Unlike the desktop, mobile platforms already work with a plethora of URI schemes which makes data pipes (like unix) serve as a loosely coupled mechanism for data and app/service integration. That works on iOS as I type. > They are not > really web resources (they use proprietary URL schemes) but use URIs as > identifiers. In RDF parlance (which I disagree with) everything (real or imagined) is a Resource. In clearer (or my preferred terminology) URIs denote entities (things). When a URI offers both denotation and connotation i.e., name and description lookup (as per Linked Data principles, for instance using HTTP URIs) iOS, Android, Windows etc.. are just services accessible via HTTP. They provide access to data object resources that can be named and de-referenced using HTTP. Basically, HTTP is still driving state transitions of the data exposed by the aforementioned services, via interaction patterns. Apps have always been service providers :-) Kingsley > > >> The crux of the matter here is that we have a Service and its >> distinguishing characteristics. Making these characteristics >> discernible >> and comprehensible to user agents is the challenge at hand. Ultimately, >> we are going to either describe URI templates using RDF documents or >> they are going to exist as literal relation values for which user >> agents >> (as many do today) will have to learn about via API docs. >> >> If we don't want to be too RDF heavy, then look to the fact that the >> URI >> template language is an open standard that has been implemented by a >> number of folks. >> >> [1] http://tools.ietf.org/html/rfc6570 -- URI Template >> [2] >> http://shuyo.wordpress.com/2008/07/24/implementations-of-uri-templates- >> in-various-languages/ >> -- old implementors list (we [OpenLink Software] for instance are >> missing from the list) . >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter Profile: https://twitter.com/kidehen >> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > -- > Markus Lanthaler > @markuslanthaler -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 10 February 2014 22:53:02 UTC