Warning:
This wiki has been archived and is now read-only.

Proposals

From RDF Data Shapes Working Group

Jump to: navigation, search

This page provides a place where RDF Data Shapes Working Group members can make proposals to resolve open issues and gather votes against them.

1 Process
2 Open Issues
3 Closed Issues

Process

Issues are managed through the Tracker but WG members are welcome to make proposals on how to resolve them here. It is recommended that people making new proposals announce them to the rest of the WG by sending an email to the list.

WG members are invited to cast votes against proposals by adding their name to the Votes along with their vote using the usual convention +1/0/-1 (i.e., support/abstain/object). Objections should be made with a comment describing the nature of the objection and what it would take for the objection to be withdrawn.

WG members may choose to make different proposals. Votes will be gathered against each proposal.

The hope is that this will help streamline disposal of open issues, allowing for at least the non controversial ones to be more quickly closed.

Open Issues

(None)

Closed Issues

ISSUE-22: Treatment of recursive shape definitions

PROPOSAL 1: close issue 22 using the existing resolution (https://www.w3.org/2015/12/16-shapes-minutes.html#resolution04)

Votes: DK: +1

PROPOSAL 2: close issue 22 by changing the existing resolution and stating "The starting point for recursion in SHACL is that dependency loops are invalid at run-time." as proposed by Holger here: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Apr/0093.html

Votes: DK: -0.9

comments (DK): there are many things that are not clear and tested here, I would rather not re-open recursion issues / discussions

ISSUE-23: Shapes as Classes

PROPOSAL a: Leave sh:ShapeClass as currently defined

Votes: HK:+1, SS:+0, DK:+0, pfps: -1, eric: -1, labra: -0.9, AR: -0.9

Comments:

pfps: The current definition has may and should, which are not suitable for this construct.
AR: Shapes and classes are conceptually very different.

PROPOSAL b: Don't include sh:ShapeClass but keep the rule that if a shape is also a class then "infer" the sh:scopeClass triple. For example ex:MyShapeAndClass a rdfs:Class, sh:Shape would imply ex:MyShapeAndClass sh:scopeClass ex:MyShapeAndClass. See email.

Votes: DK:-0.9, pfps: -0.9, HK: 0.5, labra: -0.5, eric: -1, SS: +0.9

Comments:

pfps: This is different from the previous proposal, I think, as it does not have may or should.
dimitris: My objection on this is because it will be very confusing for users. a) what happens if the user uses owl:Thing or another subclass of rdfs:Class?, reasoning is required but the relation to rdfs:Class might exist in another graph b) the function of the shape will not be deterministic, it will always depend on what triples exist on the shapes graph. It is also prone to errors when someone by mistake does not include the ontology graph in the shapes graph.
HK: (I assume you mean owl:Class instead of owl:Thing above). I think it should only do the light-weight inferencing of walking up the superclasses (as elsewhere in SHACL). But I believe all the issues you mention are under the shape author's control. If someone puts a sh:Shape triple for a class imported from another file then he already knows which other triples are present in that other file. I don't see anything non-deterministic. If someone wants to be 100% sure, he can also add both type triples into the shapes graph, yet one may argue that this would mix shape and class definitions, which some people here are critical of.
Dimitris: But this makes shapes not easily portable and reusable. Someone who wants to re-use such a shape must always make sure he/she copies the class definitions. For me this one worse from all current proposals. Proposal (d) is a combination of proposals (a) and (b) that has none of these problems and (hopefully) takes away part of Peter's concerns about modeling.
HK: Ok, I can see your point better now (although I'd argue that if someone reuses shapes then he should also honor the owl:imports of the original shapes graph). But I could live with your proposal too. Maybe sh:ClassShape is a better name though?
DK: I was thinking to rename to sh:ClassShape too, I will adjust the proposal

PROPOSAL c: Don't have sh:ShapeClass.

Votes: pfps:+1, HK: -1 (if this excludes b above), DK: +1, labra: +0.5, SS:0

Commments:

pfps: Adding the "extra" triple is a small price to pay to remove a construct that entangles shapes and modelling.
HK: The distinction between shaping and modelling is IMHO entirely philosophical.

PROPOSAL d: A variation of the existing definition in the spec with the removal of the triple "sh:ShapeClass rdfs:subClassOf rdfs:Class". This means that sh:ShapeClass is no longer a metaclass and the definition of "ex:MyShapeAndClass a rdfs:Class" is not of interest in SHACL. The SHACL engine will assume that the definition is defined "somewhere", not necessarily in the current shapes graph. To better reflect this behavior, sh:ShapesClass should be renamed to sh:ClassShape

Votes: DK:+0.5, HK: +0.5 (sh:ClassShape?), SS: +0.5, ericP: -1

Commments:

SS: I'm not sure about the implications of this.. (or what it actually buys us) (clarified by Dimitris)
pfps: I don't see this as different from proposal b (but I don't see the full implications of this proposal)

ISSUE-41: Property Paths

ISSUE-41: Using property paths to refer to values/types?

PROPOSAL: (Simplify syntax) Drop sh:inverseProperty and keep only sh:property to point at constraints that must have either a sh:predicate (URI) or a sh:path.

Votes: HK: +1, DK: +1, SS: +1

ISSUE-47: $shapesGraph

ISSUE-47: Can SPARQL-based constraints access the shape graph, and how?

PROPOSAL: Generally allow $shapesGraph access in SPARQL constraints as currently specified. Implementations that do not support it may report a Failure. For the built-ins, these implementations may use alternative approaches such as custom SPARQL code generators.

Votes: HK:+1, pfps: -1, SS:+1, DK: -0.5; AR: +0.5

Comments:

pfps: There is not need to require access to the shapes graph validation. All of SHACL should be specified so as to work correctly when the shapes graph is not available.
AR: conceptually all the information in the shapes graph could be injected into generated SPARQL, but that would be bulky. It would be simpler to allow access to the shapes graph.

PROPOSAL: Specify all aspects of SHACL so that they work if the shapes graph is not available when shapes are being validated.

Votes: pfps: +1, HK:-1, SS:-0, DK: +1

Comments:

HK: The ISSUE-47:_Can_SPARQL-based_constraints_access_the_shape_graph lists numerous use cases where $shapesGraph access is needed and/or helpful. A proposal that drops $shapesGraph should explain how to handle these, e.g. the rdf:Lists.
pfps: All these are cases where a particular implementation uses the shapes graph during validation. Different implementations can work differently, such as by generating the SPARQL code beforehand. Having the shapes graph being both accessible and controlling the validation process leads to the possibility of modifying the shapes during validation, with strange results.
HK: Your assessment is incorrect. Take 2.2 (Template arguments that are rdf:Lists) as an example. The SPARQL query that someone writes must know in advance how it can access the rdf:List. This cannot be changed by code generation. Also, the shapes graph can not be modified during validation, e.g. there is no SPARQL UPDATE built into SHACL. If someone changes the shapes graph outside of SHACL, then the same argument would apply to any other representation of shapes - another thread could change the Java objects, for example. Likewise, someone could change the data graph during validation. The surrounding code needs to make sure such scenarios don't happen, e.g. by copying the shapes graph into a temp graph with a private URI. The value of $shapesGraph can be any URI.
pfps: A particular way of doing templates may need this access, but it would be instead possible to construct the SPARQL from the shapes before querying starts.
HK: I would like to see how this can work for arbitrary SPARQL queries using rdf:List arguments in custom templates. I am not talking about the core built-in constraint types here.

PROPOSAL: Not all execution environments can support $shapesGraph access, just like not all platforms have to support SPARQL extensions in general. However, for those environments that do, the spec should define $shapesGraph access and clarify that it is an optional feature. Implementations that do not support it may report a Failure. For the core built-ins, these implementations may use alternative approaches such as custom SPARQL code generators but that is left as an implementation detail.

Votes: HK:+1, AR:+1, JA:+1

ISSUE-52: Abstract Syntax

ISSUE-52: Does the spec need an Abstract Syntax

PROPOSAL: Add an abstract syntax for SHACL

