W3C

RDF Data Shapes Working Group Teleconference

30 Apr 2015

Agenda

See also: IRC log

Attendees

Present
michel, kcoyle, ericP, Arnaud, labra, cygri, iovka, pfps, TallTed, hknublau
Regrets
aryman, SimonSteyskal, Dimitris
Chair
Arnaud
Scribe
iovka

Contents


+iovka

<Arnaud> scribenick: iovka

Admin

<Arnaud> PROPOSED: Approve minutes of the 23 April Telecons: http://www.w3.org/2015/04/23-shapes-minutes.html

<pfps> minutes look fine now

<kcoyle> none

RESOLUTION: Approve minutes of the 23 April Telecon: http://www.w3.org/2015/04/23-shapes-minutes.html

next week Arnaud will be absent

<kcoyle> maybe folks could present their proposals, without other agenda items

Arnaud: who wants to chair next week meeting ?

<pfps> I have no problems with Eric as chair

<kcoyle> eric is ok by me

Arnaud: Eric chair ?
... it would infortunate to skip the meeting, given the work to be done

<Arnaud> Teleconf 2015.05.07 chaired by Eric

Eric: accepts

Tracking of actions & issues

<Arnaud> http://www.w3.org/2014/data-shapes/track/actions/open

Arnaud: we should be able to close this one

User stories

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

<Arnaud> S40 Describing Inline Content versus References

Arnaud: the description of S40 was changed, can we approve it like this ?

pfps: fine with paragraph by Karen Coyle, not with paragraph by Arthur Ryman

Arnaud: Arthur is not here, remove his description ?

pfps: approve Karen's paragraph as S40 ?

<Arnaud> PROPOSED: Approve Karen's description as S40

<pfps> +1

<cygri> +1

<kcoyle> +1

<michel> +1

<TallTed> +1

<Labra> +1

<ericP> +1

RESOLUTION: Approve Karen's description as S40

pfps: S8 is suggested

Arnaud: not enough supporters

Requirements

<Arnaud> 2.6.11 Expressivity: Closed Shapes

Arnaud: are we ok with this requirement ?

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

pfps: as a requirement we do not know what it is
... this is not xml schema, we can have disjunction and negation; we are making a requirement we do not want how to satisfy

Arnaud: ericP, what do you think ?
... in xml schema, by default types are closed

<kcoyle> +q

Karen: we do not need a solution in order to have a requirement

<michel> +q agree on requirement gathering

ericP: ciritical functionality. pfps, do you mean you do not know how to satisfy it, or you do not know how people satisfy it ?
... there are lots of options
... there might be various strategies to meet this use case

michel: pretty crear requirement

<TallTed> with apologies for not answering the email more quickly -- https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Apr/0318.html

michel: I wonder whether there should be objection aginst this

cygri: one use case previously mentioned was mispelled properties
... in open shapes, this error won't be detected
... in closed shapes, it can be detected, because extra triple
... open shapes would be the default behaviour
... closed shapes for detecting mispelling is questionable

<pfps> +1 to richard's comment that closed shapes do not address misspelling

cygri: 2nd point, the name 'closed shape' is misleading
... there are different situations: maybe data is missing, maybe there is extra data, maybe both
... both are interesting
... people talk of this requirement is as buisness requirement, need to reject extra triples
... this is not what shacl should be for

<TallTed> the policy questions aren't part of the requirement

<TallTed> the requirement is about knowing whether the dataset being evaluated extends beyond the shape

<michel> the first aspect is to detect. the second is to deal with the policy for it

<TallTed> most of the other requirements are about detecting whether the dataset fits within the shape.

pfps: I am very negative againts this requirement, but am not going to vote against this

TallTed: frustrated by cygri's discussions on things that are not in the document
... this requirement is whether data is beyound shape, the remaining is whenther data is within shape

michel: is every approved requirement to be in the standard ?

Arnaud: it may be impossible to satisfy all the requirements. We must try to address
... at some point we must make a decision whether addressing or not

TallTed: addressing is not satisfying

<Arnaud> PROPOSED: Approve 2.6.11 Expressivity: Closed Shapes https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes

<michel> +1

<TallTed> +1

<Labra> +1

<ericP> +1

+1

<cygri> +0

<kcoyle> +1

<Arnaud> pfps: 0

<ericP> pfps: +0

RESOLUTION: Approve 2.6.11 Expressivity: Closed Shapes https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes

Arnaud: this was the last pending requirement
... maybe other requirements come, but now we can concentrate on the solution

