search

ejp-rd-vp / resource-metadata-schema

Metadata model and schemas for the EJP virtual platform
https://ejp-rd-vp.github.io/resource-metadata-schema/
Creative Commons Zero v1.0 Universal
14 stars 10 forks source link

boolean modelisation #56

Open Orphanet opened 1 year ago

Orphanet commented 1 year ago

During DCAT-AP workshop with EC expert on DCAT, they provide us an advice regarding booleans:

"Modeling advice: Boolean properties are to be avoided, use properties with a controlled vocabulary instead."

henrietteharmse commented 1 year ago

Good to know and sound advice!

The only place where this is applicable in the resource-metadata-schema is the ejprd:personalData data property. #43 asked that this is kept as a xsd:string for now.

rajaram5 commented 1 year ago

I hope that it is ok if I comment of this issue since I still getting issue emails :D. RDF do support boolean literal type xsd:boolean. See this description https://www.w3.org/TR/turtle/#booleans

henrietteharmse commented 1 year ago

Yes, that is correct. Though, I think the advise against the use of booleans is well aligned with general software engineering practices to avoid the use of flags. If you have 1 boolean on a class (in object orientation) or table (in databases), this is usually not a problem, because both states are used. The problem comes in where you want to use multiple flags in combination. For n flags the total number of possible states are 2^n. If all of the 2^n states are used in the application, that is fine. However, often only a subset of the 2^n states are used. To ensure an application does not accidentally allow states that are not sensible for its use case, often results in rather brittle code. It is much easier to model your domain to only allow the states that are actually possible for your use case - saves you a lot of arbitrary validation of data.