RDF Data Shapes Working Group Teleconference

12 Nov 2015


See also: IRC log


aryman, Arnaud, pfps, kcoyle, simonstey, dimitris, TallTed, hknublau, ericP, BartvanLeeuwen, labra_(partial), labra
hsolbrig, labra_(partial)


<scribe> scribenick: ericP


<Arnaud> PROPOSED: Approve minutes of the 5 November Telecon: http://www.w3.org/2015/11/05-shapes-minutes.html

<pfps> minutes looked OK to me

RESOLUTION: Approve minutes of the 5 November Telecon: http://www.w3.org/2015/11/05-shapes-minutes.html

<pfps> No meetings on Xgiving for me (if I want to stay married)

<TallTed> definite regrets for 11/26

Disposal of Raised Issues

<Arnaud> PROPOSED: Open ISSUE-111, ISSUE-112

<hknublau> -1 to opening ISSUE-111

Arnaud: i don't think we should close tracker
... some issues become ratholes, but sometimes should be routine

<pfps> ISSUE-111 has been under discussion the last two weeks already

<Arnaud> PROPOSED: Open ISSUE-112

<hknublau> +1


<Dimitris> +1

<kcoyle> +1

<simonstey> +1

<aryman> +1

<pfps> +1


<TallTed> +0

Arnaud: let's talk a bit more about ISSUE-111
... we've been discussing this this week

hknublau: i prefer to work on issues that have practical relevence

<simonstey> I don't see why sh:defaultValue should be dropped

hknublau: this feels like a high-level talking point that doesn't accomplishing anything and doesn't have to do with default values

Arnaud: there are two things, one high-level, one specific
... re the high-level one described in the title, i agree with you that it could be a rathole
... but it raises an interesting question about what does it take to meet charter reqs?

pfps: we've already been beat up about what's in the SHACL spec
... this isn't philosophical. it's a conversation that has led to ratholes
... this is an attempt to shine some light in the rathole so the WG can make progress

hknublau: we have more important things
... pfps is saying that we first have to handle this before other stuff

<simonstey> -q

TallTed: if we're going to talk about politeness, then we should not talk about or distinguished opposite as "raising silly arguments".
... i agree that we should move the 2nd point to another issue

<Arnaud> PROPOSED: Open ISSUE-111

TallTed: i think we should wordsmith the first [title] issue

<simonstey> +1 (only if proposal 2 is moved)

Arnaud: opening the issue is not agreeing to the proposal

<pfps> I thought that the deal was to put proposals into new issues, so I tried to do so.

<hknublau> -0.9

<kcoyle> +1 if issues are broken out

<pfps> I'm willing to remove the second proposal from this issue

<Arnaud> PROPOSED: Open ISSUE-111, and move question about sh:defaultValue to a separate issue


<TallTed> +1

<simonstey> +1

<pfps> I'm actually willing to remove both proposals if that is deemed a good thing

<pfps> +1

<kcoyle> +1

<Dimitris> +1

<aryman> +1

RESOLUTION: Open ISSUE-111, and move question about sh:defaultValue to a separate issue

<pfps> I just removed the second proposal.

<pfps> I'll do other stuff shortly, so no action required.


Arnaud: kcoyle reported yesterday that the requirements doc is pretty stable. what do we do with it?

kcoyle: we'd talked about integrating it into the UC&R
... alternatively don't publish it, or publishing it as an external doc

<Arnaud> https://docs.google.com/document/d/1whx2DeJtng-WZXo2DAHc_GZL7ElXNS_B8fBxarGA-0o/

kcoyle: pfps pointed out that the doc ends up a bit cyclical.

<simonstey> +q

<pfps> I'm happy with having this in the UCR document, I think.

kcoyle: otoh, it's a handy place

Arnaud: we should put it in W3C-land so it can be preserved
... this is a useful piece of data which we should promote somehow

<simonstey> -q

<simonstey> +q

<pfps> I think that my previous comments were about how to add this - section vs scattered

kcoyle: i suspect that more folks will encoouter it in the UC&R

Arnaud: where would you put it?

kcoyle: this would be another header under each requirement.
... that's how i envisioned it.
... interested in other proposes, but i don't want a big table

simonstey: there's a connection between uc's and r's

<kcoyle> http://www.w3.org/TR/2015/WD-shacl-ucr-20150414/

simonstey: "if you want to see how this is solved with shacl, follow the link to the shacl spec"

<pfps> I leave it up to editorial discretion

ericP: this is the topology i expect from a UC&R doc

Arnaud: looks like a green light from the WG

pfps: does UC&R still have the prob with the reply-to addr?
... all good. it's public-rdf-shapes@w3.org
... it's the other doc with the wrong addr

<pfps> The Editor's Draft for SHACL should be fixed now, before next publication.

<simonstey> +q

