Talk:Requirements

Association of Class with Shape

The language needs to include an easy-to-use vocabulary to state that a given property is associated with a class, e.g. to populate input forms with appropriate widgets but also constraint checking.

• Status: Under consideration
• Derived from: S3, S10, S11, S12, S13, S15, S19, S20, S29, S36
• Votes: HK, DTA, SSt:0.5, ericP:-0.5, labra: -1
• Comment (pfps): What does it mean that a property is associated with a class? RDF does not have anything like this.
• Answer (HK): RDF does not have this yet, but many user stories express the desire to have a way to tell agents which properties are recommended/required to be used for instances of a given class, e.g. to create input forms.
• Answer (HK): I am open to that, if we can come up with an agreement on what Shape means. I am for example perfectly happy to have these "classes" untyped and anonymous nodes, i.e they are just some resource where constraints can be attached to. But the term "class" must be a subset of "shape" then, and here we re-enter a discussion that we didn't conclude on a few weeks ago.
• Answer (HK): This particular item here (Declaration of Member Properties at Classes) is really just a grouping parent for the more specialized requirements below. By itself, it doesn't have a condition that could fail, but it is rather a structural design principle that is needed to organize constraints.
• Comment (SSt): Supporting this requirement as being a "grouping parent req." as HK mentioned.
• Objection (labra): I would also agree if we change class by shape or a similar term. I mean, constraints don't need to be attached to classes and we should be able to specify constraints about RDF nodes independently of their rdf:type. I added a new requirement that could cover the case of attaching constraints to instances of some class here.
• Objection (ericP): I like the title of the requirement but I think the description assumes classes are shapes. PROPOSE There will be an property to connect a class to a shape, with the implication that every RDF representation of an instance of that class must conform to that shape.
• Comment (labra): I would vote +1 to Eric's proposal
• Comment (hs): I also vote +1 to Eric's proposal. An obvious and common use of shapes would be the ability to say that all elements of type X should conform to shape S, but we also need to support the ability to define shapes independent of the associated type.
• Comment (HK): See ldom:ShapeSelector on a mechanism that doesn't require hard-coding a property that links a class with a shape. So I think this can generalize Eric's proposal further.

Property Labels at Shape

It should be possible to provide human-readable labels of a property in the context of a shape, not just globally for the rdf:Property. Multiple languages should be supported.

• Status: Proposed
• Derived from: S11, S19
• Votes: HK, ericP:0, pfps:-1, SSt:0, KC+1, AR: +1
• Comment (pfps): I would need some indication of how this is a constraint before I would vote for it. I also do not understand what rdf:Property is doing here.
• Answer (HK): This is not a constraint in the sense of a checkable condition. However, the goal of this spec is to provide *structural* constraints and labels and comments are structurally useful for building user interfaces and documenting the intent of a property.
• Comment (SSt): So basically, if property P is used within a constraint C for class C1 and within a constraint C' for class C2 one should be able to define labels for its representation in C as well as C' (which might differ from each other)?
• Answer (HK): Yes. An example would be ex:code to have label "ISO code" in class 1 and just "code" in class 2.
• Objection (pfps): This doesn't seem to have anything to do with constraints. I think that this can be covered for constraints by having descriptive messages coming from constraint violations.
• Answer (HK): Again, this will become clearer once we look at specific solution languages. If the language has a mechanism to attach properties to classes (such as oslc:property) then it makes sense to reuse the same (blank) node to also hold the label - from a user's point of view.

Property Comment in a Shape

It should be possible to provide human-readable descriptions of the role of a property in the context of a shape, not just globally using triples that have the rdf:Property as subject. Multiple languages should be supported.

• Status: Proposed
• Derived from: S11, S19
• Votes: HK, pfps:-1, KC+1, AR: +1
• Comment (pfps): I would need some indication of how this is a constraint before I would vote for it. I also do not understand what rdf:Property is doing here.
• Answer (HK): See my answer on labels above. With rdf:Property I was referring to triples that have the property itself as the subject, e.g. ex:name rdfs:label "name". Clarified above.
• Comment (pfps): This doesn't seem to have anything to do with constraints. If it is retained, it should be possible to have comments on many bits of the language. I think that rdfs:comment should be used for this purpose.
• Answer (HK): Again, this will become clearer once we look at specific solution languages. If the language has a mechanism to attach properties to classes (such as oslc:property) then it makes sense to reuse the same (blank) node to also hold a comment - from a user's point of view.
• Comment (HK): A good example of why this is needed is DCAT. This reuses many properties from external namespaces such as Dublin Core, but needs to override the global rdfs:comment at those properties with local text. Currently these local comments only live in the HTML spec of DCAT, but cannot be used in form builders etc. Schema.org is another example where the same property URI is used in several classes. Not having such a facility would limit what form builders can do.

Expressivity: Transitive Traversal of Properties

Some constraints need to be able to traverse a property transitively, such as parent-child or partOf relationships.

• Status: Under consideration
• Derived from: S16, S23, S26
• Votes: HK, pfps, SSt:+1, KC+1, labra: -0.5, ericP: -0.5, DK: +1
• Comment (labra): I am not sure if this is about adding some kind of inference or just traversing a property as in SPARQL property paths.
• Answer (HK): This is about SPARQL property paths only, no inferencing in the sense of adding triples.
• Objection (labra): It should be more clear it we are talking only about "Transitive property traversal" or general property paths as in SPARQL. Adding general property paths could increase too much the complexity of the solution as is described in this paper.
• Answer (HK): The ticket is only mentioning transitive property traversal, so I believe you can withdraw your objection. Having said this, I currently expect the group to agree on SPARQL for the formalism, so the actual specification may include any SPARQL-based path.
• Comment: is this a proposal that the core language have a way to express that a particular property is traversed? If not, can't we leave that to the inferences that produce the graph over which validation is performed, as we would all of the other possible RDFS or OWL inferences?
• Answer (HK): We cannot rely on inferencing to be available in general. If inferencing is activated on the graph level then we can no longer distinguish between direct and indirect neighbors. Other properties than rdfs:subClassOf are needed here. Clearly I have SPARQL property paths in mind here.