See also: IRC log
https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.09.08
<scribe> scribenick: AndyS
<ericP> PROPOSED: Approve minutes of the 1 Sept 2016 Telecon: http://www.w3.org/2016/09/01-shapes-minutes
<kcoyle> +1
<pano> +1
<Arnaud> +1
<simonstey> +1
RESOLUTION: Approve minutes of the 1 Sept 2016 Telecon: http://www.w3.org/2016/09/01-shapes-minutes
<hknublau> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Sep/0003.html
Proposal is to have a mechanism for defining groups of prefixes
EricP: can they be links to the web or will they be in-document?
... does not meet the cut&paste issue
hknublau: pre-binding makes that less valuable
<ericP> orange hung me up
marqh: I agree that snippets can't always be simply copied out so it is not a show stopper to me.
<ericP> reconnecting...
marqh: my pref is for "true SPARQL" not parts assembled.
ericP: is that feasible given the rest of SHACL? (Q to marqh and holger)
marqh: can't quite articulate my uneasiness - I am flagging my concerns ; happy to more on.
<TallTed> fumbling with buttons...
BartvanLeeuwen: about whether they can be web links.
EricP: I understand that they are "in document"
Holger: in shapes graph - to activate them the sh:prefixes must be next to sh:select.
hknublau: in shapes graph - to activate them the sh:prefixes must be next to sh:select.
EricP: not in named graph so it is a URL and it could be elsewhere by deference.
... but usually in shapes graph
TallTed: $ and ? are both variable markers in SPARQL. So it is cut-and-paste.
EricP: unconstrained variables -> more answers.
TallTed: prefixes part of SPARQL and Turtle - potential disastrous to users
... that this mechanism does not give complete queries.
... it is a security concern
<ericP> me too
AndyS: Is this deference different to say a shape? a constraint?
TallTed: I feel it is different.
AndyS: follow up in email?
BartvanLeeuwen: why not write out full queries?
<hsolbrig> +1 to Bart's question
EricP: the reason is prefixes get used multiple times. Multiple shapes.
hknublau: from experience, users don't want to repeat the prefixes each time.
... parsing looses comments and intended layout
hsolbrig: this reason exists because turtle prefixes not available to the SPARQL. Can we pass in from the Turtle file?
EricP: would need a media type, file extension because std libraries may not handle prefixes usefully.
hsolbrig: Will there be other extensions that need this mechanism?
EricP: yes - eventually. Tempted not to go there ATM.
<Arnaud> I'm sympathetic to Holger's point but I'm afraid it's a case of being doomed if you do doomed if you don't
EricP: Summary: TopQuadrant see a cost of usablity.
<hsolbrig> If there was some way that we could make a strong assertion that this isn't intended to be a variable passing mechanism...
TallTed: need a lot of mechanism and language to make this work.
EricP: We are already doing that via pre-binding.
<Arnaud> The patches among us will say let's do it, the purists will say let's no
<Arnaud> S/patches/practical /
There are examples in the working draft.
<hsolbrig> The equivalent of runtime #defines in 'C'...
"Prologue" is the right technical term in SPARQL.
https://www.w3.org/TR/sparql11-query/#rPrologue
EricP: We say the SPARQL query is the prologue (as def by SPARQL) + a query fragment.
marqh: need to define details but sounds interesting.
hknublau: looses some benefit but better than nothing. e.g. can't share prefixes across files.
EricP; marqh proposes that there is a processing mode for sh:PrefixDeclaration resources.
<hknublau> plus the declarative model can be queried, while a big string would be harder to use.
EricP: two proposals: Holgers (RDF) and Mark's (prefixes are a string somewhere)
<Arnaud> I think Ted s point is fair but maybe this deserves more thinking offline. it's enough for today. I suggest
<Arnaud> moving on to next agenda item
<ericP> STRAWPOLL: (a) decomposed prefixes in Turtle, (b) precomponsed SPARQL prologue, (c) no prefixes
I prefer to see some mechanism for reusing prefixes. As to which, I don't have an opinion ATM. i.e. "not (c)"
<pano> aren't we missing decomposed precomposed prologue?
<hsolbrig> (a)
a: +1 b:+1 c:-0.5
<hsolbrig> a: +0.9 b:0.1 c:-0.5
<ericP> a:0, b:0, c:0
<TallTed> a is preferable to b. some way to do this is desirable. I don't see it ready to work yet.
<kcoyle> aL -.5b. 0 c: +.5
<marqh> a: -0.5 b: +0.5 c: 1
<TallTed> a: +0.1 b: -0.5 c: -0
<BartvanLeeuwen> a: -0.5 b: +0.5 c: 1
marqh: precompose? (reply - (b) is a defined string)
<pano> a: +0.9 b: +0.5 c:0
<simonstey> a:0 b:0.5 c: 0.9
<hknublau> a: +1 b: 0 c: -1
marqh: sending email ...
<simonstey> issue-137
<trackbot> issue-137 -- Missing constraint for language tag -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/137
BartvanLeeuwen: intro the issue
... I do a lot of multi-lingual work
<kcoyle> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-137_Missing_constraint_for_language_tag
BartvanLeeuwen: think lang tag handling should be in base SHACL, not an extension.
kcoyle: some large case e.g. valid 3-letter tag are big tables to maintain
AndyS: the list of lang tags changes over time
BartvanLeeuwen: Use shapes for UI generation.
<hknublau> I think adding sh:langShape [ sh:in ... ; sh:stem ... ] would cover most missing use cases.
<hknublau> (replace sh:stem with sh:pattern above)
kcoyle: easier to work with limited lists library works with all tags.
<ericP> acn next
EricP: notes LANGMATCHES in SPARQL that applies the correct rules e.g. en and en-gb , case insenstive
... concern about the whole list.
kcoyle: just adding should not be a problem
hknublau: handle as a external vocabulary.
... will apply lang proposal to each of the bullet of the use case from karen
<Arnaud> Call time?
<ericP> hknublau, good early early early morning
<Arnaud> I can do 9 ET for an hour or on Wed for 1h1/2
<hknublau> Isn't there an online tool to let everyone indicate their availability?
<TallTed> https://www.timeanddate.com/worldclock/meeting.html
<TallTed> makes life easier for comparisons...
<ericP> PROPOSAL: Future meetings Wed 0900 US Eastern
<simonstey> +1
<TallTed> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20160908&p1=43&p2=47&p3=195
<Arnaud> +1
<kcoyle> +1
<pano> +0.5
<ericP> +1
<hknublau> +1
<hsolbrig> +1
<BartvanLeeuwen> +1
RESOLUTION: Future meetings Wed 0900 US Eastern
<Arnaud> Thanks ericp
<BartvanLeeuwen> thx ericP
<Arnaud> Tracbot, end meeting
<Arnaud_> Trackbot, end meeting