Re: Slash URIs and WebID Experiment

hi kingsley,

i'm glad i could help, thanks for making it as clear as it can get.

i have updated my profile and i feel much better as "any kind of resource" than as "information resource" :)

for people who want to follow your steps below, i did backup my old slash-profile @ http://www.turnguard.com/mylifeasdocument.

one note on my old profile and uriburner : you might have an old version cached.


so your point is simply, 

if we want webid to stick (hard) to linked data principles, we must have a possibility to put the difference between
name and address into the certificate. why? because linked data principles are not limited to 2-in-1-hash-uris
and a webid like http://www.turnguard.com/mylifeasdocument must be rejected because it can't be both (name and address)
without breaking said principles.

right?

wkr j

----- Original Message -----
From: "Kingsley Idehen" <kidehen@openlinksw.com>
To: public-xg-webid@w3.org
Sent: Tuesday, January 10, 2012 7:35:53 PM
Subject: Re: Slash URIs and WebID Experiment

On 1/10/12 11:58 AM, Jürgen Jakobitsch wrote:
> hi,
>
> i'm not sure if this webid [1] meets your test criteria. anyway here are the results.
>
> 1. http://id.myopenlink.net/ods/webid_demo.html
>     accepted
> 2. https://webid.turnguard.com:8443/WebIDTestServer/
>     accepted
> 3. https://resourceme.bergnet.org
>     failed
>     3.1. http://www.w3.org/2005/Incubator/webid/earl/RelyingParty#profileGet =>  failed
>     and consequently all tests southwards failed.
> 4. http://webid.fcns.eu/
>     passed (when using https://auth.fcns.eu/auth/index.php?authreqissuer=http://webid.fcns.eu/index.php)
>     passed (when using https://foafssl.org/srv/idp?authreqissuer=http://webid.fcns.eu/index.php)
> 5. https://foafssl.org/test/WebId
>     passed
>
> cleared cache, cookies and active logins (in firefox) and retried
>
> 6. https://resourceme.bergnet.org
>     failed
>     6.1. http://www.w3.org/2005/Incubator/webid/earl/RelyingParty#profileAllKeysWellFormed =>  failed
>     and consequently all tests southwards failed.
>
> wkr j
>
> [1] http://www.turnguard.com/turnguard

Jurgen,

For WebID, great i.e., you put it in SAN and it worked.

For Linked Data no [1][2]!

What you have proven is this: WebID doesn't need the full fidelity of 
Linked Data. If it did, then your use of a slash URI that returns a 200 
OK means Name/Address ambiguity, a Linked Data no-no. Ultimately, you 
end up with problems associated with object equivalence fidelity (be it 
by names or values). Using more conventional Linked Data parlance, via 
this URI, you are confusing yourself with a document.

Conclusion: your slash URI doesn't exhibit the same Linked Data 
characteristics demonstrated by mine [3][4]. That's not a bad thing 
since my fundamental point is that:

1.  my slash based HTTP URI is generated by my Linked Data platform.

2. use of my platform or others, shouldn't be the base requirement for 
WebID if it seeks full Linked Data fidelity as a mandatory requirement 
for HTTP URIs in a Certs. SAN.

You are proving my point !

SPARQL Query Proof:

## using old WebID query pattern since your graph is using old WebID 
related relations still

PREFIX : <http://www.w3.org/ns/auth/cert#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT * WHERE  {
?identity cert:identity <http://www.turnguard.com/turnguard> .
?identity rsa:modulus ?m ;
          rsa:public_exponent ?e . }

SPARQL Protocol URL Links:

1. http://uriburner.com/c/IBZM4R -- sparql query results
2. http://uriburner.com/c/IBJUQG --  sparql query editor.


Links:

1. http://uriburner.com/c/IBJUQP -- URI debugger output (note: re. 
Linked Data that should be a 200 OK)

2. http://uriburner.com/c/IBJUQS -- note how it shows you only have 
descriptor (information) resource address

3. http://uriburner.com/c/IBZM45 -- notice the 303 (how HTTP message 
exchange is used to facilitate indirection via redirection)

4. http://uriburner.com/c/IBYXSV -- note how the report concludes that I 
have a generic Name distinct from a descriptor (information) resource 
address.

Thank you once again, for helping me showcase an inevitable problem for 
those who want to start their WebID journey in commodity/consumer mode 
leveraging "cut, paste, and place at an address" patterns i.e., the most 
common Web technology exploitation pattern.

Solutions:

1. Lower Linked Data fidelity requirements in WebID -- it becomes an 
option, so 200 OK is fine if the SPARQL ASK still works
2. Allow multiple HTTP URIs in SAN where functions are clear re. Name 
and Address roles
3. Consider another (optional) location for the descriptor (information) 
resource address e.g. sIA.

We need at least one of the above to address the problem introduced by 
HTTP URIs. One that many just don't understand until bitten.


Kingsley
>
> ----- Original Message -----
> From: "Kingsley Idehen"<kidehen@openlinksw.com>
> To: "WebID XG"<public-xg-webid@w3.org>
> Sent: Tuesday, January 10, 2012 3:30:32 PM
> Subject: Slash URIs and WebID Experiment
>
> All,
>
> The URI:
> http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen , is
> now fine for testing purposes.
>
> I've verified successfully using:
>
> 1. http://id.myopenlink.net/ods/webid_demo.html
> 2. https://webid.turnguard.com:8443/WebIDTestServer/
> 3. https://resourceme.bergnet.org
> 4. http://webid.fcns.eu/
> 5. https://foafssl.org/test/WebId .
>
>
> Now, it would be nice to see someone else produce a Cert. with a slash
> based HTTP URI in its SAN that passes through all of the above, or at
> least a majority of them.
>
> At this juncture, for experimentation you have the following HTTP URI
> based Names:
>
> 1. http://kingsley.idehen.net/dataspace/person/kidehen#this
> 2. http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen .
>
>


-- 

Regards,

Kingsley Idehen 
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







-- 
| Jürgen Jakobitsch, 
| Software Developer
| Semantic Web Company GmbH
| Mariahilfer Straße 70 / Neubaugasse 1, Top 8
| A - 1070 Wien, Austria
| Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22

COMPANY INFORMATION
| http://www.semantic-web.at/

PERSONAL INFORMATION
| web   : http://www.turnguard.com
| foaf  : http://www.turnguard.com/turnguard
| skype : jakobitsch-punkt

Received on Tuesday, 10 January 2012 23:28:30 UTC