W3C home > Mailing lists > Public > public-vocabs@w3.org > February 2014

Re: An updated draft of the schema.org/Action proposal

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 10 Feb 2014 17:52:37 -0500
Message-ID: <52F95835.9080203@openlinksw.com>
To: public-vocabs@w3.org
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







Received on Monday, 10 February 2014 22:53:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 10 February 2014 22:53:03 UTC