Re: Certificate Triplify Challenge

It's getting late for this, but having looked at odata, excel power pivot and my linked data proxy profile using what is a small data cube tool (for ordinary folk), I prefer for Certs that the cert name does what general name in the san rxtension requires. One cannot change its cert semantics, by name form.

Today the San uri on a cert context had no sense/reference interpretative model. If one wishes Certs to have a name with such a model, define a new extension. In a San, each name form is an alternative (and must have the same core model).

Today if one wishes to point to a document of links declaring endpoints at which one can invoke additional services about the (general name typed) san named entity (by uri, or other-name such as web finger), one uses the subject access method extension. Each method declared is really supposed to play the role of each link (as found for example in my proxy profile page). But I could live with the very having but one, pointing to a collection of links on the referenced document. That ties semweb and Certs more tightly, for mutual benefit.

It was really easy using excel and the semantic web (via the odata/atom content type), and using services pages distinct from the feed of entity instances.

On Jan 12, 2012, at 10:34 AM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:

> On 1/12/12 1:21 PM, Henry Story wrote:
>> 
>> Let me now jump to the more positive parts of Kingsley's reply.
>> 
>> On 12 Jan 2012, at 03:54, Kingsley Idehen wrote:
>> 
>>> On 1/11/12 8:06 PM, Henry Story wrote: 
>>>> In the grey box below we have put the URI which is the name for a document served by an apache server. The name is one thing (it has 21 characters) the document is another thing (it contains a public key and many more characters, and can change over time)
>>>> 
>>>> <mime-attachment>
>>>> 
>>>> When, as in this case, the URI _refers_ to a document, the sense and the reference of the URI coincide: they are both the document, or information resource referred to. 
>>>> 
>>>> But with "https://bblfish.net/#hjs" things are different. That URI refers to <https://bblfish.net/#hjs> ie to me. The sense of the URI can be found at <https://bblfish.net/> which is a document, the same document we were discussing in the previous diagram.
>>> 
>>> In computer science terms e.g., 'C':
>>> 
>>> 1. https://bblfish.net/#hjs -- "*" (de-reference / indirection unary operator)
>>> 2. https://bblfish.net/ -- "&" (address-of unary operator).
>> 
>> yes, that is interesting. This is very likely where we got the idea of dereferencing URLs from. So this is a good time to see if this analogy is a good one. Ie, we have to see where it holds and where it does not. I don't think I ever looked at that carefully, and since we use these terms in the spec quite a lot, it is a good time to consider this.
>> 
>> So in order to answer this I first had to remind myself of C addressing since it has been some time that I have not used it. I found a good tutorial here http://augustcouncil.com/~tgibson/tutorial/ptr.html
>> 
>> [...reading...]
>> 
>> In C the address-of operator '&' is an operator that takes a variable and gives you an unsigned int.
>> 4:   float fl=3.14;
>> 5:   unsigned int addr=(unsigned int) &fl;
>> So if we apply this to URIs then we would need a function from URIs to their addresses, which could be expressed as an owl:FunctionalProperty. Let us call it :addr
>> 
>>   "https://bblfish.net/#hjs"^^xsd:anyURI  :addr   ?addr1 .
>>   "https://bblfish.net/"^^xsd:anyURI         :addr   ?addr2 .
>> 
>> It turns out that the value of the :addr relation is not determinable a-priori, since one needs in http for example to follow the possible redirects to be able to determine what the value of it is. So for example it is quite possible that following statement satisfy the above query:
>> 
>>   "https://bblfish.net/"^^xsd:anyURI         :addr   <http://bblfish.net/index.html> .
>>   
>> Now what is the equivalent of the C de-reference * operator for us? This is a function that when given an address, returns the value of that address. There is a relation in existence that does this log:content
>> ( see http://www.w3.org/2000/10/swap/doc/Reach ). I am not sure that relation is exactly what we are looking for, as it says "for documents", and we are looking for something that gives us the content of any uri. This is what in my diagrams I call the :sense relation.  In all we were dealing with was the document web then log:content would be enough. But since we also dealing with referents in the real world, as shown in this diagram, then we need the :sense             relation here (perhaps better called senseDoc ) which relates any URI to the document that gives its canonical sense.
>> 
>> <mime-attachment>
>> 
>>       
>>     "https://bblfish.net/#hjs"^^xsd:anyURI  :sense """ ... <#hjs> foaf:name "Henry Story" ... """ .
>> 
>> Interestingly it looks like we can now combine :addr with log:content to get :sense .
>> 
>>  { ?uri :addr ?addr .
>>    ?addr log:content ?content } => { ?uri :sense ?content } .
>> 
>> So perhaps we are not that far off from combining & and * 
>> 1: #include <stdio.h>
>> 2: int main()
>> 3: {
>> 4:   float fl=3.14;
>> 5:   unsigned int addr=(unsigned int) &fl;
>> 6:   printf("fl's address=%u\n", addr);
>> 7:   printf("addr's contents=%.2f\n", * (float*) addr);
>> 8:   return 0;
>> 9: }
>> Ok. So that is interesting. 
>> 
>> Good so with this mapping clarified, I will next need to see what the issue is that we were trying to resolve originally.
>> 
>> Henry
> 
> Some additional pointers (so to speak):
> 
> 1. http://www.youtube.com/watch?v=f-pJlnpkLp0 -- nice video (404 is better than that loud noise of Dr. Watson of yore re. system faults)
> 2. http://www.w3.org/2001/12/semweb-fin/timbl-1989-image.gif -- WWW design document, just overlay documents (a type or resource) with URL and then apply URI to the things described by the documents. 
> 
> 
> -- 
> 
> 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
> 
> 
> 
>