On 1/31/14 7:46 AM, Alfredo Serafini wrote:
Hi allregarding 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?
URIs have to be opaque to function properly as platform agnostic identifiers. Thus, <http://wiki/page.html> denotes one entity while <http://wiki/page.rdf> denotes another. <http://wiki/page.html>
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, <file://wiki/page.html> denotes yet another entity. Kingsley
2014-01-31 Kingsley Idehen <[email protected] <mailto:[email protected]>>: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 <http://www.openlinksw.com/blog/%7Ekidehen> Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
-- 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
smime.p7s
Description: S/MIME Cryptographic Signature
