See also: IRC log
<BartvanLeeuwen> ack ??p5
<BartvanLeeuwen> -1
<ericP> scribebick: TallTed
<pfps> scribenick: TallTed
<ericP> PROPOSED: Approve minutes of the 30 April Telecons: http://www.w3.org/2015/04/30-shapes-minutes.html
<pfps> minutes look OK to me
RESOLUTION: Approve minutes of the 30 April Telecons: http://www.w3.org/2015/04/30-shapes-minutes.html
<ericP> next meeting: 2015.05.14
action-19?
<trackbot> action-19 -- Richard Cyganiak to Add requirement(s) for RDF collections to address ISSUE-46 -- due 2015-04-30 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2014/data-shapes/track/actions/19
<cygri> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0017.html
<ericP> PROPOSED: Open ISSUE-47 and ISSUE-48
+1 open both
<pfps> +1 to opening 47
<Dimitris> +1
<pfps> +1 to opening 48 as well
<SimonSteyskal> +1
<Labra> +1
<Dimitris> +1 to open 48
RESOLUTION: Close ACTION-19
RESOLUTION: Open ISSUE-47 and ISSUE-48
<cygri> ISSUE-47?
<trackbot> ISSUE-47 -- Can SPARQL-based constraints access the shape graph, and how? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/47
issue-37?
<trackbot> issue-37 -- Naming of node kind facet -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/37
<kcoyle> +q
kcoyle: what does facet mean here?
aryman: "facet" here refers to the different kinds of things which can be used to define constraints -- "facets of a constraint"
<SimonSteyskal> +q
ericP: are these all the facets we can think of?
aryman: no, there are others. e.g., may want to require a literal be from a list of values
TallTed: there are too many variables in flux here -- each of these impacts the others, so deciding on one at a time doesn't work. we need sets to consider against each other, even if that starts with a lot of sets.
cygri: we don't need to focus on this now. let the editors pick a set, and people can argue against those later, if there are issues.
<Zakim> ericP, you wanted to propose really long names until we resolve names
<Dimitris> +q
ericP: one thing we could do for safety is to use painfully clear names, e.g., RdfSyntaxNodeKind, so search-and-replace later, when we figure out what simpler names we like, is easy
Dimitris: test suite development demands more stability than that would give us
cygri: we're not far enough along to deliver that much stablity...
ericP: maybe TallTed can pivot the naming under consideration.
<ericP> ACTION: TallTed to arrange https://www.w3.org/2014/data-shapes/wiki/Facet_Property_Names to have a table of aspects of contraints (X) and coherent proposals (Y) [recorded in http://www.w3.org/2015/05/07-shapes-minutes.html#action01]
<trackbot> Created ACTION-21 - Arrange https://www.w3.org/2014/data-shapes/wiki/facet_property_names to have a table of aspects of contraints (x) and coherent proposals (y) [on Ted Thibodeau - due 2015-05-14].
<ericP> https://www.w3.org/2014/data-shapes/track/issues/42
issue-42?
<trackbot> issue-42 -- Adding sh:notEqual to potential datatype properties? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/42
SimonSteyskal: basically sh:notEqual syntactic sugar to remove need to bracket with sh:maxExclusive, sh:minExclusive
... could also handle with SPARQL, if that's available
cygri: slippery slope here. easy to say "notEqual to a constant" but it's also easy to imagine more complex comparatives than that constant -- another property, some complex relationship, etc.
<SimonSteyskal> +q
<Dimitris> +q
cygri: how common is this use case? if very common, then perhaps sugar makes sense; if not so common, better to push to extension mechanism
<Labra> +q
<ericP> issue 41
<Dimitris> *a common use case is owl property disjointness*
Labra: supports not equal as part of core
aryman: my concern is complexity of evaluation of potentially complex expression
SimonSteyskal: origin was railway domain, where two values could not be equal
<Labra> TallTed: we are already evaluating comparisons...so we could also evaluate negatively as well
TallTed: so 41 and 42 are explicitly about paths... changes consideration
cygri: question here seems more how to decide core vs not-core/extension
... which should be based on commonality of requirement/need, according to charter and otherwise
aryman: grey area exists, too, depending on complexity of implementation even for lightly-required feature
Labra: concedes there are more complexities than first thought, so this may belong in extension rather than core
<ericP> ACTION: Simon to propose a "more compelling" use case for = and != for property paths (Issue-41, Issue-42) [recorded in http://www.w3.org/2015/05/07-shapes-minutes.html#action02]
<trackbot> Created ACTION-22 - Propose a "more compelling" use case for = and != for property paths (issue-41, issue-42) [on Simon Steyskal - due 2015-05-14].
<hsolbrig> +q
<SimonSteyskal> +q
[[ back and forth about supporting Property Paths in general, and what was intended by these issues ]]
<cygri> https://www.w3.org/2014/data-shapes/wiki/Requirements#Named_Shapes
hsolbrig: question about uniqueness requirements for Named Shapes
SimonSteyskal: both issues could certainly be realized through extension mechanism; just wanted to raise the question of whether these were worth putting into core
<ericP> ACTION: Simon to write up semantics (eq, ne, and any other constraint aspect) in the face of zero-or-more results to a property path [recorded in http://www.w3.org/2015/05/07-shapes-minutes.html#action03]
<trackbot> Created ACTION-23 - Write up semantics (eq, ne, and any other constraint aspect) in the face of zero-or-more results to a property path [on Simon Steyskal - due 2015-05-14].
issue-23?
<trackbot> issue-23 -- Shapes, classes and punning -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/23
<ericP> ISSUE-23: Shapes, classes and punning
[[ classes are not shapes ... mixing them is potentially troublesome ... but some want to mix them in some ways ]]
<hknublau> +q
hknublau: my starting point in ldom had no shapes, classes were sufficient. ontology developers who must define both a person and personshape may just laugh at us.
<Dimitris> +q
cygri: summarizes three viewpoints: 1) class and shape are different, and if we blend them, bad things will happen.
... 2) it's debatable whether and how class and shape are different, and potential problems are addressable when/if they arise.
... 3) class and shape are basically the same, and blending is natural
<pfps> problem 1: if shapes are classes then they will be used for ontology modelling
aryman: people wanted something like shapes, but all they had was rdfs and owl, so these were used ... or more correctly, mis-used
<hknublau> +q
aryman: if you put that into a reasoner, you get unintended answers
... stardog proposed an alternate semantics for owl
... proposals are now about constraints, why go back to inferencing?
<cygri> aryman, classes can be used for other things than inferencing.
<pfps> Stardog ICV is not an alternative semantics for OWL as an ontology language, it is a way to define constraints that uses the syntax of OWL
Dimitris: shapes and classes are different, but we could blur the lines in some ways
hknublau: two topics here -- 1) do we want to support selection of shapes based on rdf:type? already resolved and accepted
... 2) how can we make the link between classes and shapes to handle that support? easy if they're permitted to overlap (and could have same URI); harder if not, means many more questions must be answered
<Zakim> ericP, you wanted to ask if the propsal is that having one node identifying a type and a shape but have those definitions kept in seperate graphs
<hknublau> +q
<ericP> TallTed: +1 to harold. both extremes seem bad. giving the choice seems optimal
<pfps> +1 to Arthur, the issue not whether classes can or can't be shapes but whether the processors need to do something special for classes that are shapes
<ericP> ... is sounds like you are saying that by asserting the type arc, i'm imposing that shape on that class in all places and times
<ericP> ... i think that we're closing withing a context
aryman: "what does it mean for a shape to be a class?"
hknublau: the meaning is the same as if you define a shape identically to the class for which you're defining that shape...
... it's basically syntactic sugar
aryman: it's very common in RDF to have links that refer to resources in other graphs
... say a bug report, and reference is a test case. :hasRelatedTestCase :xyz, :xyz a :testCase
<pfps> Yes, another problem is just what it means to be a class? Is it a direct rdf:type link to rdfs:class? Can there be rdfs:subClassOf links involved? Can there be rdfs:subPropertyOf links involved? There will be complaints about any of these options.
<cygri> aryman, you can do that with subclasses.
<pfps> bye
<ericP> ADJOURNED
<cygri> very sneaky, Labra ;-)
trackbot, end meeting