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

RE: The SPARQL Query

From: Peter Williams <home_pw@msn.com>
Date: Wed, 14 Dec 2011 10:50:15 -0800
Message-ID: <SNT143-W49757EDBA91734317CE39892A20@phx.gbl>
To: <henry.story@bblfish.net>, <mischa@mmt.me.uk>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

1. I don't look at webid as a "semweb starter kit" - though I do look at it being engineered for normal consumers, using typical web tools. if its a toy (like the eletronics toolkit phillips sold me as a 12 year old to learn about having 2 transistors implement an and gate), the spec NEEDS to say that. if its ready for 5000 cisco phones with client auth capability and CTLs do now turn on the client certs the phones use when setting up a secure voice stream, thats quite a different proposition. The trust models have to work, they have to prevent device spoofing, the FBI wants to know it can rely on the certs to hang you for the contents of the call, etc. Get the spec clear about its mission: ready for productization, or,  ready for play time with SDK vendors making toolkits for *teaching* and evangelism. In the latter case, there is NO market (except making SDK training kits). 2. Assuming its a training kit focus, perhaps consider having 2  ASK-based validation steps, the second of which is optional. The second uses rdfs (and not owl) somehow. Its important (speaking as a CIO investing in technology options, now, not as a programmer) that the foaf project is highlighted in webid; it not enough to be doing triple graph walking, with a SPARQL wrapper. Im distinguishing here the foaf project (goals) from the foaf ontology (just a bunch of definitions for meta-markup). With the foaf project scope, I want the foaf spec to be used by a validator as a rule source. Im buying into rules-based IT processing, at that point - for future id management. What query can we have as "higher assurance" validation that *does something* with the foaf:openid property, related to what the first step query just proved? its important that some of the "integration themes" are showcased, without stressing the baseline. this is where the engineering upgrades do "just a little more" that justifies WHY BOTHER with all the apparatus being imposed by webid.From: henry.story@bblfish.net
Date: Wed, 14 Dec 2011 12:00:16 +0100
CC: public-xg-webid@w3.org
To: mischa@mmt.me.uk
Subject: Re: The SPARQL Query

On 14 Dec 2011, at 11:50, Mischa Tuffield wrote:Hello All, 
Given that the Cert Ontology defines both http://www.w3.org/ns/auth/cert#key and http://www.w3.org/ns/auth/cert#identity  shouldn't the spec  document the two SPARQL queries which would achieve the same thing? 
Personally I would have ditched the inverse properties as they just make things more complicated, and I would have stuck with just cert:key. danbri has thoughts on this two given his experiences with the foaf ontology.
cert:identity should be deprecated by now - in fact it is listed as "archaic" in the ontology. So yes, we have decided to go with cert:key , because it is easier to go from agent -> key than key-> agent.
the reason is of course also that we only want 1 sparql query, and we don't want people to need a OWL enabled graph with sparql.
Those are things that people will feel very useful as they explore the semweb having started using webid. But there is no need to make in necessary at this point.

That is both of the below are acceptable queries given the Cert Ontology. should section " Verifying the WebID Claim" include both of the below SPARQL queries?
PREFIX : <http://www.w3.org/ns/auth/cert#>PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>ASK {      ?webid :key [         :modulus ?mod;         :exponent ?exp;
      ] .}
PREFIX : <http://www.w3.org/ns/auth/cert#>PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>ASK {       ?bnode :identity ?webid ;       :modulus ?mod;       :exponent ?exp.
_____________________________Mischa Tuffield PhDhttp://mmt.me.uk/http://mmt.me.uk/foaf.rdf#mischa

Social Web Architect

Received on Wednesday, 14 December 2011 18:50:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:50 UTC