W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

RE: Another Translator for RDF

From: Peter Williams <home_pw@msn.com>
Date: Fri, 30 Dec 2011 07:39:45 -0800
Message-ID: <SNT143-W2310EA1350F5BD00FD581C92920@phx.gbl>
To: <mo.mcroberts@bbc.co.uk>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

Thats was very nicely stated (and did better than Kingsley, in the dumbing it all down for Peter measure).  It defined what the owl:sameAs does to the user of the translated document. it makes equivalency of the documents for de-referencing purposes, even though hosted on different "endpoints" I had looked at this in mere phone book terms - as a yellow/green pages reference to a white pages entry listed in the phonebook - in which the yellow page listing gets to add some additional facts about the white pages listing, as does the green pages listing to the same. Now, its not so scary. So, once I add the owl:sameAs, I can feel comfortable putting the translation site's endpoint into my SAN alongside the "static source".  About the only thing I dont know is how to "add some triples" (such as the commercial ad and icons, in the yellow pages analogue). Presumably this is where we move away from dyanically-rpdocued "proxy profiles" and we allow two static foaf cards to assert owl:sameAs in a wrapper/wrappee relation, with the wrapper providing the fact with the commercial ad. or, in my case, the certificate with the same key as the self-signed cert in the base profile, signed by a different CA. There can now tbe 100 such wrappers, each with a signed cert by 100 CAs, all "adding" value to the self signed cert (or the cert:key relation) And, from what I inferring from Kingsleys hints abou APPLICATION of the semantic of formal equivalency classes (in the math sense), an openid asserting minting service (an openid server) make a statement about its own or another's recent act of webid validation can vary its assertion depending on its detection of the formal equivalencies. If you play with the ODS openid/webid proxy, it will easily give a screen with a webid and openid after doing webid validation. But, the assertions  given back vary (sometimes NOT providing the so called op_identifier field). At first I though this was a bug (since it throws the receiving protocol engine). But, its acually the asserting party changing behaviour based on subtelties of what it infers about equivalencies, and what its willing to assert about the name claims it was aked to make statemenbt about. Furthermore, per the openid protocol, which provides a means of asking about some subtle distinctions about names from an "about service for secure names", it can distinguish between those formal use cases in the openid protocol - distinguishing openid 1.0, openid 1.0 delegation, and openid 2.0 identity_select secure naming regimes.          
 > From: mo.mcroberts@bbc.co.uk
> Date: Fri, 30 Dec 2011 11:48:00 +0000
> CC: public-xg-webid@w3.org
> To: home_pw@msn.com
> Subject: Re: Another Translator for RDF
> 
> 
> On 30 Dec 2011, at 09:31, Peter Williams wrote:
> 
> > his #this is NOT attached to my yorkporc URI. There is no entity with such name in my card. His #this is not even attached to the (URI=typed) parameter in the translating services invocation URI.
> 
> 
> > Onto the end of that he stuck a #this. He could have stuck a #that, but was alluding to the semantics we all know from C++'s this. We all learned #this, in moving from C to C++! (If you use extension methods in C#, its gets even more fun.)
> 
> Ahhh, okay, I see what's happening -- 
> 
> 
> So you want to use an automated translation service to get N3 (and instead of republishing that N3, just point things at the dynamically-generated version -- certainly fine for testing).
> 
> Now, your URI (which when dereferenced results in some RDFa describing you, amongst other things)  is <http://yorkporc2.blogspot.com/#me>. Whether you're meant to include the fragment in the 'url' parameter to the translation service or not is a matter for that translation service (the fact it's a "URL" parameter suggests not, as it's a resource translation facility, but it might accept it and strip it anyway, doesnít really matter).
> 
> BUT, because it's a resource translation facility, what you feed into it ó a resource which *includes* a description of <http://yorkporc2.blogspot.com/#me> ó you get back out again, subject URIs and all. A consumer of that translated resource won't know to look at the statements with <http://yorkporc2.blogspot.com/#me> as the URI because that isn't the URI you handed the consumer for yourself.
> 
> You can add assertions, though, so you add an assertion to your source document stating that <http://yorkporc2.blogspot.com/#me> is the same as <http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3#this>. Then, you tell consumers to use that URI (complete with the #this) and they do so and find a owl:sameAs relation pointing them at <http://yorkporc2.blogspot.com/#me>, which in theory they donít need to bother fetching because it's already described in the resource they've got.
> 
> What threw me was that you hadnít got as far as adding the owl:sameAs relation to your source document, so it doesn't appear in the translated output either, and so '#this' doesn't appear anywhere.
> 
> It's a neat trick, but I can think of a couple of awkward reasons why you might not want to rely on the behaviour. Tends to be easier to use the translator to generate the format you want and the republish it with conneg switched on!
> 
> M.
> 
> -- 
> Mo McRoberts - Technical Lead - The Space,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> Project Office: Room 7083, BBC Television Centre, London W12 7RJ
> 
> 
> 
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> 					
> 
 		 	   		  
Received on Friday, 30 December 2011 15:40:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 30 December 2011 15:40:15 GMT