14:04:22 <RRSAgent> RRSAgent has joined #shapes
14:04:22 <RRSAgent> logging to http://www.w3.org/2015/02/17-shapes-irc
14:04:34 <ericP> Zakim, space for 10 for 540 minutes?
14:04:35 <Zakim> ok, ericP; conference Team_(shapes)14:04Z scheduled with code 26631 (CONF1) for 540 minutes until 2304Z
14:05:06 <Zakim> Team_(shapes)14:04Z has now started
14:05:10 <Arnaud> rssagent, make logs rdf-data-shapes
<Arnaud> Meeting: RDF Data Shapes Working Group Teleconference
14:05:15 <Zakim> +pfps
14:05:22 <pfps> OK, 26631 works for me
14:05:33 <Zakim> +Dimitris
14:05:35 <Zakim> +??P19
14:05:36 <Zakim> +??P17
14:05:54 <Zakim> + +1.617.715.aaaa
14:06:04 <SimonSteyskal> zakim, ??P17 is me
14:06:04 <Zakim> +SimonSteyskal; got it
14:06:10 <cygri> zakim, ??P19 is me
14:06:12 <Zakim> +cygri; got it
14:06:17 <SimonSteyskal> thx ;)
14:06:17 <kcoyle> kcoyle has joined #shapes
14:06:38 <cygri> zakim, mute me
14:06:38 <Zakim> cygri should now be muted
14:07:16 <cygri> zakim, unmute me
14:07:16 <Zakim> cygri should no longer be muted
14:07:20 <pfps> zakim, who is here?
14:07:20 <Zakim> On the phone I see pfps, cygri, Dimitris, SimonSteyskal, +1.617.715.aaaa
14:07:22 <Zakim> On IRC I see kcoyle, RRSAgent, Zakim, Arnaud, cygri, Dimitris, SimonSteyskal, pfps, hknublau, rhiaro, sandro, ericP, trackbot
14:07:46 <pfps> q+
14:07:48 <pfps> q-
14:08:56 <SimonSteyskal> SimonSteyskal has joined #shapes
14:08:59 <ericP> Zakim, aaaa is F2F
14:08:59 <Zakim> +F2F; got it
14:09:57 <ArthurRyman> ArthurRyman has joined #shapes
14:10:30 <Arnaud> RRSAgent, make logs rdf-data-shapes
14:11:46 <pfps> I can scribe.  The best times would be during your mornings.
14:11:55 <ArthurRyman> scribe: ArthurRyman
<ArthurRyman> agenda: https://www.w3.org/2014/data-shapes/wiki/F2F2#Day_1_-_Tuesday_February_17
<ArthurRyman> chair: Arnaud
14:12:06 <ArthurRyman> TOPIC: Introductions
14:12:54 <ericP> ArthurRyman: (IBM). worked on OSCL Resource Shapes
14:13:02 <pfps> There appear to be some people in the meeting who are not on IRC.
14:13:15 <ericP> kcoyle: Dublin Core Metadata Initiative.
14:13:29 <ericP> hsolbrig: (Mayo) @@@
14:13:45 <ArthurRyman> s/OSCL/OSLC/
14:14:13 <ericP> ericP: @@@
14:14:29 <ericP> Arnaud: (IBM). wearing the chair hat
14:15:01 <labra> labra has joined #shapes
14:15:03 <hsolbrig> hsolbrig has joined #shapes
14:15:32 <iovka> iovka has joined #shapes
14:15:36 <Dimitris> *Hi*
14:15:40 <pfps> There are a number of people who have come into the working group from shape expressions.  Could they look over the requirements to see if their expectations for the result of the working group are being met.
14:16:12 <cygri> cygri: Richard Cyganiak, TopQuadrant
14:16:46 <pfps> I'm Peter Patel-Schneider (pfps).  I have been involved in the design of RDF and OWL.
14:18:24 <ArthurRyman> TOPIC: Meeting Goals
14:18:30 <ericP> SimonSteyskal: exploring how shapes will be useful at Siemens
14:19:50 <ArthurRyman> Arnaud: we've made some progress but the discussions have been very contentious
14:20:19 <ArthurRyman> Arnaud: pressure to keep on schedule and deliver on time +/- 3 months on a 2 year charter
14:20:30 <SimonSteyskal> there is some echo
14:21:00 <ArthurRyman> Please MUTE unless you are speaking
14:21:24 <pfps> zakim, mute cygri
14:21:24 <Zakim> cygri should now be muted
14:22:12 <SimonSteyskal> now i dont hear anything
14:22:15 <ArthurRyman> Arnaud: W3C works on consensus - can you live with a decision you don't agree with
14:22:16 <SimonSteyskal> hm
14:22:56 <iovka> presentation Iovka Boneva : University of Lille and Inria. I'm interested in schema-like language for RDF, and I hope the one this group comes up has well defined formal semantics with which we could work for research questions in theory of data(bases).
14:22:58 <Zakim> -SimonSteyskal
14:23:06 <ArthurRyman> Arnaud: 3 deliverables: RDF syntax, semantics, plus optional compact syntax
14:23:11 <Zakim> +??P17
14:23:21 <SimonSteyskal> zakim, ??P17 is me
14:23:21 <Zakim> +SimonSteyskal; got it
14:23:34 <ArthurRyman> Arnaud: Day 1- user stories, requirements
14:23:47 <ArthurRyman> Arnaud: Day 2 - solutions
14:23:56 <SimonSteyskal> had to redial
14:24:32 <ArthurRyman> Arnaud: Iovka will give a presentation on performance considerations
14:25:08 <ArthurRyman> Arnaud: we will also discuss the need for a Primer (optional)
14:25:39 <ArthurRyman> Arnaud: we'll also discuss Test Suite - need to prove that the solution is implementable
14:26:54 <ArthurRyman> Arnaud: the Test Suite is needed to validate implementations - we should not wait till the last minute
14:27:51 <ArthurRyman> ericP: Test Suite was developed for SPARQL as a way to discuss Issues
14:29:57 <ArthurRyman> TOPIC: User Stories
14:30:02 <hsolbrig_> hsolbrig_ has joined #shapes
14:31:05 <ArthurRyman> Arnaud: we need to publish a First Public Working Draft
14:31:24 <kcoyle> http://w3c.github.io/data-shapes/data-shapes-ucr/
14:31:40 <pfps> q+
14:31:42 <ArthurRyman> Arnaud: currently we have an Editor's Draft
14:32:54 <pfps> There are actually very good reasons for most of the publication rules, even though some of them can be a pain to meet.  :-)
14:33:07 <ArthurRyman> Arnaud: the W3C publication process is highly complex
14:34:19 <ArthurRyman> ericP: the Editor's Draft is good way to get public feedback
14:34:50 <Arnaud> ack pfps
14:35:34 <ArthurRyman> pfps: pointer to Editor's Draft should be added to the man web page, in Deliverables section
14:36:24 <ArthurRyman> kcoyle: we turned the user stories into use cases, added links to requirements
14:36:32 <TallTed> TallTed has joined #shapes
14:37:43 <ArthurRyman> kcoyle: people who wrote user stories should look at how they have been converted into use cases
14:39:16 <ArthurRyman> Arnaud: describes process of developng user stories, use cases, and requirements. LPD did this separation, we have blurred the distinctions
14:39:32 <ArthurRyman> s/LPD/LDP/
14:41:44 <ArthurRyman> Arnaud: everything is now a use case, but some content is requirements
14:42:37 <pfps> I'm happy with the user stories staying on the Wiki, and the WG document having only Use Cases.  It might be a good idea to have the WG document point back to the WIki page, if that is possible.
14:43:05 <pfps> My initial, very quick, pass over the draft indicates that the transfer was quite successful.
14:43:21 <SimonSteyskal> we tried to extract the core intention of each story
14:43:45 <SimonSteyskal> leading to the summary section
14:44:21 <ArthurRyman> kcoyle: we do not have all three levels, we converted everything to use cases - do we need the three levels
14:44:58 <SimonSteyskal> +q
14:45:53 <Arnaud> ack SimonSteyskal
14:46:32 <ArthurRyman> Arnaud: holger raised an issue about the use case document
14:47:39 <ArthurRyman> SimonSteyskal: we converted the user stories to use cases
14:49:42 <ArthurRyman> discussion about inclusion of code, need for abstraction, need for formality
14:51:49 <ArthurRyman> ericP: Holger's point is that user stories are different than use case
14:52:35 <ArthurRyman> ericP: however, does this cause a problem - do we need user stories
14:53:18 <SimonSteyskal> +q
14:53:24 <Arnaud> ack SimonSteyskal
14:53:35 <cygri> q+ to say that Holger intends to join after lunch
14:54:21 <cygri> zakim, unmute me
14:54:21 <Zakim> cygri should no longer be muted
14:54:27 <Arnaud> ack cygri
14:54:27 <Zakim> cygri, you wanted to say that Holger intends to join after lunch
14:54:41 <ArthurRyman> SimonSteyskal: agree with Holger - the use cases have too much user story content in them
14:54:46 <cygri> zakim, mute me
14:54:46 <Zakim> cygri should now be muted
14:55:01 <iovka> iovka has joined #shapes
14:56:47 <SimonSteyskal> as I said, if the WG thinks this is required I'm totally fine with doing it
14:57:20 <SimonSteyskal> but for the FPWD it's maybe sufficient enough
14:57:21 <SimonSteyskal> as of now
14:58:46 <SimonSteyskal> k
14:58:55 <SimonSteyskal> http://www.w3.org/2014/data-shapes/track/issues/open
14:59:10 <Zakim> -cygri
14:59:37 <SimonSteyskal> all stories we discussed at last call are still open or pending review
14:59:41 <pfps> I have not received anything back from David Martin.
15:00:58 <Arnaud> https://www.w3.org/2014/data-shapes/track/issues/pendingreview
15:01:16 <pfps> q+
15:01:20 <Arnaud> ack pfps
15:02:34 <ArthurRyman> reviewing issues in Tracker
15:03:11 <pfps> PROPOSED: Close ISSUE-13 as per Sandro's email and Peter's edits
15:03:25 <SimonSteyskal> +1
15:03:26 <pfps> +1
15:03:29 <TallTed> +1
15:03:32 <Dimitris> +1
15:03:32 <ericP> +1
15:03:32 <ArthurRyman> +1
15:03:38 <labra> +1
15:03:43 <hsolbrig_> +1
15:03:46 <iovka> +1
15:03:50 <pfps> RESOLVED: Close ISSUE-13 as per Sandro's email and Peter's edits
15:06:11 <SimonSteyskal> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S6:_Partial_ontology_import
15:06:39 <SimonSteyskal> https://www.w3.org/2014/data-shapes/wiki/Partial_Import
15:07:22 <SimonSteyskal> kk
15:08:38 <pfps> PROPOSED: Close ISSUE-8 as the User Story is no longer in the Wiki
15:08:48 <pfps> +1
15:08:52 <TallTed> +1
15:08:53 <hsolbrig_> +1
15:08:55 <iovka> +1
15:09:02 <ArthurRyman> +1
15:09:47 <ArthurRyman> S6 should be removed
15:10:10 <pfps> RESOLVED: Close ISSUE-8 as the User Story is no longer in the Wiki
15:10:36 <Arnaud> ISSUE-11
15:10:36 <trackbot> ISSUE-11 -- S9 is about existing but unspecified values -- open
15:10:36 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/11
15:13:10 <ArthurRyman> subtopic: ISSUE-11
15:14:12 <ArthurRyman> pfps: this appears to not be a closed world issue
15:14:17 <Dimitris> sparql can do this
15:17:29 <Dimitris> with  e.g.  FILTER (NOT) EXIST {?s <p> ?o}
15:18:49 <pfps> Possible change:  An ontology may state that instances of a property have a value for a property, but don't require it in data.   Subclasses may have a constraint that requires that there is a value for the property
15:20:58 <ArthurRyman> +q
15:21:20 <Arnaud> ack ArthurRyman
15:23:30 <TallTed> pfps - I think your (original) comment in the wiki needs correction -- "For contracts, this time interval has to have an end date." -- "contracts" should be "bonds" ... which might be a typo or might be a misunderstanding.
15:25:05 <pfps> Correct. I'll fix.
15:25:13 <TallTed> new text also -- "instances of a property have a value for a property" should be "instances of a class have a value for a property"
15:26:43 <Arnaud> PROPOSED: Close ISSUE-11 accepting Peter's proposed change
15:26:52 <pfps> The OWL constraints example needs to be changed to reflect the new wording.
15:27:04 <ArthurRyman> pfps has edited the wiki entry for S9
15:28:55 <Arnaud> "Possible change (pfps): An ontology may state  that instances of a property have a value for a property, but don't  require it in data. Subclasses may have a constraint that requires that  there is a value for the property. "
15:29:51 <ArthurRyman> hsolbrig: an ontology cannot require anything in the "data" (due to open world semantics) so how can a subclass require something in the data?
15:30:45 <ArthurRyman> +q
15:31:22 <Arnaud> ack ArthurRyman
15:32:02 <ericP> i propose s/Subclasses may have a constraint that requires/Subclasses may have associated constraints that require/
15:32:15 <pfps> I like Eric's change.
15:32:25 <pfps> q+
15:32:37 <Arnaud> ack pfps
15:35:52 <pfps> I think that we are again talking about specifics without ironing out the general notion - here the relationship between ontologies and shapes.
15:36:36 <ericP> http://w3c.github.io/data-shapes/data-shapes-primer/no-class-templates#h-associations
15:37:45 <pfps> There is some slowness making the link not jump to the section.
15:38:23 <TallTed> http://w3c.github.io/data-shapes/data-shapes-primer/no-class-templates#associations
15:39:53 <pfps> It would be better to say "every node belonging to a class conforms to some shape", although that is a bit informal.
15:41:45 <pfps> I agree that patient records don't have shapes in our parlance.  If they have a shape it is (still) likely to be 8.5x11 or A4.
15:42:55 <ArthurRyman> +q
15:43:09 <Arnaud> ack ArthurRyman
15:43:51 <ericP> ArthurRyman: this discussion illustrates the confusions stemming from conflating a class and constraints on information resources
15:46:46 <pfps> I'm happy with Eric's change.
15:47:06 <ericP> i'm happy with it as well
15:47:17 <pfps> I put the intent of Eric's change into my proposed change for S9.
15:47:23 <ArthurRyman> break for coffee
15:47:40 <ArthurRyman> resume in 15 min (at 11am)
15:47:56 <Zakim> -Dimitris
16:01:21 <kcoyle> kcoyle has joined #shapes
16:01:37 <ArthurRyman> I object to the lanuage in #5
16:01:46 <kcoyle> scribe: kcoyle
16:01:54 <Arnaud> Possible change (pfps): An ontology may state  that instances of a class have a value for a property. Subclasses may be  associated with a constraint that requires that there is a provided  value for the property. For example, in the OMG time ontology adopted by  FIBO every contract has to have an end date.  A set of constraints may  require that bonds (a subclass of contracts) have specified end dates  without requiring that all contracts have specified e[CUT]
16:02:07 <ArthurRyman> "Every RDF representation of an instance of a class" is an undefined concept
16:02:42 <ArthurRyman> in HTTP, resources have representations
16:03:02 <kcoyle> TallTed: this now seems like a null statement
16:03:09 <pfps> how is this a null statement??
16:03:26 <ArthurRyman> propose to define "an ideal representation of an instance of a class"
16:03:53 <Arnaud> PROPOSED: Close ISSUE-11 accepting Peter's proposed change
16:03:54 <ericP> +1
16:03:59 <pfps> +1
16:04:04 <labra> +1
16:04:06 <iovka> +1
16:04:10 <hsolbrig_> +1
16:04:11 <SimonSteyskal> +1
16:04:12 <ArthurRyman> -1
16:04:39 <kcoyle> ArthurRyman: it doesn't make sense to talk about instances of classes
16:04:57 <kcoyle> ericP: "every rdf representation of an instance of a class"
16:05:24 <kcoyle> ArthurRyman: we're talking about a concept that is not included in any RDF spec
16:05:26 <Zakim> +Dimitris
16:05:58 <kcoyle> ... concept: we imagine that for classes there is an ideal representation; those ideal representations conform to a shape
16:06:21 <kcoyle> ... but that doesn't mean that every instance will conform to that
16:06:21 <pfps> I'm totally confused here.
16:06:32 <kcoyle> ... uris could appear in many graphs
16:06:49 <kcoyle> labra: close scope by saying in a specific system
16:06:54 <pfps> I'm opposed to anything that talks about "ideal representation".
16:07:04 <kcoyle> ArthurRyman: shape represents ideal
16:07:30 <kcoyle> ericP: language to define structure of rdf graph
16:08:05 <kcoyle> ... a shape defines matching rdf representations
16:09:01 <kcoyle> ... for some problems, a type arc makes a claim that this conforms to the constraints
16:09:17 <pfps> It would be possible to expand out everything here, saying things like "entities belonging to the extension of the class" and "in a graph, nodes whose denotation belongs to the extension of a class" .  That is, I think, fully formal, but I don't think that we want to be so formal here.
16:09:40 <pfps> If this bit has to be fully formal, then I think that everything has to be fully formal.
16:09:57 <kcoyle> TallTed: it's the type of arc that makes a difference - description not the thing
16:10:21 <kcoyle> ... i'm claiming that this description matches your shape
16:10:42 <pfps> RDF doesn't have descriptions - it has nodes and triples.
16:11:04 <kcoyle> ericP: there can be instances that do not conform to this shape
16:12:22 <kcoyle> ArthurRyman: i'm fine with reducing things to triples; my user stories are about the structure of the data, not its meaning;
16:12:36 <kcoyle> ... that it's in RDF is not relevant; it's purely syntactice
16:13:30 <kcoyle> ericP: "class shape"
16:14:19 <cygri> zakim, code?
16:14:19 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), cygri
16:14:28 <Zakim> +??P42
16:14:33 <cygri> zakim, ??P42 is me
16:14:34 <Zakim> +cygri; got it
16:14:37 <cygri> zakim, mute me
16:14:37 <Zakim> cygri should now be muted
16:14:59 <kcoyle> hsolbrig_: non-conforming is not that type
16:15:26 <kcoyle> TallTed: should say "in my system, I require... "
16:15:29 <pfps> I would be adamantly opposed to any output from the working group that would have this social meaning aspect to it.
16:15:38 <labra> q+
16:15:59 <pfps> S9 is not making global statements.
16:16:02 <kcoyle> TallTed: context is needed
16:16:11 <pfps> Even ontologies don't make global statements!
16:16:13 <Arnaud> ack labra
16:16:25 <pfps> Even the Linked Data Cloud does not make global statements!
16:16:48 <kcoyle> labra: it's a contract, it's not global
16:17:44 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S9:_Contract_time_intervals
16:17:46 <kcoyle> Arnaud: proposal re: S9
16:18:17 <labra> labra: in some specific system, every RDF representation of an instance of a class conforms to some shape
16:19:49 <pfps> I don't see how the working group is going to make progress if there is not going to be way of associating shapes with classes.
16:20:02 <kcoyle> ArthurRyman: proposal mixes metaphors, resource sin the open world vs. shapes in a closed world; associating data with classes crosses boundaries between open and closed world
16:20:13 <kcoyle> ... ontology concepts vs data concepts
16:20:44 <TallTed> An ontology may state that instances of a class (or subclass) have a value for a property. For example, in the OMG time ontology adopted by FIBO, every contract has to have an end date. A shape may state that descriptions of instances of bonds (a subclass of contracts) always have specified end dates, without requiring that all descriptions of instances of contracts have specified end dates.
16:21:06 <kcoyle> pfps: oppose any solution that does not associated shapes and classes
16:21:50 <kcoyle> ArthurRyman: class/shape only applies in specified context
16:23:55 <kcoyle> pfps: nothing says that these constraints are global
16:24:09 <cygri> +1 to pfps. This WG is not concerned with enforcing RDF documents.
16:24:31 <pfps> I don't like "descriptions of instances"
16:24:39 <cygri> q+
16:24:48 <kcoyle> ArthurRyman: waves his objection; defer to discussion later;
16:25:19 <kcoyle> ... if scope is local rather than global ...
16:25:45 <kcoyle> TallTed: shape will not be part of class definition; shape will reference the class, class will not reference the shape
16:26:01 <pfps> The initial LDOM proposal had shapes being parts of classes, which I objected to.
16:26:57 <pfps> q+
16:27:15 <cygri> zakim, unmute me
16:27:15 <Zakim> cygri should no longer be muted
16:27:15 <Arnaud> ack cygri
16:27:18 <pfps> q-
16:29:04 <Arnaud> rrsagent, draft minutes
16:29:04 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/17-shapes-minutes.html Arnaud
16:30:18 <kcoyle> cygri: this group should just consider rdf graphs, not questions about dereferencing, etc.
16:30:22 <pfps> +1
16:30:27 <cygri> zakim, mute me
16:30:27 <Zakim> cygri should now be muted
16:30:45 <Arnaud> Possible change (pfps): An ontology may state  that instances of a class have a value for a property. Subclasses may be  associated with a constraint that requires that there is a provided  value for the property. For example, in the OMG time ontology adopted by  FIBO every contract has to have an end date.  A set of constraints may  require that bonds (a subclass of contracts) have specified end dates  without requiring that all contracts have specified e[CUT]
16:31:27 <Arnaud> PROPOSED: Close ISSUE-11 accepting Peter's proposed change
16:31:35 <pfps> +1 (without the [CUT])
16:31:41 <ArthurRyman> +0
16:31:42 <TallTed> -1  quick tiny revision of wording in a minute
16:32:03 <TallTed> An ontology may state  that instances of a class have a value for a property. Subclasses may be  associated with a constraint that requires that there is a provided  value for the property. For example, in the OMG time ontology adopted by  FIBO every contract has to have an end date.  A shape (set of constraints) may require that bonds (a subclass of contracts) have specified end dates without requiring that all contracts have
16:32:03 <TallTed>  specified...
16:32:47 <SimonSteyskal> +1
16:32:54 <TallTed> +1
16:32:54 <labra> +1
16:32:54 <Arnaud> PROPOSED: Close ISSUE-11 accepting Ted's revised proposed change
16:32:55 <hsolbrig_> +1
16:32:59 <pfps> +1 (I'll hold my nose about the shape bit)
16:33:02 <iovka> +1
16:33:05 <kcoyle> +1
16:33:07 <Dimitris> +1
16:33:20 <ArthurRyman> +0
16:33:32 <Arnaud> RESOLVED: Close ISSUE-11 accepting Ted's revised proposed change
16:34:07 <Arnaud> ISSUE-12
16:34:07 <trackbot> ISSUE-12 -- S10 needs a better story -- open
16:34:07 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/12
16:34:37 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S10:_card_.3E.3D_0
16:34:43 <kcoyle> story 10
16:35:28 <pfps> Somehow this appears to have been upgraded, so it looks OK to me.
16:36:06 <cygri> q+
16:36:30 <ArthurRyman> +q
16:37:06 <cygri> zakim, unmute me
16:37:06 <Zakim> cygri should no longer be muted
16:37:06 <Arnaud> ack cygri
16:37:39 <ArthurRyman> shapes are more than constraints - they are descriptive
16:38:00 <ArthurRyman> there is the concept of known versus unknown content
16:38:10 <pfps> My issue has been resolved by the change to S10 after [DTA].
16:38:13 <kcoyle> cygri: eric's proposal changes the story; 2nd half is from Dean's email
16:38:27 <ArthurRyman> this is important since RDF is great for open content models
16:38:30 <cygri> zakim, mute me
16:38:30 <Zakim> cygri should now be muted
16:38:33 <kcoyle> ... use dean's expanded text instead of eric's?
16:38:36 <Arnaud> ack ArthurRyman
16:39:35 <kcoyle> ArthurRyman: constraints vs. description; encourage open content models; there can be base properties but implementations can add properties
16:40:28 <kcoyle> ... there are also versions that have different requirements; a shape advertises what a system will accept; min 0 means that the processor will
16:41:00 <kcoyle> .... accept the property; this also has implementations for UI form builders
16:41:17 <kcoyle> ... also description for humans; and machine-readable for tools
16:41:49 <TallTed> s/implementations/implications/
16:41:49 <pfps> I say go with Dean's change.
16:43:01 <cygri> q+
16:43:08 <pfps> There is another story with cardinalities (S2, I think)
16:43:52 <cygri> q-
16:44:39 <pfps> +1
16:44:44 <kcoyle> ericP: do we need other cardinalities? (No; we'll just keep Dean's text)
16:44:56 <Arnaud> PROPOSED: Close ISSUE-12, accepting Dean's addition
16:44:59 <cygri> +1
16:45:08 <pfps> +1
16:45:15 <ArthurRyman> +1
16:45:23 <iovka> ?1
16:45:27 <iovka> +1
16:45:30 <SimonSteyskal> +1
16:45:43 <pfps> This is *just* about >=0, not about any other cardinalities.
16:45:53 <kcoyle> +1
16:46:11 <cygri> I think calling out this specific case of >=0 is worth doing. It has various interesting implications.
16:46:49 <TallTed> +1
16:46:49 <hsolbrig_> +1
16:46:56 <labra> +1
16:47:51 <ericP> +1
16:47:52 <Arnaud> RESOLVED: Close ISSUE-12, accepting Dean's addition
16:48:05 <Arnaud> ISSUE-14
16:48:05 <trackbot> ISSUE-14 -- S14 might be about change not constraints -- open
16:48:05 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/14
16:48:18 <pfps> There has been no action on S14.
16:48:24 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S14:_Object_Reconciliation
16:50:12 <ArthurRyman> +1 for dropping S14
16:50:15 <Arnaud> PROPOSED: Close ISSUE-14 by dropping S14
16:50:18 <hsolbrig_> +1
16:50:20 <iovka> +1
16:50:21 <ArthurRyman> +1
16:50:24 <kcoyle> +1
16:50:24 <SimonSteyskal> +1
16:50:30 <labra> +1
16:50:31 <pfps> You could say that this story is about keys, but it is not written that way, and we already have a key story.
16:50:37 <Dimitris> +1
16:50:39 <TallTed> -1
16:50:52 <pfps> I'm fine with dropping.
16:51:18 <cygri> DM’s clarification: “the essence of this example is meant to be: if there's an object X with property P1, and an object Y with property P2, and the value of P1 is related to the value of P2 in the following way: ... then *there must be* a sameAs relation between X and Y.”
16:51:34 <cygri> q+
16:52:01 <cygri> zakim, unmute me
16:52:01 <Zakim> cygri should no longer be muted
16:52:08 <pfps> "should be stated" implies to me that there is change here.
16:52:09 <Arnaud> ack cygri
16:52:57 <pfps> The clarification from David involves same-as.  That's another issue - is equality something that the working group is going to allow?
16:53:01 <kcoyle> cygri: not an inference, but given these conditions there must be a sameAs triple for this to be valid; seems a reasonable shape requirement
16:54:03 <cygri> zakim, mute me
16:54:03 <Zakim> cygri should now be muted
16:54:32 <kcoyle> ericP: if they have the same inverse functional property but not sameAs, that would be an error
16:56:48 <cygri> q+
16:57:01 <cygri> zakim, unmute me
16:57:01 <Zakim> cygri should no longer be muted
16:57:09 <Arnaud> ack cygri
16:58:43 <kcoyle> cygri: can see uses for this;
16:59:14 <ArthurRyman> S14 is very open-ended and would require close to the full expressive power of SPARQL
16:59:34 <kcoyle> ACTION: Richard - propose revision in wiki
16:59:34 <trackbot> Created ACTION-10 - - propose revision in wiki [on Richard Cyganiak - due 2015-02-24].
16:59:45 <cygri> ACTION-10?
16:59:45 <trackbot> ACTION-10 -- Richard Cyganiak to - propose revision in wiki -- due 2015-02-24 -- OPEN
16:59:45 <trackbot> http://www.w3.org/2014/data-shapes/track/actions/10
16:59:55 <Arnaud> ISSUE-15
16:59:55 <trackbot> ISSUE-15 -- S17 is about access not constraints -- open
16:59:55 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/15
17:00:06 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S17:_Specify_subsets_of_data
17:00:18 <cygri> zakim, mute me
17:00:18 <Zakim> cygri should now be muted
17:01:11 <pfps> I'm still uncertain how this relates to any output of the working group.
17:02:22 <SimonSteyskal> and it's not a user story
17:03:19 <SimonSteyskal> he says " So yes, S17 and S18 should be merged. Also, I grant this is not very constraint-like. But it is a very common use case, in my experience, whose solution would have excellent practical value. "
17:04:01 <kcoyle> hsolbrig_: this is a query use of the shape
17:04:55 <kcoyle> ericP: might result in a reporting requirement that we don't want to write into first generation of the language
17:06:07 <kcoyle> ACTION: Harold to revise based on his ideas; we'll review and accept/or not
17:06:07 <trackbot> Created ACTION-11 - Revise based on his ideas; we'll review and accept/or not [on Harold Solbrig - due 2015-02-24].
17:06:22 <SimonSteyskal> and maybe merge S17 with S18?
17:07:01 <Arnaud> ISSUE-16
17:07:01 <trackbot> ISSUE-16 -- S18 does not appear to be about constraints -- open
17:07:01 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/16
17:07:13 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S18:_Scope_of_Export
17:07:47 <pfps> Merging is fine by me.
17:08:13 <kcoyle> ACTION: Harold to merge 17 and 18
17:08:13 <trackbot> Created ACTION-12 - Merge 17 and 18 [on Harold Solbrig - due 2015-02-24].
17:10:01 <Zakim> -pfps
17:10:19 <Zakim> -Dimitris
17:10:26 <Zakim> -cygri
17:10:39 <Zakim> -SimonSteyskal
17:12:34 <TallTed> TallTed has joined #shapes
17:31:47 <TallTed> TallTed has joined #shapes
17:42:39 <TallTed> TallTed has joined #shapes
17:59:27 <kcoyle> kcoyle has joined #shapes
18:00:07 <Zakim> +pfps
18:00:19 <pfps> pfps has joined #shapes
18:00:24 <pfps> zakim, who is here?
18:00:25 <cygri> zakim, code?
18:00:26 <Zakim> On the phone I see F2F, pfps
18:00:26 <Zakim> On IRC I see pfps, kcoyle, TallTed, hsolbrig_, SimonSteyskal, RRSAgent, Zakim, Arnaud, cygri, Dimitris, hknublau, rhiaro, sandro, ericP, trackbot
18:00:26 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), cygri
18:00:34 <Zakim> +??P7
18:00:39 <cygri> zakim, ??P7 is me
18:00:39 <Zakim> +cygri; got it
18:00:41 <cygri> zakim, mute me
18:00:41 <Zakim> cygri should now be muted
18:00:48 <Zakim> +Dimitris
18:02:13 <Zakim> +??P10
18:02:25 <SimonSteyskal> zakim, ??P10 is me
18:02:25 <Zakim> +SimonSteyskal; got it
18:03:06 <labra> labra has joined #shapes
18:06:17 <Arnaud> zakim, who's on the phone?
18:06:17 <Zakim> On the phone I see F2F, pfps, cygri (muted), Dimitris, SimonSteyskal
18:07:33 <labra> scribe: labra
18:07:39 <iovka> iovka has joined #shapes
18:08:07 <labra> TOPIC: Requirements
18:08:27 <Zakim> +[IPcaller]
18:08:38 <labra> association of class with shape
18:08:39 <hknublau> zakim, [IPcaller] is me
18:08:40 <Zakim> +hknublau; got it
18:09:13 <labra> karen suggests to start with the less controversial
18:10:59 <pfps> ?
18:12:13 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property_Default_Value
18:12:38 <labra> peter proposes to remove it
18:13:43 <labra> arthur: it can be used for some proposes in forms
18:13:55 <labra> to present the initial value for some property
18:15:32 <labra> arthur: when the service creates the resource it fills with the value
18:16:08 <labra> pfps: it can be done by inference
18:16:26 <labra> arnaud: it is a common solution as in XML schema
18:16:35 <labra> +q
18:16:55 <hsolbrig_> +q
18:17:14 <labra> arnaud: in the xml it was the propose of PSVI
18:17:27 <labra> ...post schema validation infoset
18:18:14 <pfps> If this is a requirement, then there should be a requirement that RDFS domain/range information be considered as well.
18:18:15 <labra> karen: we can have a certain number of valid values
18:18:34 <Arnaud> ack labra
18:18:52 <ArthurRyman> ArthurRyman has joined #shapes
18:19:21 <TallTed> q+
18:19:30 <Arnaud> ack hsolbrig_
18:19:46 <labra> labra: default values change the original data
18:19:52 <ArthurRyman> when a REST service creates a resource from a POST request, it adds other properties, e.g. creator, creation date, possibly a unique identifier
18:19:57 <labra> ...from a semantic point of view it changes the data
18:21:09 <ArthurRyman> +q
18:21:18 <Arnaud> ack TallTed
18:21:40 <labra> harold: it may be complex with 2 semantics
18:21:50 <labra> ...and forms
18:22:00 <ArthurRyman> ted is talking
18:22:13 <labra> Tallted: another constraint that the default value should conform to the constraint
18:22:32 <hsolbrig_> +q
18:22:34 <Arnaud> ack ArthurRyman
18:22:52 <labra> arthur: the objections can be addressed by the spec
18:22:58 <hknublau> +q maybe it should be called “suggested value”?
18:23:04 <Arnaud> ack hsolbrig_
18:23:31 <labra> harold: it leads to a more fundamental question....one of the goals of shape expressions to help in forms construction
18:23:34 <hknublau> +q to say maybe it should be called “suggested value”?
18:23:46 <labra> ...if our goal is to augment the rdf graph
18:24:23 <labra> harold: constructor semantics
18:24:53 <labra> ...if the validator doesn't find it....then it adds it...
18:25:12 <ArthurRyman> q+
18:26:09 <labra> ted: it could be considered as a hint
18:26:56 <labra> harold: if don't manufacture triples then it is ok...
18:27:54 <Arnaud> ack hknublau
18:27:54 <Zakim> hknublau, you wanted to say maybe it should be called “suggested value”?
18:27:57 <labra> arnaud: the  big question is if we change the data...which is a significant step
18:28:44 <Arnaud> ack ArthurRyman
18:28:47 <labra> holger: change the wording to "suggested value"
18:29:23 <labra> arthur: within OSLC there are different uses for shapes...at creation time
18:29:42 <labra> ...a different shape when querying data
18:30:01 <labra> ...different shapes for different operations...
18:31:31 <hknublau> I am not perfectly happy with “suggested value” either. But maybe some other term.
18:32:13 <labra> arnaud: "default value" is different from "suggested value"
18:36:02 <labra> holger: it can be used in SPIN
18:36:22 <labra> ...it can be represented in spin but it doesn't do anything
18:37:02 <labra> peter: interaction with 0 cardinality
18:37:14 <labra> to help UI
18:37:15 <ArthurRyman> q+
18:37:34 <cygri> q+
18:37:39 <labra> ted: the input hint is a hint to the user...
18:37:58 <labra> ted: the default value must pass validation...
18:38:27 <Arnaud> ack ArthurRyman
18:38:48 <cygri> zakim, unmute me
18:38:48 <Zakim> cygri should no longer be muted
18:38:52 <labra> arthur: cardinality is not just for UI...it means it is useful for applications
18:38:57 <Arnaud> ack cygri
18:39:09 <cygri> “Hint” semantics: The value is a hint to users that says how to construct a valid instance.
18:39:17 <labra> cygri: articulate these 2 semantics
18:39:29 <labra> ...default value as a hint
18:39:37 <labra> vs. default value as a constructor
18:39:52 <cygri> “Default” semantics: The value tells a shapes processor that it may normalise an RDF graph by inserting a default value for a missing value.
18:40:22 <labra> richard: default semantics...it normalizes the graph to add the default value for the missing value
18:41:00 <labra> the input to the shape process and the output are 2 different graphs
18:41:05 <hsolbrig_> +q
18:41:17 <labra> it is useful but it changes the graph
18:41:34 <Arnaud> ack hsolbrig_
18:42:49 <labra> hsolbrig: hint vs insertion
18:43:14 <labra> ...the fact that they exists does not means that everyone has to use them
18:43:34 <cygri> zakim, mute me
18:43:34 <Zakim> cygri should now be muted
18:44:18 <cygri> “to insert a required property that is missing in a web service call” — sounds like modifying a graph to me
18:44:37 <labra> arnaud: the original text says that the idea is to use it as a hint
18:44:47 <labra> to help populate the form for the use...
18:45:47 <TallTed> I agree, 2 semantics here -- possibly should be 2 distinct requirements!
18:46:16 <labra> arnaud: proposes to use it as a decoration of the shape...
18:46:56 <TallTed> 1. hint to Agent of a suggested (valid!) value for form generation; 2. (valid!) value which will be inserted, lacking any Agent-input value
18:47:00 <labra> peter: proposes to put them in a different section
18:47:07 <pfps> Moving this requirement to a different section would help a lot in my opinion.  Right now the requirement is in a group of requirements that do have "validation" force.
18:47:20 <cygri> +1 to separating this into two requirements as per TallTed
18:47:55 <labra> arthur: call the category: "descriptive"
18:49:23 <labra> peter: you can add a lot of decorations....
18:49:49 <labra> ...peter: they don't do anything...they are just decorations
18:51:31 <labra> ted: proposses to divide the requirements sections in three categories: description, validation, querying...
18:52:40 <labra> +q
18:53:04 <Arnaud> ack labra
18:53:50 <Arnaud> PROPOSED: Move Property Default Value to a new category "Descriptive decorations"
18:53:51 <labra> labra: to test it the validator can return the set of triples that have default values...
18:53:56 <ericP> q+ "PSVI" is another category, which we will probably rule out
18:54:04 <ericP> q+ "PSVI" to say that is another category, which we will probably rule out
18:55:39 <Arnaud> ack ericP
18:55:46 <Arnaud> queue=
18:55:58 <cygri> I’m not sure I see the difference between “inserting” and “inferring”. Both modify the graph. Whether that’s forward or backward chaining, is an implementation detail.
18:56:29 <pfps> The working group may decide that it should support things like creation of RDF graphs.  If so, then I would have no problem with this requirement adding triples to such a graph.
19:00:45 <TallTed> inference == based on ontologies, can be forward or backward chained.
19:00:45 <TallTed> default insertion == not ontological, *only* forward-chainable, likely application-specific, akin to SQL "CREATE table COLUMNS textfield (char, 9, => 'xyz')"
19:01:19 <labra> q+
19:01:43 <ArthurRyman> q+
19:01:44 <TallTed> hint == not ontological, almost certainly application-specific, does not insert a statement
19:02:32 <cygri> TallTed, what is “insertion” in an RDF context?
19:02:45 <SimonSteyskal> +q
19:02:52 <Arnaud> ack labra
19:03:21 <iovka> q+
19:03:55 <Arnaud> ack ArthurRyman
19:04:33 <labra> labra: I would keep it as a hint...not modifying the original graph...but the report could be a list or triples with the default values
19:04:35 <Arnaud> ack SimonSteyskal
19:04:45 <SimonSteyskal> https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Mathematical_Operations
19:04:47 <TallTed> cygri - I think there's no universal answer.  in a sense, what you said earlier -- Application adds triples to the Agent's submitted graph before writing it to the Store -- is the "default insertion".  with the "hint," the Application does not add triples.
19:04:52 <kcoyle> q+
19:04:55 <labra> ...it is not inferring anything...it just reports a list of triples with default values...
19:05:19 <ericP> q+ to ask peter whether rdfs:label meets his criteria of "if it doesn't have defined semantics, we shouldn't pretend to define it"
19:05:40 <Arnaud> ack iovka
19:06:26 <Arnaud> ack kcoyle
19:06:26 <pfps> q+
19:06:29 <cygri> TallTed, but there are applications that don’t store the submitted graph at all but do something completely different with it. Is that still “default insertion”?
19:06:48 <TallTed> cygri - could be
19:07:03 <Arnaud> ack ericP
19:07:03 <Zakim> ericP, you wanted to ask peter whether rdfs:label meets his criteria of "if it doesn't have defined semantics, we shouldn't pretend to define it"
19:07:20 <TallTed> cygri - if the "default" is *acted on* by the App, then yes.
19:07:23 <pfps> q-
19:07:27 <kcoyle> create a category called tool support, move requirements into that, then we can address all of them as a category
19:08:53 <labra> ted: validating, writing, reading data...
19:09:05 <labra> ted: three categories...
19:09:30 <pfps> if there are other things going on other than validation, then the WG needs to specify what they are and how they work
19:10:18 <labra> arnaud: we agree it is not just about validation...
19:10:35 <pfps> default values for medical information are somewhat problematic, at least from what I hear from my wife who works on making such stuff acceptable for the FDA
19:13:06 <ArthurRyman> http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#defaultValue
19:13:18 <labra> peter: if there is a new section of the requirements having to be with UI then it would work for me
19:13:55 <Arnaud> PROPOSED: Move Property Default Value to a new category/section different not about "constraints"
19:14:23 <labra> arnaud: move it to another category which is not about constraints...
19:14:45 <TallTed> PROPOSED: Categorize all https://www.w3.org/2014/data-shapes/wiki/Requirements based on bullets in Introduction of http://www.w3.org/2014/data-shapes/charter i.e., Validation, Construction, Reporting/Querying
19:16:54 <cygri> Section title? “Documentation that helps humans and machines to create new RDF graphs that satisfy a shape”
19:17:51 <TallTed> PROPOSED: Categorize all https://www.w3.org/2014/data-shapes/wiki/Requirements based on bullets in Introduction of http://www.w3.org/2014/data-shapes/charter i.e., Data Construction, Constraint Validation, Visualization Hints
19:18:07 <hknublau> +1 to non-validation - anything that has no SPARQL query behind it
19:19:23 <labra> ericP: we agree that we are not changing the original graph
19:19:36 <Arnaud> PROPOSED: Move Property Default Value to a new category "Non validation related requirements"
19:19:42 <SimonSteyskal> +1
19:19:44 <iovka> +1
19:19:45 <ericP> +1
19:19:50 <Dimitris> +1
19:19:51 <TallTed> +1
19:19:54 <hsolbrig_> +1
19:19:58 <ArthurRyman> +1
19:20:00 <labra> +1
19:20:04 <kcoyle> +1
19:20:17 <pfps> +0
19:20:22 <Arnaud> RESOLVED: Move Property Default Value to a new category "Non validation related requirements"
19:21:10 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property_Labels_at_Shape
19:21:19 <labra> subtopic: Property labels at shape
19:21:41 <SimonSteyskal> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property_Comment_in_a_Shape
19:23:01 <ArthurRyman> +q
19:23:08 <TallTed> Constraint Description, Constraint Validation, User Interaction ...
19:23:56 <labra> peter: the WG has to be careful not to define subproperties...
19:24:17 <Arnaud> RESOLVED: Move Property Labels at Shape to the category "Non validation related requirements", specifying this is intended for UI
19:24:28 <Arnaud> s/RESOLVED/PROPOSED/
19:24:45 <Arnaud> PROPOSED: Move Property Labels at Shape to the category "Non validation related requirements", specifying this is intended for UI
19:25:20 <Arnaud> ack ArthurRyman
19:25:33 <labra> arthur: it's not just about UI...it's also about documenting the structure of the data
19:25:57 <labra> ...the genesis of this is in OSLC it was considered to be wrong to invent a lot of terms
19:26:32 <labra> ...don't create a new vocabulary...there is a lot of terms...example, "is-part-of"
19:26:51 <Arnaud> PROPOSED: Move Property Labels at Shape to the category "Non validation related requirements", specifying this is intended for human consumption such as documentation or UI
19:27:01 <labra> ...there's a lot of properties like that...you want to use it and to document the intent...
19:27:16 <labra> +1
19:27:18 <TallTed> so again... 3 sections/activities under Shapes -- 1. Constraint Description, 2. Constraint Validation, 3. User Interaction
19:27:19 <TallTed> +1
19:27:20 <ArthurRyman> +1
19:27:21 <SimonSteyskal> +1
19:27:21 <hknublau> +1
19:27:21 <kcoyle> +1
19:27:22 <pfps> -0
19:27:23 <Dimitris> +1
19:27:23 <ericP> +1
19:27:25 <iovka> +1
19:27:32 <hsolbrig_> +1
19:27:38 <Arnaud> RESOLVED: Move Property Labels at Shape to the category "Non validation related requirements", specifying this is intended for human consumption such as documentation or UI
19:28:13 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property_Comment_in_a_Shape
19:29:33 <pfps> I think that this would be better as an ability to put comments to parts of shapes.
19:30:35 <cygri> q+
19:30:40 <cygri> zakim, unmute me
19:30:40 <Zakim> cygri should no longer be muted
19:31:36 <labra> ericP: explains how it would work to add comments to different parts of the constraints...
19:31:40 <Arnaud> PROPOSED: Change Property Comment in a Shape to Constraint Comment in a Shape and move it to the category "Non validation related requirements"
19:32:01 <pfps> +1
19:32:03 <labra> arthur: it would be nice to be able to add comments to any part of the graph...
19:32:13 <ericP> +1
19:32:21 <labra> +1
19:32:24 <SimonSteyskal> +1
19:32:26 <cygri> -1
19:32:44 <Arnaud> ack cygri
19:32:45 <ArthurRyman> +1
19:33:16 <ericP> tooltip
19:33:18 <labra> cygri: people wants to have these things for UIs
19:33:42 <labra> if we allow labels and comments everywhere it could have implications for user interfaces...
19:33:44 <ArthurRyman> +q
19:33:45 <TallTed> +1 -- e.g., label becomes form-field label, comment becomes tooltip, etc.
19:34:07 <hsolbrig_> q+
19:34:12 <labra> cygri: not sure if it's enough
19:34:38 <labra> ...proposes to think carefully in which places are going to be added those comments/labels...
19:35:18 <pfps> Bad designers can overuse comments/labels even if they are possible only in a few places.  I don't think that there can be any a-priori restriction that makes sense.
19:35:26 <Arnaud> ack ArthurRyman
19:35:35 <labra> arnaud: it is assuming the worse
19:35:50 <labra> arthur: the textual representation of a shape should be readable and clear
19:36:17 <labra> arthur: it should be clear without document generation tools...
19:36:38 <labra> arthur: the core language should be readable by programmers
19:36:52 <labra> arthur: different stakeholders
19:37:14 <labra> the person who writes the application...the person providing data is not the person that consumes it...
19:37:31 <labra> ....2 stakeholders...
19:37:33 <Arnaud> ack hsolbrig_
19:37:41 <labra> ...more documentation is good in general...
19:37:43 <TallTed> q+
19:38:04 <labra> hsolbrig: some taxonomy of comments could be defined...
19:38:50 <hsolbrig_> +1
19:39:21 <labra> arnaud: asks cygri to reconsider his objection given that constraint is not well defined...
19:39:24 <Arnaud> ack TallTed
19:39:34 <cygri> Arnaud, then let’s leave it at “property comment”.
19:40:00 <labra> ted: non-validation is not enough
19:40:31 <labra> cygri: proposes to leave it as property comment...
19:42:43 <hknublau> +1 with cygri
19:42:46 <Arnaud> PROPOSED: Move Property Comment to the category "Non validation related requirements"
19:43:01 <pfps> +0
19:43:04 <ericP> -0
19:43:26 <hknublau> +1
19:43:27 <cygri> +1 to Arnaud’s proposal
19:43:32 <SimonSteyskal>  +1
19:43:38 <ArthurRyman> +1
19:43:41 <iovka> +1
19:43:45 <labra> +1
19:44:03 <hsolbrig_> +1
19:44:07 <Dimitris> +1
19:44:15 <TallTed> +1
19:44:27 <Arnaud> RESOLVED: Move Property Comment to the category "Non validation related requirements"
19:44:52 <cygri> zakim, mute me
19:44:52 <Zakim> cygri should now be muted
19:44:53 <pfps> is there a document that can be shared?
19:45:34 <iovka> http://www.lifl.fr/~boneva/datashapes/text0.html
19:46:18 <labra> topic: Iovka's presentation on Complexity and Expressiveness
19:47:19 <labra> iovka: XML schema validation is more complex
19:47:20 <pfps> audio is fine
19:47:30 <SimonSteyskal> better now
19:47:39 <labra> ... the main part can be validated with one pass of the document
19:47:45 <labra> ... restrictions on regular expressions
19:47:57 <labra> ... relaxng doesn't have that restriction of one-pass document
19:48:18 <labra> ... xml as data
19:48:52 <labra> ... example from dblp where he order is not important...
19:49:28 <labra> ... unordered content of xml is difficult
19:49:53 <labra> ... example which is NP-complete
19:50:34 <labra> ... this leads to the work about complexity of shape expressions...
19:52:26 <labra> ... regarding shape expressions two sources of complexity
19:52:37 <labra> ... checking whether or not it satisfies the expression
19:53:01 <labra> ... only with regular expressions it can be NP-complete
19:53:29 <labra> ... the other source of complexity discovering all the nodes...
19:53:40 <labra> ... it may be not acceptable for big graphs
19:54:09 <labra> ... solution restrictions on the constraint that a shape can define...
19:54:28 <labra> ... a notion of determinism for shapes can guarantee single pass validation (every edge of the graph is visited once).
19:55:26 <labra> iovka: complexity of SPARQL
19:56:02 <labra> ... a SPARQL query is composed of: pattern matching part
19:56:15 <labra> ... the decision problem associated with query evaluation
19:56:33 <labra> ... it is not about the time only...but the decision problem...
19:57:37 <labra> ... some options AND, FILTER, OPTIONAL only
19:57:47 <labra> ... PSPACE-complete for the size of the pattern
19:58:13 <pfps> PSPACE in the size of the query does not seem so bad.
19:59:19 <labra> ... they define "well defined patterns"
20:00:09 <pfps> The OPTIONAL has to be "guarded".
20:01:22 <labra> ... property paths
20:01:38 <labra> ... an example that is intractable
20:02:05 <labra> ... after a paper, the semantics of the spec was changed...
20:02:18 <labra> ... about LDOM
20:02:35 <labra> issues: extending a shape
20:03:47 <labra> ... adding inferences it can become a mess
20:04:03 <labra> ... inverse properties
20:06:31 <labra> ... example with inverse properties that cannot be satisfied by an finite graph
20:07:10 <labra> ... another example with a query that goes to the whole graph
20:07:32 <labra> ... it is meaningless to define global constraints...
20:08:03 <pfps> There are cases where "global" queries are useful.
20:08:37 <pfps> However, attaching a "global" constraint to a class other than a universal class if a silly idea.
20:09:22 <pfps> The guarded fragment of FOL has interesting computational properties.
20:12:00 <labra> iovka: Do we want that the language allows to write syntactically correct shapes that are meaningless, or that are not satisfiable ?
20:12:30 <labra> ... it may be a good idea to have some algorithm to detect is they are satisfiable...
20:12:33 <pfps> I think that our situation is much more like DB constraints than it is like DTDs or XML Schemas.
20:13:32 <pfps> Coffee??
20:14:03 <Arnaud> yes
20:14:42 <labra> iovka: have some syntactic ways to guarantee the complxity boundaries
20:15:18 <Zakim> -pfps
20:15:29 <Zakim> -cygri
20:15:43 <Zakim> -Dimitris
20:35:13 <Zakim> +Dimitris
20:38:23 <Arnaud> scribe: iovka
20:38:26 <kcoyle> kcoyle has joined #shapes
20:39:07 <ArthurRyman> http://www.w3.org/2008/04/scribe.html
20:39:28 <cygri> zakim, code?
20:39:28 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), cygri
20:39:33 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Association_of_Class_with_Shape
20:39:34 <Zakim> +pfps
20:39:46 <Zakim> +??P7
20:39:50 <cygri> zakim, ??P7 is me
20:39:50 <Zakim> +cygri; got it
20:39:53 <cygri> zakim, mute me
20:39:53 <Zakim> cygri should now be muted
20:40:09 <iovka> Arnaud: thinks it is a problem of formulation
20:41:04 <iovka> ... Peter, Jose, eric, please consider your objections
20:41:29 <pfps> This requirement is in a broken state.  The title says "association of class with shape" but the first sentence says "property associated with a class".
20:41:33 <pfps> q+
20:41:35 <iovka> ericP: wanted to say that there was a connecter between a shape and a class
20:41:54 <Arnaud> ack fp
20:41:58 <Arnaud> ack pfps
20:43:28 <iovka> Arnaud: let's start with the title, nobody really disagrees with the fact that there should be connexion betw. shapes and class
20:44:11 <iovka> ... the point is how to associate them
20:44:22 <pfps> What is the impact of associating a class with a shape?
20:44:29 <kcoyle> "There must be a way to associate a shape to a class"
20:44:31 <pfps> -1 to eric's current wording
20:44:56 <labra> Have some way to connect a class with a shape...  so every RDF representation of an instance of a class conforms to that shape in some system
20:45:57 <iovka> kcoyle: not every
20:46:27 <labra> "every...in some system"
20:46:29 <pfps> "every RDF representation" sounds like it is web-wide, which I don't think is the right meaning.
20:46:47 <ArthurRyman> +1
20:46:48 <TallTed> @pfps - "in some system"
20:46:53 <pfps> even worse
20:46:56 <iovka> ericP: agrees with everything member of the class conferms to a shape
20:47:43 <iovka> ... everything claiming that is member of a class also claims satisfying the associated shape
20:48:35 <iovka> ... the ldom:classShape is there to enforce that
20:48:56 <iovka> kcoyle: the requirement of the language is to be able to associates shapes with classes
20:49:40 <iovka> ... are we associating a shpe with a class, or constraints with a class
20:49:51 <iovka> ericP: my proposal is to associate a shape to a class
20:50:47 <iovka> pfps: associate a shape to foaf:Person. this means my application requires that every person has a name
20:51:39 <ArthurRyman> +q
20:51:55 <hsolbrig_> +q
20:52:00 <iovka> ericP:  most often people do it like this, when associate a name to a person, does not thing to the future
20:52:07 <Arnaud> ack ArthurRyman
20:52:43 <iovka> Arthur: we shouldn't change the meaning of a class, resources belong to a class, that membership is given by a triple
20:53:34 <iovka> ... either direct assertion rdf:type, or by inference
20:54:06 <iovka> ... shapes are different, they apply to graphs
20:54:07 <labra> +q
20:54:14 <iovka> ... class and shape are different contexts
20:54:16 <cygri> q+
20:54:56 <Arnaud> PROPOSED: Change description to: there must be an "easy" way of associating a shape with a class, meaning that all members of that class must conform with that shape
20:55:00 <labra> labra: to say "this is not about how to define shapes...it is about how to select which nodes are selected to conform to a shape"
20:55:11 <pfps> q+
20:55:14 <iovka> ericP: agrees they are different things
20:55:16 <Arnaud> ack hsolbrig_
20:55:57 <Arnaud> PROPOSED: Change description to: there must be an "easy" way of associating a shape with a class, meaning that members of that class must conform with that shape
20:56:04 <pfps> q-
20:56:30 <Arnaud> ack labra
20:56:37 <cygri> q-
20:56:44 <pfps> I'm fine with Arnaud's proposal.
20:56:47 <hsolbrig_> -1
20:57:13 <iovka> jose: not related how to define classes and shapes, it's more a matter of how to select to validate against a shape
20:57:26 <hsolbrig_> "There must be an "easy" way of associationg a shape with a class, meaning that *representations OF* members of that class must conform with that shape
20:57:31 <iovka> ... these are the nodes that have rdf:type to the type associated with the shape
20:57:36 <kcoyle> chg "easy" to "clear" - or "straightforward" ?
20:57:50 <pfps> Hmm.  There is still a problem with Arnaud's proposal having to do with scope.   This is also a problem with Harold's rewording.
20:58:27 <Arnaud> PROPOSED: Replace description with: There must be an "easy" way of associationg a shape with a class, meaning that representations of members of that class must conform with that shape
20:59:19 <iovka> pfps: prefers "instances of a class" because it does not talk about social meaning
20:59:21 <hsolbrig_> s/members/instances/
20:59:32 <kcoyle> +1 for "instances of a class"
21:00:05 <Arnaud> PROPOSED: Replace description with: There must be an "easy" way of associating a shape with a class, meaning that representations of instances of that class must conform with that shape
21:01:18 <ericP> +1
21:01:37 <pfps> If we want to be formal, the wording is going to be something like "all nodes in a graph whose denotation is an element of the class extension of a class"
21:01:38 <TallTed> `There must be an "easy" way of associating a shape with a class, meaning that (within the system where the association has been made) representations of instances of that class must conform to that shape...`
21:02:00 <iovka> Arnaud: got a question, all boils down how you scope the association shape/class. what is the mechanism of scoping ?
21:02:14 <Arnaud> s/Arnaud/Arthur/
21:02:34 <iovka> ... foaf nodes in the same document, in one context have name, in another have name and email
21:02:38 <ericP> +1
21:02:42 <kcoyle> +1
21:02:48 <iovka> ericP: then I do not use classShape
21:02:51 <hsolbrig_> +1
21:02:51 <labra> +0.5
21:02:52 <SimonSteyskal> +1
21:02:52 <iovka> +1
21:03:00 <ArthurRyman> +1
21:03:04 <cygri> I don’t understand what representations have to do with this
21:03:05 <pfps> -0 "representation" isn't something that has been defined
21:03:08 <TallTed> +1
21:03:16 <cygri> yes
21:03:54 <cygri> zakim, unmute me
21:03:54 <Zakim> cygri should no longer be muted
21:04:06 <pfps> if the substitution is s/representations of/nodes in a graph that are/ then the situation is much clearer
21:04:59 <Arnaud> PROPOSED: Replace description with: There must be an "easy" way of associating a shape with a class, meaning that nodes in a graph that are instances of that class must conform with that shape
21:05:13 <labra> +1 to pfps wording
21:05:14 <Dimitris> +1
21:05:20 <SimonSteyskal> +1
21:05:22 <pfps> of course, in informal circumstances I prefer "instances of"
21:05:26 <hknublau> +1
21:05:31 <cygri> +1
21:05:41 <pfps> ... and I'll probably continue to read the wording in this way
21:05:43 <kcoyle> +1
21:05:47 <TallTed> +1
21:05:55 <hsolbrig_> +1
21:05:56 <cygri> zakim, mute me
21:05:56 <Zakim> cygri should now be muted
21:06:09 <ericP> +1
21:06:11 <iovka> +1
21:06:17 <ArthurRyman> +1
21:06:23 <Arnaud> RESOLVED: Replace description with: There must be an "easy" way of associating a shape with a class, meaning that nodes in a graph that are instances of that class must conform with that shape
21:06:43 <pfps> q+
21:06:47 <Arnaud> ack pfps
21:07:22 <TallTed> "e.g. to populate input forms with appropriate widgets but also constraint checking"
21:07:24 <iovka> Arnaud: in the wiki we have more than what we discussed
21:07:41 <iovka> ... possibly as a different requirement
21:07:58 <iovka> hknublau: I do not see anything else
21:08:24 <iovka> pfps: nothing missing
21:08:33 <TallTed> "There will be an property to connect a class to a shape, with the implication that every RDF representation of an instance of that class must conform to that shape e.g. to populate input forms with appropriate widgets but also constraint checking"
21:10:00 <iovka> Arnaud: how do we go on the wiki for capturing this, how do we update the wiki, replace all comments and objections with new proposition ?
21:10:05 <pfps> I vote for removing the discussion.
21:11:11 <pfps> The discussion is still in the history, so I see no reason to keep the discussion.
21:11:19 <iovka> TallTed: the solution should be in green, keep everyithing
21:11:55 <iovka> hsolbrig_: move the discussion to the discussions part
21:12:37 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property_Datatype
21:12:47 <pfps> q+
21:13:00 <iovka> subtopic: Property Datatype
21:13:21 <pfps> This one was discussed last week and there was a path forward.
21:13:52 <iovka> ericP: retracts his objection
21:14:26 <ericP> RRSAgent, please draft minutes
21:14:26 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/17-shapes-minutes.html ericP
21:14:42 <ArthurRyman> +q
21:16:08 <pfps> q-
21:16:13 <Arnaud> ack ArthurRyman
21:17:12 <iovka> Arthur: I might want to specify the union of a datatype, should we be able to understand when one data type is subset of another data type
21:18:07 <iovka> ericP: in SPARQL graph pattern, 1^^xsd:int won't match 1^^xsd:byte
21:19:34 <iovka> ... filter expression would match it
21:19:43 <kcoyle> +q
21:20:08 <Arnaud> ack kcoyle
21:20:10 <iovka> ... actually, not sure whether it works in filter expression ...
21:20:44 <iovka> kcoyle: we are talking about the difference betw. checking the type and comparing values, we already have requirements about checking values, and this one is about checking a type
21:21:39 <iovka> TallTed: then the hybrid thing both value and type is different thing
21:22:53 <iovka> Arnaud: Arthur, you talked about unions, do you want other requirements
21:23:22 <TallTed> s/both value and type is different thing/ -- checking values, checking types, and checking combined value+type are different things/
21:23:23 <iovka> Arthur: I just wanted a clarification
21:24:19 <hsolbrig_> eric should now be muted
21:24:34 <iovka> TOPIC: Requirements
21:24:34 <iovka> subtopic: Property type
21:24:19 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property_Type
21:24:23 <pfps> q+
21:25:30 <iovka> hknublau: probably missed up with the next one
21:26:25 <pfps> Property Type should read "The values of a property may be limited by their type, i.e., all children have to be of type person"
21:26:52 <Arnaud> ack pfps
21:27:16 <labra> labra has joined #shapes
21:28:28 <Dimitris> only rdf:type or shape ?
21:28:37 <Arnaud> PROPOSED: Replace Property Type description with "The values of a property may be limited by their type, e.g., all children have to be of type person"
21:28:48 <TallTed> "The values of a property may be limited by their rdf:type, e.g., all foaf:children have to be of rdf:type foaf:person"
21:28:58 <Arnaud> PROPOSED: Replace Property Type description with "The values of a property may be limited by their rdf:type, e.g., all children have to be of type person"
21:29:19 <cygri> +1
21:29:23 <hknublau> +1
21:29:25 <ericP> +1
21:29:27 <SimonSteyskal> +1
21:29:29 <pfps> +1
21:29:31 <ArthurRyman> +1
21:29:34 <labra> +1
21:29:43 <Dimitris> +1 but limited only for rdf:type or shape in general?
21:29:44 <TallTed> +1
21:29:44 <iovka> +1
21:29:56 <Arnaud> RESOLVED: Replace Property Type description with "The values of a property may be limited by their type, e.g., all children have to be of type person"
21:29:57 <pfps> This one is about typing, not shapes.
21:30:14 <hknublau> for shapes use ldom:valueShape
21:30:49 <michel> michel has joined #shapes
21:30:54 <Dimitris> ldom:valueShape is the implementation, do we have a separate requirement for this?
21:31:39 <Arnaud> PROPOSE: Approve 2.5.4 Property Type (as reworded)
21:31:49 <Zakim> +michel
21:32:00 <hknublau> @Dimitris, to me this was Nested Constraint Macros
21:32:04 <pfps> +1
21:32:11 <kcoyle> +1
21:32:14 <ericP> +0
21:32:25 <hsolbrig_> +1
21:32:27 <TallTed> +1
21:32:45 <SimonSteyskal> do you mean property type not datatype?
21:32:53 <Dimitris> thanks cygri & hknublau
21:32:59 <iovka> +1
21:32:59 <ArthurRyman> +1
21:33:03 <labra> +1
21:33:11 <pfps> The relevant bit is 2.5.4, not the title  :-)
21:33:14 <Arnaud> RESOLVED: Approve 2.5.4 Property Type (as reworded)
21:33:34 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property.27s_RDF_Node_Type_.28e.g._only_IRIs_are_allowed.29
21:33:48 <Arnaud> subtopic: Property's RDF Node Type (e.g. only IRIs are allowed)
21:35:08 <iovka> ericP: sparql works on an rdf graph, how this graph is obtained (entailment, skolemization) is not the question
21:35:08 <ArthurRyman> +q
21:37:05 <iovka> ... foaf:mbox is a typical example of blank node
21:37:30 <Arnaud> ack ArthurRyman
21:37:50 <iovka> Arthur: discourages usage of blank nodes
21:38:15 <iovka> ... have seen specs where some node should be a blank node
21:38:45 <iovka> ... is it the case in owl, some things need to be blank nodes
21:39:32 <iovka> pfps: ready to remove its objection
21:40:17 <iovka> Arthur: applications want to participate on linked data, and accept also "broken software" that makes use of blank nodes
21:43:05 <Arnaud> PROPOSED: Approve 2.5.5 Property's RDF Node Type (e.g. only IRIs are allowed)
21:43:11 <labra> +1
21:43:12 <hknublau> +1
21:43:13 <kcoyle> +1
21:43:15 <Dimitris> +1
21:43:15 <SimonSteyskal> +1
21:43:16 <iovka> +1
21:43:16 <ArthurRyman> +1
21:43:20 <ericP> +1
21:43:23 <TallTed> +1
21:43:29 <pfps> +0
21:43:32 <hsolbrig_> 0
21:43:40 <Arnaud> RESOLVED: Approve 2.5.5 Property's RDF Node Type (e.g. only IRIs are allowed)
21:43:55 <michel> michel +1
21:45:10 <Arnaud> subtopic: Expressivity: Transitive Property Traversal
21:45:40 <SimonSteyskal> enumerations are already approved
21:45:51 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Transitive_Property_Traversal
21:46:51 <ArthurRyman> q+
21:47:18 <iovka> ericP: does not understand isn't it the same as using a OWL profile before validation
21:47:57 <ericP> q?
21:48:08 <ericP> ack next
21:48:24 <iovka> labra: does not understand whether only subclass or also property class. opposes if property paths
21:48:56 <iovka> Arthur: subclass should be covered by the discussion on entailment, parent/child, hierarchies are better examples
21:49:12 <pfps> I agree that rdfs:subclassOf is a poor example here.
21:49:22 <iovka> ericP: is it about transitive OWL properties ?
21:49:43 <pfps> Not about transitive OWL properties at all, as far as I am concerned.
21:49:45 <iovka> Arthur: no, you,re interested in the transitive closure of parent
21:50:24 <iovka> ... or partOf ...
21:50:40 <iovka> ... being able property+, property*
21:50:47 <ericP> q?
21:51:26 <pfps> The title is Transitive (Property Transversal) not (Transitive Property) Traversal
21:52:50 <TallTed> Transitive Transversal over Property
21:53:26 <TallTed> (Transitive) Traversal over Property (Paths)
21:53:35 <iovka> hsolbrig_: only transitive on one property, or sparql property paths
21:54:01 <iovka> Arnaud: let's first understand what it is about, and then decide whether we agree or not
21:54:36 <Dimitris> just "Property Paths"?
21:54:49 <kcoyle> Some constraints need to be able to traverse a property transitively, such as parent-child or partOf relationships
21:55:26 <Arnaud> PROPOSED: Change description to: Some constraints need to be able to traverse a property transitively, such as parent-child or partOf relationships
21:55:32 <iovka> +1
21:55:34 <hknublau> +1
21:55:36 <ericP> +1
21:55:38 <Dimitris> +1
21:55:39 <pfps> +1
21:55:39 <TallTed> +1
21:55:41 <kcoyle> +1
21:55:44 <SimonSteyskal> +1
21:55:50 <ArthurRyman> +1
21:56:01 <labra> +1 for the wording change...
21:56:08 <Arnaud> RESOLVED: Change description to: Some constraints need to be able to traverse a property transitively, such as parent-child or partOf relationships
21:56:38 <ArthurRyman> Transitive Closure of Properties
21:56:38 <ericP> s/Expressivity: Transitive Property Traversal/Expressivity: Transitive Traversal of Properties/
21:56:42 <hsolbrig_> +1
21:57:15 <michel> michel +1
21:57:32 <Arnaud> PROPOSED: Change title to: Expressivity: Transitive Traversal of Properties
21:57:39 <hknublau> +1
21:58:10 <pfps> no to saying Transitive Closure, as it can be confused with first creating the transitive closure
21:58:25 <ericP> +1
21:58:30 <ArthurRyman> +1
21:58:32 <iovka> +1
21:58:33 <Dimitris> +1
21:58:34 <TallTed> +1
21:58:34 <SimonSteyskal> +1
21:58:35 <hsolbrig_> +1
21:58:37 <michel> +1
21:58:37 <pfps> +1
21:58:48 <Arnaud> RESOLVED: Change title to: Expressivity: Transitive Traversal of Properties
21:59:47 <Arnaud> PROPOSED: Approve 2.6.8 Expressivity: Transitive Traversal of Properties
21:59:49 <iovka> ericP: the validation might be comlex
22:00:06 <hknublau> +1 to proposal
22:00:10 <Zakim> -michel
22:00:14 <michel> bbiab
22:00:24 <iovka> ... static analysis is comlpex
22:00:26 <pfps> +1
22:00:30 <Dimitris> +1
22:00:35 <SimonSteyskal> +1
22:00:38 <iovka> labra: propose this is not part of the core language
22:00:52 <cygri> +1 to proposal
22:02:05 <iovka> +1
22:02:09 <hsolbrig_> +1
22:03:00 <ericP> 0
22:03:11 <TallTed> +1
22:03:26 <kcoyle> +1
22:03:33 <ericP> ±0
22:03:43 <ArthurRyman> +2
22:03:45 <labra> +0
22:04:02 <Arnaud> RESOLVED: Approve 2.6.8 Expressivity: Transitive Traversal of Properties
22:05:55 <hknublau> It’s getting late in Europe
22:05:56 <iovka> Arnaud: resume for today, or extend for more 30 min
22:05:58 <cygri> zakim, unmute me
22:05:58 <Zakim> cygri should no longer be muted
22:06:37 <iovka> ... we resume, tomorrow discuss more on discussion on the diffirent solutions
22:06:51 <iovka> ... the main issues: whether the shape is a class or not
22:07:24 <iovka> ... some of the issues that Peter has raised
22:07:46 <iovka> ... wild like to get a better sense of which is the most promising direction to move forward
22:08:09 <Zakim> -hknublau
22:08:43 <iovka> ... sooner we have candidate proposal, is better. the discussion tomorrow help us to get closer to that point
22:09:17 <iovka> ... meeting closed
22:09:22 <Dimitris> me too ! :)
22:09:31 <Zakim> -cygri
22:09:32 <Zakim> -pfps
22:09:55 <Dimitris> *12 in Greece now*
22:10:07 <Zakim> -Dimitris
22:11:10 <Dimitris> Dimitris has left #shapes
22:11:59 <Arnaud> trackbot, end meeting
22:11:59 <trackbot> Zakim, list attendees
22:11:59 <Zakim> As of this point the attendees have been pfps, Dimitris, +1.617.715.aaaa, SimonSteyskal, cygri, F2F, hknublau, michel
<iovka> Present: pfps, Dimitris, SimonSteyskal, cygri, hknublau, michel, Arnaud, Eric, hsolbrig, kcoyle, ArthurRyman, Iovka, labra, TallTed
22:12:07 <trackbot> RRSAgent, please draft minutes
22:12:07 <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/17-shapes-minutes.html trackbot
22:12:08 <trackbot> RRSAgent, bye
22:12:08 <RRSAgent> I see 3 open action items saved in http://www.w3.org/2015/02/17-shapes-actions.rdf :
22:12:08 <RRSAgent> ACTION: Richard - propose revision in wiki [1]
22:12:08 <RRSAgent>   recorded in http://www.w3.org/2015/02/17-shapes-irc#T16-59-34
22:12:08 <RRSAgent> ACTION: Harold to revise based on his ideas; we'll review and accept/or not [2]
22:12:08 <RRSAgent>   recorded in http://www.w3.org/2015/02/17-shapes-irc#T17-06-07
22:12:08 <RRSAgent> ACTION: Harold to merge 17 and 18 [3]
22:12:08 <RRSAgent>   recorded in http://www.w3.org/2015/02/17-shapes-irc#T17-08-13