- From: Peter Williams <home_pw@msn.com>
- Date: Mon, 9 Jan 2012 21:01:15 -0800
- To: Kingsley Idehen <kidehen@openlinksw.com>
- CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>
Each of those links is an Xrd sep equivalent (and the ssl handshake plays the role of the dynamic dsig element embedded into the Xrd by the xri server for the named endpoint. Each one, for each presentation syntax, describes the same thing. Somehow I'm supposed to do what one does in ldap uri, to select suitably do as to return the properties for a particular object class (of the many for the entities in the search scope). In my case I want the ppd, and not instances of classes about data sets, crawling, or even documents entities. It is the latter that the links seem to be describing Obviously I could formulate my own rdfs centric query, and fire it off to the agent. I think you are saying that an alternative config time manipulation of the agent software could be having it not return links about documents: but always about ppds or persons, or cert:keys even Anything that I can navigate to could be the default object class for the endpoint - driving the link set returned for a simple get. This is just a change of the describe query (to be) embedded into each of the (interpreted) links. This all seems do much more coherent and big picture than rest web API (fussing over http verbs) for such system integration. Now there are m action verbs, one per sparql query one might formulate. One just defined getperson http verb, essentially. Anyways, off to get the azure oath endpoint and sample working not for limiting api access but so as to enforce limits on who can authoritatively describe me (and offer seps/links about the data sets they augment and mash up). Perhaps I don't want to be associated with all Peter Williams. One is a formal wanted terrorist and this caused a fuss for years in the us and a really major fuss then when I entered china... Fortunately I'm very distinctive visually. But we are now getting closer to something we have to procure, probably in cloud variant. There is just no way I could bring this culture in house. But, exporting profiles to then be described alternatively and in parallel in several different federated namespaces is where we are going - each one with a different cert for the same human (in his brokerage, state, professional, listing, federal, local and the regional reciprocal liaisons, and subscriber personas. This goes beyond rdfs sub-properties etc. Doing this with the same core technology that the googles etc are using for the consumer world seems natural, so the consumer and realtor identity interface will be sound. Sent from my iPhone On Jan 9, 2012, at 7:08 PM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote: > On 1/9/12 8:27 PM, Peter Williams wrote: >> ok, so since there is so little time left, >> >> >> >> the SAN URI has http://foo/x#me (for now).I will assume validators will not follow any HTTP code other than an 200. >> >> >> >> >> >> The service locator for the cert:key ( in its ASN.1 subjectpublic blob form, within the cert, as encoded using DER) in question can point to a service access point, and endpoints can refer. They can refer to other endpoints in the normal course of re-locating service delivery access points, or make 303 types statements (which I failed to mint, after an hour of trying, since ASp.NET MVC3 just doesnt want me to). >> >> >> >> I note that I have two choices, for the URI I put in the service locator : >> >> >> >> if I put this: http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About, im expecting the UA to use content negotation, and pull down its teh object in favorite encoding rules (much like any layer 6 psap, negotiating the presentation data value (PDV)). Im goint to assume asking for the RDFa access type is not advised, here >> >> >> >> If I am a browser to said URI, I will get a redirect to another document in human readable HTML >> >> http://uriburner.com/about/html/http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About >> >> >> >> Whats more, its RDFa parsable, at least for doctypes etc. >> >> >> >> I think this means that I put in >> >> >> >> 1 SAN URI: http://idweb.cloudapp.net:8080/Home/About#me >> >> >> >> 2 and subject identity URI: http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About >> 3 and subject identity URI: http://uriburner.com/about/html/http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About >> >> >> >> >> A validating agent can pull its favoriate machine-centric PDV from 2. A RDFa-aware validating agent can pull alternatively from 3. It may be possible for a VA asking for text/html or application/xhtml to get redirected from 2 to 3. >> >> >> >> By some magic I dont understand, a validating agent can also get from >> >> http://uriburner.com/about/id/entity/http/idweb.cloudapp.net:8080/Home/About to the equivalent of an XRD, identifying service access points. This seems to involve some somehow posting arguments that induces the page to morph to a different rdf type as its basis. > > Yes, this is a proxy URI that's produced by our in-built Linked Data middleware. Install Virtuoso + the sponger middleware module and you have the same thing in the domain of your choosing. We just use URIBurner to showcase this functionality while also offering a public Linked Data transformation service etc.. > > Goto: http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http%3A%2F%2Furiburner.com%2Fabout%2Fid%2Fentity%2Fhttp%2Fidweb.cloudapp.net%3A8080%2FHome%2FAbout&useragentheader=&acceptheader= . > > Just follow the links from the HTTP responses, and you'll quickly decipher the seems magical. It's just RESTful interaction that includes content negotiation as and when required. > > >> >> >> >> Finally, on the HTML form of the serice deliver page (3), we see such as >> >> >> >> http://uriburner.com/rdfdesc/oat/crypto.js >> http://uriburner.com/rdfdesc/oat/xpath.js >> http://www.facebook.com/dialog/oauth?api_key=172525162793917&app_id= .... >> >> >> >> here we see that the RDFa page is more thah a mere serialization alternative, for a PDV. Its even IS a service client implementation, and can be bearing such as the javascript for the very SSL client implementation that will now make use of the access points. >> >> >> >> very very nice. > > Yes! > > Thanks for deciphering all of this. > >> >> >> This is a variant of what I wanted to do a long time with someone from javasoft long time ago (that Bellovin crushed), in putting javascript into the cert's HTML extension, making the cert into a mobile page - with its own implementation of the service access method it keyed. > > We've always felt that Linked Data's value proposition should actually manifest via LINKs :-) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > > -- > > 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 > > > > > >
Received on Tuesday, 10 January 2012 05:01:47 UTC