See also: IRC log
<kcoyle> that was me, then i hit the wrong button. i'll be back
<Arnaud> scribe: labra
<Arnaud> PROPOSED: Approve minutes of the 26 March Telecon: http://www.w3.org/2015/03/26-shapes-minutes.html
<pfps> minutes look fine
<ArthurRyman> +1
RESOLUTION: Approve minutes of the 26 March Telecon: http://www.w3.org/2015/03/26-shapes-minutes.html
pfps: would like a compilation of the resolutions
to have them in one place
scribe: to have all together
... to search for a resolution
Arnaud: not committed to it...it should not be a lot of work
... next conference next week
... about next f2f in Toronto
... asked Peter to host it in Waterloo
... venue is set at Waterloo
... there is a wiki page to indicate participation...
https://www.w3.org/2014/data-shapes/wiki/F2F3
Arnaud asks people to fill about their participation...
no open actions...
most of the issues are about the spec
we can defer to later...
Editors have put together a draft ready for publication
scribe: publication schedule is in two days
tuesday probably
EricP: Will try to have it published tuesday
<kcoyle> no, nothing else
Arnaud: proposed new stories
... s42
<Arnaud> S42: Constraining RDF graphs for better mapping to JSON
pfps: sees it ok...why not?
<Arnaud> PROPOSED: Approve S42: Constraining RDF graphs for better mapping to JSON
<ericP> +1
<SimonSteyskal> +1
+1
<hknublau> +1
<cygri> +1
<TallTed> +1
<pfps> +1
<Dimitris> +1
<kcoyle> +1
RESOLUTION: Approve S42: Constraining RDF graphs for better mapping to JSON
subTopic: user story S40
Arnaud: to be continued
<Arnaud> 2.10.2 Human-readable Violation Messages
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Human-readable_Violation_Messages
EricP: Having a machine data structure is easy
... but trying to cover the possible errors
it will be very complex
to put that in a data structure
EricP: if it is not in the core language then it isok
Peter: we should approve requirements independent if they are in the core or not...
... something like the ability to include a string that can be filled with values...
+q
peter: is not sure if this feature should be part of SHACL at all
<ArthurRyman> +q
he is happy to put it in a requirement...
so someone can try to satisfy it
<hknublau> +q
<pfps> I agree that coming up with some data responses is much more important.
labra: I think it will be very complex to generate human readable messages
<cygri> Jose presumes a solution, and then rejects this solution by saying it’s too complicated. This is not how you evaluate requirements.
I don't understand what Arthur said
@cygri, no, that's not what I said...I say that it is out of scope
and too complex to try to do it in a right way
I couldn't hear Holger...
Holger, could you write it?
<hknublau> I was just saying that in our experience this is quite easy to implement using sh:message with template insertions.
<pfps> I'm also happy to make this a soft goal - It's not as if this is a vital part of SHACL
<Arnaud> PROPOSED: Approve 2.10.2 Human-readable Violation Messages
<hknublau> +1
-1
<kcoyle> +1
<Dimitris> +1
<cygri> +1
<pfps> +0.5
<TallTed> +1
<ArthurRyman> +1
-0.5
<SimonSteyskal> +1
<ericP> 0
RESOLUTION: Approve 2.10.2 Human-readable Violation Messages
Arnaud: We can drop some requirements later
subTopic: Other requirements
<Arnaud> 2.6.11 Expressivity: Closed Shapes
Peter: the trouble of closed shapes is trying to figure what is the requirement
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes
EricP: some mechanism to determine which triples are not covered by the validation process
Peter: it covers at least 4 different possibilities
... at least three different things
... two of them from the algebraic semantics and at least one that isn't intractable
Arthur: my objection is not about the concept...
... he is not objecting the capability
EricP: If there is some optional property and misspel it
+q
<TallTed> +1 on that hand-waved user story. also +1 on the requirement, as I understand it.
<TallTed> "all data that you give me must fit this shape. you gave me %THIS% data that doesn't fit. try again."
<cygri> The user story could perhaps be addressed with another requirements that would be simpler, e.g., by a flag in the operations, rather than by a language feature.
Arnaud: lets move on
<hsolbrig> Arnaud: you guys need to get a life.
Arnaud: a couple of points that appear again and again
... discussion about having SHACL depend on SPARQL engine
... SHACL should be defined so it can be implemented in SPARQL
it can constraint the expressivity of the language
not everything can be implemented in SPARQL...recursion and things like that
peter: wether the high-level language needs SPARQL for implementation
Arnaud: it seems that there should be a mechanism to have a extension based on SPARQL
peter: high-level language does not require SPARQL engine to be implemented
<Arnaud> PROPOSED: Implementation of "SHACL core" shall not require SPARQL
<pfps> +1
+q
<hsolbrig> Should it be possible to implement SHACL inefficiently with SPARQL?
<Arnaud> PROPOSED: Implementation of "SHACL high level" shall not require SPARQL
<pfps> +1
<hsolbrig> +1
<ericP> +1
<ArthurRyman> +1
+1
<kcoyle> +1
<TallTed> +0
<SimonSteyskal> +1
core could be seem as a profile
<cygri> +1
<Dimitris> +1
<ArthurRyman> see sections 2-6 (I think) of Holger's spec
RESOLUTION: Implementation of "SHACL high level" shall not require SPARQL
Arnaud: the other one, SHACL should not be limited to what can be implemented in SPARQl
<Arnaud> PROPOSED: "SHACL highlevel" shall not be limited to what can be implemented in SPARQL
<cygri> -1
<ericP> +1
+1
<kcoyle> +1
<hknublau> -1
<ArthurRyman> -1
cygri: I am not sure that there is any requirements that can't be implemented in SPARQL
<pfps> It seems to me that closed shapes are at least hard to implement in SPARQL
<SimonSteyskal> -1
if somebody brings a concrete that isn't implemented in SPARQL
<pfps> Recursive shapes also don't fit in SPARQL, but there aren't any viable proposals for recursive shapes
<hknublau> @pfps depends on how closed shapes are defined. Just checking for property existence is easy.
<Dimitris> -1
+q
Arthur: High-level language should be able to be implemented in SPARQL
... Basic constraints should be capable of implementation in SPARQL. However, the overall process of evaluating a Shape requires control structures beyond SPARQL, e.g. recursively following and processing valueShape links.
peter: I really want this kind of thing to work on the DBPEdia scale
<pfps> I think that the proposal should be whether the guts of SHACL (i.e., the part that actually does stuff) can be done via a translation to SPARQL
<ericP> Labra: some parts of the current spec that aren't covered by SPARLQ, e.g. recursive shapes
<ericP> ... i think there are others that can't be covered by SPARQL.
<ericP> ... templates are outside of SPARQL
<pfps> The appeal to recursive shapes would be more compelling if there was a version of recursive shapes that actually worked right
<ericP> ... i'd like a language that have different profiles, with different expressivity and complexity
ericP: Asks a question if you can implement the validation using a series of SPARQL queries
<Arnaud> PROPOSED: "SHACL highlevel" shall be implementable in SPARQL
can you implement in SPIN using SPIN templates...there are different interpretations to the meaning can you implement it in SPARQL
+q
<pfps> +1
<cygri> But which of these three meanings of “implementable in SPARQL” is the question?
<ericP> -1
+q: to ask what it means to be implementable in SPArql
<pfps> The distinction has to be between a single query and an unlimited number of queries
<hknublau> +q
<TallTed> PROPOSED: "SHACL highlevel" shall be implementable with 1-n SPARQL queries
<TallTed> PROPOSED: "SHACL highlevel" shall be implementable with 1 to n SPARQL queries
<pfps> ack
Holger: the question becomes meaningless
... its too general
<pfps> In a certain sense anything in SHACL can be answered using a single SPARQL query - SELECT * from ?a ?b ?c
<Dimitris> PROPOSED: "SHACL highlevel" shall be efficiently implementable in SPARQL
peter: says there are proposals from the sparql side and none proposals from the non-sparql side
+q
<ericP> Labra: i don't think there's a SPARQL and a non-SPARQL camp.
<ericP> ... i'm in favor of a high-level language constructs
<ericP> ... if some of them are very complex, then we can profile.
<pfps> At some point all this has to be implemented, so it's not as if the high-level language can be just anything
<ericP> it's not like we're short of ShEx implementations
@peter: but it is not "anything"
<Arnaud> PROPOSED: SHACL shall include an extension mechanism based on SPARQL
<pfps> as far as I can tell there are *NO* ShEx implementations
<Dimitris> *define high level :) *
+q
<TallTed> ... shall include an extension mechanism, which will support SPARQL and may support other means...
<cygri> … (not precluding other extension mechanisms)
<ericP> Labra: want support for SPARQL extensions to be optional. also want be able to have e.g. Javascript
<Arnaud> PROPOSED: SHACL shall include an extension mechanism allowing among other things to extend the highlevel functionality with SPARQL
<ericP> ... e.g. HTML allows <script type="application/javascript"/> as well as other languages
<ericP> +1
<TallTed> +1
+1
<ArthurRyman> +1
<hknublau> +1
<hsolbrig> +1
<SimonSteyskal> +1
<pfps> +0.5
<Dimitris> +1
<kcoyle> +1
<cygri> Well this can be read as saying that there *must* be other things beside sparql
<cygri> -1
<pfps> I agree with Richard
cygri: says that we need to have proposals
Arnaud: says that it is like HTML and Javascript
<pfps> -1
Arnaud: we can have any kind of extension mechanism
peter: says that it looks like the extension mechanism in shape expresions which is completely broken
... the extension mechanism is not even part of the language...
... if we are going to do extension mechanism they should be first class and be integratable with the rest of the language
EricP: asks why?
@peter: that's about macros
+q
in Holger the sparql extension is integrated in SHACL
<ericP> Labra: peter isn't opposed to an extension mechanism; he just doesn't like the one in shex
<ericP> ... i just don't want the extensions to be limited to SPARQL
<pfps> I think that a SHACL that is divided into a small core and an extension mechanism needs an extension mechanism that is integrated into the language
cygri: scripts made in HTML have some access to the DOM
+q
<pfps> +1 to Richard
<ericP> Labra: agree with cygri's point that we may need a structure for what gets passed to the extensions, e.g. subject, etc.
<cygri> That’s sufficient to meet the charter.
<ericP> ... if we limit to SPARQL, we're limiting to SHACL
<Arnaud> http://www.w3.org/2014/data-shapes/track/issues/raised
Arnaud: Acknowledge Richerd for raising some issues
+q
Arthur: question about the issues
<hsolbrig> Zakim won't let me back in...
if you put the name of the issue in your email it will be automatically listed in the tracker
<pfps> Again, if there is going to be something like an arbitrary extension mechanism, there is no proposal on the table, and there needs to be one If anyone wants to go this way, then they should put forward a proposal ASAP.
<pfps> +1 to open all the raised issues
<ArthurRyman> +1 to open them
<Dimitris> +1 to open all
<ericP> +1 to open
+1
<hsolbrig> Zakim won't let me in. A key thing (imo) on extensions is that the must not have side effects like adding more triples to the target graph, etc.
<Arnaud> PROPOSED: open all raised issues: ISSUE-22 through ISSUE-34
<pfps> I think that no one told Zakim that the meeting is 90 minutes!
<pfps> +1
<ericP> +1
<hknublau> +1
<cygri> +1
<ArthurRyman> +1
<TallTed> +1
+1
<kcoyle> +1
<SimonSteyskal> +1
RESOLUTION: open all raised issues: ISSUE-22 through ISSUE-34
Arnaud: we are working with multiple drafts
... people should make proposals on how to close the issues
... send email or create a page specific for the issue
... if there is a proposal that is sticking mark the issue as pending review
Arthur: says that it is not productive to have several drafts
Peter: my viewpoint its much more benefitial to have multiple specs in parallel
we would spend more time with spelling changes
we haven't even decided about going in a particular direction
Arthur: how long are we going to be ?
... with multiple drafts
Arnaud: I proposed to have two weeks to work on proposals
... and have a vote but peter didn't like that
peter: we hear that there are these things coming
<pfps> ... but nothing has come
cygri: the shex camp have a clear opinion about how things should work
Arnaud: clarify if we have to chose, the whole document can be changed at any time
<pfps> The problem with replacing sections, is that the most likely changes are to replace all the sections
??: once a document is published as a draft it will be difficult to change it
<Arnaud> trackbot, end meeting