OSLO:Rol is minder ruim dan CPSVAP:Participation.

[GeertThijs]

CPSVAP wil meer kunnen zeggen over Agents die een bepaalde rol spelen bij een PublicService. Ze wil:

• andere rollen dan User, Provider
• rollen kunnen groeperen bv per contract
• extra info over dat contract (of welke participatie dan ook)

Wat dat laatste berteft geven de specs het voorbeeld van begin- en einddatum vh contract. Echter worden deze properties verder niet voorzien ih profiel. Wat doen we hiermee: Participation als element toevoegen?

[DieterDePaepe]

CPSV-AP:Participation heeft meerdere issues volgens mij.

Allereerst staat er geen term gedocumenteerd die gebruikt kan worden. Een query op LOV levert ook niets op.

Ten tweede introduceren ze hiermee een volledig dubbele manier om rollen vast te leggen:

• Via Participation, waar een code lijst dan de rol moet aanduiden.
• Via het subklassen van CPSV:hasRole relatie.

(1) heeft als voordeel dat er nog statements kunnen gemaakt worden over de Participation, zoals bijvoorbeeld de duur ervan. (2) laat toe dat nieuw aangemaakt subklassen van de relatie kunnen herbruikt worden en dat reasoning makkelijker gaat omdat men de codelijst niet moet kennen.

Ik ben van mening dat we voor 1 aanpak moeten gaan, niet beide.

[GeertThijs]

Eigenlijk is dit een modelleringsissue?

Voor- en nadelen van subklassen (werkwoord, ttz entiteiten, associaties & properties specialiseren, hoewel gaat dit wel bij properties?) zijn volgens mij:

Voordelen:

• Subklassen verhoogt de leesbaarheid, ook voor reasoners.

Nadelen:

• Het concept dat de subklassen bundelt (Rol in het voorbeeld) gaat verloren.
• Codelijsten kan je in principe uitbreiden zonder het model zelf te wijzigen, subklassen toevoegen betekent echter het model wijzigen (of is in elk geval meer zichtbaar).

[GeertThijs]

In principe moet je pas subklassen als de verschillende subklassen andere kenmerken hebben. Bv ih geval van AdministrativeUnits is het wellicht niet nodig, een Gemeente is wel een ander administratief niveau dan een Gewest, maar het blijft een administratieve eenheid. Terwijl een Persoon toch iets helemaal anders is met andere kenmerken dan een Organisatie (beide subklassen van Agent). Hoewel ook hier weer alles afhangt vh domein waarin je je bevindt. In een generiek domein zoals OSLO is een enumeratie wellicht voldoende voor AdministratieveEenheden, in een domein Overheid of zoiets wil je er wellicht wel subklassen van maken. Alvast 1 ding lijkt mij wel duidelijk: beide methoden mengen voor eenzelfde gegeven (zoals bij Rol) in hetzelfde domein is geen goed idee.

[GeertThijs]

Ook bij Agent duiken beide methodes op. ORG werkt met subklassen voor Agent, maar CPSV-AP vindt het blijkbaar nodig om het type Agent ook nog eens met een enumeratie aan te duiden. Zie ook #9.

[DieterDePaepe]

Dit issue wordt overnomen in de publieke discussie groep, samen met #17.