IRC log of shapes on 2015-11-12

Timestamps are in UTC.

18:56:24 [RRSAgent]
RRSAgent has joined #shapes
18:56:24 [RRSAgent]
logging to
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]
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]
18:59:52 [kcoyle]
19:00:18 [simonstey]
simonstey has joined #shapes
19:01:37 [Arnaud]
19:01:41 [Arnaud]
chair: Arnaud
19:02:17 [simonstey]
19:03:37 [Dimitris]
Dimitris has joined #shapes
19:03:57 [Arnaud]
regrets: hsolbrig, labra
19:04:19 [Dimitris]
present+ dimitris
19:04:21 [TallTed]
19:04:24 [hknublau]
present+ hknublau
19:06:41 [ericP]
present+ ericP
19:07:04 [ericP]
scribenick: ericP
19:07:47 [Arnaud]
PROPOSED: Approve minutes of the 5 November Telecon:
19:07:53 [pfps]
minutes looked OK to me
19:08:04 [Arnaud]
RESOLVED: Approve minutes of the 5 November Telecon:
19:08:25 [ericP]
topic: Disposal of Raised Issues
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:42 [Arnaud]
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]
19:10:10 [hknublau]
19:10:13 [ericP]
19:10:13 [Dimitris]
19:10:16 [kcoyle]
19:10:17 [simonstey]
19:10:27 [aryman]
19:10:29 [pfps]
19:10:35 [ericP]
19:10:37 [TallTed]
19:11:08 [ericP]
topic: (meta) 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 quesion 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's 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]
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]
19:15:51 [Arnaud]
ack TallTed
19:16:26 [simonstey]
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]
19:17:11 [ericP]
... i think we should wordsmith the first [title] issue
19:17:28 [BartvanLeeuwen]
BartvanLeeuwen has joined #shapes
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]
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]
19:18:30 [TallTed]
19:18:35 [simonstey]
19:18:36 [pfps]
I'm actually willing to remove both proposals if that is deemed a good thing
19:18:40 [pfps]
19:18:48 [kcoyle]
19:18:51 [Dimitris]
19:19:14 [aryman]
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]
19:21:37 [ericP]
... pfps pointed out that the doc ends up a bit cyclical.
19:21:40 [simonstey]
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]
19:23:04 [simonstey]
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 wnat a big table
19:24:07 [ericP]
simonstey: there's a connection between uc's and r's
19:24:19 [kcoyle]
19:24:35 [ericP]
... "if you wnat 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]
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
19:26:49 [ericP]
... it's the other doc with the wrong addr
19:27:10 [ericP]
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]
19:29:40 [pfps]
I sent the message from
19:30:57 [Arnaud]
ack simonstey
19:32:53 [pfps]
19:32:53 [trackbot]
ISSUE-65 -- Consistency and cohesiveness of nomenclature (e.g., shapes, scopes, and constraints) -- open
19:32:53 [trackbot]
19:33:33 [ericP]
topic: ISSUE-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]
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]
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]
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-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]
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]
19:46:24 [trackbot]
ISSUE-96 -- Should the validation results contain stable IDs to indicate the type of violation -- open
19:46:24 [trackbot]
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]
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]
19:50:54 [Dimitris]
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]
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:35 [Labra_]
Labra_ has joined #shapes
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]
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]
19:57:21 [hknublau]
19:57:44 [ericP]
aryman: we can include, focus node, property, predicate, etc.
19:58:09 [hknublau]
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]
19:59:35 [ericP]
... but i prefer to use a class or template IRI
19:59:36 [Labra__]
Labra__ has joined #shapes
19:59:51 [ericP]
... if folks are worried about the burden, we could call it optional
19:59:56 [Dimitris]
20:00:05 [Arnaud]
ack pfps
20:00:07 [aryman]
20:00:22 [ericP]
... at least if tools wnat 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:01:54 [Labra2]
Labra2 has joined #shapes
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]
20:04:44 [ericP]
hknublau: it should be possible to represent the core constraints and templates
20:04:45 [aryman]
20:04:55 [ericP]
... then we can use those ids.
20:04:58 [Arnaud]
ack aryman
20:05:17 [Labra3]
Labra3 has joined #shapes
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]
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 impelemented directly
20:08:44 [TallTed]
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]
20:09:32 [ericP]
Arnaud: so this falls in thes 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 introduce a new requirement for a new constraint class
20:10:44 [pfps]
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]
20:21:25 [pfps]
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 stared with Resource Shapes.
20:24:06 [ericP]
Arnaud: there are several ways to get conjunciton.
20:24:24 [ericP]
... it wansn'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]
20:24:54 [aryman]
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 , 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:39 [Labra_]
Labra_ has joined #shapes
20:26:41 [ericP]
... we'd have to think hard about inheritance
20:26:41 [ericP]
20:27:03 [ericP]
... one use case for that is when you wnat 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]
20:30:32 [Arnaud]
ack hknublau
20:30:34 [ericP]
Arnaud: we don't want to trhow 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:01 [Labra__]
Labra__ has joined #shapes
20:31:19 [aryman]
20:31:23 [ericP]
... aryman's algorithm can't be express 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
20:33:53 [trackbot]
RRSAgent, please draft minutes
20:33:53 [RRSAgent]
I have made the request to generate trackbot
20:33:54 [trackbot]
RRSAgent, bye
20:33:54 [RRSAgent]
I see no action items