De standaard werd ontwikkeld n.a.l.v. Doelgericht Digitaal Transformeren maar heeft altijd de bedoeling gehad om cultuurparticipatie te gaan standaardiseren. Voorstel, nu de standaard is ontwikkeld, om de naam te veranderen van Doelgericht Digitaal Transformeren naar OSLO-Cultuurparticipatie gezien dit beter duidt over welke domeinspecifieke zaken het model uitspraken doet.

Het lijkt me logisch dat bij participanten, uitvoerders, aanbieders en activiteiten minstens één URL geplaatst kan worden, en dat er een type aan die URL kan toegevoegd worden (bv. "meer info" of "trailer" of ...) Dat lijkt nu niet voorzien te zijn?

In UiTdatabank is het mogelijk om in de contactPoint meerdere entries in te voeren voor email, tel, website. Als we die in transformatie naar OSLO-contactInfo moeten reduceren tot 1, is er kans dat we belangrijke info verliezen

Het model lijkt geen ruimte te maken om media mee uit te wisselen, bv. een foto (of een link naar een locatie van een foto). Als dat nog kan, is er ook ruimte nodig om auteursrechtelijke informatie in op te slaan.

Betreft kandidaat vocabularium op https://data.vlaanderen.be/ns/cultuurparticipatie

De toegang tot een cultuuraanbod, om de cultuurparticipatie te realiseren, is vaak afhankelijk van toegangsvoorwaarden.
Het lijkt ons nuttig om hiervoor een anker in het datamodel te voorzien.

Nu is wel 'prijsCategorie' voorzien in het model maar prijs is een attribuut van het generiekere toegangsrecht. Naast prijs zijn er immers andere modaliteiten van toegangsvoorwaarden denkbaar.

Heel concreet bijvoorbeeld is het aanbod van de Luisterpunt bibliotheek gratis voor mensen met een visuele beperking. De leden van luisterpunt krijgen een bij wet bemiddelde toegang die hen vrijstelt van een retributie aan de rechthebbenden van de aangeboden cultuurproducten.

Andere gerelateerde uses cases zijn onderanderen:

• Toegang tot de stedelijke musea voor de inwoners van een gemeente/stad is gratis.
• Toegang tot bepaalde bibliotheekdiensten is leeftijdsafhankelijk. Voorheen was het wettelijk bepaald dat toegang tot 18 jaar gratis moet zijn. Vaak is dat nog bij de concrete gemeentelijke uitbating.
• Toegang tot een tentoonstelling voor leden van een organisatie is gratis.
• Minimumleeftijd voor diensten via sociale media is 13j.
• Toegang via Museumpas.
• Korting voor <25 >65 jaar als dan niet met een tijdsvenster.
• Toegang voor bepaalde categorieën voorbehouden voor bepaalde groepen in bepaalde tijdsvensters (woensdagnamiddag enkel voor kinderen).

Voor een voorbeeld-modellering van toegang langs de concepten van een aanbod, een toegangsaanvraag, een toegangsrecht en een toegangsactiviteit zie: https://luisterpunt.data.gift/application-profiles/loan/

We vermoeden ook dat 1 cultuurproduct niet hoeft gelimiteerd te worden tot 1 manier van 'consumptie', m.a.w. er kunnen verschillende (vaak digitale) manieren zijn waarop men de cultuurparticipatie opneemt. Het lijkt ons daarom nuttig dat het datamodel ook hier voorziet in een anker om de modaliteiten van 'instantiatie', 'consumptie' of 'levering' te bepalen.

Use cases waar we aan denken:

• Het real-time volgen van een opera over een telecomverbinding vanop afstand op een andere locatie dan waar de live uitvoering doorgaat.
• Het lezen van een boek in fysieke vorm, dan wel niet op een e-reader of online.
• Het volgen van een event via een publiek scherm of internet connectie.
• Het opdelen van een cultuurevent in delen op een andere tijdsmoment.
• Het participeren aan een kunstroute al wandelend, dan wel al fietsend; met een gids of zonder.
• Het afspelen van een film op meerdere mogelijke infrastructuren.
• Een installatie van "eenzelfde" installatie in diverse locaties.

Er ontbreekt een samenwerkingstabel tussen uitvoerders, cf. bij Aanbieders. Bv. op het moment van schrijven is er een concert in de Hopper van Vaganée/Gerstmans/Verbruggen. Dat zijn drie aparte uitvoerders die voor deze gelegenheid samenwerken in een trio: https://www.cafehopper.be/

