See also: IRC log
<Arnaud> scribenick: iovka
<Arnaud> PROPOSED: Approve minutes of the 23 April Telecons: http://www.w3.org/2015/04/23-shapes-minutes.html
<pfps> minutes look fine now
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
Arnaud: we should be able to close this one
<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
RESOLUTION: Approve Karen's description as S40
pfps: S8 is suggested
Arnaud: not enough supporters
<Arnaud> 2.6.11 Expressivity: Closed Shapes
Arnaud: are we ok with this requirement ?
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
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
<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
<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 ?
... I'm not going to put this on the agenda any more.
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: 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 ?
<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
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
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?
<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
<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.
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"
<TallTed> I'm inclined to sh:valueType
<Arnaud> PROPOSED: Close ISSUE-36 by calling value type facet "sh:valueType"
<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"
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?
<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?
<trackbot> issue-23 -- Shapes, classes and punning -- open
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
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