<kcoyle> +q

<cygri> I have an action to raise a new requirement

Arnaud: editors should produce updated documents taking into account the decisions we take.

Karen: if we want to add a new requirement, do we bring it for a vote ?

Arnaud: yes
... I'm not going to put this on the agenda any more.

SHACL spec

Arnaud: 2 weeks ago we had a resolution that editors should put their proposal in decent shape, otherwise they will be dopped
... how many proposals do we have ? 3 ?
... let's give few minutes to the editors so that they present where they are

<ericP> semantics doc

<ericP> primer

ericP: this is semantics, and the primer
... I modified the primer to address issues from Karen and Peter
... semantics was modified mainly by iovka
... the challange from Peter was to propose a sound semantics, that's mostly we have here

Arnaud: this is in a good shape, we can keep it. What others think about it ?

cygri: these 2 proposals, do they address only the high-level language, or also the extensions ?

ericP: extensions is the main piece we didn't get to
... I think we can meet the requirements having the sparql semantics being an extension, having extension mechanism attached to a shape

<pfps> Is this going to be like the extension mechanism in the Shape Expressions member submission?

ericP: while validating a shape, you can invoke extension mechanisms

Arnaud: it's ok. we said decent shape, not complete
... what are we talking when we say ShEx ?

+q

<Labra> +q to say that my plan is to update my implementation to comply to that spec

<Zakim> Labra, you wanted to say that my plan is to update my implementation to comply to that spec

<ericP> iovka: we were successful in unifying the three points that pfps were different in the ShEx proposals

jose: my plan is to adapt my implementation

Arnaud: we have convergence, this is a good thin
... Holger, something about your draft ?

Holger: there was nothing to do, it was already implemented
... it meets all the requirements, it's ready to be considered

<michel> +q

Arnaud: peter's proposal ?

pfps: by document is missing english reperting erros, this is neither in the new shex
... the philosophy is met

Arnaud: how should we proceed ? see how the proposals evolve ? pfps, what do you suggest ?

pfps: we already know that one of the proposals is not complete
... Holger's proposal is compllete, even though it has some magic into it
... we do not believe promises

michel: how are we going to evaluate proposals ?

Arnaud: good question, I do not pretend to have the answer
... one option is to have a vote which one of the 3 we are starting with
... I do not think we have a consensus there

<pfps> Well, I would prefer something like Stardog ICV over my proposal, but that didn't get any support in the WG

Arnaud: this would be a starting point, any document can be modified,
... we could also give to people 2 more days to put everything together, then 2 weeks people to review the proposals

pfps: the big point is that there are 2 very very different technological bases
... impossible to proceed
... promises for things yet to come, I am very frustrated
... we cannot decide on things that are to come

<kcoyle> +q

pfps: a way forward would be to have each of the proposals evaluated by a different party

Arnaud: who do you ask to review ?

pfps: sb who cares enough in the cares of doing a good job, and also the technical background

Karen: I would like to see each of these proposals trying to solve the same problems, the same use cases

Arnaud: I like that

<pfps> who is going to choose the use cases?

+q

<pfps> there are a fair number of these already in the user stories wiki page

Arnaud: how do we chose the use cases ? everybody proposes one use case ?

Karen: nice if we had instanc data to test on

cygri: sounds good at first, but I'm a bit spectical
... if we fix user stories, people could interprete the use cases diffeently, the results would not be comparable

<Labra> +q to ask why don't we start by the shacl language operators and some test cases

cygri: another way is to have data and well defined requriements, but it would take too much time

Arnaud: I agree with cygri's concern. But it's still better than just voting w/o enough information

<Zakim> Labra, you wanted to ask why don't we start by the shacl language operators and some test cases

jose: we can start with the different language operators.
... the languages are not so different, they have the same language features
... maybe having an agreement on the language features

TallTed: one proposal is fairly complete, but has some magic. this is an issue to be raised
... another has some significant gaps

ericP: what are the significant gaps ?

<pfps> There is no treatment of an extension mechanism in http://w3c.github.io/data-shapes/semantics/

TallTed: we do not have yet two proposals to put side by side, both have gaps, this is a reason to keep both

Arnaud: we have 3, not 2
... I leave it to the proponents to take the challenge, picking the use cases, and document these
... web page, where everybody gives a solution for some use case, and the others can show their solution

michel: what metric to use to compare the solutions ?

Arnaud: the menric is 1. do you address all the requirements, which ones you don't ?

michel: list of requirements, check boxes ?

<michel> pointers to sections

