RDF Data Shapes Working Group Teleconference

08 Sep 2016


See also: IRC log


hknublau, pano, AndyS, kcoyle, simonstey, Arnaud, TallTed, marqh, hsolbrig, BartvanLeeuwen



<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

ISSUE-105: defined prefixes

<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.


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 ...

ISSUE-137: language tag

<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

Meeting time

<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

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 1 Sept 2016 Telecon: http://www.w3.org/2016/09/01-shapes-minutes
  2. Future meetings Wed 0900 US Eastern
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/09/14 15:40:18 $