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

handling unsatisfiable graphs #164

Open
pfps opened this issue Mar 6, 2025 · 1 comment
Open

handling unsatisfiable graphs #164

pfps opened this issue Mar 6, 2025 · 1 comment
Labels
needs discussion Proposed for discussion in an upcoming meeting spec:enhancement Change to enhance the spec without affecting conformance (class 2) –see also spec:editorial

Comments

@pfps
Copy link
Contributor

pfps commented Mar 6, 2025

Semantics says that RDF processors MAY signal an error if they encounter an unsatisfiable graph.

This statement should probably go into Concepts instead.

This has implications with respect to the treatment of ill-typed literals. In 1.1 RDF systems were supposed to handle these and create a graph. Currently Concepts says that systems SHOULD (not MUST) create RDF graphs that contain ill-typed literals, although this change was likely not voted on by the WG.

There should be discussion in Concepts on what happens for inputs that are syntactically legal but unsatisfiable, as are graphs with ill-typed literals.

@pfps pfps added needs discussion Proposed for discussion in an upcoming meeting spec:enhancement Change to enhance the spec without affecting conformance (class 2) –see also spec:editorial labels Mar 6, 2025
@afs
Copy link
Contributor

afs commented Mar 6, 2025

This statement should probably go into Concepts instead.

RDF Concepts does not mention "satisfiable" and "satisfies" is defined in RDF Semantics in simple semantics.

Therefore, I don't see a need to introduce the terminology into RDF Concepts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs discussion Proposed for discussion in an upcoming meeting spec:enhancement Change to enhance the spec without affecting conformance (class 2) –see also spec:editorial
Projects
None yet
Development

No branches or pull requests

2 participants