18:56:24 <RRSAgent> RRSAgent has joined #shapes
18:56:24 <RRSAgent> logging to http://www.w3.org/2015/11/12-shapes-irc
18:56:26 <trackbot> RRSAgent, make logs rdf-data-shapes
18:56:26 <Zakim> Zakim has joined #shapes
18:56:28 <trackbot> Zakim, this will be SHAPES
18:56:28 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
18:56:29 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
18:56:29 <trackbot> Date: 12 November 2015
18:58:14 <aryman> aryman has joined #shapes
18:58:28 <aryman> present+ aryman
18:58:53 <Arnaud> present+
18:58:54 <kcoyle> kcoyle has joined #shapes
18:59:37 <pfps> pfps has joined #shapes
18:59:42 <hknublau> hknublau has joined #shapes
18:59:45 <pfps> present+
18:59:52 <kcoyle> present+
19:00:18 <simonstey> simonstey has joined #shapes
19:01:37 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.11.12
19:01:41 <Arnaud> chair: Arnaud
19:02:17 <simonstey> present+
19:03:37 <Dimitris> Dimitris has joined #shapes
19:03:57 <Arnaud> regrets: hsolbrig, labra (partial)
19:04:19 <Dimitris> present+ dimitris
19:04:21 <TallTed> present+
19:04:24 <hknublau> present+ hknublau
19:06:41 <ericP> present+ ericP
19:07:04 <ericP> scribenick: ericP
<ericP> topic: Admin
19:07:47 <Arnaud> PROPOSED: Approve minutes of the 5 November Telecon: http://www.w3.org/2015/11/05-shapes-minutes.html
19:07:53 <pfps> minutes looked OK to me
19:08:04 <Arnaud> RESOLVED: Approve minutes of the 5 November Telecon: http://www.w3.org/2015/11/05-shapes-minutes.html
19:08:36 <pfps> No meetings on Xgiving for me (if I want to stay married)
19:08:40 <TallTed> definite regrets for 11/26
19:08:25 <ericP> topic: Disposal of Raised Issues
19:08:42 <Arnaud> PROPOSED: Open ISSUE-111, ISSUE-112
19:09:03 <hknublau> -1 to opening ISSUE-111
19:09:15 <ericP> Arnaud: i don't think we should close tracker
19:09:42 <ericP> ... some issues become ratholes, but sometimes should be routine
19:09:48 <pfps> ISSUE-111 has been under discussion the last two weeks already
19:10:04 <Arnaud> PROPOSED: Open ISSUE-112
19:10:10 <hknublau> +1
19:10:13 <ericP> +1
19:10:13 <Dimitris> +1
19:10:16 <kcoyle> +1
19:10:17 <simonstey> +1
19:10:27 <aryman> +1
19:10:29 <pfps> +1
19:10:35 <ericP> RESOLVED: Open ISSUE-112
19:10:37 <TallTed> +0
19:11:08 <ericP> Arnaud: let's talk a bit more about ISSUE-111
19:11:26 <ericP> Arnaud: we've been discussing this this week
19:11:53 <ericP> hknublau: i prefer to work on issues that have practical relevence
19:12:09 <simonstey> I don't see why sh:defaultValue should be dropped
19:12:19 <ericP> ... this feels like a high-level talking point that doesn't accomplishing anything and doesn't have to do with default values
19:12:36 <ericP> Arnaud: there are two things, one high-level, one specific
19:12:59 <ericP> ... re the high-level one described in the title, i agree with you that it could be a rathole
19:13:17 <ericP> ... but it raises an interesting question about what does it take to meet charter reqs?
19:13:29 <ericP> pfps: we've already been beat up about what's in the SHACL spec
19:13:53 <ericP> ... this isn't philosophical. it's a conversation that has led to ratholes
19:14:13 <ericP> ... this is an attempt to shine some light in the rathole so the WG can make progress
19:14:48 <TallTed> q+
19:14:56 <ericP> hknublau: we have more important things
19:15:12 <ericP> ... pfps is saying that we first have to handle this before other stuff
19:15:33 <simonstey> q+
19:15:51 <Arnaud> ack TallTed
19:16:26 <simonstey> -q
19:16:29 <ericP> TallTed: if we're going to talk about politeness, then we should not talk about or distinguished opposite as "raising silly arguments".
19:16:46 <ericP> ... i agree that we should move the 2nd point to another issue
19:16:59 <Arnaud> PROPOSED: Open ISSUE-111
19:17:11 <ericP> ... i think we should wordsmith the first [title] issue
19:17:28 <BartvanLeeuwen> BartvanLeeuwen has joined #shapes
<BartvanLeeuwen> present+
19:17:33 <simonstey> +1 (only if proposal 2 is moved)
19:17:35 <ericP> Arnaud: opening the issue is not agreeing to the proposal
19:17:49 <pfps> I thought that the deal was to put proposals into new issues, so I tried to do so.
19:17:50 <hknublau> -0.9
19:17:53 <kcoyle> +1 if issues are broken out
19:18:05 <pfps> I'm willing to remove the second proposal from this issue
19:18:18 <Arnaud> PROPOSED: Open ISSUE-111, and move question about sh:defaultValue to a separate issue
19:18:27 <ericP> +1
19:18:30 <TallTed> +1
19:18:35 <simonstey> +1
19:18:36 <pfps> I'm actually willing to remove both proposals if that is deemed a good thing
19:18:40 <pfps> +1
19:18:48 <kcoyle> +1
19:18:51 <Dimitris> +1
19:19:14 <aryman> +1
19:19:23 <Arnaud> RESOLVED: Open ISSUE-111, and move question about sh:defaultValue to a separate issue
19:19:31 <pfps> I just removed the second proposal.
19:19:40 <pfps> I'll do other stuff shortly, so no action required.
19:20:20 <ericP> topic: Requirements
19:20:39 <ericP> Arnaud: kcoyle reported yesterday that the requirements doc is pretty stable. what do we do with it?
19:20:53 <ericP> kcoyle: we'd talked about integrating it into the UC&R
19:21:15 <ericP> ... alternatively don't publish it, or publishing it as an external doc
19:21:30 <Arnaud> https://docs.google.com/document/d/1whx2DeJtng-WZXo2DAHc_GZL7ElXNS_B8fBxarGA-0o/
19:21:37 <ericP> ... pfps pointed out that the doc ends up a bit cyclical.
19:21:40 <simonstey> +q
19:21:47 <pfps> I'm happy with having this in the UCR document, I think.
19:21:53 <ericP> ... otoh, it's a handy place
19:22:31 <ericP> Arnaud: we should put it in W3C-land so it can be preserved
19:22:42 <ericP> ... this is a useful piece of data which we should promote somehow
19:22:56 <simonstey> -q
19:23:04 <simonstey> +q
19:23:08 <pfps> I think that my previous comments were about how to add this - section vs scattered
19:23:11 <ericP> kcoyle: i suspect that more folks will encoouter it in the UC&R
19:23:16 <ericP> Arnaud: where would you put it?
19:23:29 <ericP> kcoyle: this would be another header under each requirement.
19:23:38 <Arnaud> ack simonstey
19:23:43 <ericP> ... that's how i envisioned it.
19:23:52 <ericP> ... interested in other proposes, but i don't want a big table
19:24:07 <ericP> simonstey: there's a connection between uc's and r's
19:24:19 <kcoyle> http://www.w3.org/TR/2015/WD-shacl-ucr-20150414/
19:24:35 <ericP> ... "if you want to see how this is solved with shacl, follow the link to the shacl spec"
19:24:54 <pfps> I leave it up to editorial discretion
19:25:36 <ericP> ericP: this is the topology i expect from a UC&R doc
19:25:51 <pfps> q+
19:25:59 <ericP> Arnaud: looks like a green light from the WG
19:26:05 <Arnaud> ack pfps
19:26:15 <ericP> pfps: does UC&R still have the prob with the reply-to addr?
19:26:39 <ericP> ... all good. it's public-rdf-shapes@w3.org
19:26:49 <ericP> ... it's the other doc with the wrong addr
19:27:10 <ericP> q+
19:27:16 <Arnaud> ack ericP
19:27:33 <pfps> The Editor's Draft for SHACL should be fixed now, before next publication.
19:27:35 <simonstey> +q
19:29:40 <pfps> I sent the message from pfps@verizon.net
19:30:57 <Arnaud> ack simonstey
19:33:33 <ericP> topic: ISSUE-65
19:32:53 <pfps> ISSUE-65
19:32:53 <trackbot> ISSUE-65 -- Consistency and cohesiveness of nomenclature (e.g., shapes, scopes, and constraints) -- open
19:32:53 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/65
19:33:50 <ericP> Arnaud: after the first WG saying that there was inconsistency
19:34:01 <Arnaud> PROPOSED: Close ISSUE-65, while not perfect, the recent editorial fixes  and rewrites have sufficiently addressed this. Further inconsistencies  to be treated incrementally.
19:34:07 <pfps> q+
19:34:10 <ericP> ... hknublau says we should close it 'cause it's considerably better
19:34:16 <Arnaud> ack pfps
19:34:23 <ericP> ... as an ongoing mission, we all need to improve the doc
19:34:28 <kcoyle> arthur? have you done this?
19:34:41 <aryman> tried to
19:34:51 <ericP> pfps: i think the doc is severly wedged wrt to nomenclature, but i won't object to closing this
19:35:20 <simonstey> +q
19:35:21 <ericP> ... i think it's hard to come up with a coherent description about when shapes or filters are actu=ve
19:36:18 <ericP> ... what kinds of constraints are there -- the doc says templates and built-ins
19:36:33 <ericP> ... notion of "abstractness" which pops up in various places
19:36:41 <ericP> Arnaud: we have different issues for this.
19:36:57 <Arnaud> ack simonstey
19:37:01 <ericP> ... i would expect this kind of work to continue even if we close issue-65
19:37:33 <ericP> simonstey: regarding filters and scopes, i think that a filter is a more precise way to describe a scope.
19:37:44 <TallTed> it may be helpful to update the issue summary, with a dated section saying "these are the pieces that still need careful addressing (see also ISSUe x,y,z)"
19:37:47 <ericP> ... we need to clarify whether filters are a separate thing or just a more precise scope
19:38:03 <ericP> Arnaud: so you propose that we close this and open more specific issues
19:38:43 <ericP> pfps: i worry that we'll play wack-a-mole; we'll have wacked the moles but end up with a lumpy yard
19:38:43 <aryman> q+
19:39:01 <Arnaud> ack aryman
19:39:09 <ericP> TallTed: we can use this as an ombibus tracker for the other issues (updated to point to them)
19:39:37 <ericP> aryman: i think that part of the prob is that the spec makes certain assumptions that some members of the WG have objected to
19:39:47 <ericP> ... until we resolve them, we can't make progress
19:40:27 <ericP> ... i don't think we should be talking about abstract classes, meta-classes, and templates
19:40:51 <ericP> ... i'm not just going to unilaterally delete the stuff i don't like 'cause hknublau will revert
19:40:59 <ericP> ... we need WG resolutions
19:41:14 <ericP> Arnaud: i think the points you've made are all encapsulated in one issue or another
19:41:49 <ericP> ... i take pfps's point that if you address issues one at a time, you can end up with something uglier than if you took a more comprehensive approach
19:42:02 <ericP> ... otoh, i don't know how to avoid this in a WG
19:42:28 <ericP> ... from what i heard, i think we're better off keeping issue-65 open
19:42:49 <ericP> ... people should open other issues and make proposals
19:42:51 <ericP> q+
19:43:09 <ericP> ... the number of issues isn't the problem, it's whether we're making progress
19:43:20 <ericP> ... the proposals page hasn't changed much
19:43:35 <Arnaud> ack ericP
19:44:22 <pfps> Maybe have a link to a Wiki page about nomenclature?
19:45:08 <Labra> Labra has joined #shapes
19:45:38 <ericP> ericP: if we're going keep issue-65 open, we should have links (full urls) to related issues at the top of the description
19:45:49 <pfps> I'll volunteer to make a wiki page and link it up appropriately
19:45:50 <ericP> Arnaud: pfps propsed doing this in a wiki page.
19:46:12 <ericP> topic: ISSUE-96: Violation IDs
19:46:22 <ericP> Arnaud: we didn't discuss this on a call.
19:46:24 <simonstey> ISSUE-96
19:46:24 <trackbot> ISSUE-96 -- Should the validation results contain stable IDs to indicate the type of violation -- open
19:46:24 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/96
19:46:30 <Labra> present+ labra
19:46:35 <ericP> ... there were some votes on the wiki page, including an objection from pfps
19:46:42 <ericP> ... we need to make a decision.
19:47:15 <ericP> hknublau: in the future, there will hopefully many impls of SHACL
19:47:28 <ericP> ... i would like interop between those platforms
19:47:51 <aryman> i muted
19:47:52 <ericP> ... it's not sufficient to have a link to the subject and predicate if we don't have a known type
19:48:20 <ericP> ... hsolbrig (i think) metnioned that other specs, e.g. XML schema do that
19:49:03 <ericP> q+
19:49:10 <ericP> pfps: i think that we're cramming so much into these things [violations?], that we're making it hard to implement SHACL without much benefit
19:49:28 <Arnaud> ack ericP
19:49:33 <ericP> ... there are all sorts of things we could do that would be nice, but if we do, we end up with SQL
19:50:48 <hknublau> q+
19:50:54 <Dimitris> q+
19:51:52 <Arnaud> ericP: without a specific ordering we can't have consistency in what errors are reported, like in case of conjunctions, so user wouldn't know how to test for violation IDs
19:51:54 <pfps> good point, repeatable error messages requires that execution be deterministic
19:52:02 <aryman> q+
19:52:14 <Arnaud> ack hknublau
19:52:51 <ericP> hknublau: we have no mandatory link between top-level errors and nested (ANDs and ORs)
19:53:23 <ericP> ... i see that i need to programatically distinguish what comes back, e.g. and error getting rendered on one page or another.
19:53:45 <Arnaud> ack Dimitris
19:54:11 <ericP> Dimitris: i like this feature -- it's quite useful -- but i share ericP'
19:54:36 <hknublau> q+ could we make it optional at least?
19:54:53 <hknublau> Could we make it optional at least?
19:54:57 <ericP> ... 's concearn that it doesn't work with nested constraints.
19:55:03 <Arnaud> ack aryman
19:55:04 <ericP> ... could put it in a separate doc
19:55:07 <hknublau> At least as a shared URI of the property
19:55:30 <ericP> aryman: we don't need to invent a new syntax 'cause we can use IRIs
19:55:57 <ericP> ... we could at least identify the constraint violation.
19:55:59 <Dimitris> q+
19:56:06 <ericP> ... and it should be part of the validation report
19:56:13 <ericP> Arnaud: don't we already have that?
19:56:15 <Arnaud> ack Dimitris
19:56:29 <pfps> Lots of constraints are currently blank nodes, which do not have IRIs.
19:57:13 <aryman> sh:MinCountConstraint
19:57:21 <hknublau> +1
19:57:44 <ericP> aryman: we can include, focus node, property, predicate, etc.
19:58:09 <hknublau> q+
19:58:39 <Arnaud> ack hknublau
19:58:55 <ericP> hknublau: i agree with aryman; the IRIs need to be defined anyways
19:59:04 <ericP> ... my names are long and start with "abstract"
19:59:23 <ericP> ... the core language could use a key predicate that's in each template
19:59:24 <pfps> q+
19:59:35 <ericP> ... but i prefer to use a class or template IRI
19:59:51 <ericP> ... if folks are worried about the burden, we could call it optional
19:59:56 <Dimitris> q+
20:00:05 <Arnaud> ack pfps
20:00:07 <aryman> muted
20:00:22 <ericP> ... at least if tools want to interoperate, there should be a standard set of names
20:00:44 <ericP> pfps: are we trying to capture that a min constraint was violated
20:01:06 <ericP> ... if we know the actual constraint that was violated, we can find out what it is
20:01:29 <ericP> hknublau: we haven't make it explict. there a property called "source template".
20:02:18 <ericP> pfps: if i create a "2nd-parent constraint" and it has a number -57, you might want 2nd-parent-min-cardinality-constraint-57
20:02:43 <ericP> ... but you just want min-cardinality-constraint
20:02:58 <Arnaud> ack Dimitris
20:03:10 <ericP> Arnaud: maybe we need to take this off line
20:03:27 <ericP> Dimitris: i thought this was already covered
20:03:50 <pfps> s/2nd/fecund/
20:04:44 <ericP> hknublau: it should be possible to represent the core constraints and templates
20:04:45 <aryman> q+
20:04:55 <ericP> ... then we can use those ids.
20:04:58 <Arnaud> ack aryman
20:05:17 <ericP> aryman: we don't need to introduce templates.
20:05:42 <ericP> topic: ISSUE-78: sh:abstract
20:05:54 <ericP> Arnaud: this is an entirely separate issue
20:06:02 <ericP> ... there are folks uncomfortable with shapeClass
20:06:14 <ericP> ... should we have the ability to declare this stuff "abstract"
20:06:16 <aryman> q+
20:06:25 <Arnaud> ack aryman
20:06:33 <ericP> ... i fear the issue will be about whether we should have shapeClass at all
20:06:47 <ericP> aryman: i fear we're introducing a whole programming model
20:07:12 <ericP> ... the motivation for introducing abstract classes in OO langauges is to factor common behaviors/features
20:07:53 <ericP> ... but if we want an abstract class, we just give it a vacuous body that always returns true
20:08:09 <ericP> ... so i think that abstract classes are another piece of complexity
20:08:42 <ericP> hknublau: we've found in our experience with user tools that we want to make sure these aren't implemented directly
20:08:44 <TallTed> q+
20:08:54 <Arnaud> ack TallTed
20:09:14 <ericP> TallTed: this sounds like a bullet point for the user interface section of the specification
20:09:20 <aryman> q+
20:09:32 <ericP> Arnaud: so this falls in the same category as the sh:index that we talked about last week?
20:09:43 <Arnaud> ack aryman
20:09:46 <ericP> TallTed: right, maybe not in the spec, but in the UC&R
20:10:09 <ericP> aryman: for hknublau's case, he's introduced a new requirement for a new constraint class
20:10:44 <pfps> q+
20:10:50 <ericP> ... i.e. look for nodes that are instances of an abstract class and not any [non-abstract] subclass
20:11:03 <ericP> ... so hknublau should introduce a new req
20:11:14 <ericP> Arnaud: how about as an annotation?
20:11:35 <ericP> aryman: wants to look for actual violations
20:11:48 <ericP> hknublau: i'm fine with both.
20:11:59 <Arnaud> ack pfps
20:12:15 <ericP> ... i started with just an annotation, pfps asked me for semantics, i produced it, but i'm not convinced it's necessary
20:12:24 <ericP> pfps: we have two proposals:
20:13:02 <ericP> ... a constraint sitting on RDFS classes, but not using RDFS
20:13:11 <ericP> ... if it has bite, it should have RDFS bite
20:13:26 <ericP> ... if it's an annotation, then it's part of the user interface
20:14:01 <ericP> Arnaud: if you're only interested in the UI case, you should re-introduce
20:14:15 <ericP> hknublau: ok, i created the semantics to satisfy pfps.
20:14:30 <ericP> ... do i have to create a requirement?
20:14:52 <ericP> Arnaud: it's useful to have use cases, but i don't know that we need specific requirements for every language feature
20:15:16 <ericP> ... there's a general issue that came up last week: how much do we address (graphical) user interfaces
20:15:55 <ericP> TallTed: it's not just graphical, and not just user interface, it's user experience
20:16:16 <ericP> ... there's an IRI, which nobody wants to look at, and probably a label.
20:16:35 <ericP> ... and a title
20:17:00 <ericP> ... and a description that shows up as a popup
20:17:24 <ericP> Arnaud: it would be great to document this
20:17:37 <ericP> TallTed: i put a bit in channel last week
20:17:51 <ericP> Arnaud: no point in trying to close issue-78.
20:18:05 <ericP> ... hknublau has some work to document it as an annotation.
20:18:37 <ericP> ... it seems it has more viability if it's just an annotation than if it introduces a new constraint
20:19:02 <ericP> hknublau: is it sufficient for me to just make a new proposal, or do i have to create a use case et al?
20:19:32 <ericP> Arnaud: you should say why you want it, and we can discuss adding it to the UC&R
20:19:46 <ericP> topic: ISSUE-92: additive repeated properties
20:20:04 <ericP> Arnaud: we discussed this before, and no one persuaded the others.
20:20:20 <ericP> ... there weren't many votes (more now)
20:20:29 <ericP> ... the status quo is that we don't change anything
20:20:48 <ericP> ... we have several objections to the status quo
20:21:18 <ericP> q+
20:21:25 <pfps> q+
20:21:29 <Arnaud> ack ericP
20:22:06 <pfps> It looks to me that this proposal is to change SHACL from conjunctive to additive, i.e., completely change SHACL.
20:22:53 <Arnaud> ack pfps
20:23:32 <ericP> pfps: the summary of ericP's proposal is to throw away shacl and use shex instead
20:23:57 <ericP> ericP: that part of it anwyays. that's what we had to do in shex 'cause we started with Resource Shapes.
20:24:06 <ericP> Arnaud: there are several ways to get conjunciton.
20:24:24 <ericP> ... it wasn't clear to me why we need to use that syntax for conjunction.
20:24:42 <ericP> ... why can't we just allow that 'cause we already have other conjunctions?
20:24:53 <pfps> q+
20:24:54 <aryman> q+
20:25:01 <Arnaud> ack pfps
20:25:01 <ericP> ... there's propably something else that makes people react, but i don't know what it is
20:25:15 <ericP> pfps: everything in shacl is predicated on conjunciton.
20:25:27 <ericP> ... you have to completley change everything.
20:25:39 <hknublau> I agree, this would be a very difficult change
20:25:56 <Arnaud> ack aryman
20:26:12 <ericP> ... suppose we changed the comma in shex from additive to conjunctive; it would change everything
20:26:32 <ericP> aryman: i'm not convinced it would be that dramatic
20:26:41 <ericP> ... we'd have to think hard about inheritance
20:26:41 <ericP> q+
20:27:03 <ericP> ... one use case for that is when you want to tighten up the constraints on a super shape.
20:27:24 <ericP> ... it's easy with a conjunctive semantics.
20:27:42 <Arnaud> ack ericP
20:29:15 <TallTed> re-re-re-reading the 4 proposals on the wiki page...   I'm least troubled by Arthur's
20:29:31 <ericP> ericP: the use of conjunction only aids in extension in the trivial case
20:29:34 <pfps> Which use cases? Are they in UCR?
20:30:10 <TallTed> (and we do need to address inheritance/include effects)
20:30:24 <hknublau> q+
20:30:32 <Arnaud> ack hknublau
20:30:34 <ericP> Arnaud: we don't want to throw away inheritance
20:30:46 <ericP> hknublau: i'm always in favor of compromise
20:31:00 <ericP> ... maybe isolate to a specific construct
20:31:19 <aryman> q+
20:31:23 <ericP> ... aryman's algorithm can't be expressed in a single SPARQL query
20:31:35 <Arnaud> ack aryman
20:31:43 <ericP> Arnaud: we said we'd use SPARQL as much as possible, but it might be possible here
20:32:04 <Arnaud> s/might/might not/
20:32:13 <ericP> aryman: my algorithm can't be handled in a single sparql query
20:32:44 <ericP> ... my proposal is a compromise which would get you many of the use cases that the shex community needs but is computationally tractable.
20:33:40 <BartvanLeeuwen> thx bye
20:33:45 <Arnaud> trackbot, end meeting
20:33:45 <trackbot> Zakim, list attendees
20:33:45 <Zakim> As of this point the attendees have been aryman, Arnaud, pfps, kcoyle, simonstey, dimitris, TallTed, hknublau, ericP, BartvanLeeuwen, labra (partial)
20:33:53 <trackbot> RRSAgent, please draft minutes
20:33:53 <RRSAgent> I have made the request to generate http://www.w3.org/2015/11/12-shapes-minutes.html trackbot
20:33:54 <trackbot> RRSAgent, bye
20:33:54 <RRSAgent> I see no action items