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

Voidable properties #19

Open
jechterhoff opened this issue Feb 4, 2016 · 1 comment
Open

Voidable properties #19

jechterhoff opened this issue Feb 4, 2016 · 1 comment

Comments

@jechterhoff
Copy link
Collaborator

Description

The voidable concept used in INSPIRE is in some ways interesting as it allows explicitly stating that something, for example the name of a road, is not known (no value, but reason 'unknown' is provided) and distinguishes this from stating that a road is known to have no name (no value and no specific reason). I.e., the INSPIRE application schemas, although generally based on the closed-world assumption, support unknown facts.

In RDF not stating a property is equivalent to setting the property to nil in the GML encoding.
RDF has no proper mechanism (that we are aware of) to explicitly state that the name of a road is unknown (to some person(s) or organizations).

NOTE: RDF adheres to the open world assumption which takes into account that, in this example, someone else may have a name for the road.

Thus, without a natural way to express such facts in an INSPIRE RDF representation, the RDF representation will state that no road name is known. While this is a loss of information, it probably is not essential for most applications.

The aim (of developing guidelines for representing INSPIRE data in RDF) should be to provide the means to share all the (positive) information a data provider has. If a certain piece of information is not available at a data provider, chances are that they simply don’t know them. The case where the absence of data is explicitly known should be quite rare.

In summary, we propose to not add a schema conversion rule for <<voidable>>, because there does not seem to be a need for it.

NOTE: if it turned out that cardinality restrictions have to be represented (see issue #18 ) then all voidable properties would have to include the default minimum cardinality 0.

@jechterhoff
Copy link
Collaborator Author

The current draft vocabularies follow the proposed approach. For further details, see section Voidable of the guidelines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant