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

Forwarding Kinsgley's response for the sake of completeness.

I don't have anything to add other than that I disagree that, e.g., a 
ebay://xyz URL is a *web* service. It can, by definition, not be accessed by 
HTTP(S). Thus, it falls outside *my* definition of a *web* resource and 
consequently does not represent a web service. Since the quoted "app resource" 
below was just an explanatory term (in quotes), I don't think we need to 
discuss this further.


-----Original Message-----
From: Kingsley Idehen [mailto:kidehen@openlinksw.com]
Sent: Monday, February 10, 2014 11:53 PM
To: public-vocabs@w3.org
Subject: Re: An updated draft of the schema.org/Action proposal

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 IdehenFounder 
& 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