Re: HTTPS for RDF URIs?

Hi all

regarding opaque uri: maybe a difference in the scheme could be seen as a
complementary to a different type extension.
If i'm referring for example to the resource http://wiki/page.html or
http://wiki/page.rdf i probably expect two different representation on the
same resource, from a technical REST-like approach. Should we interpet also
those as opaques?
Sorry if this is probably a sort of recurring question.
If the formats for type extension are acceptable, the best would be in
using also the schem much like in the same way. For example I suppose that
I could have also have something like: file://wiki/page.html, for a local
copy. Is this acceptable in theory?






2014-01-31 Kingsley Idehen <kidehen@openlinksw.com>:

> On 1/31/14 6:29 AM, ☮ elf Pavlik ☮ wrote:
>
>> On 01/30/2014 09:10 PM, Kingsley Idehen wrote:
>>
>>> On 1/30/14 1:09 PM, Melvin Carvalho wrote:
>>>
>>>>
>>>>
>>>>     If not bad, is there any provision for allowing that an HTTPS URI
>>>>     that only differs in the scheme part from HTTPS URI be identified
>>>>     as the same resource?
>>>>
>>>>
>>>> http and https are fundamentally different resources, but you can link
>>>> them together with owl : sameAs, I think ...
>>>>
>>>
>>> Yes.
>>>
>>> You simply use an <http://www.w3.org/2002/07/owl#sameAs> relation to
>>> indicate that a common entity is denoted [1] by the http: and https:
>>> scheme URIs in question.
>>>
>> does it make sense then to use https: IRIs if we state that one can treat
>> http: version as equivalent?
>>
>>
>>
>>
> Yes it does. Its a choice that a data publisher has to make i.e., handle
> mapping using the combination of virtual domains and re-write rules or by
> making mappings explicit using owl:sameAs relations.
>
> I demonstrate in my personal data space, you can use http: and https: as
> mechanisms varying behavior of HTTP operations based on identity. For
> instance:
>
> 1. https requests provide a mechanism for using the WebID + TLS
> authentication protocol to verify a WebID that denotes an agent (end-user,
> their browser, or some other piece of software operating in "user agent"
> capacity) -- remember, this is just an extension of TLS which is already
> implemented by all existing browsers
>
> 2. http requests enables use of digest, openid, and oauth based
> authentication .
>
> Thus, a fault on https: can be re-routed to http: and if the
> authentication with the net effect being a processing pipeline for identity
> authentication using a variety of existing authentication protocols. Once
> an agent's identity is determined, data access policies determine access to
> data associated with one or more named graphs  (or graph groups).
>
> Try these links to see what I've outlined above in action re., my Google
> Drive mounted to my personal data space.
>
> [1] https://kingsley.idehen.net/DAV/home/kidehen/Public/GoogleDrive/ --
> https
> [2] http://kingsley.idehen.net/DAV/home/kidehen/Public/GoogleDrive/ --
> http .
>
>
> --
>
> 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
>
>
>
>
>
>