See also: IRC log
<scribe> scribenick: hsolbrig
<Arnaud> PROPOSED: Approve minutes of the 21 January Telecon: http://www.w3.org/2016/01/21-shapes-minutes.html
<pfps> look good to me
RESOLUTION: Approve minutes of the 21 January Telecon: http://www.w3.org/2016/01/21-shapes-minutes.html
arnaud: uc&r draft was republished
... last week we agreed to publish the SHACL draft pending minor editing of issue 23
aryman: what is echidna?
arnaud: a simplified document publishing mechanism, republishing is automatic once initial doc is in
... I think that the spec is in better shape than last week.
pfps: I think it is now above the "frost heave in the road for working draft"
arnaud: once text is deleted, eric will press the button and we'll see what happens
... we will try to advertise as much as possible for comments.
<pfps> It's worth opening 119 (although it may not end up having any effect on the spec)
<Arnaud> issue-119
<trackbot> issue-119 -- Defining constraints on (values of) rdf:Lists -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/119
<aryman> @ericP go ahead and push the ECHIDNA button
arnaud: Propose we open issue 119 and wait until simon is back to discuss
<Arnaud> PROPOSED: Open ISSUE-119
<hknublau> +1
+1
<Dimitris> +1
<Labra> +1
<TallTed> +1
<pfps> +1
<aryman> +1
<kcoyle> +1
RESOLUTION: Open ISSUE-119
<Arnaud> issue-120
<trackbot> issue-120 -- The spec must be more precise and consist about when a resource is a shape, a class, and an instance of a class -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/120
<pfps> also fine to open
aryman: This arose out of issue 23, how do you decide whether a resource is a class, shape or instance of a class.
... We need to be precise about what we are looking for and in which graph.
<ericP> aryman, ack -- https://www.w3.org/TR/2016/WD-shacl-20160128/ published
aryman: is this something that the editors can resolve?
<ericP> (ARG, should really be http:)
<ericP> (i'll see if we can fix those URLs in the notification email)
aryman: In general we're looking in the data graph, except issue 23, then we're looking in shapes. If no objections, the default is the data graph except shapes graph on issue 23...
arnaud: Propose that we let the editors take a pass and then check for agreement and raise specific issues if disagreement.
<pfps> fine by me to have the spec edited and then see whether the new version is acceptable
<Arnaud> PROPOSED: Close ISSUE-120 as editorial, once doc is updated specific issues may be raised
<pfps> +1
<hknublau> +1
+1
<Labra> +1
<aryman> +1
<Dimitris> +1
<kcoyle> +1
RESOLUTION: Close ISSUE-120 as editorial, once doc is updated specific issues may be raised
arnaud: next item is test suite.
arnaud: what is the status, where do we stand, what needs to be done?
pfps: Test harness was somewhat broken, may be fixed...
... ... stupid java logging problems ...
... ... can't push into repository ...
... ... no process for approving tests.
ericp: need pfps github login in order to enable push
... need logins of everyone that wants to push
arnaud: proces -- didn't we agree on free-for-all for the time being?
... followed by batch approval and then a more formal process.
pfps: Issue if a lot of the tests fail in existing implementation
... If you have a test that fails in current implementation, someone should be notified and there should be followup - either fix test or implementation
... Difficult to figure out what is going on if I download and get a whole bunch of failures...
... ... don't know where the problem lies.
<Zakim> ericP, you wanted to add traits to mark controversial behaviors
pfps: If someone proposes a test and it fails, it should trigger alarm bells so it can be resolved.
ericp: ShEx tests are peppered with lots of "traits" (sht:trait). Intent is to help with implementation reports...
... ... a way to get a handle on what they should be testing.
... ... an annotation that will aid with the issue you are dealing with.
... Wiki to record annotation types, actual annotation into test itself.
arnaud: If there are questions, should we use github issues?
pfps: Issues are completely open and any random person can file.
ericP: How big an issue is the riff-raff writing issues?
... When we go from free-for-all to controlled, do we want github to enforce that?
arnaud: I don't we need that level of formality.
... ericP will put together the wiki page.
pfps: trying to find some way to run SHACL when someone pushes a test. Have to set up a server to do this -- some people use AWS, but don't know how to do that. Someone would need a world accessible machine...
arnaud: Could W3C do this?
ericP: Systems team is gun-shy about acquiring services...
arnaud: looks like we'll have to do without this for time being.
... close test suite item.
<trackbot> issue-23 -- Shapes as classes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/23
arnaud: can we close 23 and adopt the text that is in the spec now?
pfps: While I still find this repugnant, it has reached the epsilon acceptability level...
<aryman> http://w3c.github.io/data-shapes/shacl/#definition-of-implicit-scopeClass
<Arnaud> PROPOSED: ISSUE-23, adopting the proposed text in the spec, regarding the "inferencing" of the scopeClass triple when it points to itself
aryman: I believe that the current definition is precise. We can improve on wordsmithing later...
... ... does not say inferencing anywhere
<pfps> PROPOSED: In the case where a shape is also a class, a SHACL processor MUST include all the instances of the class in the scope of the shape, exactly as if an explicit sh:scopeClass triple was present. An explicit sh:scopeClass triple is not required but MAY be included for clarity.
aryman: .. and (I believe) makes Holgar happy because it doesn't require an explicit scopeClass
<hknublau> +1
<hknublau> (and add Close ISSUE-23 to it)
<pfps> that's what "exactly" is exactly for :-)
ericP: So this is two ways to do the same thing -- hide it in a type arc or have an explicit scopeClass triple?
<TallTed> +1
<kcoyle> +0
<Dimitris> 0-
<pfps> -0.5 (which is not an objection)
<Dimitris> it is more confusing for the users than the implementers
ericP: makes it more difficult for consumers, people who are inspecting schemas "What are the shapes that this must conform to?" More that they have to look for... not just scopeClass
<pfps> If I am looking at a shape graph, then to find out scopes for a shape, I need to look for both sh:scopeClass triples and also whether the shape is a class
<ericP> -0.9
<aryman_> +1
0
<Labra> -0.5
RESOLUTION: In the case where a shape is also a class, a SHACL processor MUST include all the instances of the class in the scope of the shape, exactly as if an explicit sh:scopeClass triple was present. An explicit sh:scopeClass triple is not required but MAY be included for clarity.
<hknublau> YAY! After one year, we have closed ISSUE-23
<Arnaud> PROPOSED: Close ISSUE-23, based on resolution regarding ShapeClass (dropped) and implicit scopeClass
<aryman_> +1
<TallTed> +1
+1
<pfps> 0
<Dimitris> 0
<kcoyle> 0
<Labra> 0
<hknublau> +1
RESOLUTION: Close ISSUE-23, based on resolution regarding ShapeClass (dropped) and implicit scopeClass
<ericP> 0
<trackbot> issue-118 -- syntax errors should not be confusable with validation results -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/118
arnaud: Dimitris pointed out that this was issue 75
... Is there anything we need to do or can we just close 118 because we have all the resolutions we need?
aryman: if you want to valide a shapes graph, you validate shapes for shapes...
... ... what do you do if you are given an invalid shapes graph on input? Do you need to validate the graph every time? If it does, it should report bad shapes input as errors, not violations.
pfps: Suppose I give an implementation 2 graphs -- a shapes and a data. I should be confident that "validation violoation" comes out of data graph.
... missing file, bad RDF, SHACL processer flaw should be "something else"
... issue 75 is, suppose in the processing validator does divide by 0. What happens then?
... sh:Violation should ONLY be because of a validation problem, not something else.
<ericP> error: KT4 extinction
<ericP> (a proposal for the error reported when the data center gets hit by an astroid)
aryman: Wasn't issue 75 closed? Didn't we agree that the spec will only cover validation results?
<pfps> If the method of reporting shape syntax errors is not specified, then implementations are free to reporting them via SHACL violations
<aryman_> @pfps disagree, the violation report is specified to only contain data violations
hknublau: issue may have arisen because my system added the shapes graph to the data graph, but this wasn't intended.
<Arnaud> PROPOSED: Close ISSUE-118, validation results are the product of validation of the data graph only
aryman: I agree with 118 and if spec isn't clear, we need to clarify it.
<aryman_> +1
+1
<TallTed> +1
<pfps> I believe that the spec does not currently require that violation results are only from shape violations against the data graph, so I think that something should be added to the spec
<pfps> +1
<hknublau> +1
<ericP> +1
<Dimitris> +1
<Labra> +1
RESOLUTION: Close ISSUE-118, validation results are the product of validation of the data graph only
<pfps> there is no need to hold up WD publication for this
<trackbot> issue-95 -- Proposed simplification and clean up of template mechanism -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/95
<TallTed> a clever SHACL validation engine might have a built in (or optional) "pre process" to validate a submitted shape graph against the shape shape before validating a submitted data graph against the submitted shape graph...
<pfps> isn't most of the recent discussion with title ISSUE-95 not about the issue at all?
hknublau: we haven't yet enough substance and precision to talk about it, so it hasn't happened yet. We need another couple of weeks
aryman: document properly, then additional issue is extensions, templates and abstractions, etc.
... I have a wiki page and if folks want input on metamodel, put on this page.
hknublau: the current turtle file has left out all the controversial bits. Can I create another branch that has additional stuff?
aryman: no branches, just addl turtle file.
hknublau: rdfs:domain statements may be different in different branches.
hnkublau: extension owl:imports non-controversial base file
<trackbot> issue-117 -- sh:class should not require that its objects be known to be instances of rdfs:Class -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/117
pfps: Agree with aryman that some implementations may want to report warnings if they see things that may be unusual. Not an error or constraint violation, however...
hknublau: The purpose of the requirement fo sh:class being rdfs:Class is to help user interfaces. A compromise would be to switch severity of constraint to a warning...
<pfps> Currently the spec says "The values of sh:class must be classes (instances of rdfs:Class)."
<pfps> As well "The values of sh:directType must be classes (instances of rdfs:Class)."
aryman: Holger's propsal seems find. @pfps - in what circumstance would you not be able to tell when the object is a class?
pfps: I don't see any reason whatsoever that the thing after sh:class must be SHACL specified to be a class. You might be doing skos or owl, with no triple that ways it is an isntance of a class
... there is not need to require that the rdfs:Class triple exist anywhere, why do it? You might want to grumble if you can't find it but you can't barf.
<Zakim> ericP, you wanted to say this seem slike an RDFS lint
ericP: Isn't this a schema lint operation? It seems like something you would really want in an RDFS validation. Could be useful, but more like an ontological constraint than a shape constraint...
aryman: When we validate the shapes graph, it is unlikely we will know who is a class.
... We'll have the instance information, but ontology information would be unlikely. Propose that we downgrade to informational message.
<ericP> hsolbrig: we had earlier discussion about the difference between what had to be true for validation to occur vs. well-behaved data graphs that we couldn't enforce
<ericP> ... if there's no significant impact on the shape interpretation, why do we bother?
<aryman_> I agree that we should weaken the requirement that the object of sh:class is a rdfs:Class
<pfps> it's on the hour in Newfoundland :-)
<ericP> quarter hour in nepal
<Arnaud> trackbot, end meeting