IRC log of shapes on 2015-09-09

Timestamps are in UTC.

08:00:09 [RRSAgent]: RRSAgent has joined #shapes
08:00:09 [RRSAgent]: logging to http://www.w3.org/2015/09/09-shapes-irc
08:00:11 [trackbot]: RRSAgent, make logs rdf-data-shapes
08:00:11 [Zakim]: Zakim has joined #shapes
08:00:13 [trackbot]: Zakim, this will be SHAPES
08:00:13 [Zakim]: I do not see a conference matching that name scheduled within the next hour, trackbot
08:00:14 [trackbot]: Meeting: RDF Data Shapes Working Group Teleconference
08:00:14 [trackbot]: Date: 09 September 2015
08:00:32 [Arnaud]: present+ ericP, Arnaud, iovka, kcoyle, PhilA, hknublau, simonstey, pfps
08:00:46 [Arnaud]: chair: Arnaud
08:00:58 [hsolbrig]: hsolbrig has joined #shapes
08:01:40 [Dimitris]: πρεσεντ+ διμιτρισ
08:01:44 [Dimitris]: present+ diumitris
08:01:59 [simonstey]: I've another meeting @ 13:00 CEST but will return afterwards
08:02:06 [Arnaud]: ok
08:02:18 [Dimitris]: present+ dimitris
08:02:33 [aryman]: aryman has joined #shapes
08:03:07 [hsolbrig]: Uh, guys...
08:03:25 [hsolbrig]: the phone number above appears to be a phone sex line.
08:04:04 [aryman]: that's just Arnaud talking sexy
08:04:21 [hsolbrig]: Never mind.
08:04:26 [pfps]: which one? - not that I'm saying that you are wrong, but I'm listening to the people in Lille :-)
08:04:58 [Arnaud_]: Arnaud_ has joined #shapes
08:05:37 [Dimitris]: scribenick: dimitris
08:05:39 [pfps]: didn't that bleed into the IRC? I see something very strange from Dimitris
08:06:48 [aryman]: that's Greek to me
08:08:12 [Dimitris]: arnaud: we decided to work on a compact syntax along the lines of shex
08:09:12 [Dimitris]: .. Eric has some material he want's to present
08:09:20 [Arnaud_]: q?
08:09:58 [ericP]: http://www.w3.org/2015/Talks/0909-shex-egp/#%281%29
08:11:18 [Dimitris]: ericP: (presenting the slides)
08:12:42 [Labra]: Labra has joined #shapes
08:13:55 [pfps]: As far as I know, ShEx repetition is not a part of SHACL
08:14:32 [pfps]: q+
08:14:59 [pfps]: This appears to be strangely missing the possibility of following property links
08:15:29 [Arnaud_]: ack pfps
08:16:19 [aryman]: q+
08:16:22 [Dimitris]: pfps: this page (slide 3) is missing the idea of following property links
08:16:43 [pfps]: actually that is hidden as part of "triple constraint"
08:16:58 [Dimitris]: ... (ok found it)
08:17:02 [aryman]: Can we settle on an agreed term for a collections of shapes?. i.e. schema, shapes graphs, ...
08:20:54 [pfps]: The basic algebra of ShEx is very different from SHACL - conjunction vs addition
08:23:40 [pfps]: EXTRA doesn't add any power, as far as I know
08:23:41 [Dimitris]: ericP: (answering aruman on slide 3) extra allows other values
08:24:40 [PhilA]: q?
08:24:58 [Arnaud_]: ack aryman
08:24:59 [pfps]: doesn't SHACL handle IRI stems using patterns?
08:26:06 [pfps]: doesn't SHACL handle inclusion via AndConstraint?
08:26:20 [Dimitris]: ... semantic actions can do validation among other things
08:26:26 [pfps]: SHACL has EXTRA on by default
08:26:28 [pfps]: q+
08:27:20 [pfps]: as far as I know the only significant differences between SHACL and ShEx is the combination algebra and semantic actions
08:27:47 [pfps]: yes, ShEx partitions, and this makes ShEx processing hard
08:28:22 [Dimitris]: aryman: you have to compute all the partitions of each triples?
08:29:05 [Dimitris]: ericP: yes, when compute multiple occurences
08:29:38 [Dimitris]: iovka: we have a smart algorithm, worst case is np-complete
08:30:34 [PhilA]: q+ to ask if Iovka's algorithm should be in the spec?
08:30:47 [Arnaud_]: ack pfps
08:30:47 [Dimitris]: aryman: this feature is different from shacl
08:31:37 [Dimitris]: pfps: shacl supports IRI stems from patterns and inclusion from and constraints
08:31:52 [PhilA]: q-
08:32:11 [Arnaud]: Arnaud has joined #shapes
08:32:23 [Arnaud]: q?
08:35:56 [Arnaud]: pfps: you can achieve this using a union
08:36:45 [Arnaud]: ericp: the question is to figure out how to compile shex into shacl
08:37:04 [Arnaud]: pfps: shex doesn't have conjunctions
08:37:29 [pfps]: pfps: SHACL has both a universal and a counted construct
08:38:38 [Dimitris]: pfps:you 2-4 shoes that belongs to class A and 2-4 shoes belong to class B
08:38:57 [Dimitris]: .. in shex algebra you would count it once
08:39:05 [pfps]: pfps: as far as I can see the biggest difference between SHACL and ShEx is the combination algebra
08:39:53 [Dimitris]: iovka: if you want the same and it is additive then you would have to add negation
08:40:11 [Dimitris]: pfps: yes you would have to exclude the middle
08:40:58 [Dimitris]: iovka: I don't know what happens in you have unbound cardinality
08:41:04 [pfps]: pfps: in SHACL, values satisfiy different constraints independently; in ShEx, values can only satisfy one of a set of constraints
08:43:28 [Dimitris]: ericP: inclusion is like substituting, more like a macro
08:43:44 [Dimitris]: aryman: is there nesting in shex?
08:44:02 [pfps]: again, SHACL has this via AndConstraint,
08:44:14 [Dimitris]: ericP: you can do nesting with AND and OR in the same way with shacl
08:46:07 [pfps]: it's not an "AND" it's a "PLUS"
08:46:27 [Dimitris]: aryman: is there an implicit and and if you want an or you would explicit state it?
08:46:35 [Dimitris]: ericP:yes
08:48:04 [Dimitris]: aryman: your meaning of AND is different than SHACL
08:48:54 [Arnaud]: Arnaud has joined #shapes
08:48:55 [Arnaud]: q?
08:48:58 [Dimitris]: ericP: on multi occurrence it is obvious
08:51:18 [Arnaud]: q?
08:54:30 [Arnaud_]: Arnaud_ has joined #shapes
08:55:27 [hsolbrig]: q+ to ask whether slide 9 is shex-to-json or shex-to-SHACL
08:55:41 [hsolbrig]: q-
09:00:17 [Arnaud_]: q?
09:00:18 [Dimitris]: ericP: (discussing with pfps about ways to translate between shacl and shex)
09:01:29 [Dimitris]: ... it is easier to map from shex to shacl (rdf)
09:02:25 [pfps]: Is there a connection from here to a user-friendly syntax for SHACL?
09:04:07 [Dimitris]: arnaud: we have two different animals and we need a way to combine shex with shacl and how we deal with differences
09:04:14 [kcoyle]: q+
09:04:52 [pfps]: q+
09:05:26 [Arnaud_]: ack kcoyle
09:06:05 [Dimitris]: kcoyle: is shex a user-friendly language? we didn't see much syntax
09:06:12 [aryman]: q+
09:06:37 [Arnaud_]: ack pfps
09:06:46 [Dimitris]: ericP: we shown the syntax quite a few times in the past
09:07:23 [Dimitris]: pfps: shex syntax is fairly compact, easy to write & read, has a few peculiarities
09:07:44 [iovka]: +q
09:08:31 [Dimitris]: ... are the shex people in favor to remove conjuction?
09:09:01 [iovka]: to ask whether the shacl people are ready to turn conjunction into grouping ?
09:09:40 [Dimitris]: ericP: conjuction is the major issue
09:11:12 [Dimitris]: ... conjunction breaks user intuition. if shacl has features that are better for users we can go in that direction
09:11:31 [Dimitris]: s/conjuction/conjunction/
09:12:13 [Arnaud_]: ack aryman
09:13:14 [Dimitris]: aryman: I am with peter. I find it odd that people in this WG that develop their own tools. Let's see the differences and create a unified language
09:14:16 [Arnaud_]: ack iovka
09:14:44 [Dimitris]: iovka: what would it take for shacl people to translate conjunction in to grouping?
09:14:49 [PhilA]: q+
09:15:13 [Dimitris]: ... we should avoid having the same syntax for different languages
09:15:56 [Arnaud_]: ack PhilA
09:16:29 [pfps]: q+
09:16:37 [pfps]: q-
09:16:43 [pfps]: q+
09:16:47 [Dimitris]: PhilA: good to see consensus, the will be one W3C standard and we need to converge
09:16:49 [Arnaud_]: ack pfps
09:18:17 [Dimitris]: pfps: I don't see compromise reg. conjunction. Ideally we could add both approaches but not easy to implement
09:19:39 [pfps]: q+
09:19:47 [Dimitris]: arnaud: we can discuss with examples and test cases to see both approaches and decide later
09:20:51 [Arnaud_]: ack pfps
09:21:48 [Dimitris]: pfps: in the RDF(S) view point conjunction in the only way to go
09:22:40 [aryman]: q+
09:22:48 [Dimitris]: ... shex is a difficult language from a computation perspective
09:23:07 [iovka]: +q
09:23:51 [Dimitris]: ... according to iovka it is np-complete in worse case or maybe more
09:24:41 [iovka]: according to iovka it is in NP, perdiod. not more
09:24:54 [Dimitris]: ... if we go for a union someone has to make the argument if the computation and implementation cost worth it
09:25:06 [Arnaud_]: ack aryman
09:26:00 [Dimitris]: aryman: shacl is consistent with oslc
09:26:45 [Dimitris]: ... we have to understand the reality and see use cases
09:27:50 [Dimitris]: ... regarding complexity I trust iovka on optimizations
09:28:22 [Arnaud_]: ack iovka
09:29:12 [Dimitris]: iovka: people are working on np-complete every day.
09:30:11 [Dimitris]: ... academics found complexity problems in SPARQL property paths and OPTIONAL
09:30:34 [Dimitris]: ... in practice worst-case complexity doesn't happen
09:30:46 [Labra]: q+
09:31:34 [PhilA]: q+
09:31:57 [Dimitris]: arnaud: we can try to converge point by point
09:32:24 [Arnaud_]: ack Labra
09:32:34 [Dimitris]: labra: the differences are not that big
09:32:57 [Dimitris]: ... only in multi occurrence
09:33:24 [Arnaud_]: ack PhilA
09:33:43 [Dimitris]: PhilA: it's a year since you started 5 months ago
09:34:18 [Dimitris]: ... you published the UCR and I hear there are new use cases
09:34:33 [Dimitris]: ericP: the use case document does not capture this distinction
09:34:58 [Dimitris]: ... we have these in the wiki
09:35:12 [Dimitris]: PhilA: should be included in the UCR document
09:36:14 [Dimitris]: ... you have 1 year left
09:36:49 [PhilA]: Correction, you have nearly 2 years left (to June 2017)
09:37:40 [Dimitris]: arnaud: the ball is in shex people, the wg is open
09:38:54 [Dimitris]: ericP: if we can include multioccurrence it's fine, otherwise there is nothing else shex can give to the WG
09:39:59 [Dimitris]: ... multioccurrence is a very common pattern in shex
09:41:11 [Dimitris]: ... only lately we understood that there would be a single semantics for multi occurrence
09:41:16 [pfps]: which decision made two weeks ago?
09:42:49 [hknublau]: @pfps qcrs
09:42:51 [aryman]: q+
09:43:07 [pfps]: aah - four weeks ago
09:43:15 [Dimitris]: arnuad: I am concerned with take it or leave it approach. The path forward is clear. you need to make an effort to convince the group that your approach is better
09:44:07 [aryman]: I believe the main difference is that SHACL does not include the GroupShape operator defined in http://w3c.github.io/data-shapes/semantics/
09:45:05 [pfps]: it appears to me that the current SHACL semantics handles S47
09:45:10 [Arnaud_]: ack aryman
09:45:44 [pfps]: ... which is the use case underlying the multioccurence issue - ISSUE-53
09:46:03 [Dimitris]: aryman: GroupShape is what is missing from shacl. If we add that to shacl would it satisfy you
09:46:17 [Labra]: The decision was: http://www.w3.org/2015/08/13-shapes-minutes.html#resolution04
09:46:35 [Dimitris]: ericP: that's true
09:46:37 [Labra]: The open issue was closed at that meeting
09:47:11 [Dimitris]: iovka: adding groupShape might be possible but we need to understand the semantics of the rest of shacl
09:47:24 [Labra]: And the issue was about multi-occurrance of the same predicates
09:47:48 [pfps]: the underlying operations in ShEx are different from those in SHACL
09:48:11 [kcoyle]: q+
09:48:25 [PhilA]: q+
09:48:47 [Arnaud_]: ack kcoyle
09:49:27 [Dimitris]: kcoyle: does the first working draft depend on this?
09:49:30 [Arnaud_]: ack PhilA
09:50:08 [pfps]: q+
09:50:54 [Dimitris]: PhilA: it's not good to hear from any WG member "either we do this or we walk away". We all need each other and have to do compromises
09:50:55 [Arnaud_]: ack pfps
09:52:09 [Dimitris]: pfps: sorry if I sound bitter but the WG has been working without the shex people for some time now and we are not less viable
09:52:39 [Dimitris]: ... shacl is a result of quite a few compromises already
09:57:03 [Dimitris]: ... one solution would be to combine rdfs with recognition but it requires an owl reasoner and I don't think anyone would go with this approach
09:58:32 [pfps]: I perfect way to proceed here is to show that S47 is not currently handled in SHACL
09:59:38 [pfps]: q+
10:00:28 [Arnaud_]: ack pfps
10:00:56 [PhilA]: RRSAgent, draft minutes
10:00:56 [RRSAgent]: I have made the request to generate http://www.w3.org/2015/09/09-shapes-minutes.html PhilA
10:01:21 [Dimitris]: pfps: the basic design in shacl had one change with the qualified cardinality
10:01:44 [Dimitris]: ... in the past months
10:02:51 [Dimitris]: ericP: do I have to prove that the behaviour in slide 4 would act different in shacl?
10:03:24 [Dimitris]: pfps: you need to show that there is a use case that cannot handled by shacl
10:04:35 [Dimitris]: ... S47 is a good example
10:04:39 [PhilA]: -> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S47:_Clinical_data_constraints S47
10:08:01 [Arnaud_]: http://www.w3.org/2015/Talks/0909-shex-egp/#%284%29
10:09:00 [Dimitris]: ericP: (discussing about slide 4 with Peter and Arthur)
10:15:23 [simonstey]: I'll join again later this afternoon
10:57:15 [simonstey]: simonstey has joined #shapes
11:10:04 [kcoyle]: kcoyle has joined #shapes
11:12:30 [Arnaud]: Arnaud has joined #shapes
11:12:36 [PhilA]: PhilA has joined #shapes
11:12:50 [Arnaud]: we're back on, you guys call in
11:13:34 [aryman]: aryman has joined #shapes
11:14:21 [hknublau]: present+ hknublau
11:15:18 [hsolbrig]: scribnic: hsolbrig
11:15:55 [hsolbrig]: scribnick: hsolbrig
11:16:24 [hsolbrig]: arnaud: we need to know who is in charge and who we can depend on to lead the test suite and what needs to be done
11:16:56 [Labra]: Labra has joined #shapes
11:17:00 [ericP]: https://github.com/shexSpec/shexTest
11:17:25 [PhilA_]: PhilA_ has joined #shapes
11:17:52 [hsolbrig]: ericP: the goal of the ShEx test suite is to test a given node in a given graph on a given shape in a given schema
11:18:25 [pfps]: present+ pfps
11:18:30 [hsolbrig]: ericP: Fail or pass, but if pass we've defined a preferred solution so we can move the "semantic actions" out of band
11:18:50 [hsolbrig]: ... we expect this group will be interested in just pass or fail
11:19:19 [hsolbrig]: ... covers ShEx language features first, but will be happy to do the non-ShEx SHACL stuff as well
11:20:06 [hsolbrig]: ... one issue is to what degree we can standardize errors. If we treat it as yes, here's a proof and no, here's an error, we need consistent error reporting
11:21:19 [hsolbrig]: Arnaud: XML Schema stayed away from trying to dictate how an implementation functions. Have an open issue on results and are having second thoughts on whether we should go there at all...
11:22:00 [hsolbrig]: Arnaud: If spec says "This error returns this information", we need to test that, but maybe simpe T/F is good enough for the test suite
11:22:19 [iovka]: iovka has joined #shapes
11:22:58 [pfps]: q+
11:23:13 [hknublau]: q+
11:23:19 [hsolbrig]: ericP: We haven't done anything in ShEx yet. True is give a proof, false is just false
11:23:31 [Arnaud]: ack pfps
11:23:53 [hsolbrig]: pfps: It is not "errors" - it is violation reports.
11:24:30 [hsolbrig]: ... it is very important to get back information on the violations.
11:24:53 [hsolbrig]: ... test suite needs to say what violations are reported.
11:26:05 [PhilA_]: q+
11:26:28 [hsolbrig]: ... example, SHACL says "Hey, check whether everyone has a name", an answer of "No" isn't useful.
11:27:08 [hsolbrig]: ericp: Does this work when you get into complicated shapes?
11:27:59 [hsolbrig]: Arnaud: If I have a graph with 2 violations, do both need to be reported?
11:28:10 [hsolbrig]: pfps: Editor's draft says what happens there.
11:28:31 [hknublau]: https://github.com/w3c/data-shapes/blob/gh-pages/data-shapes-test-suite/tests/features/core/manifest.ttl
11:28:50 [PhilA]: q-
11:28:55 [hsolbrig]: Arnaud: Some implementation may keep on going, some may report first error only
11:28:56 [PhilA]: +1 to Arnaud
11:29:03 [Arnaud]: ack hknublau
11:29:09 [PhilA]: q- PhilA
11:29:37 [hsolbrig]: hknublau: We've had resolutions on that topic and want the ability to specify details including invalid value and details. Has been decided.
11:30:11 [hsolbrig]: ... look at test cases in link above, each can have more mf result objects, data that comes back from validation
11:31:19 [pfps]: I would view SHACL engines that don't produce violation results as broken
11:31:46 [hsolbrig]: ericP: Answer seems to be there. Engines that are just interested in T/F can just detect and don't need to emulate details.
11:32:31 [hsolbrig]: hknublau: I have a solution, but we should really have a different pair of eyes build the test cases.
11:32:44 [kcoyle]: q+
11:33:14 [hsolbrig]: ericP: I can work on the test suite and maintain it.
11:33:19 [Arnaud]: ack kcoyle
11:34:27 [hsolbrig]: kcoyle: Issue 51, types of validation results, only stated type of validation is open and people could develop their own. Don't know about details
11:35:06 [hsolbrig]: Arnaud: Details are part of issue 51 discussion
11:36:08 [hsolbrig]: kcoyle: Would love to provide tests, but don't have SHACL writers, how can we provide
11:36:41 [hknublau]: (BTW the test results are an example where a detailed data model of constraints (schema) may be needed - each violation should point back to the constraint instance, e.g. the object holding the minCount property).
11:36:47 [hsolbrig]: ericP: We have ShEx to SHACL translator.
11:37:10 [PhilA]: s/ericP/Labra/
11:37:10 [ericP]: s/ericP: We have ShEx to SHACL translator./labra: We have ShEx to SHACL translator./
11:37:19 [hsolbrig]: Labra: In general, translation works.
11:37:57 [hsolbrig]: Arnaud: We need to know what is needed to contribute a test
11:38:39 [hsolbrig]: Labra: Some new things in ShEx I don't know how to translate to SHACL...
11:38:50 [hsolbrig]: ... don't what the methodology will be to add new tests.
11:38:55 [Labra]: A tool to convert between syntaxes: http://rdfshape.herokuapp.com/converter/schema
11:39:12 [simonstey]: holger has a lot of tests for his SHACL API
11:40:13 [hsolbrig]: hknublau: Link to manifest file is all we have right now... the rest haven't been integrated.
11:40:50 [hsolbrig]: hknublau: ... new tests would be new folder w/ manifest file w/ results and instructions along with tests and data
11:41:22 [hsolbrig]: ... data is in one folder up from manifest
11:41:30 [simonstey]: @jose Bad request For request 'GET /converter/schema' [Missing parameter: schema]
11:42:23 [hsolbrig]: ... I've put SHACL and data in same file, but they don't have to be. I wish results would be in same file but...
11:42:49 [Labra]: http://rdfshape.herokuapp.com/
11:43:14 [Labra]: That's the right link
11:43:37 [hsolbrig]: ... there is a meta-manifest file a couple of folders up that you need to add manifest to
11:45:29 [simonstey]: thx
11:45:32 [Labra]: Example of a conversion from compact syntax to SHACL (Turtle): http://goo.gl/JnAJiT
11:45:41 [hsolbrig]: ericP: Manifest format comes from multiple groups. Usually run with manifest file, meta-manifest file, instance data and some representation of results. Tests generate "ERL" (eval and reporting language) reports
11:46:01 [hsolbrig]: ... pushes off the task of result interpretation
11:46:26 [hsolbrig]: Arnaud: We have a framework, Eric will contribute tests.
11:46:34 [hknublau]: q+
11:46:53 [hsolbrig]: ericP: Tests are amethodical exploration of the language.
11:47:20 [hsolbrig]: Arnaud: How much do you think you really cover in the language?
11:48:25 [hsolbrig]: ericP: I'm about 10% of the way through. Have parser tests for ShEx and then several different tests for inputs. Meant to be pretty rigorous..
11:48:38 [hsolbrig]: ... also have tests to cover different logical permutations
11:48:42 [Arnaud]: ack hknublau
11:49:13 [hsolbrig]: hknublau: If the process just becomes a dump from ShEx, not helpful. Should be custom designed for SHACL, not ShEx
11:50:00 [hsolbrig]: ... someone needs to try to come up with test cases from the SHACL point of view. I don't want to have to guess whether this test is supposed to work or not.
11:50:28 [hsolbrig]: Arnaud: I'm not going to turn down offers. Are there other volunteers?
11:50:54 [pfps]: I expect to be contributing tests, but probably not systematically
11:51:23 [hsolbrig]: ... we should start with ShEx and find areas that need to be beefed up for SHACL
11:51:55 [hsolbrig]: ... we need to resolved issues as tests.
11:52:24 [hsolbrig]: ericp: In SPARQL, an issue was presented with two mutually exclusive tests -- only one of which would pass depending on how the issue was resolved.
11:53:15 [hsolbrig]: Arnaud: Will you contribute as you go or will it be incremental?
11:54:38 [hsolbrig]: ericP: naming conventions, etc. require periodic refactoring ... easier to do in one place ... don't want to have vestigial crap lying around from renaming.
11:55:47 [hsolbrig]: Arnaud: as ShEx will merge w/ SHACL, can't we just have one repository?
11:58:02 [hsolbrig]: ericP: In the DAWG we had tests that said "Unextended SPARQL did this" but we also had tests that could be annotated as being extended by specific features. We could do that here
11:58:25 [PhilA]: q+
11:58:26 [hsolbrig]: ... e.g. EXTRA being ShEx only
11:59:06 [hsolbrig]: ... testing could be modal.
11:59:23 [Arnaud]: ack PhilA
12:00:26 [hsolbrig]: PhilA: Part of a test case is use cases, use cases should be part of test suite.
12:01:53 [hsolbrig]: ... RDF data that you are checking could be submitted w/o necessarily writing ShEx. Data could or be provided that did and didn't pass use cases.
12:04:29 [hsolbrig]: pfps: Lets get Karen to dump some examples and the rest of us can circle around it to build SHACL tests.
12:05:49 [hsolbrig]: Arnaud: Can Karen create a sub-directory under tests directory and start adding data?
12:06:47 [hsolbrig]: Kcoyle: Will create identified directory (e.g. dcmi) underneath -- so people can track source
12:08:16 [hsolbrig]: Arnaud: How do people feel about eric using a repo w/ stuff that belongs to ShEx only?
12:08:54 [hsolbrig]: hknublau: I'm skeptical. Will lead to a dump of files that don't work and will require a lot of energy. Wouldn't count on this happening or working
12:09:31 [hsolbrig]: hknublau: Would recommend that actual test cases only use TTL. ShEx will just be parser tests
12:09:47 [pfps]: as long as there is a clear distinction saying what is what how does it harm things if there is some other stuff there
12:10:00 [hsolbrig]: hknublau: We shouldn't force anyone to use compact syntax.
12:10:25 [hsolbrig]: Arnaud: Will keep repo separate for now.
12:11:40 [hsolbrig]: hknublau: withdrawing objection to specification including SPARQL definitions.
12:13:05 [Arnaud]: issue-44
12:13:05 [trackbot]: issue-44 -- How to express dependencies between graphs -- open
12:13:05 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/44
12:14:21 [hsolbrig]: hknublau: Suppose you want to validate something against a controlled list of terms (e.g. country codes). 3 graphs -- reference data, definition of macro and data graph itself. How can a tool that just gets a data graph
12:14:36 [hsolbrig]: ... get instructions on how to get what it is supposed to use?
12:15:36 [hsolbrig]: ... I've suggested a mechanism similar to OWL:Import w/ local mechanisms.
12:16:10 [pfps]: q+
12:16:35 [Arnaud]: ack pfps
12:17:19 [hsolbrig]: pfps: RDF should have resolved this but they didn't.
12:18:16 [hsolbrig]: .... does SHACL need to again, take out this "RDF garbage" or should we just say "not our problem -- marshalling is done elsewhere"
12:18:45 [hsolbrig]: ... another option would be to supply information in invocation
12:19:17 [hsolbrig]: ... ya option would be to just use owl:imports
12:19:53 [hsolbrig]: ... problem is if data or control IS OWL, what should owl do?
12:20:46 [hknublau]: q+
12:20:59 [hsolbrig]: ... no good way forward. Only a least bad way, which is to "be an ostrich" and say not our problem.
12:21:04 [Arnaud]: ack hknublau
12:22:20 [pfps]: one problem with an imports directive is how to handle redirection
12:22:38 [pfps]: q+
12:22:40 [hsolbrig]: hknublau: Two different types of imports, can't just rely on owl:imports
12:22:46 [aryman]: q+
12:22:53 [ericP]: scribnick: ericP
12:23:03 [ericP]: Arnaud: why do we need to have two different imports?
12:23:12 [pfps]: q-
12:23:18 [ericP]: ... why is it important to distinguish the import of data or schema?
12:23:28 [ericP]: hknublau: the opperation requires two graphs
12:23:53 [ericP]: ... the transitive closure of the imports graph would create the input graph
12:23:59 [Arnaud]: ack aryman
12:24:05 [ericP]: ... we don't want the validation to always include the shapes graph
12:24:31 [hsolbrig]: aryman: I thought we already had a property that linked a graph to a shape...
12:24:32 [ericP]: aryman: why do we need another property to connect data to shapes?
12:24:42 [ericP]: ... in a linked data world, you can just follow the link
12:25:10 [ericP]: ... i think that dictating how you build up the data graph is outside the WG
12:25:23 [ericP]: hknublau: of course it would be nicer to have the import in the rdf namespaces
12:25:43 [ericP]: ... in many cases, you can't dereference.
12:26:07 [ericP]: aryman: the assumption in XML was that your document could point to a schema
12:26:28 [ericP]: ... you didn't need to GET that graph.
12:26:50 [ericP]: ... there's a standard for XML catalogs supported by e.g. Protege
12:27:05 [ericP]: ... can we standardize schema, shapes graph
12:27:35 [ericP]: hknublau: pfps uses "control graph" but there are other controls
12:27:52 [ericP]: aryman: so why another imports?
12:28:24 [ericP]: hknublau: so in TBC, a user starts an empty file and they need to link to the shapes graph
12:28:50 [ericP]: aryman: don't we have a property that links a graph to a shapes graph?
12:29:17 [ericP]: ... these URIs should be dereferencable. if they're not, we need an e.g. catalog mechanism
12:30:03 [ericP]: Arnaud: when we talk about inferencing, we say "it's outside shacl. is there's inferencing to be done, do it before. likewise e.g. HTTP GET"
12:30:25 [ericP]: ... so we can say "we don't go there; it must be done before"
12:30:42 [ericP]: hknublau: we have a hint property called sh:entailment
12:31:00 [ericP]: ... nobody's forced to use them.
12:31:11 [pfps]: q+
12:31:36 [ericP]: ... i feel we're not looking at my needs
12:32:01 [ericP]: Arnaud: by the same token, if no one else supports it, what's the good of calling it a standard?
12:32:10 [Arnaud]: ack pfps
12:32:53 [ericP]: pfps: do we have a use case for this?
12:33:38 [Dimitris]: q+
12:33:49 [Arnaud]: ack Dimitris
12:34:12 [ericP]: Dimitris: i find this useful but i would limit it to certain graphs
12:34:30 [ericP]: ... so if i have a library of definitions, it would be nice to include other shapes
12:34:46 [ericP]: ... but i wouldn't extend that to the instance graph
12:35:22 [ericP]: ... i think the data import is out of scope
12:35:32 [ericP]: hknublau: so use owl:imports?
12:36:01 [pfps]: I also agree that being able to use external information in shapes graphs is useful - I think that there is a use case on this somewhere
12:36:10 [ericP]: Arnaud: apart from the fact that we're not using anything from OWL, what would happen to e.g. composer?
12:36:52 [ericP]: hknublau: TBC respects owl:imports. at a minimum, i'd need the shapes import
12:36:54 [aryman]: q+
12:37:35 [ericP]: Arnaud: there seems to be less resistance to the shapes import?
12:37:36 [pfps]: q+
12:37:39 [Arnaud]: ack aryman
12:37:47 [ericP]: hknublau: then how do we distinguish a shapes graph?
12:37:48 [hknublau]: https://www.w3.org/2014/data-shapes/wiki/Requirements#Including_Named_Graphs_for_Query_Evaluation
12:38:06 [Dimitris]: q+
12:38:18 [Labra]: q+
12:38:21 [ericP]: aryman: if we adopt "library", can we call it something other than "library" and define it beying a grab of triples?
12:38:34 [ericP]: hknublau: spec out of data on his
12:38:45 [ericP]: ... [ details on RDFS for this ]
12:39:26 [ericP]: ... if TBC encounters a link to a link, it dereferences it "somehow"
12:39:44 [ericP]: aryman: you also need the library include in the shapes graph?
12:39:45 [Arnaud]: ack pfps
12:39:52 [ericP]: hknublau: use for e.g. country code example
12:40:36 [ericP]: pfps: there was a dc (or cataloging)-related one for pointing to a slew of valid stuff
12:40:58 [ericP]: ... partly to reuse and partly because they were painful to include
12:41:13 [ericP]: ... i would not be opposed to a mechanism to build up the shapes graph
12:41:35 [ericP]: kcoyle: since pfps ref'd cc, most of our stuff is too big to actually be included.
12:41:56 [ericP]: ... we deference one URI at a time
12:42:18 [ericP]: ... some of it isn't easily includable
12:42:35 [ericP]: ... we pull in pieces at a time, not the whole file
12:42:58 [aryman]: q+
12:43:03 [ericP]: pfps: you want the validation process to work in an impoverished env
12:43:15 [ericP]: kcoyle: we live in an impoverished env
12:43:35 [ericP]: ... our programmars are assuming they'll have to do the imports manually
12:43:52 [ericP]: ... we don't have a mechanism to know what we have to derefernce
12:44:06 [hknublau]: Karen talks about http://www.w3.org/2014/data-shapes/track/issues/80
12:44:34 [ericP]: pfps: so taking LoC, we have a shape that says your LoC catalog number has to be in the reference
12:44:42 [ericP]: kcoyle: order 300M
12:45:23 [ericP]: pfps: so the use case is going to be that "the value exist in the value set", and thus painful to include
12:46:05 [ericP]: ... so it's better to isolate the LoC catalog
12:46:43 [ericP]: kcoyle: this will be externally ref'd e.g. by Z39.50
12:46:55 [ericP]: pfps: right, it's part of the control information
12:47:17 [Arnaud]: ack Dimitris
12:47:43 [ericP]: Dimitris: we shuold see if we can include something similar for ontologies
12:48:00 [ericP]: ... e.g. my FOAF definition includes this source of shapes
12:48:11 [ericP]: hknublau: so similar to the class owl:Ontology?
12:48:32 [ericP]: Dimitris: so i have some FOAF and i reference the shapes file to which my FOAF complies
12:49:18 [ericP]: hknublau: when you use these class definitions, because they're needed for validation, you include them by sh:dataGraph - sh:includes...
12:49:40 [ericP]: Dimitris: could use sh:include or find another property for ontologies
12:50:11 [Arnaud]: ack Labra
12:50:58 [ericP]: in ShEx, you can import a schema from another.
12:51:44 [ericP]: Labra: in ShEx, you can import a schema from another
12:52:03 [ericP]: s/in ShEx, you can import a schema from another.//
12:52:24 [ericP]: Labra: we have the notion of shapes graph in ShEx, which is i think the same as a shapes graph
12:52:45 [ericP]: ... i'm not opposed to an import mechanism for schemas, but i think data importers are out of scope
12:53:25 [hknublau]: <> sh:shapesGraph <…>
12:53:30 [ericP]: ... but to what node is the import property attached?
12:54:10 [ericP]: ... if we have to the notion of a shapes graph, how do we know that shapes are in a schema?
12:54:13 [ericP]: q+
12:54:22 [Arnaud]: ack aryman
12:54:45 [ericP]: aryman: replying to kcoyle, the feature that i was describing only applies to the data graph
12:55:11 [ericP]: ... you can link to say that a node conforms to a shape, but a validator isn't support to do anything with that
12:55:56 [ericP]: ... we should have a mechanism to address kcoyle's case with large amounts of data using SERVICE
12:56:18 [ericP]: ... or we could extend the notion of allowed values to match a URL pattern
12:56:32 [ericP]: ... but for kcoyle's use case we need to do distributed computing
12:57:57 [ericP]: hknublau: the proposal is two properies sh:include and sh:shapesGraph, used for pre-processing before validation
12:58:26 [ericP]: ... we could add a class called sh:Graph to give the range a type
12:59:32 [ericP]: Arnaud: this proposal never got enough support to get beyond "proposed"
13:00:00 [ericP]: q?
13:00:08 [Arnaud]: ack ericP
13:01:04 [hsolbrig]: ericP: owl:imports doesn't do anything semantically...
13:01:19 [hsolbrig]: pfps: correct. Just "do this"
13:01:54 [hsolbrig]: ericP: analog for us would be document #include schema / schema #include schema. No need to connect content of document with document itself..
13:02:07 [hknublau]: rdfs:isDefinedBy?
13:02:48 [hsolbrig]: Labra: If we are talking about including a shapes graph in another, we need to know what shapes were imported...
13:03:12 [hsolbrig]: Arnaud: Will SHACL engine do anything different or is it just useful information?
13:04:02 [hsolbrig]: ericP: @pfps - was there any discussion about connections between descriptions in document with document itself?
13:04:17 [ericP]: scribenick: hsolbrig
13:04:42 [hsolbrig]: pfps: Social meaning discussion -- if you used whitehouse.gov you were obligated to assert that bush was great president...
13:05:07 [hsolbrig]: pfps: ... requires social meaning contract that whitehouse.gov website is about whitehouse
13:05:34 [hsolbrig]: ericP: If we do it the owl way, there is no way to make this connection.
13:06:22 [hsolbrig]: doublespeak
13:06:38 [pfps]: q+
13:06:43 [Arnaud]: ack pfps
13:06:47 [hsolbrig]: Arnaud: Consensus about sh:shapesGraph, but not about sh:include...
13:07:48 [hsolbrig]: pfps: I thought it was the opposite? shapesGraph goes from data to shapesGraph. Eric should barf about this one
13:08:26 [hsolbrig]: ... consensus that we want to put something in a shapes graph that pulls another graph in.
13:09:32 [hsolbrig]: Arnaud: equiv to the XML omission of a way to say "this is my schema"
13:10:12 [hsolbrig]: Arnaud: inclusion of one graph is non-controversial. We can fight over names later.
13:10:39 [pfps]: I'm not wildly enthusiastic about it, but it's probably a good idea to be able to split the shapes graph.
13:11:00 [hsolbrig]: ericp: 3 things? Data -> schema, schema->schema, data->data. Schema is non-controversial, maybe same pred for data->schema, but hands off data->data
13:11:28 [hsolbrig]: hknublau: blib, click, burble, cliatter
13:12:44 [hsolbrig]: hknublau: Topbraid people open shapes graph directly and edit it as data. Not always clear whether it is shape or data graph. Implementation uses owl:imports, sh:include, sh:shapesgraph together ... click clatter bloop
13:13:39 [pfps]: q+
13:13:48 [Arnaud]: ack pfps
13:14:17 [hsolbrig]: Arnaud: is anyone fighting for data to data?
13:14:42 [kcoyle]: q+
13:15:23 [hsolbrig]: Arnaud: I understand special link for data to schema, but why data to data ... is it because links aren't typed?
13:16:34 [hsolbrig]: ericP: The issue is whether or not you work with systems where schema and data are mixed. If they are mixed, they have different effects.
13:17:15 [hsolbrig]: kcoyle: won't there be a difference in the target as well -- data graph vs. schema graph.
13:17:29 [hsolbrig]: ericP: both of these things are unordered, no artifact left
13:17:35 [Arnaud]: ack kcoyle
13:18:18 [hsolbrig]: kcoyle: yesterday we talked about a mechanism to create a named value stack?
13:19:13 [hsolbrig]: ... allowed value into macro. Wouldn't that perform same function as include?
13:20:30 [pfps]: can we have a split proposal?
13:21:52 [pfps]: the problem with one link is what do you do if you want to validate a schema graph?
13:22:13 [hsolbrig]: ericP: data to schema and schema to schema are both schema triples, do we need to differentiate?
13:22:16 [aryman]: q+
13:22:26 [Arnaud]: PROPOSED: have a mechanism to include a schema into another schema
13:22:34 [hknublau]: +1
13:22:35 [simonstey]: +1
13:22:36 [pfps]: +1
13:22:38 [Arnaud]: ack aryman
13:22:40 [Dimitris]: +1
13:22:47 [ericP]: +1
13:22:52 [hsolbrig]: +1
13:22:53 [kcoyle]: +1
13:22:56 [Labra]: +1
13:23:02 [aryman]: +1
13:23:28 [Arnaud]: RESOLVED: have a mechanism to include a schema into another schema
13:25:20 [aryman]: q+
13:25:29 [Arnaud]: ack aryman
13:25:57 [Arnaud]: PROPOSED: have a mechanism to link a data graph to a schema
13:26:01 [hknublau]: +1
13:26:11 [pfps]: -0.7
13:26:15 [hsolbrig]: +1
13:26:20 [aryman]: +1
13:26:22 [ericP]: +0
13:26:26 [kcoyle]: +1
13:26:35 [Dimitris]: +1
13:26:35 [simonstey]: +1
13:26:47 [Labra]: 0
13:27:20 [Arnaud]: RESOLVED: have a mechanism to link a data graph to a schema
13:28:59 [hsolbrig]: ericP: I've got schema X and the datashapes schema for shapes and want to test that X is compliant with that. Schema X has a schema include and a data to schema include...
13:29:32 [hsolbrig]: ,,, one of those is for sucking down stuff and the other is for validation.
13:31:21 [Arnaud]: PROPOSED: call the mechanism to link a data graph to a schema sh:shapesGraph
13:31:57 [hknublau]: +1
13:32:41 [aryman]: +1
13:32:44 [Dimitris]: +1
13:32:45 [ericP]: 0
13:32:49 [kcoyle]: kcoyle +0
13:32:51 [hsolbrig]: +1
13:32:52 [Labra]: 0
13:32:55 [pfps]: +0 I don't care what this is called, as long as it is different from the schema inclusion link
13:33:15 [Arnaud]: ED: call the mechanism to link a data graph to a schema sh:shapesGraph
13:33:21 [Arnaud]: RESOLVED: call the mechanism to link a data graph to a schema sh:shapesGraph
13:33:50 [Arnaud]: PROPOSED: have a mechanism to include a data graph into another data graph
13:33:54 [aryman]: +0
13:33:56 [pfps]: -1
13:34:12 [simonstey]: -0.5
13:34:13 [Dimitris]: -.05
13:34:24 [kcoyle]: -0
13:34:27 [hsolbrig]: -1
13:34:35 [Labra]: -0.5
13:35:12 [hsolbrig]: hknublau: that means people would continue to use owl:imports?
13:35:20 [hsolbrig]: a: that or something external
13:35:39 [aryman]: sh:includeShapes
13:35:57 [simonstey]: sh:includeShapesGraph
13:36:10 [pfps]: I like incudeShapes
13:36:16 [Dimitris]: sh:includes should do, sh: implies shapes
13:37:19 [hsolbrig]: hknublau: Just creating a union graph by all the includes.
13:37:38 [hsolbrig]: aryman: how would all the data in value lists be referenced by the shapes? SPARQL query?
13:37:43 [Arnaud]: PROPOSED: call the mechanism to include a schema into another schema sh:includeShapes
13:37:48 [hsolbrig]: hnkublau: that, walk a path and other use cases.
13:37:52 [hsolbrig]: +1
13:37:58 [kcoyle]: +1
13:38:01 [aryman]: +1
13:38:05 [Labra]: 0
13:38:07 [Dimitris]: +1
13:38:20 [simonstey]: +1
13:38:24 [ericP]: +1
13:38:34 [hknublau]: -1
13:39:04 [ericP]: ±1
13:39:06 [ericP]: ∓
13:39:15 [pfps]: +1
13:39:19 [hsolbrig]: hknublau: I don't see why we just don't do sh:include....
13:39:33 [hsolbrig]: Arnaud: 20 minute break. Resume at the hour.
14:00:49 [aryman]: aryman has joined #shapes
14:01:51 [Labra]: Labra has joined #shapes
14:02:08 [Labra]: +present labra
14:05:25 [pfps]: +present pfps
14:05:34 [pfps]: ?present arnaud?
14:05:46 [aryman]: scribeNick: aryman
14:05:55 [Arnaud]: pfps, we
14:05:59 [Arnaud]: 're back
14:06:06 [Arnaud]: if you don't hear us there is a problem
14:06:30 [aryman]: agenda: https://www.w3.org/2014/data-shapes/wiki/F2F4#Day_2_-_Wednesday_September_9
14:07:06 [aryman]: TOPIC: General Inclusion Mechanism
14:07:25 [simonstey]: present+ simonstey
14:07:37 [Dimitris]: present+ dimitris
14:07:50 [aryman]: Arnaud: if we want a generic include mechanism then use owl:imports
14:08:44 [pfps]: owl:imports is a general inclusion mechanism, albeit one tilted towards ontology inclusion
14:08:52 [kcoyle]: +q
14:09:12 [Arnaud]: ack kcoyle
14:09:34 [simonstey]: what should happen if one uses shacl with owl and then uses owl:imports&sh:include together?
14:10:36 [aryman]: knublau: we might as well use owl:imports instead of defining sh:includeShapes
14:11:24 [Dimitris]: why don't we make the reverse proposal?
14:11:42 [aryman]: Arnaud: why are people opposed to sh:include?
14:12:09 [aryman]: hsolbrig: it's a general RDF requirement and is out-of-scope for SHACL
14:12:13 [ericP]: it's arguable that SPARQL would have been the place to define this
14:12:44 [pfps]: q+
14:12:56 [Arnaud]: ack pfps
14:13:27 [aryman]: pfps: there is no argument against SHACL using owl:imports
14:13:40 [ericP]: i want to unionize RDF graphs
14:13:46 [simonstey]: I've the same argument as peter
14:14:00 [hsolbrig]: triples of the world unite!
14:14:18 [aryman]: hknublau: I can live with owl:imports
14:14:38 [Arnaud]: PROPOSED: add a note stating that owl:imports can be used for general inclusion (data to data and schema to schema)
14:14:45 [simonstey]: +1
14:14:46 [hknublau]: +1
14:14:47 [aryman]: +1
14:14:57 [hsolbrig]: +1
14:15:00 [ericP]: +1
14:15:01 [Labra]: +0.5
14:15:04 [pfps]: +0
14:15:10 [Dimitris]: does this mean we will drop sh:includeSHapes?
14:16:01 [aryman]: Arnaud: yes, this means drop sh:includeShapes
14:16:07 [Dimitris]: 0
14:16:29 [kcoyle]: +1
14:16:35 [Arnaud]: RESOLVED: add a note stating that owl:imports can be used for general inclusion (data to data and schema to schema)
14:18:45 [aryman]: q+
14:18:48 [Arnaud]: PROPOSED: Close ISSUE-44, based on the last two resolutions (sh:shapesGraph and owl:imports)
14:18:54 [hknublau]: +1
14:18:57 [pfps]: +0
14:19:00 [aryman]: +1
14:19:00 [hsolbrig]: +1
14:19:04 [simonstey]: +1
14:19:04 [Arnaud]: ack aryman
14:19:06 [kcoyle]: +1
14:19:16 [ericP]: +0
14:19:25 [Dimitris]: +0.5
14:20:22 [Arnaud]: RESOLVED: Close ISSUE-44, based on the last two resolutions (sh:shapesGraph and owl:imports)
14:25:27 [aryman]: TOPIC: ISSUE-29
14:25:36 [pfps]: issue-29
14:25:36 [trackbot]: issue-29 -- Formalism for definition of high-level language -- open
14:25:36 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/29
14:25:37 [Arnaud]: issue-29
14:25:37 [trackbot]: issue-29 -- Formalism for definition of high-level language -- open
14:25:37 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/29
14:26:05 [pfps]: q+
14:26:11 [Arnaud]: ack pfps
14:27:54 [aryman]: pfps: We have decided to use SPARQL (like options c or d in description of issue)
14:28:04 [pfps]: I think that the answer that has been chosen is "SPARQL plus an extension function for recursive shapes"
14:28:32 [Arnaud]: PROPOSED: Close ISSUE-29, as already resolved using "SPARQL plus an extension function for recursive shapes"
14:30:38 [hknublau]: rdf:rest*/rdf:first
14:32:25 [hknublau]: +1
14:32:38 [aryman]: +1
14:32:41 [simonstey]: +1
14:32:44 [kcoyle]: +1
14:32:47 [Labra]: -0.99
14:33:15 [pfps]: +1
14:33:22 [Dimitris]: +1
14:34:09 [ericP]: -0.99
14:34:59 [simonstey]: didn't we agree on using sparql for defining the semantics? (except of certain corner cases like recursive shapes)
14:35:35 [Arnaud]: RESOLVED: Close ISSUE-29, as already resolved using "SPARQL plus an extension function for recursive shapes"
14:37:11 [Arnaud]: issue-28
14:37:11 [trackbot]: issue-28 -- Is the macro facility part of the high-level language or of the extension mechanism? -- open
14:37:11 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/28
14:37:12 [aryman]: TOPIC: ISSUE-28
14:38:49 [Arnaud]: PROPOSED: Close ISSUE-28, as no longer relevant
14:38:53 [pfps]: +1
14:38:54 [aryman]: +1
14:38:56 [simonstey]: +1
14:38:57 [kcoyle]: +1
14:39:03 [hknublau]: +1
14:39:04 [Dimitris]: +1
14:39:04 [ericP]: +
14:39:15 [Labra]: 0
14:39:23 [hsolbrig]: +1
14:39:35 [Arnaud]: RESOLVED: Close ISSUE-28, as no longer relevant
14:40:36 [pfps]: issue-41
14:40:36 [trackbot]: issue-41 -- Using property paths to refer to values/types? -- open
14:40:36 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/41
14:40:38 [aryman]: TOPIC: ISSUE-41
14:41:14 [aryman]: lot of static
14:44:10 [aryman]: Simon: describes using property paths to refer to values instead of using literal constants
14:48:16 [Dimitris]: even without a property path we can have multiple values
14:50:37 [aryman]: Arnaud: who else finds this useful?
14:50:54 [pfps]: the age of people's parents are greater than 21
14:51:07 [pfps]: q+
14:51:27 [Dimitris]: property paths could be expanded to all sh:property facets
14:51:54 [simonstey]: http://w3c.github.io/data-shapes/data-shapes-ucr/#uc32-non-sparql-based-solution-to-express-constraints-between-different-properties
14:52:08 [Arnaud]: ack pfps
14:55:28 [pfps]: one problem with all this (which SHACL sort of already does) is what happens with empty sets
14:55:33 [pfps]: s/does/has/
14:55:39 [hknublau]: q+
14:56:48 [pfps]: q+
14:56:58 [Arnaud]: ack hknublau
14:57:27 [simonstey]: +q
14:57:36 [aryman]: hknublau: looks useful but may be too powerful
14:58:13 [Dimitris]: +q
14:58:16 [Arnaud]: ack pfps
14:59:50 [aryman]: pfps: this feature would introduce a complex syntax (property paths) into the core
14:59:54 [pfps]: the cost here is adding a complex and powerful mechanism to the core (which is supposed to be small)
15:00:52 [Dimitris]: q-
15:02:01 [Arnaud]: ack simonstey
15:02:02 [aryman]: pfps: we should keep the core as simple as possible
15:03:17 [hknublau]: q+
15:03:34 [aryman]: Simon: I proposed just using this for the value constraint instead of everywhere a property is used in order to minimize complexity
15:03:39 [Arnaud]: ack hknublau
15:04:16 [kcoyle]: q+
15:04:59 [aryman]: hknublau: this feature would lead to more similar features, leading us to reproduce a lot of SPARQL
15:05:06 [Arnaud]: ack kcoyle
15:05:58 [aryman]: kcoyle: what are the criteria for deciding what is Core?
15:06:15 [pfps]: q+
15:06:59 [Arnaud]: ack pfps
15:07:13 [aryman]: Arnaud: the criteria are determined by the WG
15:07:37 [aryman]: pfps: Our goal is for the Core to cover 80% of use cases
15:08:22 [aryman]: Arnaud: who else supports this use case?
15:08:54 [hknublau]: That is http://www.w3.org/2014/data-shapes/track/issues/81
15:09:03 [aryman]: hsolbrig: Comparing the values of two paths/predicates is useful
15:09:20 [Arnaud]: STRAWPOLL: a) Close ISSUE-41, add support for property paths to Core, b) Close ISSUE-41, do not add support for property paths to Core
15:09:36 [pfps]: a:0 b:0
15:09:41 [simonstey]: a) +1 b) -0.5
15:09:53 [Dimitris]: a)+0.5, b) 0
15:10:33 [aryman]: a:-0.5 b:+0.5
15:10:43 [kcoyle]: a) +0.5 b) 0
15:11:32 [hknublau]: a) -1 b) 0 I think we need such a feature, but as a separate deliverable, outside of Core.
15:11:33 [Labra]: a) +0.5 b) 0
15:11:59 [ericP]: a) -.5 b) +1
15:13:10 [hsolbrig]: a) -.8 b) +1
15:14:39 [Arnaud]: RESOLVED: Close ISSUE-41, do not add support for property paths to Core
15:16:40 [Dimitris]: you can emulate notEquals with not(hasValue)
15:16:50 [simonstey]: i know
15:16:56 [pfps]: sh:notEqual as opposed to sh:minExclusive, I think
15:17:06 [simonstey]: but it's more verbose
15:17:08 [Arnaud]: issue-81
15:17:08 [trackbot]: issue-81 -- Shall SHACL Core include support for disjoint properties and other property pair constraints? -- open
15:17:08 [trackbot]: http://www.w3.org/2014/data-shapes/track/issues/81
15:17:09 [aryman]: TOPIC: ISSUE-81
15:21:35 [aryman]: hknublau: describes feature to compare values of pairs of properties on the same subject node, e.g. different values, ordering
15:23:18 [Arnaud]: PROPOSED: Close ISSUE-81, resolved as proposed, including sh:OrderedPropertyPairConstraint
15:23:38 [hsolbrig]: +1
15:23:45 [aryman]: +0
15:24:13 [Dimitris]: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0133.html
15:25:18 [Dimitris]: +q
15:25:34 [Arnaud]: ack Dimitris
15:25:39 [simonstey]: you could add an "sh:operator" property
15:26:19 [aryman]: Dimitris: proposes adding the comparison operator
15:26:25 [simonstey]: *with predefined operators
15:26:55 [ericP]: https://xkcd.com/327/
15:27:45 [aryman]: hknublau: that would add a limited kind of template mechanism to the Core and expose it to injection attacks
15:27:54 [kcoyle]: q+
15:28:35 [aryman]: Arnaud: why not allow only an enumerated set of operator names?
15:29:00 [Arnaud]: ack kcoyle
15:29:31 [aryman]: hkublau: since we have a small number of operators, the extra argument has limited use
15:30:03 [aryman]: kcoyle: I dislike like the name "Disjoint". Why not "NotEqual" ?
15:31:09 [aryman]: kcoyle: What if only one predicate has values?
15:31:34 [aryman]: s/hkublau/hknublau/
15:32:18 [aryman]: knublau: We need to specify that
15:32:29 [Arnaud]: PROPOSED: Close ISSUE-81, resolved as proposed in Holger's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0133.html, pending better suggestions for the names
15:32:43 [aryman]: +0
15:32:43 [hknublau]: +1
15:32:47 [simonstey]: +1
15:32:50 [hsolbrig]: +1
15:32:50 [kcoyle]: +1
15:32:57 [pfps]: if the number of characters required to do this in the high-level language is more than directly using SPARQL, then it shouldn't be in the high-level language
15:33:02 [pfps]: -0.1
15:33:17 [Dimitris]: +0.5
15:33:27 [Labra]: 0
15:33:51 [ericP]: 0
15:34:03 [pfps]: if one cares about this, then one should care enough to develop short names
15:34:31 [Arnaud]: RESOLVED: Close ISSUE-81, resolved as proposed in Holger's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0133.html, pending better suggestions for the names
15:35:17 [aryman]: TOPIC: ISSUE-42
15:35:33 [simonstey]: fine with closing it
15:36:11 [pfps]: close as being subsumbed by 81
15:36:12 [Arnaud]: PROPOSED: Close ISSUE-42, as no longer relevant, given resolutions of ISSUE-41 and ISSUE-81
15:36:13 [ericP]: +1
15:36:14 [hknublau]: +1
15:36:19 [kcoyle]: +1
15:36:20 [aryman]: +2
15:36:22 [Dimitris]: +1
15:36:26 [simonstey]: +1
15:36:29 [pfps]: +1
15:36:29 [hsolbrig]: +1
15:36:40 [Arnaud]: RESOLVED: Close ISSUE-42, as no longer relevant, given resolutions of ISSUE-41 and ISSUE-81
15:37:07 [aryman]: TOPIC: Next Meeting
15:38:02 [pfps]: q+
15:38:45 [hknublau]: q+
15:38:59 [Arnaud]: ack pfps
15:39:24 [aryman]: Aranud: low attendance, but the remote participation seems to be working
15:40:21 [aryman]: pfps: travel budgets are an issue, poor job collocating at other events, e.g. at WWW conference
15:40:35 [simonstey]: http://www2016.ca/
15:40:40 [simonstey]: montreal
15:41:54 [Arnaud]: ack hknublau
15:43:09 [aryman]: hknublau: suggest having 3 hr meetings every other week in order to make more progress
15:43:42 [aryman]: hknublau: this year I will be in Germany in December
15:44:50 [pfps]: q+
15:44:57 [Arnaud]: ack pfps
15:44:58 [hknublau]: I know. Kids are looking forward to the snow
15:45:16 [aryman]: Arnaud: 3 hr meetings won't work for many people
15:45:49 [aryman]: pfps: F2F meetings have I positive effect since it forces preparation
15:46:05 [aryman]: s/I/a/
15:47:01 [aryman]: pfps: people need to do more homework to prepare for these meetings
15:49:46 [pfps]: q+
15:51:00 [Arnaud]: ack pfps
15:51:34 [aryman]: kcoyle: We should at least have a virtual F2F when Holger is in the Germany TZ
15:52:13 [aryman]: pfps: I can offer to host a F2F at Nuance if we colocate in Montreal with WWW 2016
15:52:20 [pfps]: Nuance can host in Montreal before/after WWW2016
15:53:09 [pfps]: I would have to check my end-of-year schedule
15:55:13 [aryman]: Arnaud: Propose virtual F2F Dec. 16-17-18, Newfoundland time
15:55:17 [hsolbrig]: rubber duckie, you're the one
15:57:45 [Arnaud]: trackbot, end meeting
15:57:45 [trackbot]: Zakim, list attendees
15:57:45 [Zakim]: As of this point the attendees have been ericP, Arnaud, iovka, kcoyle, PhilA, hknublau, simonstey, pfps, diumitris, dimitris
15:57:53 [trackbot]: RRSAgent, please draft minutes
15:57:53 [RRSAgent]: I have made the request to generate http://www.w3.org/2015/09/09-shapes-minutes.html trackbot
15:57:54 [trackbot]: RRSAgent, bye
15:57:54 [RRSAgent]: I see no action items