EDTF ondersteuning bij Periode of tvv Periode

[mielvds]

Opgeworpen tijdens de laatste werkgroep: zonder ondersteuning van onzekere datums heeft het AP (althans bij meemoo) weinig kans op slagen. EDTF toelaten in plaats van Periode (periodes worden ondersteund in EDTF of ISO8601-19-1) of als datatype begin/einde van Periode zou dit verhelpen.

Ik dacht dat dit ging aangepast worden voor de publieke review, maar ik zie het niet staan, dus bij deze werp ik het nog eens op.

[koenedaele]

Volledig akkoord. EDTF lijkt me de weg vooruit voor héél veel dateringsproblemen bij erfgoeddata.

In inventaris.onroerenderfgoed.be hebben we het voorbije decennium vooral gewerkt met toewijzingen aan periodes gedefinieerd als skos:concept zoals https://thesaurus.onroerenderfgoed.be/conceptschemes/DATERINGEN/c/1209?view_tree Merk op dat je die niet altijd kunt modelleren als Periode aangezien het Neolithicum bv. te dateren valt als "ca. 5250 v.Chr. (tot 2000 v.Chr.)". De knullige oplossing in het verleden in databanken is al vaak geweest dit te coderen als 01/01/-5250, maar dit geeft een vals gevoel van nauwkeurigheid en negeert het feit dat het "circa 5250" is (want iets als het neolithicum is niet op 1 welbepaalde dag gestart). Daarnaast hebben veel DateTime implementaties ook nog eens problemen met datums ver in het verleden.

Voor meer duiding waarom exacte data onwerkbaar zijn voor erfgoed, zie bv. de inleiding van https://lib.ugent.be/fulltxt/RUG01/001/418/820/RUG01-001418820_2010_0001_AC.pdf

[dimi-schepers]

URI van EDTF: http://id.loc.gov/datatypes/edtf/EDTF
Spec: https://www.loc.gov/standards/datetime/

[mielvds]

Ik wil er nog een kleine nuance voor het model bijgooien:

EDTF bestaat uit levels en gezien niet elke software leverancier alle levels wil/kan implementeren,
is het aan te raden om - naast het datatype http://id.loc.gov/datatypes/edtf/EDTF - ook

http://id.loc.gov/datatypes/edtf/EDTF-level0
http://id.loc.gov/datatypes/edtf/EDTF-level1
http://id.loc.gov/datatypes/edtf/EDTF-level2

te gebruiken. Deze zijn allemaal subClassOf http://id.loc.gov/datatypes/edtf/EDTF, dus in principe is het niet in strijd met het model, maar misschien is het nuttig voor de volledigheid.

[dimi-schepers]

Vraag voor de werkgroep: hoe wordt EDTF vandaag geïmplementeerd in RDF? Als een literal? Bijvoorbeeld:

ex:MonaLisa a oslo:MensgemaaktObject ;
        oslo:creatie ex:CreatieMonoLisa .

ex:CreatieMonoLisa a oslo:Creatie ;
       oslo:tijd "1503/1506"^^<http://id.loc.gov/datatypes/edtf/EDTF> .

Zie ook: linked-art/linked.art#218

[GeertThijs]

Ideaal zou zijn dat we ook de klassieke periode (twee vastgelegde datetimes) kunnen beschrijven door een literal van type EDTF. TODO: onderzoeken. Anders gaan we een superklasse moeten introduceren voor beide gevallen en deze als datatype gebruiken voor dit attribuut. OF een generieke klasse waarbij in de gebruiksnota staat wat de opties zijn.

[GeertThijs]

Als volgt opgelost:

• Datatype Periode uit OSLO-Generiek vervangen door Periode eigen aan OSLO-CultureelErfgoed
  

• Gemodelleerd als literal vh type EDTF & equivalent met CIDOC E52 Time-Span:
  
  

[GeertThijs]