<pfps> I sent the message from pfps@verizon.net


<pfps> ISSUE-65

<trackbot> ISSUE-65 -- Consistency and cohesiveness of nomenclature (e.g., shapes, scopes, and constraints) -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/65

Arnaud: after the first WG saying that there was inconsistency

<Arnaud> PROPOSED: Close ISSUE-65, while not perfect, the recent editorial fixes and rewrites have sufficiently addressed this. Further inconsistencies to be treated incrementally.

Arnaud: hknublau says we should close it 'cause it's considerably better
... as an ongoing mission, we all need to improve the doc

<kcoyle> arthur? have you done this?

<aryman> tried to

pfps: i think the doc is severly wedged wrt to nomenclature, but i won't object to closing this

<simonstey> +q

pfps: i think it's hard to come up with a coherent description about when shapes or filters are actu=ve
... what kinds of constraints are there -- the doc says templates and built-ins
... notion of "abstractness" which pops up in various places

Arnaud: we have different issues for this.
... i would expect this kind of work to continue even if we close issue-65

simonstey: regarding filters and scopes, i think that a filter is a more precise way to describe a scope.

<TallTed> it may be helpful to update the issue summary, with a dated section saying "these are the pieces that still need careful addressing (see also ISSUe x,y,z)"

simonstey: we need to clarify whether filters are a separate thing or just a more precise scope

Arnaud: so you propose that we close this and open more specific issues

pfps: i worry that we'll play wack-a-mole; we'll have wacked the moles but end up with a lumpy yard

TallTed: we can use this as an ombibus tracker for the other issues (updated to point to them)

aryman: i think that part of the prob is that the spec makes certain assumptions that some members of the WG have objected to
... until we resolve them, we can't make progress
... i don't think we should be talking about abstract classes, meta-classes, and templates
... i'm not just going to unilaterally delete the stuff i don't like 'cause hknublau will revert
... we need WG resolutions

Arnaud: i think the points you've made are all encapsulated in one issue or another
... i take pfps's point that if you address issues one at a time, you can end up with something uglier than if you took a more comprehensive approach
... otoh, i don't know how to avoid this in a WG
... from what i heard, i think we're better off keeping issue-65 open
... people should open other issues and make proposals
... the number of issues isn't the problem, it's whether we're making progress
... the proposals page hasn't changed much

<pfps> Maybe have a link to a Wiki page about nomenclature?

ericP: if we're going keep issue-65 open, we should have links (full urls) to related issues at the top of the description

<pfps> I'll volunteer to make a wiki page and link it up appropriately

Arnaud: pfps propsed doing this in a wiki page.

ISSUE-96: Violation IDs

Arnaud: we didn't discuss this on a call.

<simonstey> ISSUE-96

<trackbot> ISSUE-96 -- Should the validation results contain stable IDs to indicate the type of violation -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/96

Arnaud: there were some votes on the wiki page, including an objection from pfps
... we need to make a decision.

hknublau: in the future, there will hopefully many impls of SHACL
... i would like interop between those platforms

<aryman> i muted

hknublau: it's not sufficient to have a link to the subject and predicate if we don't have a known type
... hsolbrig (i think) metnioned that other specs, e.g. XML schema do that

pfps: i think that we're cramming so much into these things [violations?], that we're making it hard to implement SHACL without much benefit
... there are all sorts of things we could do that would be nice, but if we do, we end up with SQL

<Arnaud> ericP: without a specific ordering we can't have consistency in what errors are reported, like in case of conjunctions, so user wouldn't know how to test for violation IDs

<pfps> good point, repeatable error messages requires that execution be deterministic

hknublau: we have no mandatory link between top-level errors and nested (ANDs and ORs)
... i see that i need to programatically distinguish what comes back, e.g. and error getting rendered on one page or another.

Dimitris: i like this feature -- it's quite useful -- but i share ericP'

<hknublau> Could we make it optional at least?

Dimitris: 's concearn that it doesn't work with nested constraints.
... could put it in a separate doc

<hknublau> At least as a shared URI of the property

aryman: we don't need to invent a new syntax 'cause we can use IRIs
... we could at least identify the constraint violation.
... and it should be part of the validation report

Arnaud: don't we already have that?

<pfps> Lots of constraints are currently blank nodes, which do not have IRIs.

<aryman> sh:MinCountConstraint

<hknublau> +1

aryman: we can include, focus node, property, predicate, etc.

hknublau: i agree with aryman; the IRIs need to be defined anyways
... my names are long and start with "abstract"
... the core language could use a key predicate that's in each template
... but i prefer to use a class or template IRI
... if folks are worried about the burden, we could call it optional

<aryman> muted

hknublau: at least if tools want to interoperate, there should be a standard set of names

pfps: are we trying to capture that a min constraint was violated
... if we know the actual constraint that was violated, we can find out what it is

