[WG-OTTO] Schema Classes -- Following on last meeting's conversation

Bush,Judith bushj at oclc.org
Wed Feb 22 09:32:05 CST 2017


Following on the previous meeting’s discussion about the schema, we reflected that we needed to agree on some of the relationships between the different classes. I sent a message with a diagram of high level classes on that day. I looked over our previous notes and saw elements I had not included.  I also spent some time reflecting on how the metadata can be included in the entity. I’m attaching those diagrams.

The high level diagram is missing the link between the RA and the entities: I don’t see the *need* for SAML entities to identify themselves in the name space of the RA, but we have discussed how OpenID Connect RPs need the registration so that they have a shared identity within the federation.

judith

[cid:image001.png at 01D28CF6.E87D3990]


[cid:image002.png at 01D28CF6.E87D3990]



From: "Bush,Judith" <bushj at oclc.org>
Date: Thursday, February 9, 2017 at 10:46 AM
To: OTTO Working group <wg-otto at kantarainitiative.org>
Subject: Schema Classes -- Following on yesterday's conversation

The depicted is a class diagram of the schema.org classes and OTTO extensions.

There are a number of ways we can divide this and I don’t think we settled.

Here’s a straw man proposal.


1.      define Federation (operator) & Participant (better name welcome) classes as extensions of the Organization.schema.org class. Participant.otto.org is the legal organization, one that may agree to a federation operator’s terms. A participant may be a member of many federations; a federation may have many participants.

2.      Define Entity class as an extension of the Thing.schema.org class. Extend the Entity with the specific metadata needed for each type of entity we may need to describe. Participants offer many Entities; each Entity is offered by only one Participant. Federations include many Entities; each Entity may be included in many Federations.

The schema will have as attributes of each class terms that show the relationships: Participants “offersService” which are entities; Entities are “offeredBy” Participants. Federations “federatesService” which are entitites; Entities are “federatedWith” Federations.

NOTE: this is not yet stating what is required in federation metadata. No particular property is required in the Organization.schema.org class. To be determined is whether we require that the federation MUST list all entities (by reference?) but MAY list all participants, whether we require that entity metatdata MUST list the participant or MAY. Etc.

The first step, I believe, is determining whether  this is sufficient or if we need classes for the registry operator (which registers participants, federations, and entities?). I assume we don’t need another *class* for interfederation, but maybe we do? To represent the legal agreements of interfederation groups?
judith




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-otto/attachments/20170222/588924ed/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 72402 bytes
Desc: image001.png
URL: <http://kantarainitiative.org/pipermail/wg-otto/attachments/20170222/588924ed/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 66289 bytes
Desc: image002.png
URL: <http://kantarainitiative.org/pipermail/wg-otto/attachments/20170222/588924ed/attachment-0003.png>


More information about the WG-OTTO mailing list