Votes: Labra: +1, Hsolbrig: +1, ericP: +1 (propose ShEx AST, pfps: -0.5, HK: -1, DK: 0, SS: -0.5

Comments:

pfps: I see little need for an abstract syntax. What would it add to SHACL?
HK: Doing this now will only lead to further division and distractions for something that is entirely optional.

PROPOSAL: Leave this outside of the WG for now. Time permitting, this may become a non-normative WG note.

Votes: HK:+0.5, pfps: -0.5 (a non-normative abstract syntax would be pretty useless), SS:+0.5, Labra: -0.5, Hsolbrig: -0.5, eric: -0.5, DK: +0.5

PROPOSAL: There is no need for an abstract syntax at all.

Votes: pfps:+1, HK:+1, SS:+0.5, Labra: -0.9, Hsolbrig: -1, ericP: -0.9, DK: 0

Comments:

pfps: What is the benefit of having an abstract syntax?
pfps: If someone wants an abstract syntax for SHACL they are free to prepare one without any prior endorsement by the WG. An intial document on an abstract syntax is not going to be much work.

ISSUE-57: Group cardinality

ISSUE-57: cardinalities on expressions or groups of triple constraints

PROPOSAL: Close with no action, the spec already defines qualified cardinality

Votes: DK: +1, Labra: -1

Labra: As far as I can tell, although the spec contains qualified cardinality, it is not possible to represent arbitrary cardinalities over groups in SHACL.

PROPOSAL: Close with no action, cardinality of groups are not supported by SHACL

Votes: Labra: 0

Labra: Adding arbitrary cardinalities over groups increases the complexity of the language. I would not oppose to leave it out for the first version of SHACL and to consider them for later versions.

ISSUE-61: Direction of sh:nodeShape

ISSUE-61: Direction of individual scoping: sh:nodeShape vs. sh:individualScope

PROPOSAL 1: sh:nodeShape should be replaced with sh:scopeNode which points from shape to node.

Votes: HK:+1, SS:+0.5 , AR: +1, DK:+1

Comments

AR: This is a good move since a focus node may be literal and so could not be a subject. Also the spelling matches sh:scopeClass.

PROPOSAL 2a: The sh:scopeNode triples must live in the shapes graph.

Votes: HK:+1, SS:+0.5, AR: +1, DK:+0

Comments

AR: since sh:scopeClass is in the shapes graph, sh:scopeNode should also be there. However, this requires e.g. a Linked Data application to move the triple from the HTTP payload to the shapes graph. We should describe this implication in the spec.

PROPOSAL 2b: The sh:scopeNode triples must live in the data graph.

Votes: SS:-0.5 , AR: -1, HK:-1, DK:+0

PROPOSAL 2c: The sh:scopeNode triples may live either in the data graph or the shapes graph.

Votes: SS:0, AR: -1, HK:-1, DK:+0.5

ISSUE-63: sh:hasShape

ISSUE-63: Nested shapes: sh:hasShape function versus recursive SPARQL code generation

PROPOSAL: Engines with full SHACL support must implement a sh:hasShape function (the current specification may have issues with recursion, but these are mentioned in other tickets). Some implementations may use recursive code generation as an optimization.

Votes: HK:+1, SS:+1, pfps: -1

Comments:

pfps: Before agreeing on something like sh:hasShape, we should have a viable definition of it, detailed enough to determine whether the use of sh:hasShape requires top-down evaluation.

ISSUE-65: Nomenclature

ISSUE-65: Consistency and cohesiveness of nomenclature

PROPOSAL: While not perfect, the recent editorial fixes and rewrites have sufficiently addressed this. Further inconsistencies to be treated incrementally.

Votes: HK:+1, SS:+1, pfps: -0.9

Comments:

pfps: Things are slightly better now, but I don't think that "sufficient" is the correct description of the status of the current document. I'm not going to stand by myself against closing this issue, but I am still unhappy with the SHACL nomenclature and its description. One area that was unclear the last time I looked at the SHACL document is the status of scopes and filters when shapes are used within other shapes.

ISSUE-68: Definition of Pre-Binding

Pre-binding has no formal definition in the existing SPARQL 1.1 specification, and there is no standard syntax in the SPARQL protocol to pass pre-bound variables into queries. However, most APIs provide capabilities to execute (reusable) SPARQL queries with parameters:

Jena has QueryExecution.setInitialBindings
Jena 3 also has syntaxtransforms
Sesame has Operation.setBinding (Section 4.6.3)

Together these two alone cover a wide spectrum of existing databases. The cases where these initial binding implementation do not work are typically remote query execution (SPARQL end points).

DA: MarkLogic (https://docs.marklogic.com/sem:sparql) has facilities for passing bindings into queries that would be appropriate for this use.

HK: I believe there is no viable implementation strategy without something like pre-binding. The VALUES keyword is the closest syntax but cannot handle blank nodes. In cases where bnodes are not needed, the VALUES keyword can be used as work-around. I believe we just have to specify something sufficiently formal as a requirement for engines, and leave the implementation details to the specific engines. The SHACL WG is also not the right place to work out a full specification of this (we neither have the expertise nor charter for that). However, future SPARQL versions may include such a definition.
pfps: Both Dimitris and I have SHACL implementations that do not use pre-binding. A SPARQL transformation based on templates needs some way of producing SPARQL queries from parameterized precursors but this need not look or work anything like pre-binding and does not have to handle blank nodes.
pfps: The definitions of the various pre-binding setups are extremely sketchy. The only one that has anything close to an implementable description is RDFLIB, and that one appears to be like top-level VALUES, which does not handle the examples in the SHACL spec. The description of pre-binding in RDFLIB is in the exchange over the RDFLIB issue https://github.com/RDFLib/rdflib/issues/294
DA: I think the world would benefit a lot from a standard definition of what pre-binding means. Is it like VALUES? Is it like substituting values for variables? Is it like a bunch of BINDs?
HK: A bunch of BINDs would be nice and relatively easy to specify but excludes too many use cases because it would not be valid for any "nested" elements such as UNION, GRAPH or even nested { ... } blocks.

PROPOSAL: Close ISSUE-68 defining pre-binding using eval(D(G), Replace(PrjMap(X), μ) as described in https://w3c.github.io/sparql-exists/docs/sparql-exists.html

Votes: HK: +1

Comments:

Issue 71: SHACL Endpoint Protocol

See Use Case 40: Describing inline content versus references which reads: IRIs as values in triples may be the subjects of triples that are inline or may need to be de-referenced to complete the graph. In some cases the URI must be de-referenced to perform validation; in other cases, de-referencing isn't needed or is considered too costly for a low-value property.

Contributors to this use case were Karen Coyle and Arthur Ryman. This use case was not carried forth as a requirement. In an email of 24 Jun 2015, Arthur Ryman stated "Interesting idea, but I'd prefer to defer this until after we nail down the core SHACL spec." It does appear that the core is close to being nailed down at this point.

The use case asks for a way to identify, during validation (presumably coded as such in a SHACL graph) the objects of triples that cannot be validated within the present data graph but must be dereferenced prior to validation. Whether or not they are dereferenced and validated is left to the application. Dereferencing of values is needed in those cases in which the value list is too large or too volatile to be captured in-line. (There may be other reasons than those two, btw.)

This may also be related to the I-D Accept schema proposal by Lars Svensson of the Deutsche Nationalbibliothek.

Based around the need to interact with remote sources during validation, there seem to be two interlocking needs:

to identify the validation steps that require de-referencing to be actionable
1. within that to determine if de-referencing is required or optional, and what to do if de-referencing fails
to provide the protocol that will interact with a SHACL graph to make derefencing possible.

Example:

The value on very triple with dct:subject must be an IRI.
The IRI must dereference to an external source. (probably returning a 303)
The external source must be a skos:Concept

ISSUE-78: Abstract Classes

ISSUE-78: Should SHACL support marking classes as abstract

PROPOSED: Yes, sh:ShapeClass should have an optional boolean property sh:abstract.

Votes: HK:+1, DK:+0.8, pfps: -1, SS:+1 , KC:-0.1, AR: -0.9

Comments:

pfps: the meaning of abstract is not defined, if this is defined as no RDFS instances then I might be more positive
HK: I don't care whether we interpret sh:abstract as a constraint check or not. In my longer proposal (see link) the constraint check would be "any instance of an abstract class must also have at least one rdf:type for a non-abstract (transitive) subclass of that class.". Is any of these options more acceptable to you?
pfps: No. More acceptable would be "any instance of an abstract class must RDFS belong to a non-abstract RDFS subclass of that class".
HK: I don't understand how your wording means something different than mine. As already discussed, we cannot generally rely on RDFS inferencing, only walking the superclasses is realistically possible.
pfps: If SHACL is going to be doing stuff with classes, which are defined in RDFS, then it should be abiding by the RDFS meaning of these classes.
HK: We have previously resolved that we cannot rely on full RDFS inferencing, and this situation has not changed for a small feature such as sh:abstract.
pfps: Every new use of RDFS needs a separate determination of just what needs to be done. My view is that sh:abstract deserves complete RDFS treatment, even if SHACL does not automatically use full RDFS reasoning on the data graph.
KC: I'm trying to figure out the purpose of this. The wording on sh:abstract is "should" not "must" so this is an unenforceable "best practice". It seems to me that this is more of a documentation issue, letting implementers know that SHACL treats these as abstract classes, but they could indeed be instantiated if someone found a need to do so. It just doesn't seem necessary.
pfps: I agree. There are lots of "may" and "should" in the current documents, and many of them have this problem.

ISSUE-84: Allowed IRIs

ISSUE-84: Constraint to limit IRIs of focus nodes to a given enumeration (similar to owl:oneOf)

PROPOSED: This can now be closed because we have node constraints using sh:in.

Votes: HK:+1, SS:+1, pfps: +1

ISSUE-87: Turtle File

ISSUE-87: Shall we publish RDF files for the SHACL namespace?

PROPOSED: Yes, two files, shacl.ttl and shacl.shacl.ttl as per Arthur Ryman's proposal

Votes: Hsolbrig:+1, AR: +1, DK: +1, HK: +1

PROPOSED: Yes, as a SHACL graph similar to the file shacl.ttl

Votes: HK:+1, SS:+0.5, pfps: -1, kc:-.9, Labra: -0.9, DK: -0

Comments:

SS: normative or non-normative?
pfps: The current file is too tied up with a particular implementation.

PROPOSED: Yes, in a manner that reflects only the SHACL specification, and does not codify any implementation details.

Votes: pfps: +1, HK: -1, kc:+1, Labra: +1, DK: +1

Comments:

HK: There are benefits and no harm in having a SHACL-based implementation, using its own official template mechanism, encoded in the Turtle file. For example, the declarations of arguments that belong together, and stable URIs to attach sh:sparql or JavaScript bodies to, and for attaching severity is highly desirable.
KC: once again we've got a confusion between the (a?) SHACL implementation and the SHACL language standard. We need to decide what our mission is and stick to it. It could be that we are defining both, but at this moment in time the SHACL language has not been defined but the SHACL implementation has.
HK: Even my current SHACL Turtle file is not an implementation, but describes the syntactic structure of valid SHACL documents. The fact that these are also executable is a nice side effect. The SHACL language is also supposed to be defined in the spec - no Turtle file could possibly cover all details of the spec.

ISSUE-88: sh:qualifiedValue

ISSUE-88: Should we add sh:qualifiedValue?

PROPOSED: No longer needed - sh:qualifiedValueShape can now be applied to literals too.

Votes: HK:+1, SS:+1, pfps: +1, AR: +1

ISSUE-92: additive repeated properties

ISSUE-92: Should repeated properties be interpreted as additive or conjunctive?

PROPOSED: Eric's proposal

Votes: Labra: +1, ericP: +1, iovka: +1, hsolbrig: +1, pfps: -1 (this completely changes SHACL), DK: -0.9, HK: -1, SS: -0.9

WITHDRAWN: Holger's proposal

Votes: Labra: -0.9, ericP: -0.9, iovka: ??, hsolbrig: -0.9, pfps: -1 (I don't see that this proposal speaks to the issue at hand)

PROPOSED: Arthur's proposal

Votes: Labra: -0.5, ericP: -0.5, iovka: 0, hsolbrig -0.5, AR: +1, DK: -0.5, HK: -0.5 (if this feature is optional), pfps: -1 (it's much too complex, and the usual cases can be expressed already), SS: 0

PROPOSED: No changes at all. The basic combinations in SHACL are non-additive.

Votes: pfps: +1, Labra: -0.9, ericP: -0.9, iovka: -0.9, hsolbrig: -1, DK: +1, SS: +1

PROPOSAL: Close ISSUE-92 deleting sh:partition. QCRs provide sufficient coverage of the given use cases.

Votes: HK: +1, IP: +1

Comments:

iovka: "??" vote for Holger's proposal is because I do not see how the proposal relates to repeated properties; it talks about allowing literals. Regarding Arthur's proposal, the general idea might allow to address the issue, but the fact that partitions are ordered might result in unintuitive behaviour. Also, some clarifications about the expressiveness are needed, as asked for here https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Oct/0022.html
hsolbrig: By far, our most common use case is additive and conjunctive as the default would be confusing and unnatural to our community. We could live with Arthur's proposal were the rules within the partition "Iovka's semantics" vs. "greedy"
pfps: The vast majority of my use cases are for conjunction.
HK: My proposal doesn't work stand-alone, but was a pre-requisite to enable Peter's proposal. It could be deleted.
IP: We need to de-scope in order to meet deadlines. If QCR's provide enough coverage for the use cases, then deleting sh:partition keeps the scope down without much impact on the functionality. If users will discover it to be insufficient, more support could be added in SHACL 2.0. However, if Eric feels strongly about this and could commit to finishing the partition work by early January, then we could defer this issue until then.

ISSUE-93: engine / language

ISSUE-93: SHACL engine vs. SHACL instance requirements

PROPOSAL: Close ISSUE-93 as handled by section 1.3 (Conformance) and throughout the document

Votes: HK: +1, DK: +1 (without the "and throughout the document"), IP: +1 (without the "and throughout the document")

Comments:

SS: what does ".. and throughout the document" mean in that context? That we use RFC2119 key words for specifying conformance criteria? Anyway, I think we shouldn't close that issue before section 1.3 is "finished".
DK: Agree with Simon
HK: Ok then how can we finish section 1.3 - what is missing?
IP: Section 1.3 has a "TODO: needs more work". Is this related to https://www.w3.org/2014/data-shapes/track/issues/214 or to this issue?

ISSUE-94: separate syntax and semantics

ISSUE-94: Should RDF syntax requirements be separated from SHACL semantics

PROPOSAL: Close ISSUE-94 as obsolete

Votes: HK: +1, IP: +1, DA: +1

Comments:

SS: I'm not sure whether the AS can be used to address this issue in its entirety. While it certainly helps to ".. differentiate the core semantics requirements for any SHACL implementation for the RDF specific syntax", there might be parts of the spec where there's no distinction between universal requirements and ones that are only applicable in RDF syntax.
- (However, the spec. has been significantly improved&changed over the last year.. so maybe this issue isn't relevant anymore anyway)
HK: To me, SHACL is only defined by its RDF syntax. So I challenge the value of this whole ticket.
IP: This issue is over a year old. The original example of the issue talked about sh:allowedValues which was subsequently changed to sh:in. The definition of it has changed as well. It now says: "sh:in specifies the condition that each value node is a member of a provided SHACL list.". Then, there is a definition of SHACL list. Since all RDF serialization must support rdf:first, rdf:rest and rdf:nil described in the SHACL list definition, I do not see this as a valid example of a potential issue. So, I agree with Simon that the spec has changed enough to question if the issue is still relevant. If it is, we need a different example. Further, I believe the group has agreed to use SPARQL to represent formal semantics of each constraint component. And there will now be formal mathematical definitions in the spec.
DA: I like the idea of using SPARQL to represent the semantics of the components, and of assuming that SHACL is in an RDF context, so it seems to me that this issue is now obsolete.

ISSUE-95: Template Simplifications

ISSUE-95: Proposed simplification and clean up of template mechanism

UPDATE 2016-02-26: The most recent proposals can be found on Metamodel Simplications

The two candidates (Proposal 1/Arthur and Proposal 3/Holger) have a lot in common. Differences are largely syntactic, and we could try to address them on a case-by-case basis.

TOPIC 1: Shall Constraint Types be classes or a shapes or just a plain instances?

PROPOSAL 1a: Constraint types should just be normal rdfs:Classes

Votes: HK: -1, SS: +0.5, DK: -0

PROPOSAL 1b: Constraint types should be instances of sh:ConstraintType which is a subclass of sh:Shape

Votes: HK: +1, SS: +0.5, DK: 0

PROPOSAL 1c: Constraint types should be instances of sh:ConstraintType which does not subclass anything

Votes: HK: +1, SS: +1, DK: +1

TOPIC 2: How to represent the context of constraint types

PROPOSAL 2a: Use a new property sh:ClassConstraintType sh:context sh:PropertyConstraint

Votes: HK: +1, SS: +1, DK: +1

PROPOSAL 2b: Based on 1b, use something like sh:ClassConstraintType sh:scopeClass sh:PropertyConstraint

Votes: HK: +1, SS: +0.5, DK: +0.5

TOPIC 3: How shall parameters be declared

PROPOSAL 3a: Pointing at properties directly: sh:PatternConstraintType sh:parameter sh:pattern; sh:optional sh:flags

Votes: HK: -1, SS: -0, DK: -0

PROPOSAL 3b: Pointing at instances of sh:Parameter

Votes: HK: +1, SS: +1, DK: +1

TOPIC 4: Shall we support NodeValidationFunctions

PROPOSAL 4a: Yes as outlined in Proposal 3 on the wiki page (and the current spec).

Votes: HK: +1, SS: +1, ~~DK -0.9 (for allowing any functions)~~ +1 (for limited to ASK queries only)

PROPOSAL 4b: No, every case needs to have its own self-contained SPARQL SELECT query.

Votes: HK: -1, SS: -0.9, DK: +0.8

Previous Discussion (mostly outdated) left for historical reasons

PROPOSED: Yes, as suggested in the ISSUE description. The questions of rdfs:subClassOf or sh:scopeClass could be handled in separate ISSUEs.

Votes: HK:+0.5, AR: -1, pfps: -1

PROPOSED (AR): Inject property constraint templates for all instances of sh:PropertyConstraintTemplate (instead of using sh:scopeClass). Superseded by Proposal for model simplifications.

Votes: AR:+1, HK:-1

PROPOSED (AR): Model SHACL classes without using meta-classes. Superseded by Proposal for model simplifications.

Votes: AR:+1, HK:-1

PROPOSED (AR): There are two kinds of constraints: built-in and extensions. Extensions are either native or templates. Superseded by Proposal for model simplifications.

Votes: AR:+1, pfps: +1, HK:-1

PROPOSED (AR): Proposal for model simplifications. This proposal supersedes my earlier proposals.

Votes: AR: +1, pfps: -1, KC:+1

PROPOSED (HK): Constraint metamodel draft

Votes: HK: +1, KC-1

Comments:

HK: Currently all built-ins can be expressed as templates, so there is no need to invent an artificial separation here. We can certainly call them "built-in templates", and the fact that they are templates is not relevant from the core perspective. That's why we have the separation into Core and Advanced sections. Only the Advanced sections talk about templates.
AR: We should not imply that SHACL is simply a template language for SPARQL. In fact many of the built-ins cannot be expressed using vanilla SPARQL. You have introduced custom SPARQL functions such as hasShape. SHACL has certain built-in capabilities. You are wrapping those as SPARQL functions and then claiming that they can be expressed as templates. This is more complicated that saying that SHACL has a set of built-in capabilities. We should treat the definition of a standard set of SPARQL functions as part of the SPARQL language binding. This is a more advanced topic. We need to layer the material so that SHACL users (as opposed to implementers) can understand it.
HK: Sure, but where did I say "SPARQL" above? The template mechanism merely provides a generic framework where all kinds of implementations can attach their execution logic to. For example, there can be multiple SPARQL implementations, but also multiple JavaScript frameworks with their own shx:js values. You imply that I am mixing things that are clearly separated. Please ask yourself if you would still feel this way if we removed the current sh:sparql triples out of the Turtle file, and I would keep them in the TopBraid version of this namespace only.
pfps: Most SHACL constructs are about features of single RDF nodes. This is neither forming a set nor asserting something about the set. A better division is between node constraints and set constraints. One kind of node constraint is a property path constraint which starts at a node and follows a property path to get to a set of nodes.
KC: regarding Holger's last proposal, it makes no sense to me for sh:PropertyConstraint to be a subclass of sh:MinCountConstraint. I also do not think that RDF lends itself to declaration of abstract classes, because that cannot be enforced in the open world. Although I do not fully understand Arthur's proposal, it makes more sense to me than anything else I've seen, in particular the separate consideration of node constraints and property constraints. (The latter also including values, which must be associated with properties.)
HK: FWIW Arthur's proposal also has abstract superclasses (sh:Constraint and sh:Assertion). But I need to wait for a worked out RDF file to have further input on it.

ISSUE-96: Violation IDs

ISSUE-96: Should the validation results contain stable IDs to indicate the type of violation

PROPOSED: Validation results should include an ID for each constraint type. These should align with the URIs of the templates and node validation functions in the SHACL system vocabulary.

Votes: HK:+1, pfps: -1, DK: +1 (to the idea, details are not clear atm)

Comments:

pfps: Validation results are already too complex. Adding something else just worsens the situation.
HK: We already have sh:sourceTemplate. I am not suggesting to add anything, but instructions on how to use that property. It amounts to adding a URI to every constraint type, and a sentence that these SHOULD show up in sh:sourceTemplate, so that implementations become interchangeable. We could also rename the property to sh:sourceConstraintType, to make it more independent from templates.
DK: We can reuse the existing SHACL properties for this and define more detailed mapping in a post-processing step. If we are to create a new taxonomy, instead of reinventing the wheel I suggest we look at W3C Data Quality Vocabulary and re-use or extend their metrics. This vocabulary, again re-uses existing research to define metrics e.g. http://www.semantic-web-journal.net/content/quality-assessment-methodologies-linked-data-survey
HK: Peter, I am finding your -1 vote here unnecessarily extreme. Is this really a blocker for you? With the proposed assertion/constraint type architectures we get those URIs for free.

ISSUE-97: sh:derivedValues

ISSUE-97: Shall SHACL include a mechanism to define constraints using derived values?

PROPOSED: Yes, as suggested using sh:derivedValues

Votes: HK:+1, SS:+1, DK:+0

Comments:

SS: FWIW, we have related requirements e.g. R6.5
pfps: This can already be done in the SPARQL extension, so the requirement is already met.
HK: Yes, everything can already be done in SPARQL, but this doesn't make the intent and contract clear.
SS(Since it's on today's agenda): I really want to see this approved. If required, I can provided additional use cases/scenarios that require such a property.

ISSUE-99: special cases

ISSUE-99: special treatment of rdfs:Resource and rdf:List in sh:valueClass (and possibly elsewhere)

PROPOSED: Yes, as currently specified... it's a necessary evil (note that sh:valueClass has meanwhile been renamed to sh:class).

Votes: HK:+0.5, pfps: -1

Comments:

pfps: The special cases only serve to complicate the specification. Note that there is an error in one of them.
HK: If you are referring to the extra } in the SPARQL of sh:class, then this is now fixed. Any other error? And yes, the specification is a bit more complicating by this, but how else could anyone use rdf:Lists? Also note that sh:class rdfs:Resource is an idiom for saying that all values must either be blank nodes or IRIs (you may remember that old topic...)
pfps: If lists are to have a special case then it should be something useful, and the current special case just isn't useful at all.
pfps: I put together a proposal to do a right thing for lists.

PROPOSED: Add a special construct for lists (see https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Feb/0045.html) and remove the special treatment of rdf:List.

Votes: pfps: +1, HK: -1 (these things should not be coupled)

ISSUE-99.5: handling lists and resources

ISSUE-99 has morphed to include how to handle lists and resources if they are not specially handled by sh:class and friends.

PROPOSED: No special cases for sh:class and friends. This means that Turtle lists don't validate against sh:class rdf:List and that many nodes don't validate against rdfs:Resource.

Votes: pfps: +1, HK: 0.5, DK: +1
Status: This appears to have been done in the current spec

PROPOSED: Add a construct for lists that does complete checking for standard lists, i.e., exactly one rdf:first, exactly one rdf:rest, same for the rdf:rest filler, eventually gets to rdf:nil, rdf:nil has no rdf:first or rdf:rest, and also checks the list members against a shape. See https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Feb/0045.html for more details.

Votes: pfps: +1, HK: -1 (too complex), DK: -0
Status: This really relates to ISSUE-119.

PROPOSED: Leave a list-checking construct to 3rd parties, use sh:valueShape, e.g. sh:valueShape shlist:WellFormedList.

Votes: HK: +1, pfps: -1
Comment (pfps): Shaping lists is turning out to be a common thing in what I am doing. Further, getting it right is tricky, so doing it in SHACL decreases the chances of getting it wrong.
Status: This really relates to ISSUE-119.

PROPOSED: sh:NodeKind should be extended with sh:BlankNodeOrIRI (and the two other combinations)

Votes: HK: +1, DK: +1 (I would prefer sh:NonLiteral since lists are included)
Status: This appears to have been done in the current spec.

PROPOSED: sh:NodeKind should be extended for rdf:List (assuming a suitable definition exists)

Votes: HK: 0.2, DK: +0.5, pfps: -1
comment (pfps): Right now nodekind mirrors the split in RDF. Adding a different kind of thing should be done in a different construct.
Status: This really relates to ISSUE-119.

PROPOSED: Lists are indicated using something like sh:memberShape

Votes: HK: -0.5 (prefer 3rd party), DK: -0, pfps: +1
Comment (pfps): Shaping lists is turning out to be a common thing in what I am doing. Further, getting it right is tricky, so doing it in SHACL decreases the chances of getting it wrong.
Status: This really relates to ISSUE-119.

ISSUE-100: sh:index

ISSUE-100: Specifying the order of property constraints (e.g. with sh:index)

PROPOSED: Yes, as suggested using sh:index (better: sh:order, xsd:decimals)

Votes: HK:+1, DK:+0.5, SS:+0.5, pfps: -1 AR: +0.5

COMMENTS:

pfps: Although SHACL is supposed to have a UI component, this seems too far from its main purpose to be considered to be a part of SHACL. People who care about this should propose a separate set of properties in a separate namespace for this kind of thing.
pfps: There is as of yet no specification for any non-validation uses of SHACL. Adding features to SHACL supporting something that is unknown is a bad idea.
HK: Why do we need a "specification" for non-validation uses of SHACL? There are various accepted requirements for form generation. That should be clear enough. The rest happens by customer feedback, from people who start working on implementations such as myself.
AR: this is useful for the form-building use case, but it might be better to allow floats to items can be inserted
pfps: Floats only get you a single dimension. Not all form builders work this way - consider 2D layout or forms with subforms or expandable portions.
HK: I believe what you are asking for would be handled by ISSUE-114.

ISSUE-103: Syntax simplifications

ISSUE-103: Can we further simplify the syntax of some constraint types?

PROPOSED: Yes, as suggested in the ISSUE

Votes: HK:+1, pfps: -0.5 (the suggestion is underspecified)

Comments:

pfps: The simplification appears to allow negation, etc., to be combined with property constraints. This needs to be clarified before the suggestion can be adopted.
HK: I had responded to this in an email from Nov 5. What else is missing?
pfps: I was looking for something much more detailed. All that there is right now is one example per construct.

ISSUE-104: Union ranges

ISSUE-104: Should sh:datatype and sh:class have better support for OR?

PROPOSED: Yes, as suggested in the ISSUE (use rdf:Lists for multiple options)

Votes: HK:+1, pfps: -0.5; AR: +1

Comments:

pfps: The proposed resolution allows OWL classes and other OWL syntax, but only limited OWL syntax and only in certain places. If OWL classes and syntax are to be used, then all of one of the OWL profiles should be used.
HK: The proposed resolution does not allow OWL classes - this was just mentioned as a design alternative. The proposal is about the use of rdf:Lists only, and I have now clarified this above.
pfps: If this "invisible" or is to be added it should be added wherever is it useful so that users are not tripped up by non-uniform syntax. If this can be done with few problems then it would not be so bad.
HK: This technique may apply to other built-ins too, but I would only like to vote on this specific case here, as this is backed by known use cases (schema.org, SKOS)
pfps: But that's the problem. Several cases where an object or a list is allowable *and* the list is an implicit OR. If this change is going to be made, then every case should be examined to see whether it deserves to have the same feature. Otherwise users will be tempted to use this construct in analogous places (e.g., hasValue). The basic thrust here is to improve the RDF encoding of SHACL, but RDF encodings of syntax are ugly anyway so a better approach would be to have a pretty syntax for SHACL and then set up the RDF encoding to handle the constructs from that syntax.

ISSUE-105: Defined prefixes

ISSUE-105: SHACL SPARQL constraints depend on namespaces in a graph, which is not defined

This is all about the balance between the formal requirements and a user-friendly syntax. The main issue is that the RDF standard has no proper concept of prefixes, they are an entirely syntactic concept of serializations. Custom editing tools can hide the prefixes from the user at edit-time and auto-generate them, yet for people looking at Turtle code (or stack overflow) this won't help.

(HK) Requiring full URIs or explicit (repetitive) prefix declarations in the beginning of each SPARQL query is IMHO not acceptable to users. All RDF Graph implementations that I know preserve prefixes loaded from a file and keep them accessible via an API. I believe we can exploit this. Engines always need to be prepared to receive invalid SPARQL that they cannot parse. Applications just have to copy the prefix declarations from the file where the Shapes were loaded from into the shapes graph. If they don't then it's the engine's fault. At the same time, adding an optional, cleaner mechanism that works for all serializations would not be a problem.

(Tthibodeau) You didn't raise this about Turtle or other serializations of graphs... Why not? Either it applies to both scenarios (and should get much more careful consideration), or it's not such a big deal (which I submit is the case) and it's not a problem within the SHACL arena to require fully compliant SPARQL in all cases (whether by inclusion of prefix declarations, by not using CURIes, or otherwise) which is as far as this spec goes. If a SPARQL (or SHACL) engine (TQ or Virtuoso or otherwise) has a mechanism by which it handles such undeclared but (globally or locally, commonly) used prefixes -- that's fine. If a SPARQL engine receives invalid or unparseable SPARQL, it should error out! But "predefined prefixes" should not be mandated as part of the SHACL specification. (I've adjusted the proposals below to use MAY/MUST instead of may/must, as I believe that was the intent.)

I find only a couple relevant mentions of prefix declarations in the existing spec, and no mention of sh:prefix per se.
- 6.2 SPARQL-based Native Constraints "The SPARQL queries linked to a constraint via sh:sparql must be string literals that can be parsed into legal SPARQL 1.1 queries of the query form SELECT. Before parsing, a SHACL processor must prepend PREFIX statements for all namespace prefixes defined in the current shapes graph."
- 10. Derived Values Constraints "For SHACL processors supporting SPARQL, a sh:DerivedValuesTemplate can have a value of sh:sparql. The values of sh:sparql must be SPARQL fragments that can be turned into a valid SPARQL query by surrounding it with the prefix declarations from the shapes graph and SELECT ?value WHERE { ... }. These fragments can access the current focus node via the variable $this and must produce bindings for the variable ?value for all derived values. In the example above, all values of the property ex:area must be all products of ex:width and ex:height. "

PROPOSAL 1: The shapes graph MAY include triples of the form <namespace> sh:prefix "prefix". A SHACL engine MUST prepend those as PREFIX declarations to the SPARQL queries before parsing. An error MUST be raised if any prefixes conflict.

Votes:
- HK: +1
- DK: +0.5 (switching from +1 after raised arguments in the telcos)
- pfps: +0.5 (needs significant cleanup, but goes in the right direction)
- Tthibodeau -1 (Where are the conflicts contemplated here? within the single shapes graph? or between shapes graph and SPARQL engine? or somewhere else? Also, "before parsing"? SHACL engine passes the SPARQL query to SPARQL engine -- even if the SHACL engine is doing double-duty -- so presumably this should be "before passing to the SPARQL engine.")

PROPOSAL 2: A SHACL engine MUST include the standard prefixes for rdf, rdfs, owl, sh, and xsd. Assuming PROPOSAL 1 gets approved this can be implemented by placing corresponding sh:prefix triples into the SHACL vocabulary graph which is usually owl:imported into the shapes graph anyway, so this has limited costs to the spec.

Votes:
- HK: +1
- DK: +0.5 (excluding "Assuming...") (switching from +1 after raised arguments in the telcos)
- pfps: +0.5 (same excluding) I would be happy to see some good solution to having standard prefixes, but I would also be satisfied having to put the prefixes in explicitly.
- Tthibodeau -1 (I might go as far as -0.9 if this were a SHOULD, but I'd need some convincing. Also, "usually owl:imported"? We do not have sufficient sample size to say any such thing.)

PROPOSAL 3: SHACL engines must have access to a prefix mapping for the shapes graph. This prefix mapping must include the prefixes defined in the files containing the shape definitions. Engines can use these to pre-process the triples in the shapes graph. Engines throw an error if they still cannot parse a query - in that case some step in the processing pipeline did not preserve prefixes correctly.

Comment (pfps?): Graphs don't always come with prefix mappings; it is not suitable to require that a SHACL engine has access to something that may not exist.
Votes:
- HK: +1
- DK: -0.5 (switching from +1 after raised arguments in the telcos)
- pfps: -1
- Tthibodeau -1 (A graph has no concept of prefixes. A shape definition serialization is incomplete and non-compliant if it uses prefixes and leaves out their declarations. This is and should be treated as an error condition.)

ISSUE-111: charter issues

ISSUE-111: How should the working group address the issues called out in the WG charter?

PROPOSAL 1: Close ISSUE-111 as outdated and too high-level to be actionable.

Votes: HK: +1 IP: +.5

PROPOSAL 2: Add the following wording to the Introduction section.

SHACL meets all three of the issues listed in the RDF Data Shapes working group charter. The high-level (or core) language described in Sections 2 and 4 of this document defines a declarative shape language that can be used to describe "the intended topology and value constraints of nodes in an RDF graph". Sections 5 and 6 provide extensions to that language for less-common constraints. The validation process described throughout this document defines "[v]erification of data integrity with respect to a shape". The Core Constraint Components described in section 2 and the SPARQL-based Constraint Components described in section 6 can be used to "develop or optimize SPARQL queries" for checking shape verification. They can also be used for structuring some of the information needed for developing user interfaces by adding UI-specific information to shapes and constraints, particularly property constraints.

Votes: IP: +1 (?)

Comments:

SS: Karen offered to -> "try an integration of this to the current intro.".
HK: Then we need a counter proposal to close the ticket.
IP: This issue was raised by Peter and he included a pretty concrete proposal of tying the spec to the charter by adding some language to the introduction of SHACL. I do not know to what extent it is customary/required to do so. If it is customary to tie in the charter in such way, then we should do so. This is why I am voting +1 on proposal B.

ISSUE-112: misuse of RDFS properties

ISSUE-112: SHACL uses RDFS properties in ways that violate their intended RDFS meaning

PROPOSAL a): Close ISSUE-112 replacing the use of rdfs:label and rdfs:comment in property constraints with sh:name and sh:description.

Votes: HK: 0, DK: +0.5 KC: +1, AR: +1

(kc)In documenting this, it would be good to state that these take literal values, with or without a language tag. Also, I think we'll find that many will want/need additional properties, e.g. a short description (used for a mouse-0ver popup) and a long description, for a full explanation of the human-understandable rules for the property and value in a UI. Because exactly what people will need is not predictable a priori, could there be a discussion of how this can be extended as needed?

PROPOSAL b): Close ISSUE-112 continuing with rdfs:label and rdfs:comment

Votes: HK: 0.5

PROPOSAL c): Close ISSUE-112 replacing the use of rdfs:label and rdfs:comment in property constraints with dct:title and dct:description (from DCMI Metadata Terms)

Votes: DK: +0.5 KC: -0.5

(kc)While flexible in their use, dct:title and dct:description are more generally used to describe information resources, not properties. I have a preference that we not extend dct for non-information resources, although there is precedent. YMMV.

ISSUE-114: Property Groups

ISSUE-114: Should SHACL include a grouping mechanism of properties (for UI purposes)

PROPOSED: Yes, as suggested in the ISSUE (or a similar variation)

Votes: HK: +1, DK: +0.5

ISSUE-121: # in graph name

ISSUE-121: Should the SHACL owl:Ontology include the # character

PROPOSAL 1: No

Votes: HK: +1

PROPOSAL 2: Yes

Votes: HK: -0.9

ISSUE-129: Existential constraints

ISSUE-129: Existential constraints should be consistent

ISSUE-133: syntax

ISSUE-133: syntax simplification and regularization

Topic 1: Shall it be legal to have constraint components appear multiple times within the same constraint

THIS HAS ALREADY BEEN DECIDED, basically saying yes.

PROPOSAL 1a): No, all constraint parameters can only appear once

Votes: HK: 0, DK: -0.5, pfps: -1, kc: -.5, JRA: +.1

Comment (pfps): Requiring once-only makes many useful constructs much more verbose
comment kc: not sure how often this happens
comment JRA: not sure what requirement is met by the potential redundancy, what would be easier to express?

PROPOSAL 1b): Yes, for all, even if it doesn't make sense, the engines could give a warning to the user or even optimize. Multi-argument constraints are treated with a combinatorial approach.

Votes: DK: +0.5, HK: 0, pfps: -1, kc: -.5, JRA: -.5

Commment (pfps): A combinatorial approach ends up producing many surprises.
comment kc: not sure what this does that is surprising, but surprises are not good
comment JRA: not sure the repeated constraint would make sense in all cases, why would we want to support the potential confusion?

PROPOSAL 1c): Yes, for all single argument constraints only, even if it doesn't make sense. The engines could give a warning to the user or even optimize. Multi-argument constraints (e.g. sh:pattern) are not allowed on the same group and SHACL suggests to be placed in separate property groups.

Votes: DK: +1, HK: +0.5, pfps: 0

Comment (pfps): This is acceptable, but it is much better to eliminate the multi-argument components.
Comment kc: don't understand what "single argument constraints" are if we are talking about a constraint occurring more than once.

Topic 2: components may only consist of one property (parameter)

THIS HAS ALREADY BEEN DECIDED, saying No.

PROPOSAL 2a) Yes and use rdf:Lists or objects for cases with multiple values

