Open gezever opened 6 years ago
gezever
commented
6 years ago En moet http://data.vlaanderen.be/id/organisatie strikt genomen niet http://data.vlaanderen.be/id/organization zijn, aangezien er geen eigen klasse http://data.vlaanderen.be/ns/organisatie#Organisatie is gedefiniëerd?
dhaeneth
commented
6 years ago Waarom zou dit in tegenspraak zijn? De URI-standaard zegt gewoon dat de structuur van een URI moet bestaan uit http(s)://{domein}/{type}/{concept}(/{referentie})* Het concept verwijst daarbij naar het semantisch domein (in jouw voorbeeld dat van OSLO:Organisatie). In dat semantisch domein heb je dan het subconcept 'Contact', wat mapt op Schema:ContactPoint. Een concept kan toch bestaan uit een hiërarchie (ook cfr. de URI-standaard)?
dhaeneth
commented
6 years ago En voor je vraag over id/organisatie vs id/organization - er is wat onduidelijkheid. Data.vlaanderen.be/ns/organisatie vermeld weliswaar onder 'externe terminologie' het volgende : Deze sectie geeft een overzicht van terminologie uit andere vocabularia die relevant is voor dit domeinmodel samen met hun Nederlandstalige labels en definities.
In dit geval hebben we de nederlandstalige term 'Organisatie' die dus ook gedefinieerd is en die gewoon een taalproxy is voor http://www.w3.org/ns/org#Organization
gezever
commented
6 years ago Ik lees in uri-standaard dat {concept} verwijst naar de categorie van de resource, niet dat het verwijst naar het semantisch domein. met voorbeelden: id/waterweg/schelde id/school/s_7837483 id/adres/9039439430 id/gebouw/45a Indien je de context eerst vernoemt, krijg je dan niet telkens andere uri's voor de schelde bv.?
dhaeneth
commented
6 years ago Maar de resource zit in dit geval toch ingebakken in het semantisch domein? Het gaat over het contactpunt van de organisatie; niet het contactpunt aan zich.
Het zou een ander verhaal zijn moesten we een resource hebben met zuiver contactpunten (zonder hiërarchische inbedding). Dan zou je gelijk hebben en bestaat de resource domeinonafhankelijk. In dit geval bestaat de resource contactpunt enkel in functie van de organisatie (het is het telefoonnr van de organisatie) en wordt de rersource dus "organisatie/contactpunt".
Ik quoteer uit de URI-standaard : 3.1.1 Informatieresources Dingen die een digitale representatie (kunnen) hebben zoals
data: representatie van dingen of zaken in een bepaalde elektronische vorm die bijgehouden wordt op een of ander opslagmedium;
(web-) services: laten toe om toegang tot data, het ondernemen van acties met de data en acties ondernemen met de data (=aanpassen ervan). Services zijn dan diensten die een machine ter beschikking stelt die toegang verschaffen tot data en toelaten om acties met en op de data uit te voeren;
ontologieën (of vocabularia): termen, hun definities en de relaties tussen de termen om data te beschrijven.
documenten: beschrijvingen van (niet-)informatieresources op het web.
Concreet gaat het hier over de derde categorie : een vocabularium (domeinmodel) met een relatie tussen de termen.
gezever
commented
6 years ago Wanneer je stelt dat een contactpoint enkel binnen één organisatie kan bestaan heb je een punt. Het wordt blijkbaar open gelaten binnen het applicatieprofiel. Ik kan me echter één secretariaat voorstellen voor meerdere organisaties. Het hiërarchische aspect van een categorie stelde ik me als een opeenvolging van subclasses voor.
gezever
commented
6 years ago Het applicatieprofiel is ook niet helemaal duidelijk over de property http://data.vlaanderen.be/ns/organisatie#contactinfo. (ik zie dat er in de implementatie http://schema.org/contactPoint wordt gebruikt) In het appliclatieprofiel (http://data.vlaanderen.be/cms/ap/organisatie-basis-ap/overview.jpg) is contactinfo een property van Organisatie en Hoedanigheid. In de ontology is http://data.vlaanderen.be/ns/organisatie#Hoedanigheid domein van http://data.vlaanderen.be/ns/organisatie#contactinfo, waardoor een Organisatie een Hoedanigheid wordt indien http://data.vlaanderen.be/ns/organisatie#contactinfo wordt gebruikt. Is dat de bedoeling?
bertvannuffelen
commented
6 years ago Op je laatste opmerking: er is gekozen voor om een lokale naam voor een eigenschap te gebruiken in de context van een klasse. Dat betekent dat je mogelijkerwijze dezelfde lokale naam hebt, maar dit is niet dezelfde semantische relatie. een goed voorbeeld is status. Zowat op elk object zou je een status kunnen geven en in plaats van gemeentenaamstatus, organisatiestatus, hoedanigheidsstatus, ... te gebruiken om via de lokale naam een unieke benaming te bekomen is er gekozen om een zo kort mogelijke lokale benaming te hebben. En deze de disambigueren via een volledige uri. Dus voor je voorbeeldje
Maakt dit het wat duidelijker?
gezever
commented
6 years ago Ja, ik begrijp het. http://schema.org/contactPoint gaat over personen en organisaties. Daarom is er een property bijgemaakt voor Hoedanigheid.
GeertThijs
commented
6 years ago In de notes bij dit element in UML lees ik:
Kan niet naar http://schema.org/contactPoint mappen want hoogst mogelijke niveau is momenteel Persoon en Organisatie. Momenteel=mogelijk zet schema.org dit zelf naar een hoger niveau.
Wat bovenstaande bevestigt. We kunnen deze issue dus sluiten.
jensscheerlinck
commented
6 years ago @bertvannuffelen geef jij een seintje wanneer de URI's op data.vlaanderen.be zijn aangepast voor Contactinfo?
De resource van type http://schema.org/ContactPoint voldoet m.i. niet aan de uri-standaard, of begrijp ik het niet goed? <ns6:contactPoint xmlns:ns6="http://schema.org/" rdf:resource="http://data.vlaanderen.be/id/organisatie/OVO003751/contact/e7072d27-717e-53d1-658b-5a0ff6e34207"/> Moet een contactpoint niet een uri met patroon http://data.vlaanderen.be/id/contactpoint/.... hebben ipv. http://data.vlaanderen.be/id/organisatie/.... ?
curl -L -H "Accept: application/rdf+xml" http://data.vlaanderen.be/id/organisatie/OVO003751
<?xml version="1.0" encoding="utf-8"?>