Het is natuurlijk belangrijk dat rollen en types gestructureerd worden ingevoerd, maar het is soms ook belangrijk om daar bovenop nog in vrije tekst een rol of type verder te kunnen beschrijven. Bv. in theater is het soms de gewoonte om "van en met" te schrijven als rol, maar eigenlijk is de rol die wordt opgenomen "acteur". Het is belangrijk dat de standaard ruimte laat hiervoor.

Parallel met de associatietabel Uitvoerder / Activiteit kan ook de relatie tussen een Aanbieder en een Activiteit genuanceerd zijn. Welke rol neemt de Aanbieder op? Op welke plaats wordt de Aanbieder gezet (misschien zelfs voor de Uitvoerder, hoe modelleer je dat?)? Welke rol neemt de Aanbieder op?

Bv. Nuff said als "brand" is vermoedelijk een uitvoerder (want ze maken artistieke keuzes) én een aanbieder (want ze organiseren het concert), maar doen dat bv. in samenwerking met De Warande. (https://nuffsaid.be/) De rol van Nuff Said is dan programmator of samensteller ofzo, de rol van De Warande is de presentatieplek. Concreet wordt in dit geval Nuff Said "groter geafficheerd" dan de namen die geprogrammeerd worden: https://www.warande.be/programma/5828/%27Nuff_Said/_Jade_Mintjens_Shakuar_Julie_Cafmeyer_Lucid_Lucia_Soe_Nsuki_en_Bas_Birker

Er worden nu verschillende namespaces gebruikt voor cidoc, het zou duidelijker zijn om er 1 consistent te gebruiken.
Voorbeeld:

• Activiteit krijgt als URI http://www.cidoc-crm.org/cidoc-crm/E7_Activity
• de eigenschap tijd van activiteit krijgt als URI http://cidoc-crm.org/cidoc-crm/7.1.2/P4_has_time-span

Consistent zou zijn voor beide de URI met versie of zonder versie te gebruiken

https://data.vlaanderen.be/ns/cultuurparticipatie/#Activiteit.label = Te gebruiken om zaken die niet met andere codelijsten, datatypes, etc. worden ingevuld aan te vullen.

https://data.vlaanderen.be/ns/cultuurparticipatie/#Activiteit.labeltype = enum (publiek of verborgen)

Kardinaliteit van een label op een Activiteit = 0..*
Kardinaliteit van een labelType op een Activiteit = 0..*

Hoe kan je aangeven of een specifiek label verborgen is?

Logischer zou zijn dat labelType een eigenschap is op een Label?

Het is op basis van het applicatieprofiel niet duidelijk hoe de doelgroep van een activiteit wordt uitgedrukt:

• als er geen specifieke doelgroep is, wordt er dan geen doelgroep op gegeven?
• stel de minimum leeftijd is 18j hoe wordt dit dan uitgedrukt? Is het volgende voorbeeld correct?

{
     "@context": {
        "cultuurparticipatie": "https://data.vlaanderen.be/ns/cultuurparticipatie#",
        "schema": "http://schema.org/",
        "cidoc": "http://www.cidoc-crm.org/cidoc-crm/",
        "Activiteit": "cidoc:E7_Activity",
        "ParticipantProfiel": "cultuurparticipatie:ParticipantProfiel",
        "doelgroep": "https://data.vlaanderen.be/ns/cultuurparticipatie#Activiteit.doelgroep",
        "sociodemografisch": "https://data.vlaanderen.be/ns/cultuurparticipatie#ParticipantProfiel.sociodemografisch",
        "leeftijdsGroep": "schema:typicalAgeRange"
    },
    "@type": "Activiteit",
    "doelgroep": {
        "@type": "ParticipantProfiel",
        "sociodemografisch": {
          "leeftijdsGroep": "18-"
        }
    }
}

Gaat dit niet leiden tot het aanmaken van heel veel ad hoc participantprofielen?

Het is nogal reducerend om participanten louter te zien als consumenten van een activiteit. In de participatieve kunsten nemen "participanten" specifiek een rol op. Vermoedelijk is dit ook zo bij sociaal-cultureel volwassenenwerk, erfgoed, ... Welke rol neemt de participant op? Is dat die van een workshopgever (of is dat dan een uitvoerder?), actieve deelhebber, passieve deelname, ....

Bovendien is een voorbeeld van een culturele activiteiten ook een kunstenaar die een residentie doet, bv. https://morphovzw.be/residenties/development-residency-2021 Zijn die kunstenaars dan participanten van het aanbod van de residentieplek? Moeten dan de participanten niet veel uitgebreider beschreven kunnen worden?

Er zijn een hele hoop URIs in het AP incorrect of onvolledig. Ik lijst ze hier op voor correctie door de editors:

fixme urls voor

• De klasse Infrastructuur
• relatie infrastructuur op Activiteit
• relatie infrastructuur op Aanbieder
• relatie activiteit op de klasse Deelname
• relatie participant op klasse Deelname
• relatie identificator op klasse Ding
• attribuut beschikbaar op klasse Document
• de klasse FeedbackBron
• de klasse Nationaliteit
• het attribuut status op Organisatie (heeft ook geen label in het AP)
• relatie aanbieder(source) op klasse Samenwerking
• relatie aanbieder(target) op klasse Samenwerking
• relatie activiteit op klasse Uitvoering
• relatie uitvoerder op klasse Uitvoering

CIDOC base is niet correct:

• https://cidoc-crm.org/html/cidoc_crm_v7.1.1.html#E7 dit zou http://cidoc-crm.org/cidoc-crm/7.1.1/E7_Activity (of eventueel http://cidoc-crm.org/cidoc-crm/E7_Activity ) moeten zijn

Bij Uitvoerder lijkt te ontbreken:

• identificator
• infrastructuur, bv. Rosas is een uitvoerder (dansgezelschap) en heeft een eigen infrastructuur in Vorst
• organisatievorm
• type

Bij Aanbieder lijkt dan te ontbreken:

• vermeldAls
• rol

Het lijkt me wenselijk om Aanbieder == Uitvoerder te houden aangezien de personen, collectieven of organisaties die een aanbiedende of uitvoerende rol opnemen zich niet laten vastzetten. Zo kan een programmator nu eens optreden als uitvoerder (bv. samensteller van concertprogramma, en neemt zo een artistieke rol op), dan wel ook zelf de concertorganisatie en -promotie opnemen (en is dan de aanbieder, vermoedelijk in samenwerking met een concertzaal).

Er is zelfs een argument te maken om ook Participanten helemaal gelijk te modelleren met Aanbieders en Uitvoerders, omdat bv. in participatieve kunsten die rollen ook makkelijk kunnen wijzigen.

Een participant kan deel uitmaken van een groep. Tickets kunnen op groepsniveau aangekocht worden door een vertegenwoordiger van de groep zonder dat verder iets gekend is over de eigenlijke participanten. Het model voorziet deze mogelijkheid niet.

Zie https://test.data.vlaanderen.be/doc/applicatieprofiel/doelgericht-digitaal-transformeren/ontwerpstandaard/2021-10-01/#Activiteit%3Alocatie

Deze suggereert https://www.w3.org/TR/2013/NOTE-prov-xml-20130430/#element-Location , maar dit is geen rdf:Property!
Dit is een beschrijvende nota. Ik vermoed dat de bedoeling is om http://www.w3.org/ns/prov#atLocation te gebruiken (beschreven op https://www.w3.org/TR/prov-o/#atLocation).
Kan dit nog gecorrigeerd worden?

Een AlgemeenParticpantKenmerk heeft een "Participanttype" als range voor het attribuut type. Maar deze klasse werd niet gedefinieerd.

Het gepubliceerde applicatieprofiel bevat nog een aantal fouten/todo's.

Hier staan nog een TODO's:

    "Activiteit.verhoudtZichTot": {
      "@container": "@set",
      "@id": "TODO",
      "@type": "@id"
    },

    "ParticipantProfiel.bepaaltBeperking": {
      "@container": "@set",
      "@id": "TODO",
      "@type": "@id"
    },

"Acitviteit" moet zijn https://data.vlaanderen.be/ns/cultuurparticipatie/#Activiteit.boeking

    "Activiteit.boeking": {
      "@container": "@set",
      "@id": "https://data.vlaanderen.be/ns/cultuurparticipatie#Acitviteit.boeking",
      "@type": "@id"
    },

cf. https://data.vlaanderen.be/doc/applicatieprofiel/cultuurparticipatie/erkendestandaard/2023-10-01/context/DoelgerichtDigitaalTransformeren-ap.jsonld

De waardelijsten lijken me nog niet in orde. Ik bekijk die wat te linken zijn aan het aanbod:

• activiteittype: verwart nog steeds een "supercategorie" (bv. kijkenEnLuisteren) met een "subcategorie" (bv. concert, dansvoorstelling)
• thematype: dit verwart genres (jazz) en onderwerpen (feminisme) >>> moeten er genres benoemd worden in een waardenlijst?
• disciplinetypes: dit verwart disciplines (fotografie), sectoren (erfgoed) en aanbieders (archieven)
• activiteitfunctietype: geen idee wat er hier mee bedoeld wordt, ik zie geen lijn in de opsomming?
• objecttype: stream (van muziek? van video?) en podcast zijn digitaal, boek is fysiek, film is via een scherm, muziek is een discipline, ...
• aanbiedertype: programmatoren en curatoren doen een artistieke keuze, zijn ze daarom niet eerder uitvoerders? het lijkt me hier logischer om concertzalen, concertorganisatoren, promotiegaleries, tentoonstellingsruimtes, kunstbeurzen, cultuurcentra, theaters, ... op te sommen?
• samenwerkingtype: er ontbreken zaken, bv. "representatie"
• uitvoerderroltype: ook hier ontbreekt weer vanalles, acteurs, regiseur, scenografie, kostuumontwerp, pyro, bassist, curator, ...
• locatietype: is dit niet dan net het medium?

Volgens mij ontbreken nog deze waardelijsten:

• genres
• aanbiederroltype
• uitvoerdertype

En zoals elders gezegd: deze gestructureerde waardes moeten ook altijd gepaard kunnen gaan met vrije tekst.

Twee activiteiten kunnen nu met mekaar gelinkt worden via een sub/super relatie, maar er is geen typering mogelijk. Hoe geef je aan dat in een reeks van voorstellingen een bepaalde voorstelling gezien wordt als de première die geldt voor de taxshelter, en de andere voorstelling ervoor als try-out?

Nochtans is het belangrijk om aan te kunnen geven hoe zo een cultureel erfgoed ding wordt gebruikt. Is het louter een inspiratie, wordt er een fragment van gebruikt, is het een herwerking, ...

dead link Applicatieprofiel Cultuurparticipatie

Heel wat aanbieders en uitvoerders hebben (structurele) samenwerkingen, die nu niet gemodelleerd kunnen worden. Je zou kunnen zeggen dat De Vooruit een "aanbieder" is en de nieuwe organisatie VierNulVier de uitvoerder is (want ze maken een artistiek programma). Idem voor de Kopergietery in de Kazematten, of LOD op de Bijlokesite.

Het model houdt geen rekening met het rapport "ESSnet-CULTURE European Statistical System Network on Culture". Als gevolg hiervan zal data die volgens dit model uitgewisseld wordt, niet kunnen worden ingezet om i.f.v. Europese rapportering.

Op dit moment wordt "https://www.w3.org/2001/XMLSchema#dateTime" gebruikt voor de eigenschap "tijd" op Activiteit, maar dit is een rdfs:Datatype en geen rdfs:Property.

Voorstel: https://data.vlaanderen.be/ns/cultuurparticipatie#Activiteit.tijd gebruiken ?

https://data.vlaanderen.be/ns/cultuurparticipatie/#Beschikbaarheid geeft niet veel inzicht over wat er hieronder gecapteerd kan worden.

We kijken naar vocabularium van https://data.vlaanderen.be/ns/mobiliteit/trips-en-aanbod/#Beschikbaarheid en gebruiken eigenschap https://schema.org/hoursAvailable om openingsuren weg te schrijven

Daarnaast kijken we naar schema.org/availability om enumeraties van schema.org/ItemAvailability (InStock, LimitedAvailability, OutOfStock) te gebruiken, om aan te geven of er voor de Activiteit in kwestie nog tickets beschikbaar zijn.

Er is een veld Locatie bij Activiteit, maar het is onduidelijk wat er hier mee bedoeld wordt? Het zou goed zijn als een activiteit een eigen gemeente/land kan krijgen, omdat soms uitvoerder en aanbieders niet indicatief genoeg zijn voor de plek waar iets plaatsvindt.

De klasse prijsinfo staat momenteel totaal los van de transactie die hieruit volgt wat onlogisch lijkt.

Intro

Issue A
Link

@jitsedc

import x
execute y

Het wordt in de kunstensector duidelijker dat sommige kunstactiviteiten gepaard moeten gaan met triggerwarnings (bv. stroboscopisch licht, heftige beelden, taal, ...) Er is geen ruimte in het model om zulke triggers te modelleren?

Deelname veronderstelt ook een tijdstip, gedefinieerd in Periode (wat ik niet terugvond). Echter is een activiteit zoals we dit binnen het sociaal-cultureel werk kennen niet steeds te koppelen aan een vast tijdstip: die dag van dat uur tot dat uur. Het kan ook om deelname aan een actie gaan, die over een langere periode loopt. Behoort dit dan ook tot de mogelijkheden?

DeelnameType: zie issue #6.

Interpreteer ik het juist dat, wanneer iemand deelneemt aan een activiteit zonder kostprijs (bijvoorbeeld een ledenactiviteit van een vereniging), deze volgens het huidige schema ook de stappen van Transactie naar Ticket moet doorlopen om daar bij Tickettype het type ‘registratie’ te kiezen? Dit lijkt me in het huidige schema de enige mogelijke weg, tenzij deelname zonder Transactie en Ticket ook mogelijk is.

Heeft de flow van Participant > Deelname > Transactie > Ticket trouwens een dwingend karakter? Stel dat ik met mijn gezin of met vrienden naar een voorstelling wil en daar 4 of 8 tickets voor boek. Moeten deze dan allemaal op naam geregistreerd worden om het systeem sluitend te houden?

Fysieke activiteit

• Activiteit.locatie (Locatie)
• Activiteit.locatieType "fysiek"

Online activiteit

• Activiteit.locatie (VirtualLocation)
• Activiteit.locatieType "online"

Hybride activiteit

• Activiteit.locatie (Locatie & VirtualLocation)
• Activiteit.locatieType "hybride"

Voorbeeld schema.org:

    {
      "@context": "https://schema.org",
      "@type": "Event",
      "name": "The Adventures of Kira and Morrison",
      "startDate": "2025-07-21T19:00-05:00",
      "endDate": "2025-07-21T23:00-05:00",
      "eventAttendanceMode": "https://schema.org/MixedEventAttendanceMode",
      "eventStatus": "https://schema.org/EventScheduled",
      "location": [{
        "@type": "VirtualLocation",
        "url": "https://operaonline.stream5.com/"
      },
      {
        "@type": "Place",
        "name": "Snickerpark Stadium",
        "address": {
          "@type": "PostalAddress",
          "streetAddress": "100 West Snickerpark Dr",
          "addressLocality": "Snickertown",
          "postalCode": "19019",
          "addressRegion": "PA",
          "addressCountry": "US"
        }
      }],
      "image": [
        "https://example.com/photos/1x1/photo.jpg",
        "https://example.com/photos/4x3/photo.jpg",
        "https://example.com/photos/16x9/photo.jpg"
       ],
      "description": "The Adventures of Kira and Morrison is coming to Snickertown in a can’t miss performance.",
      "offers": {
        "@type": "Offer",
        "url": "https://www.example.com/event_offer/12345_201803180430",
        "price": "30",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "validFrom": "2024-05-21T12:00"
      },
      "performer": {
        "@type": "PerformingGroup",
        "name": "Kira and Morrison"
      },
      "organizer": {
        "@type": "Organization",
        "name": "Kira and Morrison Music",
        "url": "https://kiraandmorrisonmusic.com"
      }
    }
    </script>```

Op zich beschikken we denken we nog niet over zoveel informatie hoe kalenderinformatie in Oslo wordt bewaard, maar we maken ons wel een beetje zorgen over de compabiliteit tussen de twee verschillende formaten.

Wat we weten uit Oslo?

• een activiteit kan een sub- of superactiviteit hebben
• een activiteit heeft een property tijd TM_object

Waar zien we wel enkele issues?

In UiTdatabank kan een event vier verschillende calendarTypes hebben:

• single
• multiple
• periodic
• permanent

Maar een place (Locatie in Oslo) kan er ook twee hebben:

• periodic
• permanent

Hier wat meer info over deze 4 verschillende types.

single
Has startDate, endDate and 1 subEvent. The startDate and endDate of the subEvent is the same as the one of the top event.
Both the top event and the subEvent have a status and and a bookingAvailability
Applicable on: events
Example https://io.uitdatabank.be/event/16045ef7-5370-4059-872d-a1c21094d2c4

calendarType: "single",
startDate: "2022-03-22T19:30:00+01:00",
endDate: "2022-03-22T22:00:00+01:00",
status: {
type: "Available"
},
bookingAvailability: {
type: "Available"
},
subEvent: [
{
id: 0,
status: {
type: "Available"
},
bookingAvailability: {
type: "Available"
},
startDate: "2022-03-22T19:30:00+01:00",
endDate: "2022-03-22T22:00:00+01:00",
@type: "Event"
}
],

multiple
Has startDate, endDate and 2 ore more subEvents.
Both the top event and the subEvents have a status and and a bookingAvailability. The status and bookingAvailability on top event level is derived from the statuses on subEvent level
Applicable on: events
Example https://io.uitdatabank.be/event/7e5739fb-c3ac-4b36-84e9-d6b9cbdf3f9e

calendarType: "multiple",
startDate: "2022-04-21T10:00:00+02:00",
endDate: "2022-04-28T12:30:00+02:00",
status: {
type: "Available"
},
bookingAvailability: {
type: "Available"
},
subEvent: [
{
id: 0,
status: {
type: "Available"
},
bookingAvailability: {
type: "Available"
},
startDate: "2022-04-21T10:00:00+02:00",
endDate: "2022-04-21T12:30:00+02:00",
@type: "Event"
},
{
id: 1,
status: {
type: "Available"
},
bookingAvailability: {
type: "Available"
},
startDate: "2022-04-28T10:00:00+02:00",
endDate: "2022-04-28T12:30:00+02:00",
@type: "Event"
}
],

periodic
Has a startDate, endDate and sometimes openingHours
The event has a status and a bookingAvailability. The bookingAvailability is always “Available” (atm)
Applicable on: events, places
Example https://io.uitdatabank.be/event/eab93223-0cbe-497f-b037-da3f46571592

calendarType: "periodic",
startDate: "2022-07-11T00:00:00+02:00",
endDate: "2022-07-15T00:00:00+02:00",
status: {
type: "Available"
},
bookingAvailability: {
type: "Available"
},
openingHours: [
{
opens: "09:00",
closes: "16:00",
dayOfWeek: [
"monday",
"tuesday",
"wednesday",
"thursday",
"friday"
]
}
],

permanent
Has no startDate or endDa but can contain openingHours
The event has a status and a bookingAvailability. The bookingAvailability is always “Available” (atm)
Applicable on: events, places
Example https://io.uitdatabank.be/event/725BAB6A-AAC5-10AC-42348AE4E9FDBC8C

calendarType: "permanent",
openingHours: [
{
opens: "12:00",
closes: "19:00",
dayOfWeek: [
"monday"
]
},
{
opens: "08:00",
closes: "12:00",
dayOfWeek: [
"tuesday",
"wednesday",
"thursday",
"friday",
"saturday",
"sunday"
]
}
]

We zien vooral momenteel nog niet hoe periodic en permanent events in het Oslo-datamodel zullen worden gerepresenteerd. Een lijst van allemaal apart events (via sub- of super) kan wel eens heel complex worden (en niet mogelijk voor permanent). Ook bij multiple gaat het veel moeilijker zijn voor integratoren als de subevents in aparte events zitten (tov. zoals in de UiTdatabank waar het een property is).

Hoewel er verwezen wordt naar het datatype, wordt dit datatype niet beschreven in het applicatieprofiel:
https://data.vlaanderen.be/doc/applicatieprofiel/doelgericht-digitaal-transformeren#Beschikbaarheid

De huidige uitsplitsing van de klassen uitvoerder en aanbieder is totaal onzinnig. Correcte modellering zou iets moeten zijn in de richting van “1 of meerdere OSLO-agenten zijn verbonden met de activiteit en nemen hierin een bepaalde rol op”;

Meerdere klassen en attributen hebben ongelukkige benamingen (bv. ticket i.p.v. het generiekere toegangsbewijs);
Meerdere attributen staan misplaatst binnen bepaalde klassen (bv. themaActiviteit bij klassen uitvoerder en aanbieder);
Meerdere attributen zijn momenteel duidelijk niet goed gedefinieerd, met onduidelijke of soms foutieve of dubbelzinnige codelijsten waardoor het onmogelijk is te controleren of het model eigenlijk wel goed zit (bv. Aabiedertype)