Add a view template for type
One of the significant updates to the manifest for v1.0 was to Remove identifierSpace and schemaSpace and make view templates mandatory.
In my understanding, the manifest identifierSpace field has been replaced with a view template defined in the manifest view field. This is used by the Reconciliation client to add hyperlinks to the candidate IDs (instances).
There appears to be no replacement for schemaSpace. There is a partial replacement with the view template field featureView. However this is limited to the reconciliation candidate response matching feature and therefore not applicable to type ids and property ids (not in the array of candidate features).
This leaves no obvious solution of how to add a view template for the following:
- type id (class)
- property id (predicate or propertyId)
Given that it is common (at least in my projects) to have a mix of types and properties from external vocabularies and ontologies, it is desirable for the Reconciliation client UI to add hyperlinks to the local names of types and properties. This would suggest that view templates are needed.
One currently available option is to use the view template "url": "{{+id}}" for all ids. This entails using full URIs for entities as well as types and properties. This is not desirable as it would mean entities would always be a full URI instead of a compact ID. This would also make the UI of the client more difficult to design and less generic as some services would return a short ID and others a complete URL.
Therefore I propose the following changes to fields in the manifest:
- rename
view->entityView - add
typeView - add
propertyView
To make this more concrete with an example, below is the manifest for a reconciliation service that return IDs for entities and URIs for type ids and propertyIds.
"entityView": {
"url": "http://kg.artsdata.ca/resource/{{id}}"
},
"typeView": {
"url": "{{+id}}"
},
"propertyView": {
"url": "{{+id}}"
}
The existing featureView as well as the new typeView and propertyView should remain optional, leaving only the entityView template as mandatory.
@fsteeg @wetneb I am interested in your opinion about this suggestion.
It looks good to me, I can see those templates being very useful for clients indeed.
Sounds good!
(For reference, the + in {{+id}} means that the id may contain reserved URI characters, see RFC 6570).
@saumier: In today's meeting, you mentioned that this would be useful when using different ontologies. Just to clarify: it would help if e.g. types come from a different ontology than properties, but it would still require all properties to come from a single ontology (if we want to use short ID and provide the full link in the template), right?
(In our service, we use properties with short IDs, which are mapped to many different ontologies in the context.)