Use of prefixed names in JSON responses

[manuelfiorelli]

The current version of the specification suggests to only include the namespace for most vocabularies; therefore, most attributes will be written in as prefixed names (e.g., "dcterms:title" rather "title").

However, a few implementations, including the OntoPortal one, uses plain attributes.

From the RDF-viewpoint, both forms are equivalent; however, if the response is to be interpreted as plain JSON, perhaps one, standardized serialization should be agreed upon.

[manuelfiorelli]

@syphax-bouazzouni is your validator interpreting the JSON objects as RDF, thus accepting any equivalent serialization, or are you set on one of them. I think that it is important to know this, because this might determine the score obtained by implementations.

[syphax-bouazzouni]

@syphax-bouazzouni is your validator interpreting the JSON objects as RDF, thus accepting any equivalent serialization, or are you set on one of them. I think that it is important to know this, because this might determine the score obtained by implementations.

No it does not parse and validate it as RDF, the validator just check the JSON response, and see if it matches what we would expect based in the implementation of OntoPortal and TSNFDI Gateway.

[manuelfiorelli]

@syphax-bouazzouni is your validator interpreting the JSON objects as RDF, thus accepting any equivalent serialization, or are you set on one of them. I think that it is important to know this, because this might determine the score obtained by implementations.

No it does not parse and validate it as RDF, the validator just check the JSON response, and see if it matches what we would expect based in the implementation of OntoPortal and TSNFDI Gateway.

An implementation that follows the specs pedantically will thus appear non-conforming. We should reach an agreement on this.

[syphax-bouazzouni]

@syphax-bouazzouni is your validator interpreting the JSON objects as RDF, thus accepting any equivalent serialization, or are you set on one of them. I think that it is important to know this, because this might determine the score obtained by implementations.

No it does not parse and validate it as RDF, the validator just check the JSON response, and see if it matches what we would expect based in the implementation of OntoPortal and TSNFDI Gateway.

An implementation that follows the specs pedantically will thus appear non-conforming. We should reach an agreement on this.

Personally I don't really like the prefixed version as it is bit less readable, even if agree it is still valid and equivalent RDF/JSON-LD.

Regarding reaching an agreement on this, currently, OntoPortal, TIB, NERC, and TSNFDI implementations don't use the prefixed version.

However, I'm still open to update the validator to accept the prefixed version if you (@manuelfiorelli) think it is a better implementation.

[manuelfiorelli]

Hi @syphax-bouazzouni I am not in favor of any (although most RDF processing framework may not be able to produce the plain on e). The problem is that the specs is saying the opposite, so either the validator or the specs must be updated.

[manuelfiorelli]

In the meanwhile, I turned to the unprefixed form and the use of plain Json types for some things such as acronym, totalItems, etc.. so that I can use your validator locally.

[jonquet]

Hello. Not sure how the prefixes end up in the MOD-API spec @antony-wilson
If most have of us have implemented without prefixes, then my recommendations is to change the API specification to remove the prefixes to.
@antony-wilson Can you PR this and @manuelfiorelli review.

(sorry closed/reopen by error)

[manuelfiorelli]

Just and additional note. In the api specs, both rdfs:comment and rdfs:comment are used, but I don't know if any of there is mandatory/suggested. If we drop the prefix, they would be both mapped to comment