See also: IRC log
<scribe> scribe: dimitris
Dimitris: I have an open source implementation of SHACL people can try
Arnaud: That's great, please, add it to the list on the WG page
<pfps> It would be interesting to know the implementation philosophy of Dimitris's implementation
<aryman> @Dimitris great news
https://github.com/AKSW/RDFUnit/issues/62
<Arnaud> PROPOSED: Approve minutes of the 18 February 2016 Telecon: http://www.w3.org/2016/02/18-shapes-minutes.html
<aryman> looks good
<pfps> looked fine to me
arnaud: any objection to approve theminutes of last week?
RESOLUTION: Approve minutes of the 18 February 2016 Telecon: http://www.w3.org/2016/02/18-shapes-minutes.html
arnaud: there is a change in WG membership, Arthur is retiring from the WG due to other commitments
... on behalf of the W3C, I want to publicly thank Arthur for his contribution, we will miss him
<TallTed> sad to see you go, aryman! you've made significant contributions to our progress.
<aryman> thanks
sad to see you go as well
<jima> you will be missed
arnaud: Arthur had an action to draft a semantics document for the specification, I want to give the option to WG, instead of closing this action someone can take over
... is anyone interested to take over or should we close it?
... hearing none we will then close Arthur's action, anyone is still free to make a proposal later on if they want to
<trackbot> ISSUE-95 -- Proposed simplification and clean up of template mechanism -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/95
Arnaud: Arthur, Holger and Simon came back with two proposals
<hknublau> https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_3
Arnaud: let's discuss the agreements
hknublau: we had a lot of redundant metaclasses and made very good progress thanks to Arthur
... we agreed that the term "template" is misleading and arguments have been renamed to parameters
... (... reading and explaining the proposal...)
<pfps> I thought that this was supposed to be a simplification!
+q
dimitris: asking when we use the constraints in filter if we need a different query (decided to take it offline)
aryman: the motive for doing this was to avoid the same sparql code in different queries and holger tried to refactor that
... in holger's design the sparql engine has to do the surgery, it's a little more complex and requires more implementation
... easier to debug your queries too but the downside is that you might have 3 very similar queries but maybe it's not so bad
<simonstey> http://w3c.github.io/data-shapes/shacl/#functions
aryman: in my proposal it corresponds to simple rdfs classes
simonstey: proposal 3 is much inline with arthur's proposal
... we already have defined functions in the spec and we allow users to define their functions
... it's kind of difficult, extending shacl should be different from using shacl and I'm inclined in option a
pfps: I thought we would simplify but it's still complex
... our syntax is complicated and hard to understand
... another complexity is the support for different execution languages that noone implements
... that's why I like Arthur's proposal
hknublau: we have javascript support in spin already
... node validation functions are not that hard to implement and people can use the verbose approach
... what I do not like about Arthurs constraint classes is that they are never instantiated
jima: I have sympathy for adding complexity to solve problems, I need time to read the proposals more
pfps: both proposals are not simple but I see Arthurs simpler.
aryman: in my view the classes are instantiated, sh:property is an sh:propertyConstraint and are instantiated
hknublau: then you need rdfs inferencing
aryman: it will be an engine rule
... this will be how a shacl engine will treat a shacl program
dimitris: in my implementation Arthurs proposal will be easier to implement
arnaud: let's leave it at this for today
<trackbot> ISSUE-22 -- Treatment of recursive shape definitions -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/22
<simonstey> what about http://w3c.github.io/data-shapes/shacl/#functions if we don't want/can process custom functions?
arnaud: Arthur had an action for a recursion proposal and said he cannot deliver. We are free to be
... completely silent or have a statement about recursion
<hknublau> @simonstey agreed, plus we decided to not limit ourselves to SPARQL endpoints. Furthermore, I believe implementations can just inject the ASK part into a new query template.
aryman: I send a part of a recursion spec I did write. It was recursion for OSLC RS but SHACL is more powerfull
... there is a huge intersection of RS and SHACL and we can define recursion only on that part
jima: isn't the problem still there? (grey recursion areas)
aryman: by defining recursion in a subset we move some obstacles in SHACL adoption
pfps: Arthurs semantics are not tight to anything we understand (Z language)
... something in the lines of the RDF semantics would be useful
(didn't hear Eric, voice was breaking)
aryman: we can be conservative with recursion like static analysis and reject all loops
... Eric is taking a conservative approach
arnaud: what do we do now? will someone pick this up?
... if not we need to discuss how to close this
jima: we can say nothing, leave it to implementers or say will be supported in a later version
<trackbot> ISSUE-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/92
aryman: I got a note from iovka for a proposal related to this. She found the partition proposal well founded
ericp: I hope to get a little of her time next week
<trackbot> ISSUE-99 -- special treatment of rdfs:Resource and rdf:List in sh:valueClass (and possibly elsewhere) -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/99
pfps: special treatment of rdf:List and rdfs:Resource should be removed
... if we do something for rdf:List we should do it right
hknublau: we just try to identify that it is an rdf:List
... for rdfs:Resource we can use sh:nodeKind
... we can add an issue for better support of rdf:Lists, I am not against to what Peter suggests
<aryman_> +1
dimitris: prefer to remove the checks of rdf:List and rdfs:REsource to sh:nodeKind
<Arnaud> trackbot, end meeting