Re: HTTPS for RDF URIs?

On 31 January 2014 13:46, Alfredo Serafini <seralf@gmail.com> wrote:

> Hi all
>
> regarding opaque uri: maybe a difference in the scheme could be seen as a
> complementary to a different type extension.
>

Opacity is probably the most difficult of the design axioms.

In truth, *no* URI is opaque.  You always split on the ":" and look at the
scheme to the left.  Then you use the out of band ABNF to analyse the
string on the right.

Opacity is a design principle, meaning that introspection on the actual
string hinders scalability or interoperability, because others will need to
know your introspection rules.  It does have its uses tho, for example
blogs and SEO.


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

Best to treat these two as separate resources, unless you have a good
reason not to (that reason may be that you designed the system).  However,
as the web is a scale free system the danger of making that assumption is
that others may not follow it, leading to possible unexpected results.


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

Yes, but you would be following the "file" protocol here, and not, "http".
You may end up getting the same content, tho, or you may not.


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

Received on Wednesday, 5 February 2014 18:58:08 UTC