See also: IRC log
<scribe> scribenick: TallTed
<Arnaud> PROPOSED: Approve minutes of the 14 January Telecon: http://www.w3.org/2016/01/14-shapes-minutes.html
RESOLUTION: Approve minutes of the 14 January Telecon: http://www.w3.org/2016/01/14-shapes-minutes.html
<pfps> Looked OK by me
Arnaud: are we ready?
kcoyle & simonstey: think so...
<Arnaud> PROPOSED: publish the latest UCR Editor's draft http://w3c.github.io/data-shapes/data-shapes-ucr/
<pfps> I think that UCR is OK to go (I only did a quick glance, but I don't see any issues).
<kcoyle> +1
<aryman> +1
+1
<Labra> +1
<pfps> +1
<Dimitris> +1
<simonstey> +1
<ericP> +1
<hknublau> +1
RESOLUTION: Publish the latest UCR Editor's draft http://w3c.github.io/data-shapes/data-shapes-ucr/
Arnaud: let's talk about Karen's questions, https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jan/0093.html
kcoyle: I did a review of UCR vs current spec, and flagged the things I couldn't clearly match
Arnaud: seems best to stay with email for this for now; please everyone take a look!
<pfps> I believe that the document reflects the recent resolution on recursion.
<pfps> However, I do not think that ACTION-29 has been completed.
aryman: spec disallowed recursion. more recently we've been exploring some ways to allow it in certain circumstances, but spec'ese of this has not yet been done
[ discussion echoing aryman ... ACTION-29 and ISSUE-22 remain open ]
aryman: in the course of updating for issue-23, I discovered another issue...
... determination of Class/subClass looks to data graph in some places and shape graph in others
... this needs some additional clarity if not consistency
... computing shapes graph is up to application calling validator, so it seems pulling such Class triples from data graph should be easily done there, if needed
... SHACL validator probably shouldn't be made to do this
pfps: class-based reasoning is very complicated, and has to be explicitly covered if it's to be part of SHACL processor implementation
aryman: right, so calling application should pull all { $x a rdfs:Class } and { $a rdfs:subClassOf $b } triples into shape graph
pfps: not enough
hknublau: I think that `scopeClass` and `shapeClass inference` are different; shouldn't be thrown together
... person creating shapes will often be different than person using those shapes
... so explicit class declarations must be left to the shape creator
<Zakim> ericP, you wanted to say that the SPARQL approach is to work over ground facts, which may be a "virtual" product of inference
hknublau: pulling 50,000 class definitions (in one real ontology) across is not viable
aryman: pfps's objections apply to what existed before as much as revision
... question is currently which graph is used to determine whether something is an rdfs:Class or not
pfps: I thought the only thing that mattered was class membership in the data graph
... that now seems not to be so
... the current thread says that much I would consider to be outside the data graph comes into play
... current issue is the requirement to determine whether a shape is also a class.
aryman: issues arise because we chose to describe our shapes using RDF, making it possible to do shape-class reasoning over the shape graph
... we can simply state that *all* class-based reasoning must be based entirely on the data graph
hknublau: anyone creating a shape definition can just import any relevant ontology, to inherit such class defs
pfps: there might not be an ontology graph to import. such is not required by any other spec. relying on it is thus problematic.
hknublau: a person writing shape definition knows which classes they're talking about, so can import, create, or whatever as needed
aryman: the inconsistency I thought I was seeing is minor, and can be easily addressed without changing spec substantially
pfps: as far as I can tell, SHACL doc is inconsistent. in different places, it says to look at different evidence to make what appears to be the same determination.
... the existing inferable inconsistency is better than making it an explicit inconsistency.
<pfps> the spec needs to be changed so that it has a clear specification of how to handle the various class-related questions
<aryman> fyi we are taking about http://w3c.github.io/data-shapes/shacl/#scopeClass
<aryman> I will change that to say "If a resource X is both a shape and a class ..."
<pfps> changing behaviour is not word smithing!
[ pfps and aryman discuss possible rewording to resolve concern ]
<aryman> "If a resource X in the shapes graph is both a shape and a class ..."
Arnaud: reconsideration of resolution may be appropriate, looking at https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jan/0060.html
aryman: resolution seems OK, might mean we need a couple new things to address these concerns
<pfps> if shapes can have severity then use that severity for closed violations
hknublau: I believe there are real use cases where closedness will be applicable to part but not all of a given shape, or within context of a filter
<hknublau> ex:MyShape sh:constraint sh:Closed .
<hknublau> ex:MyShape sh:closed true
<hknublau> ex:MyShape sh:constraint [ sh:closed true ]
hknublau: previous setup allowed for many user-friendly shortcuts, which resolution disallows
<simonstey> ignore property thingy
aryman: this nuance about rdf:type -- under what circumstances can we ignore rdf:type?
<hknublau> ex:MyShape sh:constraint sh:ClosedIgnoringRDFTYpe .
hknublau: it's not an existing special case, but it could be, and I believe would be valuable
TallTed: I'm inclined to the reconsideration
Arnaud: if it were just me, I feel inclined to to bow to hknublau's arguments
pfps: doesn't feel like a good solution to me. closure can't be determined locally.
... have to look at all constraints associated with ... the shape the constraint is attached to.
... and what happens if this is beneath an `and` constraint.
... this doesn't act entirely like a constraint, so we shouldn't treat it like one
<Dimitris> if we have severity at the shape level, then all shape constraints can inherit the shape severity (unless they override it)
pfps: all that said, it won't cause decline and fall of Roman Empire to be so treated
aryman: it might be the case that the author wants to know about extra properties, but they won't break everything
<aryman> sh:closed sh:Hopefully
<simonstey> sh:closed sh:mostly
<Arnaud> PROPOSED: Change Rersolution of ISSUE-115 to have sh:closed on sh:constraint instead of sh:Shape
<Arnaud> PROPOSED: Change Rersolution of ISSUE-115 to have sh:closed on sh:NodeConstraint instead of sh:Shape, and define sh:Closed as syntactic sugar
<Arnaud> PROPOSED: Change Resolution of ISSUE-115 to have sh:closed on sh:NodeConstraint instead of sh:Shape, and define sh:Closed as syntactic sugar
<hknublau> +1
+1
<simonstey> +1
<aryman> +0
<pfps> 0
<ericP> 0
<kcoyle> +0 but I believe Holger
<Labra> -0
<Dimitris> 0
RESOLUTION: Change Resolution of ISSUE-115 to have sh:closed on sh:NodeConstraint instead of sh:Shape, and define sh:Closed as syntactic sugar
<pfps> With those two changes I think that the draft can go out.
<aryman> I will update the text for ISSUE-23 today
<hknublau> I will handle sh:closed today
[ previous PWD incorrect mailing list has been fixed ]
[ let's try to publicize better this time, try to drum up more public review and response ]
<pfps> Sending something to the appropriate W3C mailing lists would be good.
<pfps> I'm happy with publishing "as is" (i.e. with the changes mentioned).
+1 publish after today's changes are applied
<aryman> +1 to publish
<Dimitris> +1
<Arnaud> PROPOSED: Pending edits regarding issue-23 and issue-115, publish the updated SHACL draft
<pfps> +1
<hknublau> +1
<kcoyle> +1
<simonstey> +1
<aryman> +1
<ericP> +1
+1
<Dimitris> +1
<Labra> +1
RESOLUTION: Pending edits regarding issue-23 and issue-115, publish the updated SHACL draft
<pfps> test cases for next week?
<Arnaud> trackbot, end meeting