See also: IRC log
<ericP> having a hard time dialing it
<Arnaud> scribenick: hknublau
Arnaud: Not clear if ISSUE-46 is closed (It is not).
<Arnaud> PROPOSED: Approve minutes of the 7 May Telecon: http://www.w3.org/2015/05/07-shapes-minutes.html
<pfps> minutes looked fine to me
RESOLUTION: Approve minutes of the 7 May Telecon: http://www.w3.org/2015/05/07-shapes-minutes.html
<michel> regrets, i have a conflict
<scribe> no progress on open actions
Arnaud: Current agenda just there to outline meeting times
… we may start discussing test cases even if no draft is there yet
… I hope next meeting will be real face to face again
… Report from social WG, which also has entrenched groups with three proposals
… at the last F2F of that report, we had in-depth dives for each proposal, based on (general enough) user stories
… goal was to increase understanding, then self-criticism session.
… some magic happened: collaboration improved, possible convergence points identified
aryman: what we need is a process to pick a document
… we could create sample data to be validated
<kcoyle> Arnaud: +1, maybe a miracle will happen, but we won't know without trying
<pfps> shapes as classes is a detail, not a fundamental issue
+q
hknublau: classes vs shapes is independent of draft selection, needs to be answered in any case
<kcoyle> +q
aryman: lots of issues are cross-cutting, we should avoid triplicating efforts to improve efficiency of discussion
kcoyle: Pushing hard for specific examples, happy to provide examples
<ericP> +1 to arnaud's proposal
<pfps> I'm willing to do the work required
arnaud: Presenters could prepare user stories based on specific examples
… an hour per proposal, “demo”
… “what would it take for the other proposals to be acceptable” -> compromises
+q
<pfps> I view the ShEx proposal as *very* different from the other two.
hknublau: Drafts mainly differ in ways that things are formalized, not so much on surface syntax
arnaud: Traffic has slowed down a bit, is everyone just frustrated?
<pfps> As far as I am concerned, the issues that have been discussed matter very little to me, so I have not been posting much.
pfps: ShEx proposal is completely different from the other two ones, despite SPARQL fallback
<pfps> s/issues/discussion/ in my typed comment
arnaud: if this meeting doesn’t lead to starting point, we are in real trouble with schedule.
<Arnaud> http://www.w3.org/2014/data-shapes/track/issues/46
<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0017.html
Arnaud: is issue resolved now that the requirement is written down?
<pfps> I think that the two requirements address the need for validating rdf:Lists, so ISSUE-46 can be closed. This is *separate* from actually approving the requirements.
<Arnaud> PROPOSED: Close ISSUE-46 by adding requirements 2.6.12 and 2.6.13 as proposed by Richard in: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0017.html
+1
<TallTed> +1
<pfps> There are lots of aspects of RDF documents that the WG is not addressing.
<pfps> +1
<aryman> +1
<Dimitris> +1
<pfps> +1 to adding the requirements to the requirements page (i'm also in favour of approving the requirements, by the way)
<Labra> +1
RESOLUTION: Close ISSUE-46 by adding requirements 2.6.12 and 2.6.13 as proposed by Richard in: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0017.html
<kcoyle> +1
<Arnaud> PROPOSED: open ISSUE-49
http://www.w3.org/2014/data-shapes/track/issues/49
pfps: unclear about distinction, ShEx doesn’t have scoped vs unscoped shapes, neither is it essential to the others.
… not sure if this distinction matters
Dimitris: yes it is a technical question
TallTed: This seems to be about nested shapes, if you have more than zero of something, then they must be within constraints
Dimitris: Mostly about complexity
<pfps> leave as is
Arnaud: Shall we close and later reopen, or just wait?
aryman: In Holger’s draft this is more like a filter condition
<pfps> In my proposals, all shapes are unscoped. They only get a scope in use.
<pfps> s/proposals/proposal/ :-)
… Hard to discuss without having a draft first, we should delay this topic
… can we postpone it in issue tracker?
<Arnaud> PROPOSED: Postpone ISSUE-49
<aryman> +1
+1
<kcoyle> +1
<Dimitris> +1
<Labra> +1
<TallTed> +1
RESOLUTION: Postpone ISSUE-49
+q
<kcoyle> +q
hknublau: I believe notEqual doesn’t belong into the core - too specific. Can already be handled by macros + SPARQL, already approved
aryman: Does not look like a compelling example yet
kcoyle: Can we agree on term “Core”
Arnaud: Maybe we can extend the core now to make everyone happy, reduce resistance against SPARQL extensions.
<pfps> It's too soon to dispose of S43
pfps: S44 requires revision, mangled
<pfps> the body of S44 is completely unrelated to issue-42
Arnaud: let’s move on
<Arnaud> issue-48?
<trackbot> issue-48 -- How do we limit the scope for a shape? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/48
pfps: Title is misleading
… Michel (probably) wants the scope to be more than for example class membership
Arnaud: Michel should take another pass at the issue
<pfps> The title of ISSUE-48 talks about how to limit the scope of shapes, which all proposals have. The body talks about scopes of shapes that go beyond just individuals and class extensions.
<michel> coming
michel: whether or not we can select data for a shape, not for all data but for selected data only
<pfps> I'm still confused as to whether Michel wants scopes on shapes or expressive scopes on shapes.
aryman: Are you asking for a requirement or propose a design?
<pfps> Every proposal has scopes on shapes.
<pfps> Some proposals only have limited kinds of scopes allowable.
+q
<pfps> As Holger says, there are already requirements for instance and class scopes.
<pfps> I agree with Holger that expressive scopes are useful.
hknublau: scope as precondition is not yet captured by requirements
<Dimitris> I also agree to include general scopes
<pfps> An expressive scope would work just like a class-based scope - I don't see any difference.
<pfps> Of course, there may be effects of allowing expressive scopes.
aryman: if precondition fails then the constraint may be true
+q
<aryman> its like an if-then
<pfps> For example you could have a scope be all nodes that are objects of a particular property - if the type is rdf:type then this is (close to) class scopes
<pfps> I'm not sure why "core" is again raising its head
hknublau: maybe scopes should go into another sub-dialect than “core”
aryman: dynamic forms are a frequent requirement, as long as scopes are nice and declarative, they should be supported by core
<michel> just lost power
<michel> lol
pfps: I am in favor of adding this requirement for expressive scopes, separate from core-or-not
<pfps> PROPOSED: Close ISSUE-48 by adding a requirement that the effect of expressive scopes be in SHACL
+1
<aryman> +1
<Dimitris> +1
<michel> +1
<kcoyle> +1
<TallTed> +1
<Labra> +1
<pfps> I'm willing to write the requirements
RESOLUTION: Close ISSUE-48 by adding a requirement that the effect of expressive scopes be in SHACL
<pfps> ACTION: pfps to write requirement coming from ISSUE-48 [recorded in http://www.w3.org/2015/05/14-shapes-minutes.html#action01]
<trackbot> Created ACTION-24 - Write requirement coming from issue-48 [on Peter Patel-Schneider - due 2015-05-21].
http://www.w3.org/2014/data-shapes/track/issues/23
<Arnaud> ISSUE-23?
<trackbot> ISSUE-23 -- Shapes, classes and punning -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/23
+q
TallTed: some of the discussion in last meeting was about the flexibility to allow mixing classes and shapes
… to avoid having to rewrite their ontology with shapes, reusing the same URI should be allowed
… does not mean that every shape is a class or every class is a shape.
… allow people to do things more efficiently
Arnaud: We cannot really prevent users from mixing classes and shapes anyway
TallTed: Tools that don’t understand shap es can ignore the shape aspect
<pfps> But if I am a shape-aware system and I see a shape that is also a class am I obligated to run the shape on all instances of the class?
… owl:sameAs has been abused, but if you can selectively ignore certain sameAs triples, it’s fine.
<Dimitris> +q
ericP: still have to copy OWL restrictions into shape, so this doesn’t help you much
<pfps> +1 to eric
aryman: from Linked Data point of view, class is global, but may have different interpretations per graph
… if class definition is local then I have no discomfort
Dimitris: Allowing the same URI is OK, but would prefer to keep metaclasses distinct.
<ericP> no one tells you what to do in the privacy of your own triple stoer
<ericP> store
Arnaud: Would prefer a solution that accommodates both design patterns.
<Arnaud> trackbot, end meeting