Re: default hashtags

On 12/2/11 4:20 PM, Peter Williams wrote:
> Hmm.
> I dont know what to do, despite all the words :-). I dont know it FCNS 
> test site is conforming or not, in its ACCEPT behaviour.

Andrei: how are you are you verifying WebIDs? Do you use SPARQL ASK? If 
not, how are you determining the WebID (an Object/Entity Identifier) 
used in relation lookup?

> I do know that anyone can mint a cert, and anyone can stick any crap 
> in one (particularly the self-signed variety).


> I do know that anyone can get a 90day eval of windows 2008 R2 EE and 
> run a Windows CA themselves, into whose certs the admin can stick any 
> old crap... I know that installing openssl binaries is a matter of 
> no-effort, as is running its little command line tool. Running 
> makecert.exe is not much harder in the windows installs of a million 
> developers using microsoft compilers. (Remembering the ever-moving 
> path to its bin directory is the hardest part.)


> I do know that validation agents are responsible for formulating the 
> query, and choosing which URIs of the n options **to try** to 
> dereference. They have responsibility for filtering the URIs 
> *suggested*, that is.

Yes, and this is the key to the matter, so to speak. We have an 
identifier (WebID) for a Subject that's in a relation expressed in a 
profile graph in the IdP space.

The WebID is a de-referencable identifier so via indirection it resolves 
to a profile graph (in fact any directed graph based structure) that  
bears a semantic relation between the subject identifier and the public 
key components of an x.509 cert.

> Are we saying that a good/better validation agent would IGNORE certain 
> URIs if they dont meet some rule?

Yes, esp. as the rule is one that MUST disambiguate Name and Address 
roles. If using mailto: scheme URIs this is pretty clear, but with a 
data access cost re., de-reference based indirection. If using http: it 
is quite unintuitive but cost effective re., de-reference based 

This is basically about using http: scheme URIs to deliver functionality 
delivered by "*" (de-reference) and "&" (address-of) operator 
functionality at InterWeb scales.

> If so, the spec needs to say it, specific it, or give a big hint how 
> important it is.

Yes, but the problem is this httpRange-14 has been raging on forever and 
I don't blame Henry for trying to stay clear of it re. WebID. That said, 
if we veer toward conventional computer science terminology then the 
whole issue vaporizes leaving the ingenuity of http: scheme URI usage in 
this regard in full glory. Most developers (I think) understand 
de-reference and address-of operations re. data access by reference.

> Could we say that UNLESS you have an RDFS reasoner attached to engine 
> evaluating the ASK query, that you ignore this or that of the URI set, 
> if it does or does not terminate with / or a hashtag??

The key is to use URIs *unambiguous* names/handles that resolve to 
documents bearing an EAV/SPO based directed graph pictorial that 
represents a description of the URIs referent.

http: scheme URIs introduce Name / Address ambiguity.
> That seems perfectly reasonable counsel to give implementors.

Yes, if we can get it down into simple language. I like what came out of 
the JSON-LD [1] effort re. de-referencable URIs and graph pictorials. I 
would encourage re-use.
> Our  goal is not to make the most complicated way ever designed of 
> screen scraping 2 strings from a text file on a TCP/IP port.


> It has now to justify all the complexity because the side-effects are 
> WORTH IT. And this means, the semantic web BENEFITS have to now shine 
> (and without being a pain in the ass, reuqireing special web servers, 
> or requiring a PhD in querying). Anyone who has done a a 2 week course 
> in prolog should be able to handle this.

I really think high school kids should be able to handle this :-) They 
already grok Subject, Predicate, Object sentence structure. They use 
need to recognize the fact Web style hyperlinks (URIs) can be used as 
Names re. parts of the aforementioned triple / 3-tuple.

> For example, in my code, I rejected those URIs whose servers would not 
> give me an OK, for a GET on the URI. I.e. if the site redirected me, I 
> ignore the URI from the cert (and moved onto the next one, in ASN.1 
> order).

You have to follow 303 since that's the based design of the WWW itself 
saying: here is how I handle slash terminated http: scheme URIs used as 
a Name rather than a data access Address.

> This is the kind of advice the spec needs to give. It *can* give 
> required handling rules. The rules need NOT to be idealisms or 
> super-correctness as in a academic programming exam, but what 
> facilites WEBID adoption based on *value*.

It has to make clear the fact that a WebID is an unambiguous Subject 
Identifier serving a Generic Name function. Thus, it cannot be an 
Address/ Location Name.

It has to make clear the fact that a WebID provides indirect (rather 
than direct) access to data (the profile and/or claims graph) 
irrespective of URI scheme.
> yes, I want now to know HOW (and when) to exploit equivalencies, so 
> that I can compute the foaf card of the user from my local triple 
> store AND the graph pointed to by the webid. Then, semantic web and 
> foaf cards start to get real. Im doing something I cannot easily, 
> otherhwse.

Yes. Another reason why we must use unambiguous names :-)

