See also: IRC log
<BartvanLeeuwen> Zakim: ??P15 is me
<Arnaud> scribe: hsolbrig
<Arnaud> PROPOSED: Approve minutes of the 12 March Telecon: http://www.w3.org/2015/03/12-shapes-minutes.html
<pfps> Minutes looked fine to me
RESOLUTION: Approve minutes of the 12 March Telecon: http://www.w3.org/2015/03/12-shapes-minutes.html
Arnaud: will meet again next week on March 26
... FTF - preferred option is Toronto, CA May 19 or 26
<pfps> ... which isn't working at all right now
Arnaud: Propose May 19-21 in Toronto and see whether Simon can participate for FTF
ArthurRyman: Will arrange hosting with the lab.
<cygri> Arnaud, I expect to be able to join remotely at any of the tentative dates
hsolbrig: S17 is revised. Apologies for not mailing
Arnaud: Close action 11
Arnaud: Issue-15 related to S17
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S17:_Specify_subsets_of_data
<cygri> ISSUE-17?
<trackbot> ISSUE-17 -- S19 and S20 need information to distinguish from ontology recognition -- closed
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/17
<pfps> ISSUE-15, I think
https://www.w3.org/2014/data-shapes/wiki/User_Stories#S17:_Specify_subsets_of_data
Ericp: Propose appoint one other person to read Issue 15 related to S17
<ericP> last sentence, paragraph 2: "They could also act as filters, funneling incoming instances to secondary processes where necessary. "
<Arnaud> pfps, are you satisfied with the revision? do you feel it addresses your concern and we can close ISSUE-15?
<pfps> I'm still not sure just what S17 is about, but it does look as if it now has a connection to shapes, so I'm fine with closing ISSUE-15.
<pfps> ... and leaving the hard work to the UC&R editors. :-)
RESOLUTION: close ISSUE-15, accepting Harold's revision
Arnaud: Milestone -- all issues against user stories are now closed. Whee!
<pfps> Don't celebrate too soon. There are new user stories to consider.
Arnaud: Karen -- we have a draft that the editors believe that can be released as the first WD?
Karen: Still needs some formatting, hopeing to cajole Simon into changing it.
Arnaud: Are you guys ready to approve the first public working draft now or a week to read?
<pfps> Remember, publish early - publish often. It's possible to completely junk a FPWD and replace it with something completely different.
<pfps> I've been ready to approve UC&R for FPWD for a couple of months.
Arnaud: No commitment, just a first draft, we can start over if needs.
<ericP> as staff contact, i'm obliged to pressure people to publish
<Arnaud> PROPOSED: publish UCR as a FPWD http://w3c.github.io/data-shapes/data-shapes-ucr/
<ericP> +1
<BartvanLeeuwen> +1
<Labra> +1
<Dimitris> +1
<pfps> +2
+1
<TallTed> +1
<kcoyle> +1
<ArthurRyman> +1
<cygri> -0 would have liked to read it before approving it
RESOLUTION: publish UCR as a FPWD http://w3c.github.io/data-shapes/data-shapes-ucr/
<ArthurRyman> fyi, I have completed my ACTION to introduce Arnaud to my contact in the IBM Toronto Lab
Arnaud: Publishing is a rather cumbersome process, lots of steps before it actually arrives including W3 management approval.
<pfps> Actual publishing takes somewhere between 1 hour and 1 month.
Arnaud: Will take a few days, perhaps a week to actually show up on the TR space
<michel> +1
Arnaud: I have a list of requirements that should be ready for approval
<Arnaud> PROPOSED: Approve requirements 2.14.1, 2.14.2, 2.14.3
<ArthurRyman> @ericP, when glaciers are heavy we use smoke signals to communicate
<hknublau> +1
<pfps> I'm not particularly happy with any of the 2.14 requirements. I view them as, at best, nice-to-have. If they cause any problems I would vote to shove them under the bus.
<pfps> =0
<pfps> 0
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.03.19#Requirements
<TallTed> +1
+1
<ArthurRyman> +1
<Dimitris> +1
<Labra> +0
<michel> +0
ericp: Default value may cause interesting issues with the public
ArthurRyman: We shouldn't strictly interpret shapes for constraint checking. Use cases are to support tools as well
<pfps> Yes, default value is likely to require quite a bit of effort on whoever writes primers and guides.
ericp: Could we add "consuming applications" into the document to clarify?
Arnaud: Would rather not do it on the fly
RESOLUTION: Approved requirements 2.14.1 Property Default Value, 2.14.2 Property Labels at Shape, 2.14.3 Property Comment in a Shape
Arnaud: We are left with 5 requirements w/ objections
... First one is function and property macros
<Arnaud> 2.7.2 Function and Property Macros
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Function_and_Property_Macros
<ericP> maybe we can have a discussion of closed shapes/closed schema
ArthurRyman: This sounds like an extension mechanism, wouldn't it depend on the execution language?
<ericP> maybe we can have a discussion of closed shapes/closed schema/graph coverage
<hknublau> I think our time would be best spent on the specs today
ericP: Against it because I don't want to have the same conversation again ...
Arnaud: Is there any of the 5 requirements that folks think could have the objections resolved?
<cygri> Closed Shapes has a -1 from Arthur as well
Ericp: Closed shapes/close schema
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes
<Arnaud> Expressivity: Closed Shapes
ericp: Arthur's concern was around an LDP endpoint it couldn't store... I don't think that closed schema is only about what the LDP endpoint does when it receives instance data.
... client programmers will want a tool to know whether a given service will be losing information
<pfps> Does anyone have a definition of closed shapes or closed schema that works with the approved requirements?
ArthurRyman: Not just LDP, any REST api. Benefits of RDF is that it is extensible. One parser can parse anything, but receiving application may not understand everything. Never want to force customers into concurrent updates.
... We should be encouraging forgiving and robust behavior, with message, but not "reject"
<TallTed> "reject" is not "break"
<TallTed> "reject" is "your submission doesn't fit my box"
<ericP> "silent failure" is more often "break"
cygri: This may not require any special support in the language. Once you can define shapes, isn't it up to the process to treat it as closed?
... If server publishes a shape -- here is the information I need and the options, but doesn't need to say it is closed. One mode could check "is anything missing to satisfy" a different mode could say "is there any extra that is unnecessary"
Arnaud: My understanding that if you have those two modes, it should cover the use cases.
<pfps> That requires support from the implementation, I think.
cygri: Is it a language feature to say what is closed or is it a procedure.
ericp: My guess is that the semantics would have to reflect this -- there are many more use cases, and without this you can't know you've made a mistake.
michel: This kind of behavior is pretty important in data exchange, where client expects to see dat in a particular shape.
<hknublau> +q
<pfps> Right, if implementations need to be able to do it, there needs to be a specification of what it is that they are supposed to be doing.
<cygri> Maybe the wording of the requirement could be clarified?
michel: could see either way. An important requirement and needs to be done, but as language or server ... either way
ArthurRyman: It would be a burden on a client to have to sanitize if the server says that it doesn't take extra content.
<michel> +q
Arnaud: The server can tell you: here are the properties I recognize
hknublau: If we limit to the number of properties that are explicit (using shacl:property) but if it includes information in SPARQL it would be hard to implement.
<ericP> ArthurRyman, you spoke of the server letting the client know what's in the fringe. do you want to leverage shacl for that?
hknublau: Do not understand how we are supposed to reference inheritence w/ subshape. Sympathetic with idea but concerned about implementability.
<Labra> +q
michel: In HL7, they are expected to conform to one spec. Any additional information would make it invalid. Support ability to reject as "malformed"
<ericP> michel, we can disregard health care; it's only 18% of the US GDP so a trivial market.
michel: Server could be populating other sorts of tables such as SQL and might have any where to put it if they can't reject.
<pfps> If the task is to populate an RDB table, then just ignore the extra.
<Arnaud> pfps, but can the server say that this is what will happen?
<pfps> Sure, why not?
<Arnaud> how?
Labra: If a service has extra properties. If the designer of shapes wants closed or open they need the ability to say it.
ArthurRyman: This requirement is the ability to define a shape as closed. We need to be convinced that it is implementable
<pfps> The service can say anything it wants to. It can say "I'm taking all the triples and ignoring them". It can say "I'm talking all the triples and carefully placing them in a graph DB." It can say any gradation in between.
<hknublau> +q
Arnaud: XML Schema has them closed by default and you open them by XSD Any. Should we have XSD Any by default?
hknublau: If we interpret this as excluding explicitly enumerated properties, then templates already implement this. Wouldn't have to be a requirement as "satisfy templates" requirement would cover it
ericp: Are there semantics for that?
hnkublau: Closed == exclude any properties that aren't explictely enumerated.
Arnaud: By default to we accept more than what is there?
<cygri> I’d like to see a definition of what “closed” means.
Labra: Holger is talking about how he wants to implement it. Do we need to say in the language that some shapes are closed?
<pfps> +1 to cygri
Labra: Open by default and closed when stated
Arnaud: Propose further discussion on the wiki
cygri: Still have trouble understanding what the requirement really asks for.
... need to understand how this interacts with, say need to have an integer. Now I have string data so it is invalid -- does this pass in "open"?
... would like to understand what notion is actually being discussed.
<pfps> I'm happy. :-)
I'll have what he's drinking
Arnaud: A whole bunch of drafts, at least 3 different versions and a lot on the mailing list
... none have been approved or adopted
<ArthurRyman> @ericP, what is the meaning of <SH|TC>?
Anaud: Encourage editors to make it really clear that they are merely proposals
Arnaud: Straw poll last week was about where people stood on general approach bottom up or top down (a) or (b)
... group was divided. May be fear or misinterpretation or fear of depencency on SPARQL
@pfps - link?
Arnaud: The number of documents we produce is a working group decision. Can publish informative notes, specifications on recommendation track, not everything has to be in same document. Several specs can all become recommendations, dependencies or not...
... A document cant' become a normative recommendation if it depends on a non-normative document.
<hknublau> +q
Arnaud: We have to be aware if there are unpopular extension mechanisms that, if present the document, don't get implemented it will impede adoption.
... If document is architected around a layer that isn't implemented, you are "really screwed"
... Implementation requirement may play a key role on how things move forward
<pfps> Are there any proposals that we have seen that are architected around a layer that needs implementation?
hknublau: Understand the situation, but am not in favor of splitting the documents because there have to be references.
... My revision is more clearly divided between sparql and non-sparql bits
<Labra> +q
hknublau: Don't understand issues about implementations. It just requires SPARQL queries, we can publish an open source implementation
Arnaud: Working groups have failed at this. If it is easy and we have reports that is great
<pfps> I don't understand the scribing of what Arnaud said.
Arnaud: My understanding is that you've moved the SPARQL stuff to later in the document that separates the SPARQL from the high level stuff. If they only want high level they only need to read to section 6
Labra: I am in favor of a more neutral high level language, I really like Eric's approach and could agree with sections 1-6 in holgar's document. Maybe we could have a separate document that is combo of Eric's and Holger's 1-6?
<Arnaud> pfps, hknublau said it will be easy to get implementations, I said other WGs thought so too but failed
<Labra> Labra: but remove references to SPARQL in Holger's sections 1-6
ericp: My objective was to very explicitly document what a shape is. Cardinality, node type, value type, etc. Each is attached to the semantics that tell you how to evaluate that. Objective was a short and clear spec that gave a ground for other semantics
<hknublau> @labra, yes 2-6 were supposed to be free of SPARQL refs, as much as possible
<hknublau> if I have forgotten some, then I’ll fix that
<pfps> In http://w3c.github.io/data-shapes/shacl/ there are features in Section 4 that are defined in terms of SPARQL plus some extra code. (It really doesn't matter what is said in the documents, what matters is what the specification needs.)
ericp: my is to provide a ground that you can reference in other semantics.
<Labra> hknublau: but they contain links to SPARQL anyway...
ericp: This text could serve as the narritive for the formal semantics
... Holger said it doesn't deal with global constrains, but I haven't figured out what these are... a shape constraint atached to a SPARQL query.
<ArthurRyman> what is the link to Eric's new spec?
<ericP> ericP's semantics proposal
<pfps> The exposition in http://w3c.github.io/data-shapes/semantics/ has ill-founded constructs, or at least that is what would come from the intuitive reading of the document.
<pfps> Global constraints don't (need to) have a shape at all.
Arnaud: Holgar - why are you against separating 1-6 from the SPARQL and producing two documents?
... Eric and Jose pushing for top down approach. Arthur pushing for different levels. Karen not in one camp or another.
<Labra> I have been unconnected and zakim says the conference is restricted...
hknublau: Are these just attempts of avoiding how the high level language and SPARQL interact.
<michel> +q
<pfps> I don't understand the rationale for separation the first part of http://w3c.github.io/data-shapes/shacl/ from the rest. The first part of that document is given meaning by SPARQL++ so there would be no gain as far as I can see.
+q
<pfps> If there is a need to have a high-level profile, it is easy to put that into a normative guide or some other normative document.
hknublau: this is a core unresolved question and slicing the documents just gets these confused. A document without the SPARQL bit is giving the option of ... we need to resolve the quesition of how SPARQL is going to be accomidated
<pfps> +1 to holger
<hknublau> (the above was cygri)
Arnaud: we have agreed to specify the semantics (to the extent possible) using SPARQL, but it is contentius whether SPARQL is necessary for implementation
<pfps> Nothing in http://w3c.github.io/data-shapes/shacl/ says that SPARQL is necessary for implementing the high-level language.
<pfps> SPARQL is just the specification language.
michel: I find it distracting to find SPARQL references in the main document. Separate document is best. I worry about templating mechanism as people will express constraints using templates vs. SHACL itself.
<ericP> hsolbrig: concur with michel re separation
<ericP> ... issue of what a SHACL construct does
<Labra> but there are other ways to specify the semantics that only in SPARQL
<ericP> ... no objection to using SPARQL if that's the simplest way
<ericP> ... worried about the camel's nose
<ericP> ... if it's implementable in SPARQL, more power to it
<pfps> Well, then, someone needs to come up with an alternative that covers the requirements.
<Zakim> ericP, you wanted to ask why this doc needs to tell you how to implement with SPARQL
<pfps> Or make a proposal that excludes some requirements.
<ericP> ... but don't want full SPARQL expressivity
<Labra> but we should be able to identify the language constructs so the users know which is the SHACL language
<pfps> Proposals that just cover the core language leave the hard decisions up to later, and can close off the route to the best solution.
<cygri> ericP, it needs to say how SPARQL would be used as an extension mechanism
<pfps> +1 to cygri
ArthurRyman: The separation I propoesd is based on audience. The largest audience will be those who don't use or know SPARQL. It should express a high level core language and not mention templates of SPARQL
<pfps> Either that or it needs to say that it is throwing SPARQL extensions under the bus, and see whether the working group finds that acceptable.
<ericP> can't a semantics doc talk about an extension mechanism (returns T or F), and have other docs talk about various implementations of the extensions?
<pfps> I don't think that Arthur's proposal is a step forward. It also leaves the hard decisions to later.
<Labra> Eric's core language proposal can be extended with some mechanism to invoke a external constraint language like SPARQL, javascript, etc.
Arnaud: We have a resolution that we will define the semantics using SPARQL and an extension mechanism using SPARQL. THe question is whether it HAS to be implemented using SQARQL
<pfps> It is entirely possible that the core semantics could make it impossible to extend in particular ways.
<Labra> it is just a matter to add a new language construct to have that feature
<hknublau> Arnaud, this is a show stopper f or us.
<hknublau> Many people have been OK with keeping the documents.
<hknublau> a single document
<pfps> OK, let's add a new language feature that permits one to define shapes based on whether the IRI of a node encodes a theorem in arithmetic.
<ArthurRyman> @pfps the WG can control what is in the core and ensure that it upward compatible with the extension mechanism
<ericP> hknublau, why is it a show stopper?
<pfps> @Arthur: NO!
<BartvanLeeuwen> bye
<hknublau> I had already explained this. Because someone will object to the SPARQL feature, and we end up with nothing at all.
<ericP> if the spaql impl is useful, why don't you think it will get implementations and editorial action?
<Arnaud> trackbot, end meeting