RDF Data Shapes Working Group Teleconference

14 Sep 2016


See also: IRC log


hknublau, Arnaud, Dimitris, ericP, karen, AndyS, kcoyle, TallTed
ericP, hknublau


<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


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


Disposal of Raised issues


<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


<Arnaud> PROPOSED: Open ISSUE-177


<kcoyle> +1

<hknublau> +1


ISSUE-105: defined prefixes


<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


<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


<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

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 8 Sept 2016 Telecon: http://www.w3.org/2016/09/08-shapes-minutes.html
  2. Open ISSUE-177
  3. 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
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/09/26 16:18:43 $