Closed fdiehr closed 4 years ago
fdiehr
commented
4 years ago zu 3.:
hab gerade sparql query mit SELECT * WHERE {?s ?p _:t1513} gemacht. Dabei kam heraus, dass die Property http://www.metaphacts.com/fieldDefinition/P94i_was_created_by als Subject fungiert. das geht natürlich nicht. P94i_was_created_by ist zum eine eine Property und zum anderen ist http://www.metaphacts.com/fieldDefinition/P94i_was_created_by eine Feld Definition.
Mir ist nicht klar, wie das gedacht ist
fdiehr
commented
4 years ago SELECT * WHERE {?s ?p _:t1513}
ok, war glaube ich faslche query. hab jetzt mal SELECT * WHERE { <https://objekte.museum4punkt0.de/narrenschopf/C%201.1.2.40-16.tif> ?property ?object . }
ausgeführt, und da kommt ein entsprechendes object (https://enter.museum4punkt0.de/resource/3a9e2d45-dbd6-54dd-acf1-bbef9ca60e15) mit rdf:type crm:E65_Creation. das sehe ich daran, dass er das entsprechende Template benutzt, dass ich für Instanzen von crm:E65_Creation definiert habe.
Allerdings sieht man keine Daten, wenn man https://enter.museum4punkt0.de/resource/3a9e2d45-dbd6-54dd-acf1-bbef9ca60e15 aufruft. Beim Import müssten also noch ein paar Daten gespeichert werden, die für crm:E65_Creation wichtig sind. zur specification müsste daher folgendes dazu kommen
<{creation_iri}> a crm:E65_Creation; m4p0:hasCreationPhase <https://www.museum4punkt0.de/catalogue/ontology/MaterialProduction>; m4p0:hasCreationMethod <{concept_iri}>
an dieser Stelle wird es noch schwieriger, weil jetzt noch labels für ein skos:Concept erzeugt werden müssen....
das ist doch sicherlich alles viel zu komplex, oder??? :'(
p.s. wollte den pull request re-open, aber da gibt es n conflict und ich will nix kaputt machen.
fdiehr
commented
4 years ago https://enter.museum4punkt0.de/resource/3a9e2d45-dbd6-54dd-acf1-bbef9ca60e15
base URI sollte dafür aber so aussehen: https://enter.museum4punkt0.de/resources/E65_Creation/{{UUID}}
wobei mir gerade auffällt, dass das generell vielleicht etwas blöd ist... ich kann das noch ändern bei mir.... hmm, ja, pass auf, ich ändere das bei mir so das der base URI so ist wie bei dir also:
https://enter.museum4punkt0.de/resource/
funkyfuture
commented
4 years ago zu 3.: da ist jetzt der stand, dass zu E65_Creation bezügliche daten fehlen, richtig? da habe ich in erinnerung, dass die "von hand" erfasst werden sollten. richtig?
wollte den pull request re-open
welchen konrekt?
hmm, ja, pass auf, ich ändere das bei mir so das der base URI so ist wie bei dir also
genau, so ne hierarchisierung hatte ich für die beim import erzeugten entitäten nicht vorgesehen, sondern eben dieses universelle schema. äh, mir geht jetzt vieles zu namespacing durch den kopf und was die lehre sein könnte, auch eingedenk der entitäten, die du in der app verwendest. aber ja, simple stupid is jetzt wohl das beste. das risiko für namenskollisionen bei den iris mit diesem flachen schema ist sehr sehr gering.
funkyfuture
commented
4 years ago der typo und die umlaute sind gefixt. ist hier noch was offen?
fdiehr
commented
4 years ago zu 3.: da ist jetzt der stand, dass zu E65_Creation bezügliche daten fehlen, richtig? da habe ich in erinnerung, dass die "von hand" erfasst werden sollten. richtig?
ja, aber ich habe beim review des testimport festgestellt, dass das so nicht funktioniert, leider. es müssten noch mehr infos mitgespeichert werden. das kann sonst niemand mehr zuordnen.
fdiehr
commented
4 years ago der typo und die umlaute sind gefixt. ist hier noch was offen?
ja: die sache mit den objects von P94i_was_created_by:
hier habe ich wohl in der Specification einen ontologischen Fehler übersehen:
GRAPH {graph_iri} { <{creation_iri}> a crm:E65_Creation ; rdf:label "{data_provider} / {file_namespace} / {media_type}" ;
data_provider etc. dürfen aber keine labels von E65_Creation sein, das macht keinen Sinn. Eine "Creation" ist ja nur der Vorgang der Erzeugung.
die labels müssten als objects von eigens dafür definierten properties dienen, also:
D1.Digital_Object (domain) edm:dataProvider <{data_provider}> diese Property benutzt du aber bereits um den Data Provider des Graphs anzugeben. Das ist auch richtig so. Ich verstehe nicht, warum er also als label von crm:E65_Creation nochmal auftaucht. dasselbe gilt für <{file_namespace}> und <{media_type}>
was also geändert werden muss ist dieser Part:
GRAPH {graph_iri} { <{creation_iri}> a crm:E65_Creation ; rdf:label "{data_provider} / {file_namespace} / {media_type}" ;
Für crm:E65_Creation müssen eh noch weitere Informationen gespeichert werden (siehe oben).
<{creation_iri}> a crm:E65_Creation; m4p0:hasCreationPhase <https://www.museum4punkt0.de/catalogue/ontology/MaterialProduction>; m4p0:hasCreationMethod <{concept_iri}>
die Import-Tabelle müsste meines Erachtens nicht erweitert werden, da die Werte abgeleitet werden können, also von uns festgelegt werden können. dazu hab ich den pull request für die specification.md wieder geöffnet und schreib da mal rein, was noch dazu kommt.
funkyfuture
commented
4 years ago die idee, das label dort hinzuzufügen war, dass editierende, die daten zu diesen creations erfassen, ne orientierung haben, um welche es sich konkret handelt, via bezug über die resultate.
es fällt mir sehr schwer den erörterungen hier zu folgen. ist alles diesbezügliche in #13 enthalten?
fdiehr
commented
4 years ago die idee, das label dort hinzuzufügen war, dass editierende, die daten zu diesen creations erfassen, ne orientierung haben, um welche es sich konkret handelt, via bezug über die resultate.
hmm verstehe. alle anderen creations haben aber kein label, dann find ich das ungünstig, wenn nur diese eines bekommen. und es ist auch etwas hässlich aus sicht der wissensrepräsentation. ich denke, die zuordnung wird auch anders möglich sein: der hauptanker dafür ist der bezug zum digital object. über das bekommen sie die dazugehörige creation aufgelistet. auch über den data provider wäre das möglich. hinzukommt, dass ich antizipieren, dass sie im nachgang die creations nicht nochmal manuell bearbeiten werden deswegen hätte ich gern die angabe von "hasCreationPhase" und "hasCreationMethod" direkt gespeichert.
es fällt mir sehr schwer den erörterungen hier zu folgen. ist alles diesbezügliche in #13 enthalten?
ja, die sind eigentlich in der spec drin. aber ich verstehe, dass es schwierig zu verstehen ist, wenn man nicht so tief in der datenstruktur drin steckt. deswegen dachte ich kurz treffen, weil kann man besser erklären. ich kann das aber auch mal versuchen aufzumalen und dir dann schicken.
fdiehr
commented
4 years ago über das bekommen sie die dazugehörige creation aufgelistet. btw... wie ist das jetzt? wird eine creation pro import erzeugt (also n + 1 digital object hat 1 creation) oder hat jedes digital object seine "eigene" creation? ersteres wäre zu bevorzugen, da sonst sinnlos viele creations entstehen würden. aus der spec würde ich aber 2. verstehen.
funkyfuture
commented
4 years ago btw... wie ist das jetzt?
je datenset und den darin enthaltenen distinkten media type wird eine creation angelegt.
ich schließe das jetzt hier, weil ich denke, dass ein aktiver ort zur diskussion von zusammengehörendem nachvollziehbarer und verlässlicher ist. das sollte im augenblick an der änderung der spezifikation erfolgen.
fdiehr
commented
4 years ago je datenset und den darin enthaltenen distinkten media type wird eine creation angelegt.
ja, perfekt!
ich schließe das jetzt hier,
yo, alles klar!
MuseumObjectTtileund da es eine property ist, bitte klein schreiben: museumObjectTitlehttp://www.vsan.de/ / https://objekte.museum4punkt0.de/narrenschopf/ / https://www.iana.org/assignments/media-types/image/tiffals Object muss hier eigentlich die Klasse crm:E65_Creation kommen. Bin mir nicht sicher, was du hier mit den Eingaben für ein Statement machen wolltest. Laut der Specification muss hier eigentlich folgendes kommen:digital_app_creation <- crm:E65_Creation-instanz via m4p0:hasCreatedDigitalApp von {digital_app} (optional)(Zeile 101-102)