k (→problemen) |
|||
Regel 36: | Regel 36: | ||
===problemen=== | ===problemen=== | ||
# Er wordt gebruik gemaakt van DCMI Period (http://dublincore.org/documents/dcmi-period/) om een tijdinterval aan te duiden. Dat is nodig omdat dcterms:valid als waarde een rdfs:Literal moet hebben. Maar het zou beter zijn als een tijdinterval als een complex object kan worden beschreven, dat gebruik maakt van algemenere datatypes als xsd:DateTime, xsd:gYear of xsd:integer. | # Er wordt gebruik gemaakt van DCMI Period (http://dublincore.org/documents/dcmi-period/) om een tijdinterval aan te duiden. Dat is nodig omdat dcterms:valid als waarde een rdfs:Literal moet hebben. Maar het zou beter zijn als een tijdinterval als een complex object kan worden beschreven, dat gebruik maakt van algemenere datatypes als xsd:DateTime, xsd:gYear of xsd:integer. Met xsd:DateTime of xsd:integer (voor jaren) zouden de data bijvoorbeeld makkelijker in een SPARQL-query gefilterd kunnen worden. | ||
# Wat nog ontbreekt is een manier om vast te leggen (in de metadata van de dataset) dat het om een dataset met objecten die versies kunnen hebben gaat. Als een gebruiker dat niet weet kunnen verkeerde conclusies worden getrokken. Wordt in het voorbeeld bijvoorbeeld gevraagd hoeveel kerken er zijn (instanties van ex:Church), dan is het antwoord 2. Maar de dataset bevat maar 1 courante kerk. | # Wat nog ontbreekt is een manier om vast te leggen (in de metadata van de dataset) dat het om een dataset met objecten die versies kunnen hebben gaat. Als een gebruiker dat niet weet kunnen verkeerde conclusies worden getrokken. Wordt in het voorbeeld bijvoorbeeld gevraagd hoeveel kerken er zijn (instanties van ex:Church), dan is het antwoord 2. Maar de dataset bevat maar 1 courante kerk. |
Datasets beschrijven vaak een bepaalde staat van de dingen waarover data zijn vastgelegd. Vaak stelt dit de huidige, of laatst bekende staat voor. Maar in werkelijkheid veranderen dingen: Dingen onstaan, ondergaan veranderingen en verdwijnen soms weer. Om de werkelijkheid goed te beschrijven moeten datasets dus een notie van geschiedenis hebben. Met andere woorden, de dingen die worden beschreven in een dataset kunnen versies hebben. De vraag is hoe dat het beste aangepakt kan worden bij publicatie van een dataset als vijfsterrendata.
De volgende algemene (niet toepassingsspecifieke) eisen kunnen aan een oplossing worden gesteld:
Hieronder wordt een simpel voorbeeld uitgewerkt in Turtle-notatie, om duidelijk te maken hoe versies van objecten kunnen worden gepubliceerd. Het voorbeeld gaat over een kerk die op 30 september 1929 in gebruik genomen is met de naam "OldName". Op 20 juni 1990 wordt de naam veranderd in "NewName".
:c1 a ex:Church ; dcterms:title "NewName" ; dcterms:valid "start=1990-06-20;" dcterms:replaces <c1/version1> . <c1/version1> a ex:Church ; dcterms:title "OldName" ; dcterms:valid "start=1929-08-20; end=1990-06-19;" dcterms:isVersionOf :c1 ; dcterms:isReplacedBy :c1 .
Eigenschappen van de oplossing zijn:
De activiteiten van Platform Linked Data Nederland (PLDN) worden mede mogelijk gemaakt dankzij het Kadaster, TNO, Big Data Value Center (BDVC), ECP, Forum Standaardisatie, Kennisnet, SLO, Waternet, Taxonic, MarkLogic, Triply, Franz Inc., SemmTech, Rijksdienst voor het Cultureel Erfgoed (RCE), Beeld en Geluid, EuroSDR, de KVK en ArchiXL
Wilt u op de hoogte gehouden worden van nieuws en ontwikkelingen binnen PLDN?
Schrijf u dan in voor de nieuwsbrief