Votes: HK: -1, DK: -0.5, pfps: +1

PROPOSAL 2b) No, leave it as currently designed

Votes: HK: +1, DK: +1, pfps: -0.5, JRA: +1

Comment (pfps): Multi-component components end up complicating everything. The syntax is more complex; implementations are more complex; the meta-model is more complex. That's probably all not so bad, but multi-component components place an extra burden on users who have to piece together the component components. The situation is akin to a programming language that requires the arguments for function calls to be spread around the calling function and only makes the call if all the arguments are specified.

Topic 3: splitting `sh:constraint`

A1 HAS ALREADY BEEN DECIDED, spawning off sh:sparql.

PROPOSAL A1: simplify sh:constraint and make it link to only sh:nodeConstraints, SPARQL constraints will linked with a new property e.g. sh:sparqlConstraint

Votes: DK: +1, HK: +1, pfps: 0, kc:-.5

Comment (pfps): This is a small step forward. Eliminating default value types as per Dimitris's proposal would be good as well.
Comment kc: not clear what a "node constraint" is

PROPOSAL A1b: close issues 110 & 134 by accepting this proposal

Votes: DK: +1, pfps: -1

Comment (pfps): Issue 100 is already closed. This change does not speak to Issue 134.

rename sh:constraint

PROPOSAL A2a: rename sh:constraint to sh:node

