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

On 2/11/14 6:13 AM, Markus Lanthaler wrote:
> 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.
ebay://yxz is a URL. It isn't a *web* service. It's an identifier that 
denotes something using the "ebay:" scheme.

A Web Service (aka network accessible App) could provide the ability to 
perform operations on data based using an ebay://yxz URI.


>   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.

Please digest my comments above. URIs denote things. Unlike the desktop 
dominated by Web Browsers, there are mobile platforms that work with a 
variety of URI schemes. They even allow registration of custom schemes.

> Since the quoted "app resource"
> below was just an explanatory term (in quotes), I don't think we need to
> discuss this further.

At this point the labels don't really matter that much. All that really 
matters are the semantics of the vocabulary under construction. I am 
still perceiving this vocabulary as a WSDL like solution that leverages 
RDF en route to bringing data (resource) operations, actions, into the 
mix, RESTfully.

There can be a kind of entity that exhibits all of the characteristics 
required for discovery and comprehension of methods (and their call 
patterns) in regards to manipulating data state transitions, across 
endpoints on a network. We just need to be clear that we are trying to 
describe a service, and more than likely, one that works with the 
"http:" scheme.

Anyway, as I said, we can close this matter (accurately) and move on 
since labels are quite secondary at this point in the process :-)


Links:

[1] http://bit.ly/1bD2eZs -- Identifier .
[2] http://bit.ly/1elU7Rh -- URI.

Kingsley
>
>
> -----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 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