See also: IRC log
<Arnaud> scribe: michel
<kcoyle> i'm here
<ericP> ericP: some stuff ericP said
<ericP> ... some more inane crap
<Arnaud> PROPOSED: Approve minutes of the 5 February Telecon: http://www.w3.org/2015/02/05-shapes-minutes.html
<pfps> minutes look fine by me
RESOLUTION: Approve minutes of the 5 February Telecon: http://www.w3.org/2015/02/05-shapes-minutes.html
arnaud: no teleconference calll next week
... we will have our f2f
... asks everybody to indicate whether and how they will participate
... feedback on agenda is welcome
<hknublau> (I am not able to join the voice via Skype - it doesn’t react to the conference code).
F2F: https://www.w3.org/2014/data-shapes/wiki/F2F2
<pfps> It might be nice to have some time devoted to discussion of underlying issues. Maybe that is the point of the morning of the first Wednesday?
arnaud: will cover issues in the tracker
peter: lots of discussion of shapes vs classes recently, will wed be the time to discuss?
arnaud: yes that's the plan. two proposals on the table. hoping to focus on this and come to resolution
peter: each proposal has a different idea to what is a shape is.
... getting hung up on what goes into a proposal rather than what is in the proposal itself
... ldom suggests that shapes are classes
... constraints proposal suggests that shapes are not classes, but both are not sufficiently explicit
arnaud: how to link to shapes, classes, etc
... please feel free to propose any additional topics for discussion
pfps: will put together a document to "get us out of the weeds"
arnaud: feel free to raise issues as you see fit
arnaud: no actions pending review
... no open actions
... no issues pending review or raised
arnaud: issues on user stories were not being addressed
... contacted individuals responsible
... S6 https://www.w3.org/2014/data-shapes/track/issues/8
arnaud: unsure who is responsible
hknublau: not Dean or me
... check with Ralph
arnaud: issue 13 https://www.w3.org/2014/data-shapes/track/issues/13
https://www.w3.org/2014/data-shapes/wiki/User_Stories#S12:_App_Interoperability
scribe: Sandro responded - http://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Feb/0126.html
pfps: will incorporate in user story
arnaud: Dean has responses to inquiries
pfps: user stories need to be fixed or removed
arnaud: will communicate this
<Arnaud> http://w3c.github.io/data-shapes/data-shapes-ucr/
kcoyle: 80-90% done
arnaud: hope that next week we can make progress on the remaining issues
... have a clear plan to publish this draft
... please read the document, we need to know the issues to discuss at the meeting
arnaud: proposed a set of requirements for approval
... pfps was expressing concerns, we agreed to remove it altogether
... requirements were addressed
er - concerns were mostly addressed -
<Arnaud> PROPOSAL: Approve requirements 2.5.2, 2.5.4, 2.5.10, 2.5.11, 2.6, 2.7, 2.7.1, 2.7.4, 2.9.
pfps: 2.5.4 has been changed
... after objection was raised
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property_Type
ericP: had changed a few as a result of discussion
<TallTed> it's a wiki.... change history exists
pfps: property datatype
... now 2.5.3
arnaud: ericP and hknublau
ericP: we should re-examine property datatype, property type, node rdf type and make sense of it
hsolbrig: numbering is very fragile
... mediawiki uses tags, we should too
ericp: maybe we can work to get this functioning properly
<Arnaud> PROPOSAL: Approve requirements 2.5.2,2.5.10, 2.5.11, 2.6, 2.7, 2.7.1, 2.7.4, 2.9
<pfps> +1
<SimonSteyskal> +1
+1
<hsolbrig> +1
<ericP> +1
<TallTed> +1
<Labra> +1
RESOLUTION: Approve requirements 2.5.2,2.5.10, 2.5.11, 2.6, 2.7, 2.7.1, 2.7.4, 2.9
arnaud: discuss 2.5.3
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property_Datatype
pfps: restriction should read - if you have a restriction xsd:integer, you could have xsd:int; as it is stated now it could fail
... went from the value that the literal means to the syntactic form of the literal
ericP: two proposals: 1. you can constrain a property to have a literal with a particular datatype
... 2. you can constain a property to a inferred datatype (?)
<ericP> XSD type hierarchy
pfps: the xml schema - basic datatypes are disjoint
arnaud: request that interested parties discuss offline
<pfps> proposal: have both restriction by datatype and by value
ericP: do people like restrict to xsd:integer and the byte does match, or rather that it does not match?
hsolbrig: prefers the latter. more work for implementers, but less work for users
<TallTed> I think they're both necessary...
ericP: i thought the opposite...
<kcoyle> can
<kcoyle> can't unmute
kcoyle: in the datatypes that we'll be working with, simply limiting to a particular datatype would be sufficient, without looking at the value
... used for providing forms for input
<hknublau> I am also in favor of the simple direct matching.
<pfps> I don't understand - validation always has the value available
<hknublau> and if I remember correctly, Arthur was too
<TallTed> if I require an xsd:integer, even though in many senses xsd:byte might be thought a sub-set of xsd:integer, this might not be so for me.
ksolbrig: if you receive an instance of a datatype of "byte", but would that pass a constraint that specifies an "integer"
<Dimitris> I am also in favor of strict matching but we can have both as different types of restrictions
<SimonSteyskal> i second karen on that
<pfps> Well, XML Schema datatypes says that xsd:byte is a subset of xsd:integer
hsolbrig: if you restrict to xsd:integer, then xsd:byte should validate
<hknublau> Let’s add both variations and let people vote?
I think that both are needed
it's similar to what i was articulating from choosing a specific term in a hierarchy versus using any inferred subtype
arnaud: revision of Holger's proposal a few weeks ago
... had a straw poll to determine where people stand
<pfps> I have mentioned several issues that I have even with the current version of the document.
arnaud: have spent more time talking about it
... a vote on the proposal is meant to stimulate discussion as a starting point
<Arnaud> STRAWPOLL: Does Eric's proposal look to you like a good starting point?
<ericP> +1
<Labra> +1
<hsolbrig> +1
<SimonSteyskal> +1
+1
<pfps> -0
<kcoyle> +0 (don't really understand)
<Dimitris> 0 (didn't have time to read in detail)
<hknublau> 0 (fine as a discussion base of course)
<pfps> -0 lots of work is still needed
<TallTed> +0 (only skimmed)
arnaud: shape selectors
https://www.w3.org/2014/data-shapes/wiki/Shape_Selectors
<hknublau> +q
hsolbrig: clarification on meeting agenda
hnublau: appears to be two approaches - use rdf:type, or separate data structure
... other WG have tried to accomodate both
... we may not know what is the best approach
... came up with a generalization
... the validation can be parameterized
... one of the main motiviations to have shapes separate from classes is to avoid clashes.
... users may want to be able to slice and dice across dimensions
... add their own properties in their own namespace
... mixture of these shape selectors could be possible
pfps: disagree with the approach; we will end up with different input... challenging for users
arnaud: we'll get more opportunities to discuss this
<hknublau> I agree with Peter, but this is the last resort if we fail to compromise and have vetoes