Votes: DK: +1, HK: 0.2, pfps: 0, kc -.5

comment kc: (everything is a node, even things we are not constraining)

PROPOSAL A2b: rename sh:constraint to sh:self

Votes: DK: +1, HK: -0.5, pfps: +1, kc -1

comment kc: too programmy.

PROPOSAL A2c: rename sh:constraint to sh:this

Votes: DK: +1, HK: -0.5, pfps: +1, kc -1

comment kc: too programmy.

PROPOSAL A2d: leave it as is (sh:constraint)

Votes: DK: -0.5, HK: 0.7, pfps: 0, kc: 0

Comment (HK): The property may be dropped altogether, see topic 4

find a property name for SPARQLConstraints

PROPOSAL A2e: rename sh:constraint to sh:constraintSet

Votes: kc +.9

A constraint is very singular in English, but you can have a set of constraints.

PROPOSAL A3a: use sh:sparqlConstraint

Votes: DK: +0.8, HK: +0.5, pfps: -0.5 (no other linking property uses "constraint" in its name)

PROPOSAL A3b: use sh:sparql (and rename the existing sh:sparql to sh:sparqlQuery)

Votes: DK: +1, HK: +0.5, pfps: 0

PROPOSAL A3c: use sh:sparql (and rename the existing sh:sparql to sh:select and sh:ask)

