6.4.6.1 - beoordelen voorstel voor uitwerking primitieve datatypen + vervolgactie

[dkrijtenburg-GNM]

nav opmerknig gerald groot roessink

vervolgactie bepalen

• nogo
• in 1.2
• in 2.0

par 6,4,6,1 Primitieve datatypen: De transformatie van user defined datatypes is simpel: het wordt een rdfs:Datatype. Maar het is niet beschreven hoe dat moet gebeuren. Voor de hand ligt OWL:

cdm:Postcode a  rdfs:Datatype;
             owl:onDatatype  xsd:string;
             owl:withRestrictions ( [xsd:maxLength 6] [xsd:minLength 6] ).

Dit is vergelijkbaar met het definiëren van datatypes in XSD en dan kun je in theorie dit gegevenstype opnemen bij de propertyshape:

schema:AddressShape
    a sh:NodeShape ;
    sh:property [
        sh:path schema:Postalcode;
        sh:datatype  cdm:Postcode;
    ] .

Helaas, dit lijkt technisch niet mogelijk.

Wat dat mij wel lukt is dit:

schema:AddressShape
    a sh:NodeShape ;
    sh:property [
        sh:path schema:Postalcode;
        sh:datatype  xsd:string;
        sh:maxLength 6;
        sh:minLength 6;
    ] .

Maar ja, er zijn meerdere properties die postcode als datatype hebben. Sterker nog, postcode is een modeloverstijgend zelfs landelijk datatype. Dat zie ik graag ook in het model uitgedrukt.

Het lijkt erop dat MIM hier een doodlopend weg in slaat. Of is er een andere manier om user defined rdfs:Datatype te definiëren die ik niet heb kunnen vinden?

[architolk]

Gerald stipt hier een probleem aan dat feitelijk niet is op te lossen in de huidige betekenis van primitieve datatypes en wat de betekenis daarvan in MIM is versus LD. Zie ook: https://stackoverflow.com/questions/66859624/how-are-owl-defined-datatypes-intended-to-be-used. In MIM lijkt een eigen primitief datatype een soort van "shortcut" te zijn om beperkingen op attribuutwaarden in een "eigen" datatype te stoppen, waarbij het datatype een verbijzondering is van het originele datatype. Echter, in LD werkt dat niet (met OWL) omdat eigen datatypes niet meer worden gezien als literals, maar als classes (dwz: het zijn geen syntactische dingen meer, maar ontologische). Dit is een beetje ingewikkeld en fundamenteel, maar daardoor ook een feitelijk probleem... De beste oplossing voor nu is denk ik om de transformatie te doen met subclassificatie (rdfs:subClassOf). Een aanvulling zou zijn om de bewerkingsregels die op het eigen datatype zijn geformuleerd te kopiëren naar elke PropertyShape waar dit datatype wordt gebruikt, en dan als sh:datatype het "originele" datatype te (blijven) gebruiken. Dat werkt alles zoals bedoeld, zonder veel problemen. Overigens: in LD is het veel gebruikelijker om subproporties te introduceren voor dergelijke gevallen, waarbij UML dit niet kan, en (dus?) met eigen datatypen moet werken?

[JanCampschroer]

Feitelijk komen we hier aan het wezenlijke deel van de relatie tussen 'de dingen in het model/ de gegevens' enerzijds en 'de dingen waar naar verwezen wordt'. Of, in IT-jargon, respectievelijk de lexical-space en de value-space. Laat ik beginnen met op te merken dat 'datatypes' (https://www.w3.org/TR/xmlschema11-2/#datatype) zoals bedoeld door w3c al -in mijn ogen - semantisch niet zuiver zijn. Bij bijvoorbeeld het datatype string zijn valuespace en lexicalspace gelijk, de string verwijst naar zichzelf, en dat geldt dan ook voor html e.d.. Bij bijvoorbeeld datatype date heb ik verschillende strings die naar één dag kunnen verwijzen; en dat geldt dan ook voor integers en booleans. Dat ze allemaal op een hoop geveegd worden heeft, denk ik, historisch gegroeide implementatie-achtergronden. Goed, daar moeten we mee leren leven.

Neemt niet weg dat er behalve booleans, dagen en getallen ook wel andere klassen zijn die breed gebruikt worden binnen de overheid en waarvan we de manier waarop we ze aanduiden zouden moeten standaardiseren. Bij de Politie komen die voor in de verzamelingen met 'referentielijsten'. Denk dan aan landen, nationaliteiten, provincies, gemeenten, woonplaatsen, postcodegebieden, valuta (Euro, Dollar, ...) , meetdimensies (lengte, gewicht, oppervlakte, ..), meeteenheden (meter, kg, are, ...) , Met URI's creeer je hier een (technische) lexical space voor. De value space ligt buiten het IT systeem. Elke coderingsstelsel voor zo'n klasse (een heel kleine grammatica, waarvan soms enkel de terminals gedefinieerd worden door een autoriteit) is in feite een andere lexical space. Als je verschillende URI's hebt voor hetzelfde ding (buiten het IT-systeem) dan kun je die via owl:sameAs aan elkaar knopen. Voor elk coderingsstelsel zou je een property (subproperty van skos:notation ?) op kunnen nemen met daarbij in de definitie de autoriteit die hem definieert. Als we dat op één plek kunnen samenbrengen binnen de overheid, dan zouden we al weer een stukje interoperabiliteit hebben gewonnen.

[JanCampschroer]

En voor de postcode moet je dus niet het adres voorzien van een postcode (een speciaal datatype), maar koppelen aan een postcodegebied en dat gebied heeft dan een code (vastgesteld door PostNL) die de vorm 9999AA heeft.

[JanCampschroer]

Nog een nabrander: Elke code voor een postcodegebied heeft de vorm 9999AA maar niet elke string van de vorm 9999AA is een postcode. Je kunt dus ook geen (statisch) datatype definiëren want de set van codes die een postcode zijn, wijzigt en is niet geautomatiseerd afleidbaar.

(ik realiseer me dat postcodegebieden door de Post vroeger afgebakend zijn als 'loopgebied': het waren de kleinste stukjes die werden toebedeeld aan een Wijk die door één postbode op één dag gedaan werd. )

[pmaria]

In SHACL kun je ook node shapes gebruiken voor literal nodes.

Dus we kunnen ook genereren:

schema:PostalcodeShape a sh:NodeShape ;
  sh:datatype xsd:string ;
  sh:maxLength 6;
  sh:minLength 6;
.

Dit kun je dan kan gebruiken als

schema:AddressShape
    a sh:NodeShape ;
    sh:property [
        sh:path schema:Postalcode;
        sh:node schema:PostalcodeShape ;
    ] .

Dit past mijns inziens het beste op hoe MIM datatypes behandelt.

[architolk]

Aanpassingen zijn doorgevoerd: de beschrijving is aangepast zodat nu sprake is van een sh:Node ipv een rdfs:Datatype