SemWeb people sure make things as obtuse as possible.  But there is sense in the world in regards to making SemWeb do simple directory work based on object databases.

Based on a reading of http://www.ida.liu.se/~janma/SemWeb/Slides/dario.ppt, one can comprehend RDFS in its own terms. The lucidity in that reading contrasts with the RDFS specification itself. RDFS constructs can also be more easily explained in terms of X.500 standards.

X.500 sense

In the X.500 directory, there are entries. Organized in a tree, each entry has a hierarchical name and several attribute that list properties about the thing being described. Its not hard to understand -- its just the phone book, online. In the phone book, white pages list residential persons, yellow pages list businesses, and other color pages do other variant listings (such as local government pages). In a yellow page entry you often get advertisement images - properties that are rarely present in white pages listings.

The entry states which object classes are listed. Its the objectClass attribute - a list of objectClass names.  Each object class states in the schema which attributes an instance may or must list. Each attribute is declared to have a type - which may may be complex but is more often just a type of string or an integer.

That's it.  It wasn't hard to understand at all, was it?

An introduction to ldap (where LDAP is just the son of X.500) shows a nice example of what an entry looks like in the database:

In the figure, some of the attribute are part of Person class, others OrganizationalPerson class. These relationship are NOT shown. Each attribute has a type, furthermore. uidnumber is an INTEGER type. mailhost is a domain name type. MailRoutingAddress is an RDF822 address type.O (for Organization) is a string type, limited to some character set in all likelihood.

Some other (unseen) fancy schemas elements called TreeControls also allow an entry listed below a given entry to constrain which objectClasses its immediate subordinate Must or May have. This nicely allows for corporate directories, which seek to list entries by organizational unit or other structure. Users don't know TreeControls exist. While your entry probably needs to have a Person class, an organization does not. Guess what? It has an organizational object class. If you are describing a military Organization, it will be a subclass of Organization with a few military codewords for common attributes thrown in for good luck.

RDFS Nonsense

If we turn now to an excerpt from http://www.ida.liu.se/~janma/SemWeb/Slides/dario.ppt we see a similar set of idea being explained. Unfortunately, it doesn't rely on intuitive notions like the phone book. It heads straight for math.

We see how to constrain that a given attribute is (MUST/MAY) be an element of a particular objectClass. Depending on which way you look at the world, the objectClass is in the domain of the attribute - which is in the range of the class in turn.

Assuming you accept that CandidateFor is an attribute in an object class Constituency, you can even determine its type - which may be complex. In the case above, the attribute is of type Person - a complex type of several attributes we can guess.

Contrasting the schemes

In X.500 1998 we would have said what RDFS says much more simply. The directory lists several constituencies, each of which lists its candidates as attributes in a Constituency objectclass. Name CandidateFor, a given candidate attribute would have an ASN.1 value type "Person" - defined as several fields in all likelihood.

RDFS folks will argue that making Person a value type (vs a class) means its the data blob in the database is not reusable and reference-ible in other listings. So, that's where X.500 1992 came in, giving us inheritable properties. We didn't need a lesson in formal entailment, though. The definition of CandidateFor can inherit the attributes from the Person class for the candidate, that are stored ...guess where? ....in the person's main directory entry.

Summary

Classes are classes. Types are types. Don't mix the two. Whilst X.500 standard did in fact use its ISO 8824 type notation to define the very construct of a class, this was a meta-notation that no designers of real world directories ever needed to see, and few ever did.

Work in Progress.

Topic

In Tying FOAF identity with the identity semantics of OpenID - v2.7 we discussed how the conceptual model of FOAF could augment the notions of identity present in OpenID Auth 2.0. We extend that discussion in this memo by addressing the question: Can we apply SPARQL, FOAF and WOT to assure the asymmetric keys used to strongly authenticate an OP Identity? We propose a solution to several problems that we view as characterizing the current lack of strong authentication in OpenID protocols. We outline a study of how each solution element addresses a need in a Realty application of OpenID, and state why the solution to each problem is a proper security requirement for any realty infrastructure adoption OpenID.

Background Material

[For each core technology, provide a precis of the major components. Bias the presentation towards the elements that we will actually leverage]

OpenID

SemWeb

FOAF

WOT

SPARQL

Introductory Ideas

[State the main problem - OpenID lacks strong authentication. There is insufficient protocol to gauge assurance, in general.]

State subproblem #1:  Staying close to web means use HTML discovery, applying delegation. How do we propose putting an encoded SPARQL query into the delegation field?

State subproblem #2:  FOAF provides a method for reasoning with user-centric trust lists (knows: relations). How do we propose applying knows relations to assure the strong authentication of OpenID consumers to OpenID Providers ?

State subproblem #3: OpenID Consumers and OpenID Providers are mutually suspicious. How do allow one SPARQL query from the user's delegation value to be applied by both the Consumer and the Provider?

State subproblem #4:  FOAF is not a standard part of OpenID Auth 2.0. How do we propose using namespace extensions to indicate the desire for SPARQL processing of FOAF files?

State subproblem #5:  OpenID extensions indicate the claims the Consumer wishes to receive. How do we propose using using SPARQL and FOAF to satisfy the requested claim set and perform claim transformation?

State subproblem #6:  FOAF normally contains public data. How do we apply AX, namespace extensions , SPARQL and additional FOAF classes to enforce access controls for a variety of policies?

Elements of Strong Authentication

[Outline the proposed solution components]

States

Messages

Processing

Impact of Strong Authentication on Realty Infrastructure