Votes: HK: +1

PROPOSAL A3d: use sh:native (to make more general for other native constraints in the future, e.g., javascript)

Votes: DK: 0, HK: -0.5, pfps: -0.5

PROPOSAL A3e: use sh:scriptConstraint (as suggested in the concall)

Votes: DK: 0, HK: -1, pfps: -0.9

Topic 4: merging `sh:Shape` and `sh:NodeConstraint`

See thread at https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0197.html

PROPOSAL 4a: delete sh:constraint and sh:NodeConstraint, use sh:Shape instead

Votes: HK: +1, pfps: 0
comment JRA: SHACL is intended to specify constraints and (descriptive) metadata for graphs containing nodes and edges. It therefore makes sense for there to be graphs of constraints on nodes (shapes) and constraints on properties (property constraints, including inverse). Names should be chosen to be consistent with what is being constrained: graph, resource, property --> graph ResourceShape, PropertyShape (since we have to have the word shape in there), or NodeShape/PropertyShape, or NodeConstraint/PropertyConstraint. This is essentially identical to OSLC ResourceShapes 3.0 and has worked well in practice. What SHACL can add is combining constraints into more complex expressions, constraint inheritance (for ResourceShape and PropertyShape), and extensibility.
comment DK: Jim, it is not clear what you suggest here, are you suggesting 1) only delete without renaming 2) delete & rename sh:Shape to sh:ResourceShape / sh:NodeShape or 3) delete & rename sh:property to sh:shapeProperty
comment JRA: it's just a comment, not a proposal.

PROPOSAL 4b: delete sh:and (its job will be done by sh:Shape/sh:shape)

Votes: HK: +1, pfps: -0.5 (sh:or without sh:and?)

PROPOSAL 4c: delete sh:classIn and sh:datatypeIn (use sh:or)

Votes: HK: +1, pfps: 0

PROPOSAL 4d: introduce sh:Union/sh:OrConstraint as suggested here: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0236.html

Votes:

ISSUE-135: and/or syntactic sugar

ISSUE-135: Should sh:and/sh:or/sh:not/sh:valueShape support constraints too?

PROPOSAL: Yes, the values of sh:and, sh:or and sh:not may also be constraints.

Votes: HK: -1, pfps: +0.5, ericP: 0, labra: 0

Comments:

pfps : Why stop here? Why not let every component that takes a shape also permit a constraint? That would further shorten quite a few constructs. Stopping here further complicates the syntax, and the syntax is already too complex.

PROPOSAL: ANDs, ORs, and property constraints are composed into triple expressions. A shape has a triple expression (likely an AND) and can have other attributes to be decided upon separately, e.g., a CLOSEDness flag, and a list of open properties (like QCRs) like in ShEx.

 clin:AdmissionForm a sh:shape; sh:closed true;
   sh:expr [ a sh:And ; sh:exprs (
     [ sh:predicate clin:givenName ; sh:nodeKind sh:Literal ]
     [ sh:predicate clin:familyName ; sh:nodeKind sh:Literal ]
   ) ].

The abstract syntax (very close to the ShEx Jason representation) defines the legal constructs:

 shape : openProperties* CLOSED? tripleExpression?
 tripleExpression: allOf | someOf | tripleConstraint
 allOf : tripleExpression tripleExpression+                    # Passes if all tripleExpressions pass.
 oneOf : tripleExpression tripleExpression+                    # Passes if exactly one tripleExpression passes.
 tripleConstraint : INVERSE? predicate valueExpression min max # Passes if the number of matching triples is between min and max.
 valueExpression : NEGATED? (valueConjunction | valueDisjunction | valueConstraint)*
 valueConjunction : valueExpression valueExpression+           # Passes if the value (S or O) passes all of the valueExpressions.
 valueDisjunction : valueExpression valueExpression+           # Passes if the value (S or O) passes some of the valueExpressions.
 valueConstraint : nodeKind? datatype? shape? valueSet? XSfacet*

While the grammar for ShExC valueExpressions is complex to restrict to the reasonable intersections of node kinds, nested shape constraints, value sets and XS facets, the AS permits non-satisfiable combinations like a literal with a shape or an IRI with a datatype.

Votes: ericP: +1, labra: +1, pfps: 0 (this is a major refactor of the syntax, I think)

ISSUE-136: Property pair names

ISSUE-136: Can we clarify the names of property pair constraint types?

PROPOSAL: sh:equalProperty, sh:notEqualProperty, sh:lessThanProperty, sh:lessThanOrEqualProperty

Votes: HK: +1, DK:+1, pfps: -1

PROPOSAL: sh:equalValue, sh:notEqualValue, sh:valueLessThan, sh:valueLessThanOrEqual

Votes: HK: -0.5, DK: -0.5, pfps: -1

PROPOSAL: existing naming: sh:equals, sh:notEquals, sh:lessThan, sh:lessThanOrEqual

Votes: DK: +0.5, HK: -0.5, pfps: -1

PROPOSAL: only change notEquals: sh:equals, sh:disjoint, sh:lessThan, sh:lessThanOrEqual

Votes: pfps: +1

Comment (pfps): notEquals means disjoint and should be so-called.

Comment (pfps): adding Property to the names makes it look like it is the properties that are supposed to be equal/whatever; adding Value is better

Comment (HK): We have external evidence that the current names are not intuitive. Leaving them as-is is IMHO not a good idea. I am OK with using "disjoint" in the names, but then rather sh:disjointProperty. "Value" does not work for me because it's then similar to sh:hasValue, i.e. people would expect these parameters to point at specific values, not properties.

ISSUE-137 Missing constraint for language tag

"Some constraints require comparing language tags of RDF literals, e.g., to check that no language is used more than once per property."

Examples of language tag constraints:

In SKOS, there can be only one prefLabel per language tag
Constrain the valid language tags to a provided set, e.g. (@en, @de, @fr)
Require that all literals have/do not have a language tag
Require that a particular property have a set of literals, one each language tag, e.g. "there must be 3 instances of dct:abstract; the values must be literals; there must be one literal for each valid language code (@en, @de, @fr)"
Check that the language tag is { 2-letter | 3-letter | does/does not have hyphens }
Check that the 2- or 3-letter tag is valid (according to ISO, localized list, or otherwise)

ISSUE-138: Property constraints as lists

ISSUE-138: Should property constraints use rdf:Lists?

PROPOSAL: No, keep current syntax (see item 25 at https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0106.html)

Votes: HK: +1, DK: +1, pfps: -1, SS: +1, KC: -1

PROPOSAL: Yes, switch to rdf:Lists where the first list entry is a property or inverse property, and the other items are shapes

Votes: HK: -1, DK: -0.5, SS: -1, KC:+1

Comment (pfps): Currently constraints use a complex mechanism for determining their meaning. Explicit types, default value types, direct types, indirect types, and the incoming link all play a part in this determination. This makes for a complex, hard-to-understand, and error-prone syntax.

Comment (HK): I don't see what your comment has to do with ISSUE-138, and why it motivates a -1. Once again you are putting the "beauty" of the metamodel over the user experience. As I said many times the algorithm to determine the meaning is in fact quite easy.

Comment (KC): I don't care if the algorithm is easy or not - I care whether this is easy for humans. I agree with Peter that all of the various types make it more likely that people will be confused and will make mistakes. If SHACL is this difficult, though, my assumption is that most people won't try to use it at all. The beauty of the metamodel can make a big difference to users.

ISSUE-139: Universal applicability

ISSUE-139: Can all constraint properties be applied in all scenarios?

Topic 1: Applicability

PROPOSAL 1a: No (e.g. see items 11,12,13 at https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0106.html)

Votes: HK: +1, pfps: -1, SS: +1, DK: -0.5, KC: -1

Comment (pfps): There are lots of bits of SHACL that are silly but not forbidden. For example, the conjunction of a shape with itself or the conjunction of a shape with its negation. Allowing, for example, a sh:datatype in an inverse property constraint might be considered to be silly, but that is not a good reason to forbid it. Further, allowing an sh:datatype in an inverse property constraint is future-proofing (and even now-proofing) the case where a triple store allows literals as subjects. SPARQL itself allows literals in the subject position of triple patterns.
Comment (HK): Your arguments are extremely weak. I cannot see how you can rationally justify a -1 vote here. The recent RDF 1.1 WG explicitly decided against literals as subjects, no RDF 1.2 is in sight and such a change would force a cascade of other changes breaking applications around the world. Also you are comparing apples with oranges. Interpretation of useless conjunctions at least does not require different behavior of the engine (as for the three constraint types). Anyway, there is no point in having a further discussion if you refuse to acknowledge problems such as those listed in my email. For example how on earth does sh:closed make sense for property constraints, and how would it be implemented? How would a random SPARQL extension make sense in all three cases?
Comment (DK): All programming languages allow people to do silly things; we have compilers, IDEs and static analysis tools to identify what is silly and what not. But, we should provide the (SHACL) language with hints on how to identify such silly definitions.
Comment (KC): this issue is not just about allowing illogical functions to be described. The limitation of min/maxCount to predicates is one where a desired function is not allowed but should be.

PROPOSAL 1b: Yes (a single implementation for each constraint component that works in all contexts. No default, no overriding, no wrong context, etc.)

Votes: DK: +0.5

Comment (DK): As mentioned above I think we need to give hints to the engine on what makes sense and what not so I am in favor of keeping the context as explicit information in the component.

PROPOSAL 1c: as proposal 2 but require to state the contexts that always produce errors or the contexts that do not (as it is now)

Votes: DK: +1

Comment (KC): This may be fine, but we need to define the contexts that are valid and those that are not. If the definitions remain the same as they are today, then that is not acceptable because they do not meet user needs.

Comment(HK): I am ready to change my votes on this topic if the outcome of Topic 2 provides similar expressivity as proposal 2a, and if there is a standard design pattern for extension developers to indicate whether a constraint component applies to node constraints and/or property constraints.

Topic 2: Boilerplate Macro injection for SPARQL

PROPOSAL 2a: Similar to this email using something like $this $PATH ?value, with $PATH being replaced with the path or statement to operate on focus nodes.

Votes: HK: +1, DK: -1

