We have a nice new profile to add to our collection, one hosted in Windows Azure and in IIS7. This profile, to be known as “idweb” works with one site (which is better than zero). Other profiles to which I have asserted mutual owl equivalence to/from idweb include: yorkporc2 (a blogsite). Another profile is yorkporc, to which idweb asserts one-way equivalency (since I cannot now edit yorkporc, further).
Our goal is now to get ourselves a proxy URI for idweb (http://idweb.cloudapp.net:8080/Home/About#me) in the linked data cloud. So lets do work on querying the triples from the document at http://idweb.cloudapp.net:8080/Home/About.
The result is here (show below with an interesting twist, since that run was looking at a ”draft” page).
The RDFa distiller service provides another view, which makes the special “blogging” relationship of the openid to the blog site more apparent (than either of the other views). The red arrow show this, while the cert:key (blue arrow) does NOT show such a special relationship.
Similarly, we edit idweb to complete the mutual relation:
And, we confirm it still works with WebID Realm, with new triples shown. For an easy to to mount technical demo, we need only use the bookmark to view the profile page, and then click the uriburner “isparql” bookmarklet (which prepare a sparql query for the page on view):
When we look at our page as a person would, we can now use the linked data validator (which tells us our document and endpoints are not perfect). One option is to ping the semantic web (to alert crawlers to now crawl). The idea is that THEY can deliver the same data in the appropriate manner, leaving me alone to build web application for people.
We then see that the world can see our assertion of equivalencies (by which we induce one crawler to have crawled, incidentally). We use
define get:soft “soft”
# SELECT query using
# FROM to identify each named graph (by IRI) to which inference context is to be applied.
#DEFINE input:same-as “yes”
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX : <http://www.w3.org/ns/auth/cert#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
?s owl:sameAs ?o
We get our expected result:
But, we notice that it is not the triple we asserted (in our namespaces). Rather the derived names (using a copy of the data) that are make derived sameAs assertions between themselves (describing the actual equivalency in our own namespaces). Lets remember, the inferencing engine can reason about our original namespaces using its model (in its proxied namespace). It can answer queries as-if it was reasoning directly.
Looking at the personal document, it was quite fun using the iPhones QR reader to point at the screen, and navigate to that complex query (via a tiny URI).
Finally, we can add another equivalency relations — from idweb to yorkporc. This is not reciprocated at yorkporc (since we no longer have an working account)
Now, we add the linked data viewer bookmarklet to our site…
and then use it (here).
First we see,
where we note the form of the GET operation:
If we click on the seeAlso link (Peter variant), we see
where we note the subtle difference in the GET (to the seeAlso resource on the SAME “document”)
Clearly, what we are looking at is the “crawlers” view of documents (and facts of crawling acts).
So how do we now link to Person object we most covet?
Well, we can use the isparql bookmarklet, hosted on uriburner.com, clicking on the navigator’s view of the person object and then viewing (using the triples view):
The navigator itself shows our proxy URI and the proxy profile: http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About
Now, hopefully we can put that in the certificate as the SAN URI and use it, at foaf.me.
Well done Henry (and co). Well done linked data (now I know what it even is).