[DD-620] define uri templates for resources Erstellt: 08/Jul/14  Aktualisiert: 20/Apr/16  Erledigt: 20/Apr/16

Status: Fertig
Projekt: D:SWARM
Komponente(n): Keine
betrifft Version(en): Keine
Lösungsversion(en): 0.9.2

Typ: Story Priorität: Schwer
Autor: Gängler, Thomas (Inaktiv) Bearbeiter: Nicht zugewiesen
Lösung: Fertig Stimmen: 1
Stichwörter: conceptualized, schema-editor, ub-dortmund-requirement

Verknüpfungen:
Blocks
blocks DD-654 erm-use-case: csv to rdf Aufgaben
is blocked by DD-1204 define uri template parameter values Aufgaben
is blocked by DD-789 create resource in target record Fertig
Relates
relates to DD-392 [BE] extend converter to be able to h... Fertig
relates to DD-766 [FE] make URI input form better/more ... Aufgaben
relates to DD-735 Extend MorphScriptBuilder Fertig
relates to DD-72 using HTTP APIs as transformation fun... Fertig
relates to DD-872 [BE] uri minting on demand for subent... Fertig
Unteraufgaben:
Schlüssel
Zusammenfassung
Typ
Status
Bearbeiter
DD-876 define concept for uri template mecha... Technische Aufgabe Fertig  
DD-1320 [BE] enable specific processing for r... Technische Aufgabe Fertig  
DD-1321 [BE] regenerate inbuilt schemata to i... Technische Aufgabe Fertig  
Aufwand: 32
Sprint: sprint 27, sprint 29, sprint 51, sprint 52, sprint 53, sprint 54, sprint 55

 Beschreibung   

Currently, when a new resource is created in the target data model (via a transformation) we just utilise the URI from the resource in the source data model. It should be possible to define URI templates that will be utilised for URI minting (of new resources) in a target data model.

  • each (non-leaf) element in the target schema widget is a resource indicator
  • each resource indicator can hold an URI template
  • a URI template can be defined with help of a mapping to a resource indicator
  • all necessary mapping inputs that are needed to construct the URI template are part of this mapping
  • the whole function set can be applied to create the URIs
  • the target of those mapping could be a direct mapping to the attribute path of the resource indicator, e.g., "bibo:Document" (in the example from above); the only "disadvantage" of this approach is that it is probably more difficult to identify those attribute paths later when processing the task in the morph script builder (albeit, it is possible!)
  • note: we don't need to display the record class right now (this is another issue )
  • the produced uris will be displayed in the target example widget (as all other values will be displayed in that way)

=> https://avgl.mybalsamiq.com/mockups/1118466.png?key=27106ea66faf01c9ad98a275eac48683ac53bf00 already shows how it could looks like, i.e., the mapping that is responsible for the URI template is named 'identifier' and the output is displayed in the target example widget (after the "bibo:Document" attribute)

  • another approach would be an attribute path that is constructed with the attribute path of the resource indicator + (e.g.) rdf:ID (or just the special attribute, when it is the root level)
  • the special attribute (here the example is rdf:ID) for relating the resource identifier should only be utilised for this use case, because it will be treated specifically in the morph script builder to produce and assign the resource identifiers

acceptance criteria:
(- a graphical element/dialog is available for defining a URI template (could be extended to a URI template builder later))

  • URI templates can be processed by converter
  • new resources are created that have URIs that follow the URI template


 Kommentare   
Kommentar durch Polowinski, Jan [X] (Inaktiv) [ 06/Jan/15 ]

I suggest to use our existing transformation / function tooling to concat the URI (String) graphically. We could internally handle the mapping to rdf:ID as an URI-templating just as we handle the mapping to rdf:type in a special way. In the GUI, targeting the top attribute path (of a sub-schema) could be interpreted for building the URI of the sub-entity (so rdf:ID does not have to appear in the GUI!). Comments welcome

Kommentar durch Gängler, Thomas (Inaktiv) [ 09/Jan/15 ]

Polowinski, Jan [X]: yes this a possible approach, however, I'm not 100% sure, whether this delivers the intended user experience. we should sketch this in a wireframe.

Kommentar durch Gängler, Thomas (Inaktiv) [ 23/Sep/15 ]

since URI templating can be resolved via a transformation workflow (cd .DD-1204), I would tend to prefer implementing DD-789 instead.

Kommentar durch Gängler, Thomas [ 15/Mär/16 ]

will go with rdf:about as property for the statement that holds the record identifier (cf. http://answers.semanticweb.com/questions/2189/should-i-use-rdfabout-or-rdfid + http://stackoverflow.com/questions/7118326/differences-between-rdfresource-rdfabout-and-rdfid), i.e., the attribute that can be utilised for a mapping to generate a record identifier.

Kommentar durch Gängler, Thomas [ 15/Mär/16 ]

record identifier generation (via mapping) will be supported for first level only (i.e. the record itself, not hierarchical records).

Erstellt am Sat Aug 18 23:52:37 CEST 2018 mit JIRA 7.8.0#78000-sha1:4568b9d484113d74dfb6f152fb925b5fa1be2ef7.