RDF Data Shapes Working Group Teleconference

<Arnaud> 41#

<ericP> ack ??P9

<Arnaud> scribe: ArthurRyman

Admin

Arnaud: delay approval of minutes to next week so Arthur can make edit

subTopic: Next F2F

Arnaud: only 5 people may attend in person

<Labra> +q

unable to hear Jose

<Labra> labra: I just wanted to say that I was not sure

<Labra> labra: for me, it is not a problem if it is virtual

<Labra> because the travel expenses are high

<hknublau> maybe just have 6 hours per day

<hknublau> on phone yes

<SimonSteyskal> I definitely can't attend in person as already stated in the wiki

Arnaud: we will make a decision next week to either meet in-person or virtually for F2F3

subtopic: TPAC2015

Arnaud: who could attend a F2F at the next TPAC in Japan?

<BartvanLeeuwen> +1

<pfps> Going to Japan for a F2F is not something that I'm enthused about.

<Arnaud> STRAWPOLL: would you attend a WG F2F in October in Sapporo Japan?

<kcoyle> i'd take advantage of the excuse to go to japan

<ericP> no

<Arnaud> +!

<BartvanLeeuwen> +1

<Arnaud> +1

<ericP> 0

0

<SimonSteyskal> +0.5

<hknublau> -0.5

<pfps> -0.5

<ericP> -.5

<kcoyle> +.5

<Labra> 0

<Arnaud> STRAWPOLL: would you attend a WG F2F in Fall in France?

<SimonSteyskal> +1

<Labra> +1

<kcoyle> +1

<hknublau> time zone would be ideal

0

<pfps> ISWC is on the east coast two weeks before TPAC, I would go to a F2F near ISWC

<pfps> +0.5 France is more likely than Japan

<BartvanLeeuwen> +1

<ericP> +1

<hknublau> -1

<TallTed> I'd love to go to any.... but unlikely to get budget of time/money

<cygri> ack [IPcaller]

Tracking of Actions and Issues

<Arnaud> ISSUE-33

<trackbot> ISSUE-33 -- Shifting section "Shape Selection" to introduction? -- pending review

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/33

<pfps> I'm fine with closing this issue as "not currently completely relevant to the WG"

Arnaud: ISSUE-33 is editorial

<hknublau> +q

Holger: How do I close issues?

Arnaud: Mark them as pending review and we'll discuss it.

<Labra> +q

Arnaud: proposes to close ISSUE-33

<Arnaud> ISSUE-35

<trackbot> ISSUE-35 -- Language-tags -- raised

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/35

<Arnaud> PROPOSED: Open ISSUE-35

<pfps> open

Arnaud: proposes to open ISSUE-35

<TallTed> +1

<pfps> +1

+1

<kcoyle> +1

<cygri> +1

<SimonSteyskal> +1

<hknublau> Arnaud, the two tickets that I have proposals for are not even open (they are RAISED only)

RESOLUTION: Open ISSUE-35

<ericP> +1

<Dimitris> *apologies for joining late*

<pfps> The naming issues look a bit like re-arranging deck chairs on the Titanic, but I'm not against opening them.

<Arnaud> PROPOSED: open ISSUE-36 through ISSUE-39

<cygri> +1

<hknublau> +1

<SimonSteyskal> +1

<kcoyle> +1

<Dimitris> +1

+1

<Labra> +1

<TallTed> +1

<ericP> +1

RESOLUTION: open ISSUE-36 through ISSUE-39

RESOLUTION: ISSUE-33 is closed

<Arnaud> ISSUE-41

<trackbot> ISSUE-41 -- Using property paths to refer to values/types? -- raised

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/41

<Arnaud> ISSUE-42

<trackbot> ISSUE-42 -- Adding sh:notEqual to potential datatype properties? -- raised

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/42

<Arnaud> PROPOSED: open ISSUE-41, ISSUE-42

<cygri> +1

<SimonSteyskal> +1

<hknublau> +1

<kcoyle> +1

<ericP> +1

<Dimitris> +1

<Labra> +1

+1

RESOLUTION: open ISSUE-41, ISSUE-42

<pfps> ISSUE-41 is tied up with the status of SPARQL as an extension mechanism. If SPARQL is truely integrated into SHACL, then there are property paths in SHACL and the only thing left to consider is whether they are in the high-level language. If SPARQL is not truely a part of SHACL, then there is more to think about here.

Publication of UCR

ericP: UCR not published due to workload contention

