W3C

RDF Data Shapes Working Group Teleconference

17 Feb 2015

Agenda

See also: IRC log

Attendees

Present
pfps, Dimitris, SimonSteyskal, cygri, hknublau, michel, Arnaud, Eric, hsolbrig, kcoyle, ArthurRyman, Iovka, labra, TallTed
Regrets
Chair
Arnaud
Scribe
ArthurRyman, kcoyle, labra, iovka

Contents


<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

Introductions

<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.

Meeting Goals

<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

User Stories

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

Requirements

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's presentation on Complexity and Expressiveness

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

Requirements

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> https://www.w3.org/2014/data-shapes/wiki/Requirements#Property.27s_RDF_Node_Type_.28e.g._only_IRIs_are_allowed.29

<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

Summary of Action Items

[NEW] ACTION: Harold to merge 17 and 18 [recorded in http://www.w3.org/2015/02/17-shapes-minutes.html#action03]
[NEW] 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]
[NEW] ACTION: Richard - propose revision in wiki [recorded in http://www.w3.org/2015/02/17-shapes-minutes.html#action01]
 

Summary of Resolutions

  1. Close ISSUE-13 as per Sandro's email and Peter's edits
  2. Close ISSUE-8 as the User Story is no longer in the Wiki
  3. Close ISSUE-11 accepting Ted's revised proposed change
  4. Close ISSUE-12, accepting Dean's addition
  5. Move Property Default Value to a new category "Non validation related requirements"
  6. Move Property Labels at Shape to the category "Non validation related requirements", specifying this is intended for human consumption such as documentation or UI
  7. Move Property Comment to the category "Non validation related requirements"
  8. 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
  9. 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"
  10. Approve 2.5.4 Property Type (as reworded)
  11. Approve 2.5.5 Property's RDF Node Type (e.g. only IRIs are allowed)
  12. Change description to: Some constraints need to be able to traverse a property transitively, such as parent-child or partOf relationships
  13. Change title to: Expressivity: Transitive Traversal of Properties
  14. Approve 2.6.8 Expressivity: Transitive Traversal of Properties
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-03-05 21:12:23 $