I created yet another web role in Azure, discarding MVC (thinking it to be a hinderance). The master site template and the page from the MVC project were simply moved over to a classical ASP.NET project. The Home/About resource from the MVC world is now /About.aspx.
http://b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/About.aspx produces the following view in a browser. To the relatively named subject (#me) I bind a webid cert:key predicate whose value is a reference to structured entity of the RSAPublicKey type. With an anonymously named subject, this latter entity has two further predicates: the modulus and exponent. These predicates each bear a property (a value type) constraining the object value – much like a particular relation between actual entities in the ER world can have properties.
Click here to execute the render a sparql query concerning the graph:
The result is:
in the entity whose subject name is “http://uriburner.com/about/id/entity/http/b3d0c8f68475422784748b65f76b1642.cloudapp.net:8080/About.aspx#me”, note the uriburner prefix (to what is now a “proxy” URI). Viewing this URI in the browser shows:
Now, lets create a cert with two SAN values
When we use this value at FCNS we still get errors:
We did learn something about linked data (finally) though, in the sense that the uriburner page reveals how it wraps or “connects” to my underlying page. Not only does it cache, but it describes it further. If nothing else, it describes the method it uses to crawl my triples into “my” local triple store in my “dataspace”. This is all very nice, except that webid doesn’t work.
So, let’s now take some advice and replace the relative names “#me” (in the underlying triple collection) with absolutely named triples.
We start with
and (having edited the master document for the foaf:primaryTopic reference, similarly) we end up with
Understanding that my data space in ODS is a wrapped copy of my “connected” data source, where all identifiers are proxy URIs (including such as foaf namespace), presumably ONLY the ODS-based webid validator can take advantage of this particular triple store – knowing to do webid queries in this “connected” context.
Does this mean the same cert works at FOAFSSL, or FCNS? Well… sort of. It’s all relative (and upside down, and twisted inside out).
We can guess that FOAFSSL is able to reason with the more advanced triples in the openlink reference, and tune up its query to validate the cert against the linked data version of my “connected” profile – though it cannot do so against the original source.