dini-ag-kim/amb

`isBasedOn` unterscheidet sich von `isPartOf`

Closed this issue · 6 comments

kulla commented

Mir sind größere Unterschiede zwischen https://dini-ag-kim.github.io/amb/draft/schemas/isBasedOn.json und https://dini-ag-kim.github.io/amb/draft/schemas/isPartOf.json aufgefallen:

  • Die Liste der required-Attribute ist unterschiedlich
  • Sollten Properties wie type, id und name verlinkt werden?

Ich vermute, dass beide Schemas ähnlich sein sollen. Welche von beiden Schemas ist die aktuellere?

Wir sollten bei denen m.E. einfach rekursiv https://dini-ag-kim.github.io/amb/draft/schemas/schema.json referenzieren, weil hier im Prinzip eine komplette Ressourcenbeschreibung angegeben werden kann. Oder?

Bei hasPart / isPartOf (invers) wäre das m. E. nicht sinnvoll/nötig bzw. redundant, da hier einfach das tatsächlich zugehörende Objekt verknüpft würde und theoretisch beide Objekte verfügbar sein müssten (damit die Relation Sinn ergibt / nutzbar ist). Hier erhält man ggf. auch schnell veraltete Metadaten, wenn das referenzierte Objekt geändert würde?

Bei isBasedOn sähe ich hingegen eventuell den Unterschied, dass die originale Ressource gar nicht mehr verfügbar sein muss (Derivate bspw.). Hier könnte eine ausführlichere Ressourcenbeschreibung erfolgen, um vor allem die Abstammungsversion mit Urheber, Lizenz und sonstigen Metadaten nachzuzeichnen (also das von @acka47 vorgeschlagene Schema).

Ich folge der Argumentation von Manuel und würde bei has part / is part of würde ich nicht aufblähen. Jedoch sollten wir bei Relationen wie isVersionOf genauso umfangreich wie bei isBasedOn sein

kulla commented

Jedoch sollten wir bei Relationen wie isVersionOf genauso umfangreich wie bei isBasedOn sein

Wo kommt isVersionOf vor? In der Spezifiaktion finde ich es aktuell nicht...

kulla commented

Ergebnis der heutigen Diskussion: Die aktuelle Definition passt so und @oellers konnte gut den Gedanken dahinter erklären. Mit #238 kann dieses Ticket geschlossen werden.

Eine Verbesserung im Anschluss an den Kommentar von @acka47 könnte man #241 umsetzen, aber das ist kein Thema, welches man vor der 1.0 machen muss...

Ich meinte es perspektivisch, als Erinnerungsposten – habe es in einem anderen Schema schon mal als Wert gesehen