Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

boolean modelisation #56

Open
Orphanet opened this issue Jun 30, 2023 · 3 comments
Open

boolean modelisation #56

Orphanet opened this issue Jun 30, 2023 · 3 comments
Labels
model status: awaiting decision Awaiting decision by members on whether this change/extension should be applied

Comments

@Orphanet
Copy link
Contributor

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."

@Orphanet Orphanet added the model label Jun 30, 2023
@henrietteharmse
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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.

@henrietteharmse henrietteharmse added the status: awaiting decision Awaiting decision by members on whether this change/extension should be applied label Aug 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
model status: awaiting decision Awaiting decision by members on whether this change/extension should be applied
Projects
None yet
Development

No branches or pull requests

3 participants