See also: IRC log
<scribe> scribe: aryman
<Arnaud> PROPOSED: Approve minutes of the 23 July Telecon: http://www.w3.org/2015/07/23-shapes-minutes.html
<pfps> minutes looked acceptable
RESOLUTION: Approve minutes of the 23 July Telecon: http://www.w3.org/2015/07/23-shapes-minutes.html
<pfps> Let's close ISSUE-2, implicitly saying that the current document set is written at more-or-less the right level.
kcoyle: Is the ShEx-like language still in scope?
Arnaud: yes, we intend to define a more human-readable syntax
<Arnaud> PROPOSED: Close ISSUE-2, it is no longer relevant
+1
<hknublau> +1
<Dimitris> +1
<pfps> +1
<kcoyle> +1
<TallTed> +1
RESOLUTION: Close ISSUE-2, it is no longer relevant.
<Arnaud> PROPOSED: Close ISSUE-23, as currently specified in editor's draft.
pfps: I need more time.
Arnaud: fair enough, we'll look at it again next week
<pfps> I'm happy closing this issue with no change to the document.
<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.
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
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%).
hknublau: The current document is split into two parts. Part 1 is High Level. Part 2 is about Extensions (SPARQL).
Note that some High Level commands are defined by templates.
discussion on high-level vs core
<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
<hknublau> +1
<TallTed> +1
<Dimitris> +1
<kcoyle> +1
+1
pfps: I don't really care, I already said we can close the issue
RESOLUTION: 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
<Arnaud> PROPOSED: Close ISSUE-32, it was addressed by the adoption of the current editor's draft.
<hknublau> +1
+1
<Dimitris> +1
<TallTed> +1
RESOLUTION: Close ISSUE-32, it was addressed by the adoption of the current editor's draft.
<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.
<pfps> Therefore I do not think that Section 1.4 can be used as the basis for closing ISSUE-51.
Dimitris: concerned about how to count errors, do statistics
... 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
<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
<Arnaud> http://w3c.github.io/data-shapes/shacl-ref/#results-vocabulary
<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
pfps: Please clarify what are supposed to be agreeing with? All of section 1.4?
<pfps> Are we agreeing one four classes and their taxonomy, or are we agreeing on the entire contents of Section 1.4?
kcoyle: not sure this is the right set, I expect people will end defining their own
aryman: Suggest we add a required property for severity on the base class.
Dimitris: That would satisfy my immediate concern about doing statistics.
hknublau: Having an integer severity would be useful in some cases.
pfps: Section 1.4 contains a lot of content that needs discussion
<pfps> All the stuff in Section 1.4 is in some sense related to the results vocabulary.
<pfps> I do agree that a lot of the section need discussion - and a lot of it is new.
hknublau: Need to start somewhere. I invite a counter-proposal.
<TallTed> for consideration...
<TallTed> ODBC has *disjoint* return codes --
<TallTed> - SQL_SUCCESS = Function completed successfully ;
<TallTed> - SQL_SUCCESS_WITH_INFO = Function completed successfully, possibly with a (retrievable) nonfatal error/warning ;
<TallTed> - SQL_ERROR = Function failed. Details are retrievable. ;
<TallTed> - SQL_INVALID_HANDLE = Function failed due to a programming error ;
<TallTed> - SQL_NO_DATA_FOUND = No more data was available ;
<TallTed> - SQL_NEED_DATA = More data is needed from consumer ;
<TallTed> - SQL_STILL_EXECUTING = asynchronously executed op still running... (end)
<TallTed> for SHACL, we might consider similar *disjoint* -- sh:success, sh:succinfo, sh:error, sh:what?, sh:missinginput, sh:inprogress ...
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.
<Dimitris> fyi, this was my draft suggestion on May https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0145.html
Arnaud: ok, let's continue the discussion by mail, please, try to sketch a counter proposal
+1 to align with RDF 1.1
<Dimitris> +1 to stick with rdf1.1 too and fine with adding sh:string
pfps: We should respect the definition of xsd:string
hknublau: Agreed. So we should introduce sh:string or sh:text instead of using the SHACL union mechanism, sh:or
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.
<Dimitris> *sh:text Holger proposed would be less confusing actually*
<Arnaud> PROPOSED: Close ISSUE-69, defining a new datatype sh:string
<hknublau> +0.8
<pfps> +1 with the provisio to try to do better if possible
<kcoyle> +1
+1 to the spirit
<pfps> sh:text might be a better name
<Arnaud> PROPOSED: Close ISSUE-69, defining a new datatype sh:text
<hknublau> +1
+1
<Dimitris> +1
<kcoyle> +1
<TallTed> +1
RESOLUTION: Close ISSUE-69, defining a new datatype sh:text
hknublau: there is a similar need with xsd:date and xsd:dateTime but we can look at that another time
<pfps> rdf:PlainLiteral was proposed as a datatype to cover both strings and language-tagged strings, but it was not picked up by RDF
hknublau: Order of execution is important so that users always get the same results in error situations.
... and it is important for recursion
pfps: we don't need to define order of execution for recursion
Arnaud: need to get user input on importance of execution order - Karen please
aryman: Recursion should not require fixed order of execution
pfps: SPARQL allows booleans to return ERROR and defines operations
... SPARQL allows changed execution order to enable optimization
<pfps> SQL has a different solution, but also one that does not specify execution order
<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
Arnaud: given the tie we have with SPARQL it would seem natural to have the same approach
... let's resume discussion next week. Karen - will you have input?
<pfps> QCRs?
Arnaud: need to clarify what the issue is
hknublau: This issue is about how to tell the engine what to do.
... I changed the description to clarify
Arnaud: ok, we need to make sure everyone agrees with the change
<pfps> I agree with Holger here - some of the recent comments on ISSUE-3 were related to ISSUE-5
<pfps> I also agree with the change
Arnaud: ok, let's leave it at this for today, please, have a look and we'll talk about it again next week
<Arnaud> trackbot, end meeting