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.

Sign up for GitHub

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

w3c/sparql-12#101 SEP-0003 for re-introducing min/max #116

Merged
merged 4 commits into from
Sep 18, 2020
Merged

w3c/sparql-12#101 SEP-0003 for re-introducing min/max #116

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
3977281
w3c/sparql-12#101 Draft SEP-0003 for re-introducing min/max
JervenBolleman Sep 16, 2020
05e49af
Update SEP/SEP-0003/sep-0003.md
JervenBolleman Sep 16, 2020
25c1e10
Fix type SEP/SEP-0003/sep-0003.md
JervenBolleman Sep 16, 2020
1e45350
Table markdown fixed.
JervenBolleman Sep 16, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions SEP/SEP-0003/sep-0003.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
# Property paths with a min/max hop

* Short Name: min-max-propery-path
* SEP Number: [SEP-0003](sep-0003.md)
* Author: [Jerven Bolleman](https://github.com/jervenbolleman)

## Abstract

In the SPARQL 1.1. working group, a form of bounded property path where supported in the late [drafts](https://www.w3.org/TR/2012/WD-sparql11-query-20120105/#propertypaths). The form being a path element _elt_, followed by a curly bracket enclosed min/max pattern.

|Syntax Form|Matches|
|-----------|-----------|
| _elt_{n,m} | A path of between n and m occurrences of elt. |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume m is inclusive here?
An option would be to use the [n,m] notation in the description in this table (also for the next forms).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The july 2012 spec, did not say but it is something that should be written down. For consistency with other functions, I think it should be inclusive.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To discuss? must m and n be a constant or are variables allowed?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Supporting variables would require a major change to the evaluation semantics.

| _elt_{n} | A path of exactly n occurrences of elt. |
| _elt_{n,} | A path of n or more occurrences of elt. |
| _elt_{,n} | A path of between 0 and n occurrences of elt. |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wondering if would be valuable to have this mean "A path of between 1 and n occurrences of elt" instead?
I've noticed that an implementation of the zero-case can be tricky to optimize, while users may not really need it this often(?).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to agree that the zero-length case is often not what is wanted (especially in cases where both subject and object are variables), and requiring the full {0,m} form to get those semantics would probably be desirable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Imho, it would be a bit strange to have {,n} mean {1,n} and not {0,n} because 1 is not the lower bound of the possible values. What about not allowing {,n}? {1,n} and {0,n} are just one key press away from {,n}.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Tpt on reflection, I think being explicit is better than being implicit so disallowing the form {,n} seems sensible. Adding {n,*} to mean at least n hops seems sensible to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great! My personal opinion would be to keep {n,} instead of {n,*} in order to avoid adding an extra symbol and use the same syntax as a lot of regex languages.


This was removed in later draft and recommondation, upon the change to non-counting semantics.

> Such connectivity matching does not introduce duplicates (it does not incorporate any count of the number of ways the connection can be made) even if the repeated path itself would otherwise result in duplicates.

The functionality of limited connectivity checks is still valid with non-counting semantics, in pragmatic terms.

## Motivation

As raised in [sparql-12#101](https://github.com/w3c/sparql-12/issues/101), it would be nice to have this functionality available in SPARQL 1.2.

Pragmatically many stores already implement the form `{,max}` as the `*` and `+` versions are implicitly limited.

## Rationale and Alternatives

An alternative is that this could be reintroduces with counting semantics.

## Evidence of consensus

**TODO: To be filled in when/if such evidence becomes available**

## Specification:

## Backwards Compatibility

This proposal is purely additive to SPARQL 1.1.

## Tests and implementations