hknublau: we haven't make it explict. there a property called "source template".

pfps: if i create a "2nd-parent constraint" and it has a number -57, you might want fecund-parent-min-cardinality-constraint-57
... but you just want min-cardinality-constraint

Arnaud: maybe we need to take this off line

Dimitris: i thought this was already covered

hknublau: it should be possible to represent the core constraints and templates
... then we can use those ids.

aryman: we don't need to introduce templates.

ISSUE-78: sh:abstract

Arnaud: this is an entirely separate issue
... there are folks uncomfortable with shapeClass
... should we have the ability to declare this stuff "abstract"
... i fear the issue will be about whether we should have shapeClass at all

aryman: i fear we're introducing a whole programming model
... the motivation for introducing abstract classes in OO langauges is to factor common behaviors/features
... but if we want an abstract class, we just give it a vacuous body that always returns true
... so i think that abstract classes are another piece of complexity

hknublau: we've found in our experience with user tools that we want to make sure these aren't implemented directly

TallTed: this sounds like a bullet point for the user interface section of the specification

Arnaud: so this falls in the same category as the sh:index that we talked about last week?

TallTed: right, maybe not in the spec, but in the UC&R

aryman: for hknublau's case, he's introduced a new requirement for a new constraint class
... i.e. look for nodes that are instances of an abstract class and not any [non-abstract] subclass
... so hknublau should introduce a new req

Arnaud: how about as an annotation?

aryman: wants to look for actual violations

hknublau: i'm fine with both.
... i started with just an annotation, pfps asked me for semantics, i produced it, but i'm not convinced it's necessary

pfps: we have two proposals:
... a constraint sitting on RDFS classes, but not using RDFS
... if it has bite, it should have RDFS bite
... if it's an annotation, then it's part of the user interface

Arnaud: if you're only interested in the UI case, you should re-introduce

hknublau: ok, i created the semantics to satisfy pfps.
... do i have to create a requirement?

Arnaud: it's useful to have use cases, but i don't know that we need specific requirements for every language feature
... there's a general issue that came up last week: how much do we address (graphical) user interfaces

TallTed: it's not just graphical, and not just user interface, it's user experience
... there's an IRI, which nobody wants to look at, and probably a label.
... and a title
... and a description that shows up as a popup

Arnaud: it would be great to document this

TallTed: i put a bit in channel last week

Arnaud: no point in trying to close issue-78.
... hknublau has some work to document it as an annotation.
... it seems it has more viability if it's just an annotation than if it introduces a new constraint

hknublau: is it sufficient for me to just make a new proposal, or do i have to create a use case et al?

Arnaud: you should say why you want it, and we can discuss adding it to the UC&R

ISSUE-92: additive repeated properties

Arnaud: we discussed this before, and no one persuaded the others.
... there weren't many votes (more now)
... the status quo is that we don't change anything
... we have several objections to the status quo

<pfps> It looks to me that this proposal is to change SHACL from conjunctive to additive, i.e., completely change SHACL.

pfps: the summary of ericP's proposal is to throw away shacl and use shex instead

ericP: that part of it anwyays. that's what we had to do in shex 'cause we started with Resource Shapes.

Arnaud: there are several ways to get conjunciton.
... it wasn't clear to me why we need to use that syntax for conjunction.
... why can't we just allow that 'cause we already have other conjunctions?
... there's propably something else that makes people react, but i don't know what it is

pfps: everything in shacl is predicated on conjunciton.
... you have to completley change everything.

<hknublau> I agree, this would be a very difficult change

pfps: suppose we changed the comma in shex from additive to conjunctive; it would change everything

aryman: i'm not convinced it would be that dramatic
... we'd have to think hard about inheritance
... one use case for that is when you want to tighten up the constraints on a super shape.
... it's easy with a conjunctive semantics.

<TallTed> re-re-re-reading the 4 proposals on the wiki page... I'm least troubled by Arthur's

ericP: the use of conjunction only aids in extension in the trivial case

<pfps> Which use cases? Are they in UCR?

<TallTed> (and we do need to address inheritance/include effects)

Arnaud: we don't want to throw away inheritance

hknublau: i'm always in favor of compromise
... maybe isolate to a specific construct
... aryman's algorithm can't be expressed in a single SPARQL query

Arnaud: we said we'd use SPARQL as much as possible, but it might not be possible here

aryman: my algorithm can't be handled in a single sparql query
... my proposal is a compromise which would get you many of the use cases that the shex community needs but is computationally tractable.

<BartvanLeeuwen> thx bye

<Arnaud> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 5 November Telecon: http://www.w3.org/2015/11/05-shapes-minutes.html
  2. Open ISSUE-112
  3. Open ISSUE-111, and move question about sh:defaultValue to a separate issue
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2015/11/20 16:56:00 $