listing properties in the service manifest

[eroux]

In our reconciliation service (which starts to work on https://ldspdi.bdrc.io/reconciliation/en/ , we want to allow users to use 2 properties ("has author" and "author of"), but only those two. They are arbitrary conventions that we define for our reconciliation service and do not correspond to direct properties in our ontology (they would be a path in our graph, :creator/:agent in SPARQL). They are thus more or less impossible to guess (unlike the Wikidata property which are all direct properties and thus usable directly in the context of reconciliation).

My proposal would be to ad an optional possible_properties in the service manifest that would list some possible properties, where properties would be like:

"possible_properties": [
    {
        "pid": "hasAuthor",
        "name": "has author",
        "type": ["Person"]
    }
]

Perhaps the semantics could be something like:

• if possible_properties it should be considered exhaustive
• if type is present it should be considered exhaustive

[fsteeg]

A possible option might be to implement a property suggest service that returns only these 2 properties. In our lobid-gnd service we suggest all available properties if the requested prefix is empty. The specs make no explicit mention of this usage, but I think it's actually correct since all entries start with an empty prefix. In OpenRefine however, this (currently) requires typing a blank in the property text field to get the suggestions.

[eroux]

oh, very interesting! Well, in our case the properties to use for the search are different from those of a potential extend service... so... perhaps the suggest service could differentiate them? in any case, I'll implement a property suggest service, that will be very useful

[fsteeg]

in our case the properties to use for the search are different from those of a potential extend service... so... perhaps the suggest service could differentiate them?

Not sure if that's what you mean, but the extend service has its own property proposal service.

[eroux]

ok perfect, I understand now.

I think the spec could be a little more clear that this is a use case of the property suggestion service