Arnaud: the editors should document the limits of their poposals

cygri: let's look back to the charter, section 4, deliverables
... see the non optional things there

<michel> gotta run. excited to see progress on clear enumeration of coverage of approved/non-approved requirements

cygri: the ShEx proposal does not address a signficant part, because does not propose an extensibility mechnism

<Arnaud> STRAWPOLL: use as a starting point a) Peter's proposal, 2) Holger's proposal, 3) Eric's proposal

<pfps> It's a bit premature to make -1 be "can't live with it"

<hknublau> too many people are missing today

<TallTed> strawpoll is about general feeling. it's not a binding vote in any way.

<kcoyle> a) +0 b) +.5 c) +.5

<cygri> a) +0.5 b) +0.8 c) -0.8

<pfps> a) +1 b) 0 c) -1

<TallTed> a) +0.5 b) +0.8 c) -0.5

<hknublau> a) 0 b) +1 c) -1 (surprise!)

<ericP> a) -1 b) -.8 c) +1

<Labra> a) -1 b) -0.5 c) +1

<cygri> The problem with c) is that it addresses only a part of the charter. Proposals a) and b) are complete.

Arnaud: the group may stick with one proposal, and people unhappy can continue their effort independently
... unless we can merge the different propsals, we need to take a winner and continue this way

topit: issues

<Arnaud> ISSUE-36: Naming of value type facet https://www.w3.org/2014/data-shapes/track/issues/36

<trackbot> Notes added to ISSUE-36 Naming of value type facet.

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

Holger: no majority. the proposition was to rename value type to type

<TallTed> issue-36: polling on wiki page - https://www.w3.org/2014/data-shapes/wiki/Facet_Property_Names#Value_Type

<trackbot> Notes added to issue-36 Naming of value type facet.

<Arnaud> PROPOSED: Close ISSUE-36 by calling value type facet "type"

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

<TallTed> I'm inclined to sh:valueType

<hknublau> +1

<cygri> +1

<TallTed> -1

<kcoyle> -1

<Arnaud> PROPOSED: Close ISSUE-36 by calling value type facet "sh:valueType"

<TallTed> +1

<ericP> +1

<kcoyle> +1

<hknublau> 0

<cygri> -1

<Labra> 0

<ericP> sh:referencedRDFType?

<Arnaud> PROPOSED: Close ISSUE-36 by calling value type facet "sh:valueType" and revert resolution of ISSUE-39 to use "sh:valueShape" rather than "sh:shape"

<kcoyle> yep

<TallTed> +1

<hknublau> 0

<Labra> 0

<cygri> 0

<kcoyle> +1

cygri: having the word "value" added to all, or to none of the property names, but not mixing

<Zakim> ericP, you wanted to sh:referencedRDFType?

<ericP> 0

<pfps> I am deeply uninterested in picky details of syntax, particularly determining piecemeal which names are used for particular constructs.

people discussing on how to call it

RESOLUTION: Close ISSUE-36 by calling value type facet "sh:valueType" and revert resolution of ISSUE-39 to use "sh:valueShape" rather than "sh:shape"

Arnaud: we can live with it, I'm going to close it

<TallTed> we might unify these into collections of terms and thus one propsal/resolution?

<TallTed> issue-23?

<trackbot> issue-23 -- Shapes, classes and punning -- open

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

<hknublau> +q

Holger: accept that there are 2 different view points
... we should be able to support both, with or without interaction with classes
... my proposal is to keep classes and shapes separate

Arnaud: I do not want to re-open the question whether shapes are classes
... how do we accomodate these two viewpoints

<hknublau> +q

pfps: shapes as classes is bad, people would expect too much of it, I prefer a solution where we do not permit associatin clasess and shapes

TallTed and pfps discuss about what punning is

<cygri> There is a specific and a general sense of punning here

<Arnaud> ack TallTed[

<Zakim> TallTed, you wanted to suggest shapeScope (rather than classScope) as inverse of classShape

TallTed: punning is not in any spec, it's a functionality, I don't think we shoud document it in a spec

<pfps> I don't see Holger's solution as much of a compromise

<Arnaud> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 23 April Telecon: http://www.w3.org/2015/04/23-shapes-minutes.html
  2. Approve Karen's description as S40
  3. Approve 2.6.11 Expressivity: Closed Shapes https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes
  4. Close ISSUE-36 by calling value type facet "sh:valueType" and revert resolution of ISSUE-39 to use "sh:valueShape" rather than "sh:shape"
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2015/05/13 21:47:07 $