RE: neither FCNS nor FOAFSSL can read a new foaf card (hosted in Azure). RDFa validators at W3C and RDFachecker say its fine...

 Im convinced that  the pyRDFa tool is behaving correctly, when one uses option 2. Correctly, the server provides no triples given URI #2 on the wire, and the reader infers NONE. It doesnt "fabricate" any triples. ------------ Of course, pyRDFa might have acted as a sponger, inferring some triples from the HTTP 400 response message. But, we are not in the sponging part of the web. WebID actualy needs the documents to be assertions (in which only the statement made are considered, and then only "authorized" inferences can be made).  Im distinguishing now between the method of sponging (to use Kingsley's term) as a way of screen scraping some RDF (traditional semweb), from proxy profiling (as a function of webid). In the webid context specifically, it makes perfect sense to be intending to create "proxy profile" and then use  the multiple SAN URI feature. > Date: Wed, 28 Dec 2011 09:44:10 +0100
> From: j.jakobitsch@semantic-web.at
> To: home_pw@msn.com
> CC: kidehen@openlinksw.com; public-xg-webid@w3.org
> Subject: Re: neither FCNS nor FOAFSSL can read a new foaf card (hosted in        Azure). RDFa validators at W3C and RDFachecker say its fine...
> 
> hi,
> 
> you should use http://www.w3.org/2007/08/pyRdfa/ to check your rdfa.
> 
> paste 
> 
> 1. http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Aboutrel.aspx      => rdf
> 2. http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Aboutrel.aspx#me   => empty rdf
> 
> in the "distill by URI" tab.
> 
> wkr http://www.turnguard.com/turnguard
> 
> ----- Original Message -----
> From: "Peter Williams" <home_pw@msn.com>
> To: kidehen@openlinksw.com, public-xg-webid@w3.org
> Sent: Wednesday, December 28, 2011 8:08:19 AM
> Subject: RE: neither FCNS nor FOAFSSL can read a new foaf card (hosted in        Azure). RDFa validators at W3C and RDFachecker say its fine...
> 
> 
> 
> Your tester fails against http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/Aboutrel.aspx#me 
> 
> The stream is literally the RDFa card from the spec (with the modulus changed). 
> 
> (The endpoint will provide an error response, should the GET bear a fragment in the URI request arg.) 
> 
> While the "snippet" of that spec card works fine in blogger with all test sites, none of the 3 testing sites work with what is actually given. This suggests the spec needs to change its example. 
> 
> One notes how the Turtle example is absolutely anchored (unlike the RDfa example). Advise that the spec have identical triples (in different representations) 
> 
> 
> > From: home_pw@msn.com 
> > To: kidehen@openlinksw.com; public-xg-webid@w3.org 
> > Date: Tue, 27 Dec 2011 21:37:48 -0800 
> > Subject: RE: neither FCNS nor FOAFSSL can read a new foaf card (hosted in Azure). RDFa validators at W3C and RDFachecker say its fine... 
> > 
> > 
> > I have spent a few hours getting really to grips with both ODS and linkburner. 
> > 
> > Certain things are VERY straightforward. 
> > 
> > 
> > 
> > I logon with a password, and then map a cert to the account (just like in windows). And, I can use the ODS builtin CA, to mint a second cert with a variety of browser plugins/keygentags. The net result is I can do https client auhn to ODS, replacing the password challenge. Technically, a cert-based login to ODS may even count as an act of webid validation (rather than mere https client authn based on fingerprint matching). 
> > 
> > 
> > 
> > Next, the account gives me a profile page. For any n certs registered (with logon privileges, or not), the profile publishes cert:key. Well done. From cert, infer cert:key. For a third party cert, I can now reissue it (same pubkey) adding the ODS profile URI. 
> > 
> > 
> > 
> > Then I got a real feel for sponging an html/rdfa resource. The proxy prpofile/URI is essentially a new profile, borrowing bits from the "data source" that it screen scrapes. It has nothing to do with the accounts' own profile page. The resultant profile has a proxy URI, and one can put this in the SAN URI set of the cert whose pubkey was in the the original data source (and now in the proxy profile). 
> > 
> > 
> > 
> > I altered by http://yorkporc2.blogspot.com/ template/page. It now as a webid.cert relation/link. Its a data URI, of type cert... with base64 blog content. Ideally, sponger would now infer cert:key from that link (but not any webid/foaf material), much like ODS profile inferred cert:key from its store of mapped certs/accounts. It would sponge the rest of the foaf card as normal. 
> > 
> > 
> > 
> > I was able to use the ODS webid validator to validate against my cloud/azure hosted TTL card. 
> > 
> > 
> > 
> > I was able to run sparql queries on my yorkporc HTML and TTL resources. I now understand (finally, after 2 years) why the sparql query for HTML gives the proxy name for the subject (with cert:key) rather than the data sources URI. Im really doing sparql against the proxy profile (not the data source), despite the FROM clause in the sparql identifying the data source. When one uses a non sponged resouce (TTL), the sparql result is more insituitive as to subject names. 
> > 
> > 
> > 
> > i went through all the product documentation. 
> > 
> > 
> > 
> > I learned that you are using the foaf:account as a mapping mechanism (not merely a publication device). If one uses facebook websso to authenticate, it maps to an ODS account whose foaf profile publishes said foacebook account name in a foaf:account property. 
> > 
> > 
> > 
> > I suspect (but could not confirm) that the foaf:openid similarly enables an openid identifier presented in openid websso to mapto a ODS profile, on login authentication. O failed at any UI to get the system to act as an openid relying party, talking to my http://yorkporc.wordpress.com's openid server. 
> > 
> > 
> > 
> > The built in openid server (that uses a webid challenge) is confusing. I dont know if the webids and profiles that it vouches for are limited to those in an ODS profile, in a proxy profile, or are for any other public webid (for which a proxy profile is immediately created). 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> -- 
> | 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
>