> ------------------------------------------------------------------------
> Date: Fri, 2 Dec 2011 15:29:47 -0500
> From:
> To:
> Subject: Re: default hashtags
> On 12/2/11 1:50 PM, Peter Williams wrote:
>     The test site is behaving as I want (though I dont know if its
>     conforming, or going "beyond" the spec). its natural, and useful.
>     It works well with the same blogsite also serving as an openid
>     delegation point.
>     To accomplish the following, all I did was what is "user natural".
>     I took my RDFa from the spec, changed the mod value, changed to
>     integer typing for the exponent, duplicated that a second
>     graph has localid of #, added an openid relation to the
>     #-=identiied graph, and made a cert with 3 URIs, as shown below.
>     If the following holds true to the spirit of this movement, Ill
>     stop putting #tags in the URIs of my certs (assuming that the RDFa
>     marks the graph with the default # tag).
>     * Checking ownership of certificate (public key matches private
>     key)... PASSED (Reason: GENEROUS)
>     * Checking if certificate contains URIs in the subjectAltName
>     field... PASSED
>     * Found 3 URIs in the certificate (a maximum of 3 will be tested).
>     * Checking URI 1 (
>     - Trying to fetch and process certificate(s) from webid profile...
>     Testing if the modulus representation matches the one in the webid
>     (found a modulus value)...
>     Testing modulus... PASSED
>     WebID=b94692148969aeb.......c165dfa03526b25
>     Cert =b94692148969aeb.......c165dfa03526b25
>     *Match found, ignoring futher tests!*
>     * Authentication successful!
>     Your certificate contains the following WebIDs:
>       *
>       *
>       *
>     The WebID URI used to claim your identity is:
>       * (your claim was SUCCESSFUL!)
> Your choice of "/" or "#" terminated URI re. WebID verification is 
> important since we are using hyperlinks as object names/handles rather 
> than object access addresses (URLs). Basically, good old indirection 
> based data access by reference. This fidelity comes into play when you 
> actually put WebID to use performing basic equivalence reasoning. This 
> is why http: scheme hyperlinks are unintuitive object identifiers 
> since they are more commonly used as resource access addresses. This 
> is why a mailto: scheme URI + Webfinger within context of WebID works 
> more intuitively, you don't have the burden of Name or Address 
> disambiguation. Of course, you then end up with a different cost re. 
> data access, but that's covered on the XRD front via hammer stack [1].
> The SPARQL ASK is of the form:
> PREFIX :<>
> PREFIX xsd:<>
> ASK {
> <ObjectID-Which-Maybe-Hash-or-Slash-terminated> 
> <>  
> :key [
> :modulus "{modulus}"^^xsd:hexBinary;
> :exponent "{exponent}"^^xsd:integer;
> ] .
> }
> For now, I encourage you to stick with keeping the "#" in use while in 
> user mode.
> Links:
> 1. -- 
> hammer stack.
> Kingsley
>      *
>     ------------------------------------------------------------------------
>     Date: Fri, 2 Dec 2011 13:18:26 -0500
>     From: <>
>     To: <>
>     Subject: Re: default hashtags
>     On 12/2/11 12:53 PM, Peter Williams wrote:
>         My brain is such that I dont remember technical stuff for more
>         than a few months, unless its refreshed. I dont remember the
>         rules of hashtags, anymore.
>         if I put  in the SAN URI of the
>         certs, will hat get treated asIf
> for the purposes of SPARQL ASK?
>         Im hoping I can change my graph in my webid profile to stop
>         using #me as the RDFa-coded graph's localid, but use #
>         instead, so the above would all dereference
>         Does it?
>         If it doesnt happen by default, is there any statement I could
>         put in my graph at http:/ today to
>         that would induce the validation agent doing SPARQL ASK (when
>         agumented with an RDFS reasoner, perhaps) to have view SAN URI
>         of   asIF
> (and/or
>         http:/
>     Use: http:/ (which is what has to be in
>     the cert. SAN) for SPARQL ASK query patterns, that URI identifies
>     the entity that has a relation with the modulus and exponent parts
>     of the "mirrored claims" held in the IdP hosted profile graph.
>     BTW - you still have the issue of retrieving the profile graph.
>     This is where the FROM clause comes into play re. some SPARQL
>     engines. For instance, Virtuoso (our engine) will perform an HTTP
>     GET subject to in-built cache invalidation rules. Of course, you
>     can override using pragmas.
>     -- 
>     Regards,
>     Kingsley Idehen	
>     Founder&  CEO
>     OpenLink Software
>     Company Web:
>     Personal Weblog:  <>
>     Twitter/ handle: @kidehen
>     Google+ Profile:
>     LinkedIn Profile:
> -- 
> Regards,
> Kingsley Idehen	
> Founder&  CEO
> OpenLink Software
> Company Web:
> Personal Weblog:  <>
> Twitter/ handle: @kidehen
> Google+ Profile:
> LinkedIn Profile:



Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Friday, 2 December 2011 22:01:06 UTC