Meeting minutes
phase 1 deliverables
elianaP: response to the tag review
<AndyS> detailed agenda -- https://
nicholascar: quickly mentioning the overall picture: looking over the responses
… mostly have nothing to do, as some of the issues were already closed
… there is one were we have to do something but we'll come to that later
list of old PRs
elianaP: ajnelson-nist any infos on that?
ajnelson-nist: nothing new since last week
… was working on profiling stuff
… still some stuff to do on them
elianaP: there were also 2-3 from vladimir, not sure if something remains to be done on them
… or whether those were related to compact syntax by any chance
TF updates
HolgerK: I would appreciate some feedback on the PR (link above)
… uniqueValuesFor -> you can provide a single propery or multiple ones where the combination of all these values must be unique
nicholascar: makes sense, all instance of that class have this value
HolgerK: You just said "instances" — that's one of the hairy points I'm unsure about. Whether we have to limit this to all the other target nodes of the shape, or whether this should be applied globally, wherever this predicate is used. The algorithm becomes much more complicated if we limit it to the target nodes of the shape, because the
… constraint could be reached indirectly from a node constraint, and then it's unclear what the target nodes are
nicholascar: That's how I read it. So your target class of "record" would mean only records need to have a unique ID field. You might have records 1–70, you might have chickens 1–7. But the shape's only going to see records as being unique within the scoping of that node shape, right?
ajnelson-nist: But what happens if a chicken and a record have the same ID value?
HolgerK: It doesn't matter, because the node shape's only looking at records - or whatever subjects of that class - and the other one's looking at chickens or whatever. So it's only unique within that scope. That's how I initially read it, Holger - but are you saying that's actually harder than the global case?
HolgerK: because you just have to do basically a join to see if the value is already used elsewhere with the same predicate. The problem is that this would be the first constraint that actually depends on the target declaration of its surrounding shape. I don't think we have this anywhere else. Which is why I'm a bit nervous about it. Saying that
… this only applies to instances of the class is of course an easy case, but it's not always that easy - it could be a totally different target, a target node with a node expression, or whatever.
nicholascar: Speaking from my own experience with vocabularies: we use skos:notation over and over again as the uniqueness/literal-binding predicate. What defines the uniqueness is the context it's in - a concept scheme or something like that - which a node filter could handle. It could say "just look at the ones in here" - e.g. target objects of
… skos:inScheme for this concept scheme, for instance, would do it.
simonstey: so if you have multiple properties, it's a set? so no order?
HolgerK: yes
AndyS: if it's a list and so it's a composite key, the order does matter doesnt it?
HolgerK: Well, they would have to show up with exactly the same predicate and the same object. And then it's a set again
… so I don't see how order matters there.
AndyS: You don't know they're unique in that sense, because you haven't got a constraint that they only occur once. And if you're going to make a list for bad data, I think you would get duplicate keys
… but that may not matter to you. What I was going to say is: if it's complicated about what it applies to, maybe there should be another predicate to give some kind of scoping. Or to say it only applies to nodes which are acting in the target role
… because they may be linked to as well, and hence their target is irrelevant. Something like "it has to be a target node" or similar.
nicholascar: we have couple of PRs that have been under review, and I merged it about 10 seconds ago
… the main PR we wanted to get through is through and it's unofrtunately pulled out all these errors that we made in our unfinished profiles vocab
… conceptually it's all fine, but need to clean things up
… we have 2-4 more use cases to appear. I actually rejected a UC which was not about profiling but actually SHACL rules
… We've also got a small conceptual issue to do with all the things you might benefit from having done SHACL validation on. If you have a data graph and you run a test and show that it's valid, our contention is that you can then assert in your own graph that that data graph
… conforms to that shapes graph
… But we don't actually have a class for "data graph" or "shapes graph." We've been doing this informally, using IRIs of graphs to identify them
… but that's an underspecified object
… If it's a file without an ID, it's a local ID that doesn't mean anything externally. If we've got a system with a named graph in it, we can say that graph conforms to that shapes graph
… but that's not good enough. We actually need more ontology to say this properly. We need objects called DataGraph and ShapesGraph. We have definitions for them
… what we need to do is that we have a few bits of ontology in SHACL Profiling that have been entirely borrowed from elsewhere: "isDefinedBy", "conformsTo" etc. But in some cases, "conformsTo" from Dublin Core is not actually ontologically strong enough for what we need. So I think we're going to need to make a small vocabulary
… it would give you just enough ontology to describe the outcomes of validation, so you can record: "this thing is valid against that thing." What is "this thing"? It's a chunk of RDF. What is "that thing"? It's a set of SHACL shapes
<ajnelson-nist> https://
ajnelson-nist: link above is for a "private" project for profiling
edmond: we have the scoring now in a PR
… mainly, we've been discussing how to move forward with SHACL UI in terms of how flexible and how modular we should make it
… with the idea to align with SHACL core without validation processes
… e.g. you give it a set of inputs and there is an expected set of outputs
… we'll have a look at the SHACL profile work
AndyS: there is a proposed meeting this week
… for SHACL Rules
… features and Service description are additional features to the spec not do you implement them or not
… there are very few exceptions to what people have implemented
… there is some proposed work to do
… [more discussion]
AndyS: two PRs, one is editorial the other one an algorithm from david
… we probably won't be able to close all issues that are marked rules
ajnelson-nist: one of the profiles that we had considered a while ago was about profiles of SHACL based on computational complexity
… applies to nodeexpr too
… have you done some complexity analysis like big O complexity for the features of rules?
AndyS: don't know about SHACL SPARQL, but you're off to lalaland anyway, because it's SPARQL
ajnelson-nist: so are you suggesting to hold off on having a profile for comp. complexity for now?
AndyS: I don't think it's helpful to have a profile for all of SHACL
… e.g. maybe you could combine core+sparql for the comp. cost of valdation
nicholascar: or maybe just one for SHACL Core, forget nodeexpr, SPARQL, rules, etc.
… I've got a thing that only allows certain kinds of functions that are known to be runnable. Here's my profile of SHACL Core that doesn't do X, X1
… And in fact, most of the time we don't bother with RL either - we just use RDFS. So that's the kind of thing I'm thinking about. And what I want to know is: does the community actually implement things this way? Yes, at least some of them do.
compact syntax
nicholascar: got in contact with Jesse and told him we need to have scope by the middle of the month
… and shell of the document by the end of the month
… and by the end of April we need substantial work to be done
elianaP: if anyone wants to support the editor of the CS document, please get in touch
nicholascar: more impacts coming through as Alex finds faults in the Dataset Exchange outputs, but they're fairly straightforward to fix. What I've been doing is creating tickets against the Profiles Vocabulary and so on for the things we're discovering
… they just go in there, and that means when that work starts, it'll be an easy win to just address those things.
… And if the profiling work has come up with additional ontology and things like that, I see no reason why that more generic profiling document wouldn't say "by the way, this is how it's done in SHACL"
discussing tag review
<nicholascar> TAG review of Core for actioning: w3ctag/
nicholascar: the dervied properties feature mentions that it introduces its own inferencing and reasoning capabilities.
… we suggest the summary is recised to avoid giving the impression that SHACL defines new semantics of hidden inferencing -> so I'll leave that to the core group to address
AndyS: you also asked the RDF and SPARQL WG for review.. what do you exactly want from them?
nicholascar: well, we're duty bound to ask
AndyS: there haven't been changes that would affect the way SHACL is used
… but if you want feedback to specific features you have to link to them