<Arnaud> ACTION: ericp to publish the UCR by 14 April 2015 [recorded in http://www.w3.org/2015/04/09-shapes-minutes.html#action01]

<trackbot> Created ACTION-17 - Publish the ucr by 14 april 2015 [on Eric Prud'hommeaux - due 2015-04-16].

<pfps> I didn't notice any forward progress.

Requirements

<Arnaud> 2.6.11 Expressivity: Closed Shapes

<ericP> Closed Shapes Req

<scribe> ACTION: aryman to advance discussion of S40 by 16 April 2015 [recorded in http://www.w3.org/2015/04/09-shapes-minutes.html#action02]

<trackbot> Created ACTION-18 - Advance discussion of s40 by 16 april 2015 [on Arthur Ryman - due 2015-04-16].

subTopic: 2.6.11 Closed Shapes

pfps: concerned that there is no definition for how closed shapes work
... requires an existence proof for closed shapes that behaves intuitively from the user pov

<hknublau> I still want a definition of this before I can vote, -1 otherwise

<Zakim> cygri, you wanted to ask whether this is a requirement for a language construct or for an API operation

cygri: asks if it can be possible to indicate which part of a graph is considered to be closed

<pfps> If closed shapes are on the API then is it supposed to admit all SHACL shapes?

ericP: shex api allows this via api. not opposed to making it a language construct

<kcoyle> +q

Arnaud: expects to be able to say: "graph contains nodes a, b, c, and no others" in the shape

<ericP> existence proof of closed shapes

kcoyle: reminds us that the shape is documentation of the documents so an api solution is not aligned with that requirement

<pfps> gives error: ReferenceError: checkRemaining is not defined

<Arnaud> 2.7.2 Function and Property Macros

<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Function_and_Property_Macros

subTopic: 2.7.2 Function and Macro Requirement

hknublau: willing to make macros a SPARQL-only extension

ericP: withdraw my objection since we are not distinguishing between core vs SPARQL in the Requirements doc

Labra: will withdraw objection but want the macro mechanism to not be SPARQL-only

<Arnaud> PROPOSED: Approve 2.7.2 Function and Property Macros https://www.w3.org/2.7.2 Function and Property Macros2014/data-shapes/wiki/Requirements#Function_and_Property_Macros

<pfps> +0.5

<TallTed> +1

<SimonSteyskal> +1

+1

<cygri> 0

<ericP> +0

<Labra> 0.5

<hknublau> +1

<kcoyle> +0

<Dimitris> +1

RESOLUTION: Approve 2.7.2 Function and Property Macros https://www.w3.org/2.7.2 Function and Property Macros2014/data-shapes/wiki/Requirements#Function_and_Property_Macros

<cygri> (I think this is a general SPARQL issue and not really validation-specific, therefore this WG is not the best place for it)

<cygri> (And I don’t know what a non-SPARQL version of this would look like)

SHACL Spec

Arnaud: discussing ISSUE-2 what is the audience

<kcoyle> +q

kcoyle: discusses three audience division

<ericP> i got disconnected, but used that to show that the telecon reservation has been extended

ArthurRyman: 1) users who know OO but not SPARQL and will use the high level functionality, 2) authors who write new custom constraints in SPARQL, 3) implementers of SHACL engines - need precise spec

<kcoyle> link to arthur's email: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Mar/0228.html

cygri: add 4) this WG - writers of the spec

<pfps_> +1 to richard - there are many audiences, with different knowledge sets

pfps: agrees with Richard - we need to satisfy ourselves in order to finish

<Arnaud> PROPOSED: Close ISSUE-2 specifying that our audience is made of four groups 1) people who don't know SPARQL (e.g. app developers) and will use the high level functionality, 2) people who know SPARQL and will use the extension mechanism to go beyond the high level functionality, 3) implementers of SHACL engine, 4) spec developers and reviewers (starting with this WG members)

<ericP> we forgot to list the RDF haters who look for any reason to condem RDF

<pfps> +1

<Labra> labra: to say that the group 2) is assuming that the high level extension is going to be based on SPARQL only

<TallTed> I agree with Richard... distinction is less about knowing SPARQL and more about whether they're a basic user, an advanced user, an edge-case user...

<Labra> labra: if the high-level extension is generic, that group should not need to know SPARQL...maybe javascript

<pfps> -1 to javascript

cygri: propose to redefine 1) as those who read SHACL n=but don't write it

<Labra> @pfps: but the extension mechanism may not be restricted to SPARQL...could be other language (not necessarily SPARQL)

<kcoyle> not true

Labra: 2) should consist of people who know SOME other language

ArthurRyman: 1) consists of developers who both consume and provide APIs and need to both read and write shape docs

<pfps> I'm against calling SPARQL-in-SHACL as an *extension* mechanism.