Comments(DK): this introduce a lot of magic on how the SPARQL query is altered for execution, I would rather use $path as a pre-binding variable with a union for node constraints

Topic 3: Size of value nodes set for node constraints

Node constraints currently are expected to operate on sets of size 1, containing one focus node at a time.

PROPOSAL 3a: Shall we change the meaning of node constraints so that they apply to the set of all in-scope nodes at once, allowing set operations such as minCount?

Votes: HK: -1

ISSUE-141: Mixed ranges

ISSUE-141: How to represent mixed datatype-or-class ranges

See Issue description for details. Note that the discussion about this has morphed into a general redesign of sh:class and sh:datatype, not only for mixed ranges. So the ISSUE description should only be regarded as one example among others.

PROPOSAL 0: Do nothing

Votes: HK: -0.5, DK:+1, SS: -0.5, pfps: +1

Comments:

pfps: This is better than any of the proposed changes.

(Other proposals have been withdrawn)

PROPOSAL 3: Unify sh:class and sh:datatype into sh:type, use sh:typeIn for mixed ranges. See specific options below.

Comments:

pfps: This has some benefits but I don't see them as overwhelming. As well, there is the problem of identifying which of the entries are classes and which are datatypes.

PROPOSAL 3a) The meaning of sh:type would be identical to the current sh:datatype if the parameter value is a known datatype (either a system RDF datatype or has rdf:type rdfs:Datatype), otherwise use sh:class semantics.

Votes: HK: +1, SS: +1, pfps: -0.5, jamsden: +0.9, Dimitris: -0.9

PROPOSAL 3b) The meaning of sh:type would be identical to the current sh:datatype if the parameter value is a built-in RDF datatype (xsd:string, rdf:HTML, xsd:boolean, etc), otherwise use sh:class semantics.

Votes: HK: +0.5, pfps: 0 (acceptable but not ideal), Dimitris: -1

PROPOSAL 3c) If the value node is a literal, then the datatype of this literal must be $type. Otherwise (IRI/bnode) use sh:class semantics.

Votes: HK: -0.8, pfps: +1, Dimitris: +0.8

Comments:

HK: a) was my original choice but has a performance and complexity problem with user-defined datatypes that are hardly ever used (and not well supported by SPARQL anyway). b) resolves this by limiting itself to the well-known datatypes. c) may work in practice but the logic seems inverted - it would for example allow "a"^^owl:Class. c) would need to be combined with sh:nodeKind to be safe.
pfps: What performance issues? Oh, maybe a SPARQL implementation might have a slightly longer query. That doesn't appear to be significant. Proposal 3b requires stating what the well-known datatypes are, which can cause problems if they change.
HK: Yes, performance is not a show stopper here. What worries me more is that it becomes harder to take a "static" look at the shapes graph and determine what is going on without also taking a look at the declared rdfs:Datatypes in the data graph. Under what conditions may the built-in RDF datatypes change? We could add a clause to state that future versions of SHACL would track the evolution of RDF (1.2 etc), although I don't think any further work on RDF is planned right now. I don't see user-defined datatypes widely adopted anywhere, and thus believe we should skip them (in the Core vocab).
DK: If we get to choose one of 3*, 3c is the best choice. 3a requires the datatypes definitions to exist in one graph (which one?), 3b does not allows other datatypes besides the standard ones. 3c in combination with sh:nodeKind can cover all use cases
HK: Updated preferences to 3a because several people had use cases for user-defined datatypes. Updated my vote on 3c because this would force a combination with sh:nodeKind each time, and this is neither user-friendly nor algorithm-friendly nor efficient.

ISSUE-148: Scope declaration simplification

ISSUE-148: non-uniform syntax in scopes

PROPOSAL 1: close issue with no action (as defined in spec)

Votes: DK: +0, pfps: -1

Commment (pfps): The current syntax makes an unwarranted distinction between class scoping and predicate scoping. As these two act similar, they should look similar.

PROPOSAL 2a: for propertyScope and inverse property scopes, do not use sh:scope but the dedicated properties sh:scopeProperty and sh:scopeInverseProperty that point to a property directly. e.g. ex:shape sh:propertyScope ex:myPredicate .

Votes: DK: +0.5, pfps: +0.8, HK: +0.5

Comment pfps: The names should be changed to something like sh:scopePropertySubjects
Comment HK: The names should be sh:scopeProperty and sh:scopeInverseProperty - sh:scopeClass also points at a Class
Comment DK: correct, I updated the property names

PROPOSAL 2b: for all subject/object scopes, do not use sh:scope but the dedicated properties sh:allSubjectsScope and sh:allObjectsScope that have a boolean as value. e.g. ex:shape sh:allSubjectsScope "true" .

Votes: DK: +0.5, pfps: +0.8

Comment pfps: The names should be changed to something like sh:scopeAllSubjects

PROPOSAL 2c: for all subject/object scopes, use sh:scope but simplify the syntax and use sh:AllSubjects and sh:AllObjects as direct values. e.g. ex:shape sh:scope sh:AllSubjects

Votes: DK: +0.5, pfps: 0

Commment pfps: The previous syntax is better

PROPOSAL 3: Delete AllObjectsScope and AllSubjectsScope from Core.

Votes: HK: +1, DK: -0.2, KC: +1, pfps: +1 (as long as they just go away)

ISSUE-150: Treatment of nested severities

Example 1:

ex:TopShape a sh:Shape ;
 sh:property [ sh:predicate ex:p1 ;
               sh:severity sh:Warning ;
               sh:valueShape ex:OtherShape ] .

ex:OtherShape a sh:Shape ;
 sh:property [ sh:predicate ex:p2 ;
               sh:severity sh:Info ;
               ... ] ] ;
 sh:property [ sh:predicate ex:p3 ;
               sh:severity sh:Violation ;
               ... ] ] ] .

Proposal 1: Take into account only the top severity and ignore all nested severities even if top severity is not defined (default to sh:Violation), so the severity above is always sh:Warning.

Proposal 1a (current situation): Only produce a validation result if the nested severity is sh:Violation, so a violation from the ex:p2 constraint will never produce a validation result for ex:TopShape (and would not produce a validation result even if the severity of the top shape was sh:Info).

Proposal 1b: Only produce a validation result if the nested severity is not lower than the top severity.

Proposal 2: Take into account only the child severities and ignore the top one, so the severity above is either sh:Info or sh:Violation.

Proposal 3: Take into account only the top severity only if the child severity is lower, otherwise use the child severity, so the severity above is either sh:Warning or sh:Violation.

Proposal 4: Do away with severities.

ISSUE-160: Generalizing sh:valueShape into sh:shape

ISSUE-160: Generalize sh:valueShape

PROPOSAL: Rename sh:valueShape to sh:shape, add sh:NodeConstraint to its context.

Votes: HK: +1

ISSUE-170: exists blank nodes

ISSUE-170: SPARQL specifies a different reading for exists and blank nodes than needed for SHACL

(Awaiting input from SPARQL EXISTS CG, but we can remove this dependency with the following proposal, because only the 4 mentioned definitions use EXISTS)

PROPOSAL 1: Close ISSUE-170, removing the SPARQL Definitions of sh:languageIn, sh:uniqueLang, sh:closed and sh:hasValue for now. We can bring them back once the SPARQL EXISTS CG has produced a document. Our remaining usage of EXISTS is in the templates of the section about ASK Validators. This is an unnecessary implementation detail that can be deleted as implemented here: https://github.com/w3c/data-shapes/commit/66729cf836cdb25bba87a54127609e2624953b61

Votes: HK: +1, DA: +1

PROPOSAL 2: Close ISSUE-170 by using SPARQL CG recommendation as described https://w3c.github.io/sparql-exists/docs/sparql-exists.html#an-alternative-to-substitution

Votes: IP: +1

Comments:

DA: I have to say, I'm not happy with this resolution. I really like using SPARQL as a means for precisely defining what SHACL means. I a unsure whether this really is a SPARQL issue, or even more fundamentally an issue with how blank nodes in RDF are defined (i.e., as existential quantifiers)

But unhappy as I am, it seems as if the plan is indeed to bring these definitions back in, in due course. In the interest of getting the CR underway, this is an acceptable compromise.

ISSUE-175: rename `scope`

ISSUE-175: Rename term scope

Proposal 1: Do not change, scope / in-scope are fine

Votes: DK: +0.5, HK: 0, KC 0, TT -0.9

Proposal 1a: Keep "scope" for the general concept in the text, but change in-scope to "selected" or "selected node" and say that the scope "selects". Change the wording in 2.1 in this way:

Was:

Scopes specify which nodes in the data graph are considered in-scope for a shape and SHACL includes four core scope types: node scopes, class-based scopes, property scopes, and inverse property scopes.
The SHACL language additionally defines a general scoping mechanism based on SPARQL.
When multiple scopes are provided in a shape, the scope of a shape is the union of all in-scope nodes produced by these scopes. In addition to the explicit scoping mechanism, a shape may get an implicit scope when it is mentioned from other shapes (e.g. in shape-based constraint components). Nodes specified by scopes are not required to exist in the data graph.

to:

