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