<Arnaud> PROPOSED: Close ISSUE-2 specifying that our audience is made of four groups 1) people who don't know or want to use SPARQL (e.g. app developers) and will use the high level functionality, 2) people who know SPARQL and will use the extension mechanism to go beyond the high level functionality, 3) implementers of SHACL engine, 4) spec developers and reviewers (starting with this WG members)

<kcoyle> +q

<TallTed> PROPOSED: Close ISSUE-2 specifying that our audience is made of four groups 1) people who are satisfied by the simple, high-level functionality, 2) people who will use the extension mechanism to go beyond the high level functionality, 3) implementers of SHACL engines, 4) spec developers and reviewers (starting with this WG members)

<pfps> There was a long debate about moving SPARQL out of the first part of Holger's document so at least some in the WG want to divide audiences based on whether they know SPARQL.

<Labra> @pfps: people didn't want to move SPARQL out of the spec because they didn't know SPARQL

TallTed: the distinction is a) are you happy with the basics or do you want to write custom constraints, b) do you want to implement an engine for the basics or do you want to support SPARQL too

pfps: SPARQL is a core technology so not mentioning it is "marketting"

<pfps> If SHACL uses RDF, then the documents should not hide that fact. If SHACL uses SPARQL, then the documents should not hide that fact.

<ericP> does SHACL core use SPARQL? do users need to know that?

<Labra> @pfps but the mandatory use of SPARQL has not been decided yet

<pfps> Ted's distinction is not a bad one.

<Labra> +1 to Ted

<pfps> @Labra note the "If"

<ericP> +1 to Ted's distinction

<Labra> @pfps: ok

<ericP> pfps, "iff"?

+1 to Ted's distinction

<pfps> @eric If SHACL does not use SPARQL, then free to prominently state that in the primer!

<pfps> I am adamantly opposed to putting out a guide-like document without knowing what SHACL is.

<kcoyle> +1 to arthur's suggestion - move forward with Holger's draft

ArthurRyman: Holger proposed a division of the SHACL spec into Part 1 and 2 - Part 1 is ready for FPWD

<pfps> I do not believe that Part 1 of Holger's document is anywhere near ready for FPWD.

subTopic: Discuss Holger's Property Name Proposals

<Arnaud> ISSUE-38: Naming of cardinality facets

<trackbot> Notes added to ISSUE-38 Naming of cardinality facets.

<TallTed> issue-38?

<trackbot> issue-38 -- Naming of cardinality facets -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/38

<Zakim> ericP, you wanted to oppose count

<pfps> The naming of the SHACL properties is something that I care very, very little about.

ericP: objects to use of "count"

<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Facet_Property_Names#Cardinality

<cygri> +1 to ericP

ericP: stick with just minCount and maxCount

<Arnaud> PROPOSED: Close ISSUE-38, using minCount and maxCount (no Count)

<ericP> +1

<Labra> +1

+1

<hknublau> 0

<SimonSteyskal> +1

<TallTed> +0

<pfps> 0

<kcoyle> +1

<cygri> +1

fyi, oslc has "exactly-one"

<Dimitris> +0.5

<kcoyle> "loud and clear", arnaud

RESOLUTION: Close ISSUE-38, using minCount and maxCount (no count)

<cygri> ISSUE-39?

<trackbot> ISSUE-39 -- Naming of value shape facet -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/39

<kcoyle> re-load - i just voted

<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Facet_Property_Names#Value_Shape

@pfps What is missing in Holger's Part 1?

<kcoyle> vlueshape

<kcoyle> but spelled correctly

<SimonSteyskal> but we do have sh:valueType right?

<Arnaud> PROPOSED: Close ISSUE-39 using shape (not valueShape)

<hknublau> +1

<cygri> +1

+1

<SimonSteyskal> +1

<ericP> +0

<kcoyle> +0

<Labra> 0

<Dimitris> +0

<TallTed> -0.5

<pfps> 0.0000000000000000000000000000000000000000000000

<Labra> +1 to be consistent

<Labra> +q to say that we may vote both together

<Zakim> Labra, you wanted to say that we may vote both together

<TallTed> TallTed: shapes within shapes seems potentially confusing and problematic

<hknublau> But then we’d also need sh:valueDatatype

<hknublau> I’d close it now and we can reopen it if we call the other valueType.

<SimonSteyskal> or we stick to sh:shape, sh:type, sh:datatype

RESOLUTION: Close ISSUE-39 using shape (not valueShape)

<SimonSteyskal> ;)

<Labra> ok

<cygri> The deck chairs are nice and tidy!

<Arnaud> trackbot, end meeting