Wel nog vermelden dat EDTF intussen opgenomen zou zijn in ISO 8601 versie van 2019 (zie https://www.iso.org/standard/70907.html). Verwachting is dat de notatie niet afwijkt van deze in EDTF, maar we zouden dit moeten nagaan in de specificatie zelf. Verder betekent dit dat er mogelijk een alternatieve uri voor het EDTF-datatype bestaat.

[mielvds]

Hoe zou dit er dan concreet uitzien? Is dit een correct voorbeeld (in turtle):

@prefix cidoc: <http://www.cidoc-crm.org/cidoc-crm/> .

ex:MonaLisa a cidoc:E28_Conceptual_Object ;
        cidoc:P94_has_created ex:CreatieMonoLisa .

ex:CreatieMonoLisa a cidoc:E65_Creation ;
       cidoc:P4_has_time-span "1503/1506"^^<http://id.loc.gov/datatypes/edtf/EDTF> .

EDTF is inderdaad (deels) opgenomen in de ISO8601-19 standaard, maar enkel als extensie ISO 8601-2:2019. Ik zou het toch bij EDTF houden, want de ISO standaard is betalend en duur, dus niemand kan eenvoudig achterhalen hoe dit correct te implementeren (vandaar dat xsd:dateTime populairder is). Ik vrees ook voor veel verwarring tussen ISO8601 en ISO8601-19 bij implementatie, met redelijk wat compatibiliteitsproblemen tot gevolg. Eventueel kan http://id.loc.gov/datatypes/edtf/EDTF wel equivalent zijn met de datatype URI van ISO 8601-2:2019, als die bestaat.

Ik vraag mij nog af wat er in OSLO algemeen als dataType beschouwd wordt? Gezien ze attributen hebben, wat is dan het onderscheid met een klasse en hoe verhouden ze zich dan tot het datatype voor literals van RDF?

[dimi-schepers]

Jouw voorbeeld lijkt inderdaad te kloppen (moet wel P94i zijn denk ik, maar dat is naast de kwestie).

En ja, als iedereen akkoord gaat met EDTF is dat zeker ok voor ons. We hadden alleen graag geverifieerd hoe ISO EDTF heeft opgenomen voor de zekerheid (en eventueel om de URI over te nemen), maar ook wij zijn tegen die vervelende paywall gestoten.

Wat complexe OSLO datatypes (i.e. met attributen) betreft, deze worden evenzeer als owl:Class beschouwd. Ik denk dat het voornaamste verschil is dat we, door ze als datatypes te classificeren in een AP, willen aangeven dat ze in RDF geen URI moeten krijgen maar wel best als blank node geïmplementeerd worden. Maar misschien dat @GeertThijs dat even kan bevestigen.

Literals zijn getypeerde strings, wat een EDTF Periode dus ook inderdaad is. Dus alhoewel dit ook als "datatype" geclassificeerd wordt, wordt deze wel niet als owl:Class geïmplementeerd.

[GeertThijs]

Er is een verschil tussen primitieve datatypes (Strings, Integers edm) en gestructureerde datatypes (een datatype met meerdere attributen). Inderdaad worden dat in het eerste geval literals en in het tweede geval owl klassen. In RDF wordt geen onderscheid gemaakt tussen gestructureerde datatypes en klassen, dat klopt. Een datatype (ook een primitief datatype) verschilt van een klasse indie zin dat instanties van een datatype louter gedefinieerd zijn door hun waarden, terwijl instanties van een klasse een eigen identiteit hebben. Concreet: een string "Janssens" (een instantie vh primitief datatype String) is een string "Janssens", de ene string "Janssens" verschilt niet van de andere string "Janssens". Een instantie vd klasse Persoon "Janssens" is echter verschillend van een andere instantie vd klasse Persoon "Janssens", het gaat wellicht over twee personen met dezelfde naam maar wel twee verschillende personen. In het tweede geval heeft de instantie een identiteit, je kan het een identificator geven (een uri bvb). In het ander geval zou je dat hoogstens doen om praktische redenen, inderdaad met een of andere lokale identifier (bvb een blank node). Maar meestal wordt een instantie van een datatype (gestructureerd of niet) gewoon inline in de data gezet, niet als een apart (geïdentificeerd) data-element.

[mielvds]

Er is een verschil tussen primitieve datatypes (Strings, Integers edm) en gestructureerde datatypes (een datatype met meerdere attributen). Inderdaad worden dat in het eerste geval literals en in het tweede geval owl klassen. In RDF wordt geen onderscheid gemaakt tussen gestructureerde datatypes en klassen, dat klopt.

Ok! Vanuit het RDF of SHACL perspectief is best verwarrend (een datatype typeert een literal, de rest zijn types/klassen); ik zou suggereren om binnen OSLO een ander woord (ComplexDataType of ObjectDataType? Of waarom zijn het niet gewoon ook klassen?) te gebruiken ipv dataType, gezien het einddoel toch RDF is (ook al snap ik dat die techniciteit een beetje geschuwd wordt). Dit is totaal naast de EDTF kwestie uiteraard.

Wat EDTF betreft lijkt mij de huidige voorstel prima!

[GeertThijs]

Zelf gebruiken wij de term GestructureerdDatatype of ComplexDatatype. Wat in UML met "Datatype" wordt aangeduid inderdaad. De PrimitieveDatatypes noemt UML "Primitive". En eigenlijk zijn dit de RDF literals, de UML elementen Class en Datatype worden op owl:Class gemapt (waarbij owl ook maar een metamodel bovenop RDF is). Ons einddoel is overigens niet enkel RDF of RDFS of OWL, er zijn ook XML of JSON of SQL implementaties te bedenken van de OSLO modellen. RDF of lagen daarbovenop is wel na te streven uiteraard want daar zit de semantiek ingebakken.