spec contents, generality, keeping the semwebiness trivial and obvious

I had another look at the spec.

 

Having been through something of a learning curve over the last 3 years
(just to do FOAF+SSL in visual basic script, last year) and having had the
benefit of VERY patient teachers (folks here), I now know what I didn't know
then and what I half know now.

 

It may be a bit demeaning for folks working at professorial level to write
material at a level for CS undergrads (or lower), but I think it's what's
needed - on the ontology/sparql-related aspects of this protocol,
specifically.

 

ON the one hand, what is being done here functionally is trivial. Get a
client authn cert from a browser doing https (produced and delivered to 50%
of the planet 15 years ago), and see if it's public key exists in the
container identified by the subject's URI name-form in the cert. This is a
trivial variant of what was expected in 1988, for the directory Name
name-form - which had a validation agent confirm that a cert existed in the
contained identified by that type of subject name. Obviously, one uses a
URI+reasoning lookup in webid land, whereas one used a DAP/LDAP lookup in
directory-land. In DNS land, one maps a domain-name in a cert to a DNS
lookup, etc; in oid land, an oid naming an entity to an oid lookup.

 

Now, in the description of the URI+reasoning lookup that folks could do SO
MUCH good. One could create the conditions for actual adoption today.

 

Just as I once remember looking at the foaf spec and realized that the
referenced resource (in its rdf content-type) itself coded the ontology in
rdf/rdfs/owl (that thereby auto-added its rules to the rdf-based reasoning
engine I was using at the time), so I look to the cert and rsa ontology
expecting these documents to:

 

1)      Teach a fancy reasoning engine in a high-end website how to interact
with the various ontological descriptions, AND

 

2)      Teach a very unfancy bit of CGI code how to issue a sparql query or
issue a sparql protocol request -  in practice. 

 

Now, what I suspect we don't want in this class of specification ( that's
just a simple protocol description) is to very correctly but very
academically write up a design that caters for all the most difficult cases
-  being so properly "generalized" that it can and will cater for all the
query languages and descriptions  - even those yet to even have been
formulated by the community. That property is a nice to have (the universal
webid machine), but - speaking personal - so off-putting that 95% of
programmers will probably just fall back to some adhoc http-class GET query
(and not bother with the semweb, sparql, reasoning, or anyting else that
makes a meal out of test of whether a remote array has a value).

 

What the spec(s) may want to do is just ensure they provide the sparql
queries that SHOULD work 80% of the time (in this year's typical server side
libraries), addressing some of the commonest cases anyone can imagine a
visual basic programmer doing, today.

 

It must not need an advanced degree in CS merely to understand the
description of how to do this. Its trivial in the ldap world to do this
(remembering the practice already exists  for cert, and is deployed widely).
It must be equally trivial in the foaf profile world.