See also: IRC log
<Dimitris> but on listen-only mode, there is a lot of noise here
<ericP> scribenick: ericP
PROPOSED: Approve minutes of the 8 Sept 2016 Telecon: http://www.w3.org/2016/09/08-shapes-minutes.html
<AndyS> +1
+1
RESOLUTION: Approve minutes of the 8 Sept 2016 Telecon: http://www.w3.org/2016/09/08-shapes-minutes.html
Arnaud: our resolution missed Jose.
<Arnaud> I can hear you guys just fine
<Arnaud> weird
next meeting likey 2016.09.20
<Arnaud> let's hear from Ted before we make the final call
(tuesda)
ISSUE-177
<trackbot> ISSUE-177 -- Abstract Syntax is disconnected from concrete syntax -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/177
ericP: ref'd OWL spec defines mapping from RDF graph to OWL AS
... we have to opposite
<TallTed> +1 open it
hknublau: I don't want to spend much time on this now since it's for a non-normative doc
... it would be nice to have parsers for the AS
... as was done with OWL
... I would like that more than what we have now but I see this as editorial
+1
<Arnaud> PROPOSED: Open ISSUE-177
+1
<kcoyle> +1
<hknublau> +1
RESOLUTION: Open ISSUE-177
ISSUE-105
<trackbot> ISSUE-105 -- SHACL SPARQL constraints depend on namespaces in a graph, which is not defined -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/105
Arnaud: lots of discussion last week. Can we get closure?
<hknublau> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0023.html
ericP: i believe we approached consensus noting that SPARQL parts of SHACL are really SPARQL body components.
<Zakim> AndyS, you wanted to say the BASE is not a significant issue.
ericP: noting that we almost agreed to call them that and have a prefix
TallTed: Noting that base declaration increases what I'm saying.
... Either we're using SPARQL or we're moving further away.
... Breaking up the "SPARQL Query" is going to confuse users.
... The expert user who sets up all the separate bells in whistles is one thing.
... but we have to consider the person who's maintaining this but doesn't know SPARQL.
... This is a fine enhancement for your SPARQL tool.
AndyS: the base should compose
... I would have thought that in the SHACL example that base isn't particularly relevent.
TallTed: it may never be relevent but we're making our beast stranger
... as we are tweaking things, we are moving away from using SPARQL
AndyS: SPARQL doesn't start until you've parsed it
... all of the proposals deal with how you compose the SPARQL query.
<AndyS> "construct the query string"
Arnaud: my understanind aligns with AndyS's: SPARQL doesn't come into play until you construct the string.
... we're free to say how it's constructed.
TallTed: we're free to but it's not the best idea
... we're talking about who we make work harder and why
<hknublau> SHACL engines also inject a clause to bind $this into the beginning of the query e.g. $this a ex:Person .
TallTed: the questions is whether the prefixes should be moved into an include file
... i've yet to see something which makes this concrete enough that i'm ok with it.
<Dimitris> from my side, resolving prefixes in an automated way can be useful but the actual benefit might not be as big since it will be mostly used in constraint components and hidden from the actual use
Arnaud: what would it take to satisfy you?
TallTed: i've seen things that open up maintanance and comprehension problems
... we're saying "we've got someone in the group who's doing this" and it tastes weird to me
<hknublau> SPIN's sp:text does this (even based on the prefixes from the TTL file)
AndyS: if you mean managing the prefixes from the query then i beleive several of the SPARQL workbenches provide this.
ericP: yeah, thye have standard prefixes and/or buttons to embed them
TallTed: looking at this proposal, it makes it easy to have the problem with duplicate prefixes
Arnaud: we saw real preference for either block or composed prefixes last week.
TallTed: looking at hknublau's proposal, maybe we need to say "sh:prologue"
... this adds extra complexity
AndyS: the prolog is just BASE and PREFIXes
<AndyS> [4] Prologue ::= ( BaseDecl | PrefixDecl )*
Arnaud: you said to Peter a number of times "their may be problems but we'll fix 'em"
... you're speculating about whether people will be confused.
... this doesn't seen to enough to kill this.
ericP: i'd like to hear from holger about why to break it up
hknublau: because otherwise we need a SPARQL parser.
... the triple notation gives us more control.
kcoyle: is this only about SPARQL? will it affect parts of SHACL that someone may implement without SPARQL?
... 'cause we aren't requiring that SHACL be implemented in SPARQL
hknublau: it affects SHACL/SPARQL and the definitions
... we're using prefixes in the spec
+1
<Dimitris> I also agree that if we include prefixes we add them right and not with a string based approach
last week's STRAWPOLL: (a) decomposed prefixes in Turtle, (b) precomposed SPARQL prologue, (c) no prefixes
<Dimitris> between a and b I prefer a
<hknublau> Duplicate prefixes should be marked as invalid shapes graph.
<hknublau> It's the safest and clearest for users.
TallTed: if we're going to "do it right" with a decomposed prolog, we should do it as an ordered list.
we already have a tree structure
hknublau: we already have a tree structure
... it's easy to find mistakes and avoid duplications
TallTed: we're making it extra easy for people to shoot themselves in the foot.
Arnaud: it sounds like TallTed is coming around, potentially combined with an errata on SPARQL.
... please update the proposals page
... next week we will vote on the most popular proposals and have limited discussion.
<trackbot> ISSUE-137 -- Missing constraint for language tag -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/137
hknublau: we had fruitful discussions
... i proposed LangShape which was correctly deemed too complicated
... i then proposed LanguageIn(l1, l2, ...) which uses SPARQL LangMatch
... i support the latter
AndyS: i agree with your checkpoint. i18n feedback could add lots of time.
<hknublau> AndyS: The Internationalization topic is time consuming
<scribe> scribenick: hknublau
thanks mate
Arnaud: Being pro-active might be good
<kcoyle> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-137_Missing_constraint_for_language_tag
kcoyle: Which of these are resolved by sh:languageIn
<Dimitris> apologies, I have to drop out
kcoyle: (going through the list)
AndyS: Depends on whether SHACL needs to enforce the specific language lists (from the external standards)
kcoyle: The last bullet item is not resolved.
AndyS: Trade-off how common and important that use case is compared to cost
... language tags can become really complex
kcoyle: Checking valid 2 letter tags is sufficient for most of our use cases
TallTed: Prime candidate for shape reuse, some 3rd party could put their shape on github as open source
sh: languageIn points at an rdf:List. That rdf:List can have a URI.
kcoyle: All seems to be reasonably covered.
<Arnaud> PROPOSED: Close ISSUE-137, adding sh:langShape as outlined in Holger's email http://www.w3.org/mid/1462fb16-9be3-1676-5340-d25c2af618f5%2540topquadrant.com . Meaning: if a value node has a language tag then the string of the language tag itself needs to have the given sh:Shape
<kcoyle> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0033.html
<Arnaud> PROPOSED: Close ISSUE-137, adding sh:langShape as outlined in Holger's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0033.html
<Arnaud> PROPOSED: Close ISSUE-137, adding sh:languageIn as outlined in Holger's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0033.html
+1
<AndyS> +1
<kcoyle> +1
<TallTed> +1
(That was my laziness)
RESOLUTION: Close ISSUE-137, adding sh:languageIn as outlined in Holger's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0033.html
<trackbot> ISSUE-71 -- SHACL Endpoint Protocol -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/71
hknublau: Time frame situation advises us to close this topic due to lack of time
Arnaud: (Agreed)
kcoyle: I think Arthur wanted something like this, Resource Shapes had a reference construct
Arnaud: I can check with OSLC, but I am not sure if anyone is willing to fight for this at this stage
... we cannot close it today, but I expect this to happen
... expectation is to close it "as is", i.e. doing nothing for such a protocol
<Arnaud> trackbot, end meeting