17:57:44 <RRSAgent> RRSAgent has joined #shapes
17:57:44 <RRSAgent> logging to http://www.w3.org/2015/07/30-shapes-irc
17:57:46 <trackbot> RRSAgent, make logs rdf-data-shapes
17:57:46 <Zakim> Zakim has joined #shapes
17:57:48 <trackbot> Zakim, this will be SHAPES
17:57:48 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
17:57:49 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
17:57:49 <trackbot> Date: 30 July 2015
17:58:15 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.07.30
17:58:18 <Arnaud> chair: Arnaud
17:59:22 <Arnaud> regrets: ericP, labra, simonstey
18:01:25 <pfps> pfps has joined #shapes
18:01:33 <pfps> present+ pfps
18:01:42 <Arnaud> present+ Arnaud
18:01:51 <aryman> aryman has joined #shapes
18:02:07 <Arnaud> present+ hknublau
18:02:12 <kcoyle> present+ kcoyle
18:03:09 <Arnaud> present+ aryman
18:05:56 <TallTed> present+ TallTed
18:06:49 <Dimitris> Dimitris has joined #shapes
18:07:26 <aryman> scribe: aryman
18:07:43 <aryman> Topic: Admin
18:08:03 <Arnaud> PROPOSED: Approve minutes of the 23 July Telecon: http://www.w3.org/2015/07/23-shapes-minutes.html
18:08:14 <pfps> minutes looked acceptable
18:08:22 <Arnaud> RESOLVED: Approve minutes of the 23 July Telecon: http://www.w3.org/2015/07/23-shapes-minutes.html
18:11:39 <aryman> Topic: ISSUE-2: Audience skills
18:12:39 <kcoyle> q+
18:12:39 <pfps> Let's close ISSUE-2, implicitly saying that the current document set is written at more-or-less the right level.
18:12:49 <Arnaud> ack kcoyle
18:13:36 <aryman> kcoyle: Is the ShEx-like language still in scope?
18:14:08 <aryman> Arnaud: yes, we intend to define a more human-readable syntax
18:14:41 <Arnaud> PROPOSED: Close ISSUE-2, it is no longer relevant
18:14:46 <aryman> +1
18:14:47 <hknublau> +1
18:14:49 <Dimitris> +1
18:14:53 <pfps> +1
18:14:55 <kcoyle> +1
18:14:56 <TallTed> +1
18:15:02 <Arnaud> RESOLVED: Close ISSUE-2, it is no longer relevant.
18:15:20 <aryman> Topic: ISSUE-23: punning
18:15:27 <Arnaud> PROPOSED: Close ISSUE-23, as currently specified in editor's draft.
18:15:29 <pfps> q+
18:15:33 <Arnaud> ack pfps
18:15:56 <aryman> pfps: I need more time.
<aryman> Arnaud: fair enough, we'll look at it again next week
18:16:31 <aryman> Topic: ISSUE-32: SHACL+-
18:17:38 <hknublau> q+
18:17:43 <Arnaud> ack hknublau
18:17:55 <pfps> I'm happy closing this issue with no change to the document.
18:18:46 <pfps> This issue was put forward when it was unclear whether the high-level language was going to be something like ShEx or an RDF vocabulary and syntax.
18:20:02 <aryman> hknublau: High-level means not requiring knowledge of an extension language, Core means the High-Level language we define, Human-friendly means compact, e,g, ShExC
18:21:54 <aryman> kcoyle: Need to be open to feedback about what we put in the Core. We need to include the most common user requirements (80-90%).
18:25:37 <aryman> hknublau: The current document is split into two parts. Part 1 is High Level. Part 2 is about Extensions (SPARQL).
18:26:30 <aryman> Note that some High Level commands are defined by templates.
18:26:55 <aryman> q+
18:27:05 <Arnaud> ack aryman
18:30:21 <aryman> q+
18:30:31 <Arnaud> ack aryman
<aryman> discussion on high-level vs core
18:31:31 <Arnaud> PROPOSED: High-level refers to the part of SHACL that does not require use of an extension language, Core is the built-in High-Level language we define as part of SHACL, Human-friendly means compact, e.g., ShExC
18:31:54 <hknublau> +1
18:32:22 <TallTed> +1
18:32:33 <Dimitris> +1
18:34:34 <kcoyle> +1
18:34:36 <aryman> +1
<aryman> pfps: I don't really care, I already said we can close the issue
18:35:00 <Arnaud> RESOLVED: High-level refers to the part of SHACL that does not require use of an extension language, Core is the built-in High-Level language we define as part of SHACL, Human-friendly means compact, e.g., ShExC
18:35:08 <Arnaud> PROPOSED: Close ISSUE-32, it was addressed by the adoption of the current editor's draft.
18:35:13 <hknublau> +1
18:35:20 <aryman> +1
18:35:30 <Dimitris> +1
18:35:34 <TallTed> +1
18:35:47 <Arnaud> RESOLVED: Close ISSUE-32, it was addressed by the adoption of the current editor's draft.
18:36:03 <aryman> Topic: ISSUE-51: Results Vocabulary
18:37:05 <pfps> One problem with Section 1.4 of the document is that there are both vocabulary and phrases that are not used elsewhere in the document.
18:37:33 <pfps> Therefore I do not think that Section 1.4 can be used as the basis for closing ISSUE-51.
18:42:06 <aryman> Dimitris: concerned about how to count errors, do statistics
18:43:19 <pfps> q+
18:43:42 <aryman> Dimitris: if you let people subclass the Result class then you need to load the ontology in order to determine which results are subclasses of Error
18:44:33 <TallTed> pfps - that seems to me a separate issue/concern -- it's not nothing, but not a reason that 1.4 cannot satisfy ISSUE-51
18:45:25 <aryman> q+
18:45:43 <Arnaud> http://w3c.github.io/data-shapes/shacl-ref/#results-vocabulary
18:45:56 <pfps> Ted - that depends on what we are agreeing on - Holger just pointed to 1.4 - which has a lot of baggage - he didn't say that the resolution was to have the four classes
18:46:33 <Arnaud> ack pfps
18:47:49 <aryman> pfps: Please clarify what are supposed to be agreeing with? All of section 1.4?
18:48:37 <Arnaud> ack aryman
18:49:39 <pfps> Are we agreeing one four classes and their taxonomy, or are we agreeing on the entire contents of Section 1.4?
<aryman> kcoyle: not sure this is the right set, I expect people will end defining their own
18:51:16 <aryman> aryman: Suggest we add a required property for severity on the base class.
18:51:42 <aryman> Dimitris: That would satisfy my immediate concern about doing statistics.
18:53:14 <aryman> hknublau: Having an integer severity would be useful in some cases.
18:53:44 <pfps> q+
18:53:56 <Arnaud> ack pfps
18:55:33 <hknublau> q+
18:55:39 <Arnaud> ack hknublau
18:55:58 <aryman> pfps: Section 1.4 contains a lot of content that needs discussion
18:56:04 <pfps> All the stuff in Section 1.4 is in some sense related to the results vocabulary.
18:56:34 <pfps> I do agree that a lot of the section need discussion - and a lot of it is new.
18:56:36 <pfps> q+
18:56:56 <aryman> hknublau: Need to start somewhere. I invite a counter-proposal.
18:57:21 <Arnaud> ack pfps
18:58:13 <TallTed> for consideration...
18:58:13 <TallTed> ODBC has *disjoint* return codes --
18:58:13 <TallTed> - SQL_SUCCESS = Function completed successfully ;
18:58:13 <TallTed> - SQL_SUCCESS_WITH_INFO = Function completed successfully, possibly with a (retrievable) nonfatal error/warning ;
18:58:14 <TallTed> - SQL_ERROR = Function failed. Details are retrievable. ;
18:58:14 <TallTed> - SQL_INVALID_HANDLE = Function failed due to a programming error ;
18:58:16 <TallTed> - SQL_NO_DATA_FOUND = No more data was available ;
18:58:18 <TallTed> - SQL_NEED_DATA = More data is needed from consumer ;
18:58:20 <TallTed> - SQL_STILL_EXECUTING = asynchronously executed op still running...  (end)
18:58:22 <TallTed> for SHACL, we might consider similar *disjoint* -- sh:success, sh:succinfo, sh:error, sh:what?, sh:missinginput, sh:inprogress ...
18:59:18 <aryman> pfps: The spec has a lot of interdependencies so it requires a lot of work to make a consistent change. Need to allow partially worked-out proposals.
18:59:40 <Dimitris> fyi, this was my draft suggestion on May https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0145.html
<aryman> Arnaud: ok, let's continue the discussion by mail, please, try to sketch a counter proposal
18:59:55 <hknublau> q+
18:59:56 <aryman> Topic: ISSUE-69: rdf:langString
19:00:02 <Arnaud> ack hknublau
19:01:19 <aryman> +1 to align with RDF 1.1
19:02:18 <Dimitris> +1 to stick with rdf1.1 too and fine with adding sh:string
19:03:03 <aryman> pfps: We should respect the definition of xsd:string
19:04:24 <aryman> hknublau: Agreed. So we should introduce sh:string or sh:text instead of using the SHACL union mechanism, sh:or
19:06:21 <elf-pavlik> elf-pavlik has joined #shapes
19:06:26 <aryman> pfps: Too bad that RDF 1.1 did not define a datatype for this purpose. We should define one and try to get it put in the RDF vocabulary.
19:07:17 <aryman> q+
19:07:27 <Arnaud> ack aryman
19:07:32 <Dimitris> *sh:text Holger proposed would be less confusing actually*
19:07:45 <pfps> q+
19:07:52 <Arnaud> ack pfps
19:08:11 <Arnaud> PROPOSED: Close ISSUE-69, defining a new datatype sh:string
19:09:26 <hknublau> +0.8
19:09:42 <pfps> +1 with the provisio to try to do better if possible
19:09:51 <kcoyle> +1
19:09:54 <aryman> +1 to the spirit
19:10:44 <pfps> sh:text might be a better name
19:10:53 <Arnaud>  PROPOSED: Close ISSUE-69, defining a new datatype sh:text
19:10:58 <hknublau> +1
19:11:02 <aryman> +1
19:11:04 <Dimitris> +1
19:11:08 <kcoyle> +1
19:11:10 <TallTed> +1
19:11:21 <Arnaud> RESOLVED: Close ISSUE-69, defining a new datatype sh:text
<aryman> hknublau: there is a similar need with xsd:date and xsd:dateTime but we can look at that another time
19:12:47 <pfps> rdf:PlainLiteral was proposed as a datatype to cover both strings and language-tagged strings, but it was not picked up by RDF
19:12:46 <aryman> Topic:ISSUE-76: commutability
19:12:50 <aryman> q+
19:13:16 <aryman> q-
19:14:31 <aryman> q+
19:14:40 <Arnaud> ack aryman
19:16:23 <pfps> q+
19:18:26 <Arnaud> ack pfps
19:19:21 <aryman> hknublau: Order of execution is important so that users always get the same results in error situations.
<aryman> ... and it is important for recursion
<aryman> pfps: we don't need to define order of execution for recursion
19:19:59 <aryman> Arnaud: need to get user input on importance of execution order - Karen please
19:20:48 <aryman> aryman: Recursion should be require fixed order of execution
19:21:13 <aryman> pfps: SPARQL allows booleans to return ERROR and defines operations
19:21:50 <aryman> pfps: SPARQL allows changed execution order to enable optimization
19:23:40 <aryman> s/should be/should not/
19:24:08 <aryman> q+
19:24:10 <pfps> SQL has a different solution, but also one that does not specify execution order
19:24:18 <Arnaud> ack aryman
19:25:58 <pfps> RDF graphs are not good for syntax - rdf:List was added to RDF to get around some of the problems with RDF containers when used for syntax - its initial use (in OWL) did not have any execution ordering implications
<aryman> Arnaud: given the tie we have with SPARQL it would seem natural to have the same approach
19:26:34 <aryman> Arnaud: let's resume discussion next week. Karen - will you have input?
19:26:55 <pfps> QCRs?
19:27:41 <aryman> Topic: ISSUE-3: Shape association
19:27:56 <aryman> Arnaud: need to clarify what the issue is
19:28:48 <aryman> hknublau: This issue is about how to tell the engine what to do.
<aryman> ... I changed the description to clarify
<aryman> Arnaud: ok, we need to make sure everyone agrees with the change
19:29:34 <pfps> I agree with Holger here - some of the recent comments on ISSUE-3 were related to ISSUE-5
19:30:49 <pfps> I also agree with the change
<aryman> Arnaud: ok, let's leave it at this for today, please, have a look and we'll talk about it again next week
19:32:39 <Arnaud> trackbot, end meeting
19:32:39 <trackbot> Zakim, list attendees
19:32:39 <Zakim> sorry, trackbot, I don't know what conference this is
19:32:47 <trackbot> RRSAgent, please draft minutes
19:32:47 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-shapes-minutes.html trackbot
19:32:48 <trackbot> RRSAgent, bye
19:32:48 <RRSAgent> I see no action items