The scope defines which nodes in the data graph are selected to be compared to the SHACL constraints. SHACL includes four ways to select the node or nodes in the data graph: select by node; select by class; select by property, select by inverse property. (I don't know what the next sentence means, about general scoping, so dropping that here for the moment.)
When multiple scope definitions are included in a shape, the selected node in the data graph is the union of all included scope definitions. In addition to the explicit definition of the selection of nodes in the SHACL scope statement, the selection of nodes can be further defined by the constraints in the SHACL graph. If the nodes defined in the SHACL graph by the scope statement do not exist in the data graph, no action is taken.

Votes: KC + 1

Proposal 2a: Use select / selected instead of scope / in-scope. The existing properties would be renamed to sh:selectNodes, sh:selectInstancesOf, sh:selectObjectsOf, sh:selectSubjectsOf

Votes: DK: +1, KC 0, TT +0.8, HK: -0.5

- KC: The equivalent of "scope" would be "selection" not "select" (I'm reading "scope" as a noun). But there is a difference in how you would use selection: "The scope of shapeA is a nodeX" "The selection of shapeA is nodeX". "The select of shapeA is nodeX". None of those work. You have to have say "shapeA has the selection nodeX" - still not very sensible in a sentence. Now, if we thought of "scope" as a verb and used it as "scope by" then we could substitute "select by".

Proposal 2b: Use selector instead of scope / in-scope. The existing properties would be renamed to sh:selectorNode, sh:selectorClass, sh:selectorObjectsOf, sh:selectorSubjectsOf

- KC: This interprets "scope" as being "has scope", so "selector" would be "has selector". That makes sense, but "selectorNode" does not. The selector IS a node? The selector is selecting a node? Conceptually you are selecting BY (or A) node, class or predicate. But running "selector" and "node" together doesn't say that. The predicates could be simply sh:byNode, sh:byClass, etc.

Votes: HK: +1, DK: +0.5, TT -0.5

Proposal 3: Use collect / collected instead of scope / in-scope. The existing properties would be renamed to sh:collectNodes, sh:collectInstancesOf, sh:collectObjectsOf, sh:collectSujectsOf

Votes: DK: +1, HK: -1, KC -.5, TT -0.9

Comments:

DK: I like select more but with collect we avoid any possible confusion with SPARQL select
HK: I generally don't like verb forms (sh:select being an exception because it points at a SELECT query)
KC: predicates ARE verbs, there's no getting around that; that's their role in grammar. Dictionary def: "the part of a sentence or clause that expresses what is said of the subject and that usually consists of a verb with or without objects, complements, or adverbial modifiers". in RDF it's the statement of a relationship, and it therefore has a verb-like role: X (is in relationship B with) Y. I don't go along with folks who precede every predicate name with "has" or "is", but that is grammatically correct.
HK: In the RDF world, predicates are usually not verbs. The most established practice for naming properties is that the term is implicitly assumed to be surrounded by "has X" or "is X of". Examples include schema.org (schema:address, schema:givenName, schema:email), Dublin Core (dct:creator, dct:subject, dct:date), FOAF (foaf:name, foaf:age, foaf:interest), RDFS/OWL (rdfs:subClassOf, owl:equivalentClass). SHACL also uses this convention for all other property names. Using the term "selector" thus is consistent and establishes terminology if a passive form is needed, e.g. "the selector of shape X is the class Person".
KC: Holger, "predicate" means "verb" (plus some other similar stuff). It doesn't matter that many vocabularies do not use a "has" or "is" - they are predicate forms. (I can bring along a vocabulary of 900-1000 terms that all have "has" and "is" so there is no one rule that is followed). But the key thing is that a "thing" cannot be a predicate, and "selector" reads like a "thing" - so you have to understand how terms are used and what they mean to people. "Trigger" can be used either in a noun or verb form ("it is a trigger" "you trigger something") so people will pretty much get the meaning of "triggering." But if you have <X> <dog> <Y> it isn't going to read well for most humans. It also isn't clear if the meaning is "is dog" or "has dog". Predicates tend to be qualities, conditions, states of being. Dog would be a lousy predicate. Selector is not as bad, but it is not a good predicate.
HK: I had enumerated plenty of examples from the most widely used namespaces in RDF that all use nouns as predicate names. Every noun can be turned into a "verb" by pre-pending "has". Yes, some people esp from OWL DL background, use hasAddress or hasDog, but that is in my experience the minority, and even there they use a noun (address) instead of livesIn. Object properties are sometimes called "role" because they describe the role that an object plays for a subject, e.g. ex:parent is a typical property name. Anyway, I think from all given options, "target" would be best. It can even be used as a verb form and nicely states that a shape is targetted at certain classes, nodes or objects.

Proposal 4: Use trigger instead of scope / in-scope. The existing properties would be renamed to sh:triggerOnNode, sh:triggerOnInstancesOf, sh:triggerOnObjectsOf, sh:triggerOnSubjectsOf

Votes: DK: +0.5, HK: +0.5 (this vote for version without "on" only) KC -.9, , TT -0.9

Proposal 5: Use target instead of scope / in-scope (suggested by James Anderson). The existing properties would be renamed to sh:targetNode, sh:targetInstancesOf, sh:targetObjectsOf, sh:targetSubjectsOf (sh:targetClass?)(kc)

Votes: DK: 0, HK: +1 kc +.5, TT +0.5
- (kc): I don't recognize the "instancesOf" "objectsOf" "subjectsOf" properties. Are those new?

Comment: (KC) other possible English language terms: pick, choose, choice, option

ISSUE-177: abstract-syntax-disconnected

ISSUE-177: Abstract Syntax is disconnected from concrete syntax

PROPOSAL 1: Close ISSUE-177 by making abstract syntax a more focused document or appendix to spec. Move useful explanatory prose and examples into spec.

Votes: HK: -0.5, SS: +1, DK: +1, IP: 0

PROPOSAL 2: Close ISSUE-177 with no change before CR. Abstract syntax is currently not on the recommendation track. If WG has sufficient time and resources after reaching CR milestone and sees value in it, abstract syntax could be updated to become a more focused document, better sync up with the spec and be published as a WG note.

Votes: IP: +1, HK: +1

Comments:

IP: Do we really need the formal mathematical definitions ala Peter's proposal AND the abstract syntax? Having both seems like doing extra work that we do not have resources for. With this, I believe that the resolution of this issue is dependent on the resolution of ISSUE-216: [Editorial Shall we switch to the (mathematical) style of definitions suggested by Peter?].
HK: My impression/expectation is that the Abstract Syntax will be dropped altogether.

ISSUE-179: label annotations

ISSUE-179: Should SHACL include a mechanism to specify display labels?

PROPOSAL 1: Close ISSUE-179 adding sh:labelFunction as outlined in the summary of the issue

Votes: HK: 0.5, SS: -0, IP: 0

PROPOSAL 2: Close ISSUE-179 as out of scope (and out of time), e.g. leave it to Community Groups

Votes: HK: 0.5, SS: +1, IP: +1 DA: +1

IP: I think it is a useful feature, but at this point we must be ruthless about keeping the scope in check

ISSUE-181: partial validation

ISSUE-181: SHACL conformance for partial validation reports

PROPOSAL 1: Close ISSUE-181 as covered by section 3 of the current spec (Only SHACL implementations that can return all of the mandatory properties of the Validation Report Vocabulary are standards-compliant.) Others may of course only return partial results.

Votes: HK: +0.5, IP: +.5

PROPOSAL 2: Replace "After validation, SHACL processors MUST return a validation report containing all validation results." with '"After validation, SHACL processors MUST be capable of returning a validation report containing all validation results. Implementors may support optional parameters that limit the number of returned results".

Votes: IP: +1, DA: +1, HK: +1

Comments:

SS: Jose stresses that use cases like UC34: Large-scale dataset validation require that "the validation engine must be flexible enough to provide different levels of the violation result details.".
SS: In section 3 of the current spec we also say that: "After validation, SHACL processors MUST return a validation report containing all validation results.".
- SS: Would a SHACL processor that stops its validation process after the first encountered violation be standards-compliant if the validation report it's returning contains all validation results produced so far?
HK: We do not define any interface (in the sense of an API) to start validation. If we had such an API then we could define parameters and expected results. Without it, I believe such things can be left unspecified and basically be features of specific implementations.
IP: I don't think this has to be an issue. SHACL implementation must be able to return all mandatory properties. To me, this means that if an implementation wants to add some custom parameters that direct it to return only the first n results, it is OK as long as it can return all results if this parameter is not set. If a user when dealing with a large dataset decides to use this parameter and set it to 1, they can do so. Is there any need to change the language to indicate that this is the case? As in '"After validation, SHACL processors MUST be capable of returning a validation report containing all validation results. Implementors may support parameters that allow users to limit the number of returned results".
DA: It seems to me that this issue concerns itself with performance-limited implementations. As a spec, we should be describing the perfect behavior, without reference to performance. In the real world, of course, performance is an issue, and any implementation can choose to limit processing to keep inside performance specs.

ISSUE-182: Clarifications needed to section 3.0

PROPOSAL: Close ISSUE-182 as addressed by the current spec (https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0056.html)

Votes: HK: +1, DA: +1

Comments:

IP: Is this issue only/mainly about section "3.4.2 Validation Result (sh:ValidationResult)"? If so, I think it still needs some work. It is not clear if the section is normative. If it, it is not clear what are the required fields and what are optional. I would like to see the section use "MUST" and "MAY". As to how the values for the property sh:value are figured out, I am not sure that belongs in the spec. The spec needs to say what they are. If this will cause too many back and forth to resolve, we may want to consider dropping something from the ValidationResult - in the interest of time.

DA: Looking at the spec now, it seems that the MUST/MAY wording that Irene asked for is now present. It seems to me that this should have been closed when that edit was made.

ISSUE-194: valueStem

ISSUE-194: stems in value sets

PROPOSAL 1: Close ISSUE-194 keeping sh:stem as is

Votes: HK: +0.5, DK: +0, IP: +0.2

PROPOSAL 2: Close ISSUE-194 deleting sh:stem as rather useless (it is a short cut for sh:pattern which supports the use of regular expressions)

Votes: HK: +0.5, DK: +0.5, IP: +0.5

PROPOSAL 3: Close ISSUE-194 adopting Eric's more comprehensive proposal

Votes: HK: -1, IP: -.5

Comments

DK: I was missing from the telco and did not see Eric's proposal but I would put a minus to something that complicates the existing design
IP: We need to de-scope where possible, so deleting looks slightly more attractive

Karen said she couldn't figure out how sh:step used with multiple values and asked for an example saying that dct:subject must have a value that is the stem of any one of the following: http://id.loc.gov/subject/ http://en.wikipedia.org/ http://dbpedia.org/. Here it is, but I made it a bit more complex by also saying that the value must exist. This was motivated by Karen saying that all the examples are too simple. May be someone could post an example of how this would be expressed if sh:stem was removed.

sh:property [
		sh:predicate dct:subject ;
		sh:minCount 1 ;
		sh:or (
			[
				sh:stem "http://id.loc.gov/subject/”;
			]
			[
				sh:stem "http://en.wikipedia.org/”;
			]
			[
				sh:stem "http://dbpedia.org/”;
			] ) ] .

using sh:pattern instead of sh:stem doesn't look that much different, but is a bit more verbose especially if flags have to be added:

sh:property [
		sh:predicate dct:subject ;
		sh:minCount 1 ;
		sh:or (
			[
				sh:pattern "^http://id.loc.gov/subject/”; sh:flags = "i";]
			[
				sh:pattern "^http://en.wikipedia.org/”; sh:flags = "i";
			]
			[
				sh:pattern "^http://dbpedia.org/”; sh:flags = "i";
			] ) ] .

ISSUE-197: Defined

ISSUE-197: "Defined" and "declared" used in multiple ways, and not defined

PROPOSAL: Close ISSUE-197 as resolved by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0130.html

Votes: HK: +1

ISSUE-198: rdf:langString

ISSUE-198: rdf:langString not included in datatypes

PROPOSAL: Close ISSUE-198 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0083.html and https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0094.html

Votes: HK: +1, DK: +1, KC: -1

Comments:

KC: There is still a contradiction between the definition in the terminology section and the treatment of language strings in the datatype section. The first refers to RDF definitions, the second to SPARQL functions. They must both refer to the definition in the SPARQL documentation.
HK: I find the RDFS spec contradictory. In one place it calls rdf:langString a datatype IRI, and it also states that each literal has a datatype. So at this stage I cannot see a difference between the SPARQL and the RDF definition.

ISSUE-201: node target

ISSUE-201: how does node target specify targets for a shape?

PROPOSAL: Close ISSUE-201 as addressed: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0079.html

Votes: HK: +1, DK: +1

ISSUE-202: Remove pre-binding from core

ISSUE-202: Suggestion to remove pre-binding from core

PROPOSAL: Close ISSUE-202 as explained in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0080.html

Votes: HK: +1, DK: +1, IP: +1

Comments:

KC: Does this affect how the core interacts with full? If full uses pre-binding and full implements the core... what does that mean?
HK: These are unrelated. SHACL Core does not need pre-binding, it's just used as one possible implementation strategy of the built-in constraint components. They may also be simply hard-coded in Java, or we may simply define all constraint components without SPARQL.

ISSUE-203: Constraint components

ISSUE-203: Constraint component is an IRI

PROPOSAL: Close ISSUE-203 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0112.html

Votes: HK: +1, KC: -1, IP: +1, DA: +1

Comments:

KC: The language "A constraint component has an IRI" does not appear in the spec. Where was this change made?
HK: This was further rewritten (by Dimitris) and can now be found as "Constraint components have an IRI which is used,..." in section 2.4. It's sometimes hard to keep track of a moving document, but at the same time we need to continue address things as they come along.

ISSUE-204: Constraint node

ISSUE-204: Fourth node is unclear

PROPOSAL: Close ISSUE-204 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0113.html and a number of subsequent edits that make the issue obsolete

Votes: HK: +1, IP: +1, DA: +1

ISSUE-205: Validation report

ISSUE-205: Section 1.4 - graph is the result of validation

PROPOSAL: Close ISSUE-205 as already addressed by the recent introduction of sh:ValidationReport and the corresponding edits by Dimitris

Votes: HK: +1, DK: +1

ISSUE-207: Parameters

ISSUE-207: Parameter descriptions for constraint components

PROPOSAL: Close ISSUE-207 as addressed, see https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0115.html

Votes: HK: +1, DK: +1

ISSUE-208: $this

ISSUE-208: $this in aggregations

PROPOSAL: Close ISSUE-208 as addressed by https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0027.html

Votes: HK: +1, KC: -1, IP: +1, DA: +1

Comments:

KC: Peter's response to that email was: "I don't think that the new wording conforms to that used in SPARQL, so there are still changes required."
HK: The wording (use of "project") was fixed later and replaced with the terminology ("return") that the SPARQL 1.1 spec uses. His other response was about removing the sentence of Aggregates which had become redundant, and I have now removed that, too: https://github.com/w3c/data-shapes/commit/773a55edd846f905bf80f1885e48c68d091fd081 . His response is very cryptic and I didn't get a direct response to what I asked.

ISSUE-209: What is a shape

PROPOSAL: Close ISSUE-209 as addressed by https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2

Votes: HK: +1, KC: -1

Comments:

KC: Nothing in the email thread to indicate that Peter thinks that his question has been answered. In particular this, this and this.
HK: I have no idea what our formal process to answer Peter's many emails is supposed to be. My assumption is the WG prepares a response and if the WG members are sufficiently happy then we can close the tickets. There is no requirement that we have to agree with everything that Peter says, neither do we need to wait for formal responses (although this would be kind and helpful). Otherwise we'd make it too easy for anyone to block progress until they get exactly what they want.

ISSUE-210: Expected type

ISSUE-210: value types and expected types

PROPOSAL: Close ISSUE-210 as addressed by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0116.html

Votes: HK: +1, DK: +1

Comments:

KC: Once again, we haven't heard back from Peter on this. I don't think we should close his issues without hearing from him.
DK: Karen, I think this should go the other way around. Non-WG members raise comments, the wG creates issues when needed, we resolve the issues and respond back. Hearing back for approval in a nice to have but not a requirement.

ISSUE-212: Property constraints

ISSUE-212: Property constraints and focus node constraints

PROPOSAL: Close ISSUE-212 as resolved by https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0129.html and replace the term "focus node constraint" with "shape" throughout the document.

Votes: HK: +1, KC:-1

Comments:

KC: To begin with, this is not just a matter of replacing the words "focus node constraint" with the word "shape". There is an entire section on focus node constraints. To continue, as I say here, this is a change that was added in August, and now is proposed to be removed, and I think we're piling changes on changes to the point that it is necessary to step back and look at the whole.
HK: Replacing the term needs (of course) be accompanied by slight restructuring work where needed. We need to look at the flow between the sections on Constraints and those on Shapes. They do have graph-like cross-references, which makes it a non-linear document but that's unavoidable with any design.

ISSUE-211: Eliminate property constraints

(OLD) PROPOSAL: Close ISSUE-211 as already discussed (extensively) and too late for such a fundamental change, see https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0117.html

Votes: HK: +1, PM: +1

Comments:

KC: To what extent were Arthur's proposals implemented? this
HK: Arthur's proposal was an intermediate step that served as input to my consolidated "compromise" proposal later. This was a very long discussion indeed.
PM: I too think that the proposed change, though interesting, is too fundamental at this point in time to consider.

PROPOSAL 1: Adopt a variation of Peter's suggestion as described in this thread. The new metamodel diagram is here. A re-write of the spec from Peter for his original proposal is here, the proposed variation is a small addition there.

Votes: DK:+1, HK: -1, PM: -1, ericP: +1

Comments:

HK: We are out of time. This would be a fundamental redesign, requiring a substantial change to terminology, invalidating many previous resolutions, requiring updates to implementations and thus invalidating all previous user experience. We would be violating principles of a proper process if we made such a change a few weeks before reaching CR status. It feels more like last minute panic. The current design is not broken. This is driven by speculation that it may solve some questionable soft targets over which there can be multiple opinions.
HK: Our tooling requires the ability to distinguish shapes and property constraints because they can have different attributes (e.g. only shapes can have sh:closed, only property constraints can have sh:minCount). I had only accepted a compromise on ISSUE-139 (see https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jul/0062.html) because I assumed that we keep the separation. Making this other change now would be very unfair to these previous resolutions.
HK: I believe the current design of having shapes (comparable to classes) and property constraints (comparable to attributes) is easier to explain to users because it resembles OO and XML Schema. It is unnecessary for property constraints to also have sh:targets, adds to the complexity (more things to check, more variations to express the same things). This is significantly adding to the implementation costs, likely degrade performance and add to the general complexity of working with the SHACL metamodel, e.g. to drive user interfaces and other algorithms.
PM: This is, in my opinion, the only practical vote that I can come to that makes sense time wise. I find the proposed change interesting, and if there was more time left, I would definitely find it worth exploring. But taking the current time frame into account, and the (re-)discussions that this will bring, let alone the (for me) unclear impact for non-validation goals like UI/form generation and similar SHACL-based data exploration activities that are being developed, I would vote -1 and propose to continue to work with the current metamodel towards making CR.

PROPOSAL 2: Generalize targets so that they apply to all shapes. Rename sh:PropertyConstraint to sh:PropertyShape. Rename its abstract superclass from sh:Constraint to sh:AbstractShape. Use the term "constraint" to refer to the use of parameters such as sh:minCount.

Votes:

HK: +1

The following is a spin off from the more general topic, not a complete solution but an intermediate step. This would not exclude making further changes.

PROPOSAL: Turn sh:property and sh:sparql into constraint components as described in https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Dec/0062.html

Votes:

HK: +1

ISSUE-213: Finding shapes

PROPOSAL: Close ISSUE-213 because it is a duplicate of ISSUE-209

Votes: HK: +1, DK: +1, KC: -1

Comments

KC: They are not duplicates, they are two different problems with shapes. One (209) is from Peter's email of October the other (213) from November. We should at least ask Peter if he sees these as addressing the same issue.
DK: In Peter's mail the problem was with the sh:hasShape function that is now removed

ISSUE-215: parameters with a value type that is a datatype

PROPOSAL: Replace "In a shapes graph, the non-literal values of a property or a property path can have an expected type." with "In a shapes graph, values of a property or a property path that are required to be non-literal can have an expected type."

Votes: IP: +1, DA: +1

Comments

IP: The relevant definition is "The values of sh:minCount are literals with datatype xsd:integer." I think this issue is now entirely obsolete since the definitions of each core constraint component have been significantly redone using input from Peter Patel-Schneider. All the wording about "expected type" is no longer there.

ISSUE-216: Shall we switch to the mathematical style of definitions

ISSUE-216: [Editorial Shall we switch to the (mathematical) style of definitions suggested by Peter?]

For example:

Given f a focus node, {v1,...,vn} a set of value nodes, D a data graph, s a shape, and S a shapes graph any results graph for a sh:ClassConstraintComponent constraint with mandatory parameter values <sh:class,c> is a combination of some multiset Template:R1, ..., rn where ri is the empty RDF graph if vi is a SHACL instance of c and ri is a validation result for f, vi, s, the path of s in S if present, the severity of s, and sh:ClassConstraintComponent

PROPOSAL 1: Yes, the entire spec should be written in this style

Votes: HK: -0.5

PROPOSAL 2: No, we should minimize the use this style

Votes: HK: 0

PROPOSAL 3: Yes, place all the formal definition into one section at the end of the spec, but keep the first sections as descriptive tutorial style.

Votes: HK: +1

Comments

ISSUE-217: Path vs predicate clean up

ISSUE-217: Further clean up of paths versus predicate

PROPOSAL 1a: Limit sh:path to blank nodes, i.e., its values must be paths, not predicate IRIs.

Votes: HK: +1, DK: -0.2, IP: +.5

PROPOSAL 1b: Delete sh:predicate and keep only sh:path since all sh:predicate values can already be represented by sh:path

Votes: DK: +1, HK: -0.7, IP: -.5

Advantages of 1a:

Potentially easier to understand for end users
Easier to query in cases where we are only interested in property declarations:
{ ?node sh:predicate ?predicate }
versus
{ ?node sh:path ?path . FILTER isIRI(?path) }
Better suitable for sh:Parameter declarations (which do not accept paths) - sh:Parameter is a subclass of sh:PropertyShape.
This syntax has been in production for a long time. All examples, tools, tests and tutorials will continue to work.

Advantages of 1b:

Potentially cleaner because properties are just a special kind of path
Easier to ask "is this node a property constraint?":
FILTER EXISTS { ?node sh:path ?any }
versus
FILTER EXISTS { ?node sh:path|sh:predicate ?any }

PROPOSAL 2a: Rename sh:resultPath to sh:resultPredicate and limit it to IRIs.

Votes: HK: +1, DK: -0.5, IP: 0

PROPOSAL 2b: Delete both, sh:path and sh:resultPath

Votes: IP: +1

Comments:

DK: we should either keep both or delete both
HK: there is already a difference: SPARQL constraints can only ever return predicate IRIs, not paths. I think the cost of creating and specifying sh:resultPredicate is very low, and it is required for sh:closed to pinpoint the actual predicate that is violated. Apart from that I could live with dropping both.

Retrieved from "https://www.w3.org/2014/data-shapes/wiki/index.php?title=Proposals&oldid=3893"

Proposals

Contents

Process

Open Issues

Closed Issues

ISSUE-22: Treatment of recursive shape definitions

ISSUE-23: Shapes as Classes

ISSUE-41: Property Paths

ISSUE-47: $shapesGraph

ISSUE-52: Abstract Syntax

ISSUE-57: Group cardinality

ISSUE-61: Direction of sh:nodeShape

Comments

Comments

ISSUE-63: sh:hasShape

ISSUE-65: Nomenclature

ISSUE-68: Definition of Pre-Binding

Issue 71: SHACL Endpoint Protocol

ISSUE-78: Abstract Classes

ISSUE-84: Allowed IRIs

ISSUE-87: Turtle File

ISSUE-88: sh:qualifiedValue

ISSUE-92: additive repeated properties

ISSUE-93: engine / language

ISSUE-94: separate syntax and semantics

ISSUE-95: Template Simplifications

TOPIC 1: Shall Constraint Types be classes or a shapes or just a plain instances?

TOPIC 2: How to represent the context of constraint types

TOPIC 3: How shall parameters be declared

TOPIC 4: Shall we support NodeValidationFunctions

Previous Discussion (mostly outdated) left for historical reasons

ISSUE-96: Violation IDs

ISSUE-97: sh:derivedValues

ISSUE-99: special cases

ISSUE-99.5: handling lists and resources

ISSUE-100: sh:index

ISSUE-103: Syntax simplifications

ISSUE-104: Union ranges

ISSUE-105: Defined prefixes

ISSUE-111: charter issues

ISSUE-112: misuse of RDFS properties

ISSUE-114: Property Groups

ISSUE-121: # in graph name

ISSUE-129: Existential constraints

ISSUE-133: syntax

Topic 1: Shall it be legal to have constraint components appear multiple times within the same constraint

Topic 2: components may only consist of one property (parameter)

Topic 3: splitting sh:constraint

Topic 4: merging sh:Shape and sh:NodeConstraint

ISSUE-135: and/or syntactic sugar

ISSUE-136: Property pair names

ISSUE-137 Missing constraint for language tag

ISSUE-138: Property constraints as lists

ISSUE-139: Universal applicability

Topic 1: Applicability

Topic 2: Boilerplate Macro injection for SPARQL

Topic 3: Size of value nodes set for node constraints

ISSUE-141: Mixed ranges

ISSUE-148: Scope declaration simplification

ISSUE-150: Treatment of nested severities

ISSUE-160: Generalizing sh:valueShape into sh:shape

ISSUE-170: exists blank nodes

ISSUE-175: rename scope

ISSUE-177: abstract-syntax-disconnected

ISSUE-179: label annotations

ISSUE-181: partial validation

ISSUE-182: Clarifications needed to section 3.0

ISSUE-194: valueStem

ISSUE-197: Defined

ISSUE-198: rdf:langString

ISSUE-201: node target

ISSUE-202: Remove pre-binding from core

ISSUE-203: Constraint components

ISSUE-204: Constraint node

ISSUE-205: Validation report

ISSUE-207: Parameters

ISSUE-208: $this

ISSUE-209: What is a shape

ISSUE-210: Expected type

ISSUE-212: Property constraints

Topic 3: splitting `sh:constraint`

Topic 4: merging `sh:Shape` and `sh:NodeConstraint`

ISSUE-175: rename `scope`