RDF Data Shapes Working Group Teleconference

<scribe> scribe: simonstey

Admin

<Arnaud> PROPOSED: Approve minutes of the 17 September Telecon: http://www.w3.org/2015/09/17-shapes-minutes.html

Arnaud: I'll fix the present list

RESOLUTION: Approve minutes of the 17 September Telecon: http://www.w3.org/2015/09/17-shapes-minutes.html

Arnaud: next meeting 1.10

SPWD of UCR

http://w3c.github.io/data-shapes/data-shapes-ucr/

<Zakim> pfps, you wanted to ask whether there should be a "Changes" section

simonstey: current version is up2date and ready for review

<ericP> pfps: no changes since last version section

<ericP> simonstey: since the last doc, we've mostly not added stuff

<pfps> So changes would say "editorial changes and addition of new use cases"

<Arnaud> simonstey: I think we should renumber the UCs and Rs

<ericP> ... we've cleaned up a few.

<pfps> So then changes would say "editorial changes only"

<pfps> ... plus fixes to existing use cases.

aryman: I don't think that we need to renumber the UCs

<ericP> +1 to not bothering

<pfps> pick one

aryman: all mails that were referring to those stories would be obsolete

<kcoyle> +1 to keeping links

<Arnaud> Arnaud: ok, let's keep the current numbers

https://www.w3.org/2014/data-shapes/wiki/Requirements

simonstey: I'll prepare a list of REQs to look over for the next call

<aryman> the UCR looks good

<pfps> In general I prefer the option of allowing review.

aryman: I don't feel the need to review it

<Arnaud> PROPOSED: Publish UCR Editor's draft, with added changes section

<pfps> doesn't looking require a week?

ericP: everyone could look at their UCs and see whether they are correctly represented/interpreted

<pfps> you can observe a lot by just looking for a week

<pfps> +0.5

<aryman> +1

+1

<ericP> +1

<TallTed> +1

<hsolbrig> +1

<kcoyle> +1

RESOLUTION: Publish UCR Editor's draft, with added changes section

Disposal of Raised Issues

<Arnaud> PROPOSED: Open ISSUE-90, ISSUE-91, ISSUE-92

Arnaud: I suggest we open all raised issues

<pfps> these all look like appropriate issues

ISSUE-90

<trackbot> ISSUE-90 -- Can the focus node be a literal? -- raised

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

ISSUE-91

<trackbot> ISSUE-91 -- Default Cardinality -- raised

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

ISSUE-92

<trackbot> ISSUE-92 -- Should repeated properties be interpreted as additive or conjunctive? -- raised

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

<ericP> +1

<kcoyle> +1

+1

<TallTed> +1

<hsolbrig> +1

<pfps> +1

<aryman> +1

<hknublau> +1

RESOLUTION: Open ISSUE-90, ISSUE-91, ISSUE-92

FPWD of SHACL Spec

Arnaud: we've gone back and forth; quite some changes were made

<pfps> that is, of course, not a ringing endorsement of the document as is

Arnaud: since no one is heavily against publishing it as a FPWD I propose to do so

<Arnaud> PROPOSED: Publish SHACL Editor's draft as a FPWD

<aryman> +1

<TallTed> +1

+1

<kcoyle> +1

<hknublau> +1

<ericP> +.5

<pfps> the bar to be passed is that the document does not go against WG consensus and will be mostly understood by readers

<pfps> 0

<hsolbrig> Got dropped off the Skype connection -- trying to get back in

Arnaud: none of what's in the document is cast in stone! everything can be changed
... the document can be changed at any time

<Arnaud> hsolbrig, do you care to vote?

<pfps> I'm planning on publicising the document to a couple of mailing lists, along with comments about some of the aspects of SHACL

<hsolbrig> I lost audio a bit back

<hsolbrig> Skype seems to be having another fit

<hsolbrig> +1

RESOLUTION: Publish SHACL Editor's draft as a FPWD

Arnaud: I guess publishing the draft isn't that easy, eric and I will figure out what has to be done to publish it

ISSUE-87: Turtle file

ISSUE-87

<trackbot> ISSUE-87 -- Shall we publish RDF files for the SHACL namespace? -- open

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

Arnaud: the short name might be kind of misleading
... normally you have a document that shows up when someone resolves the SHACL namespace

ericP: usually I hit up the editors to provide HTML, turtle, RDF/XML representations of the vocabulary

<aryman> see http://www.w3.org/TR/cooluris/

<ericP> ldp.{html,ttl,rdf,var}

ericP: (eric looks up LDP example)

<aryman> see also http://www.w3.org/TR/swbp-vocab-pub/

<ericP> http://www.w3.org/ns/ldp

Arnaud: the question is how much we want to put in there as of now

<pfps> +1 to a stake in the namespace ground only

Arnaud: we could just have a pointer to our work
... but the question is what we actually want to publish as .ttl (if we want to do so ever)

aryman: we should align with W3C's recommendations on specifying vocabularies and should definitely publish it at some point
... I just had the impression that the current vocab contains too much implementation specific parts

Arnaud: were is the current .ttl file stored? It seems to be gone from the repo

hknublau: I've deleted it from the repo, since there was no consensus on having such a document
... it can still be found on the github page of the topbraid/shaclapi

Arnaud: I don't think the file should have been deleted

aryman: the vocab should contain at least every term mentioned in the FPWD
... I've access to tools that can ensure the consistency of .ttl/rdf/xml/html representation of a vocab by transforming one into another
... just having a document there that says "that's a namespace" doesn't make much sense

<pfps> how can i get to historical versions of the turtle file

<hsolbrig> +1 to pfps

pfps: If we include a URL it must resolve, we need to put a stake in the (our namespace) ground

<pfps> the actual document could just have *no* RDF content whatsoever

ericP: I'm working on something already

<pfps> that's going to have to have some disclaimers

<Zakim> pfps, you wanted to say that 0 properties and 0 classes are adequate

<hsolbrig> Definitely NOT ShapeClass...

Arnaud: I'm concerned that including parts of the vocab in there requires some additional confirmation of WG members

<pfps> +1 to a pro-forma document

<kcoyle> +1 to stake in the ground

Arnaud: if people follow the ns link, they get to a pro-forma document

<hsolbrig> +1 to snake on the ground

+1

<TallTed> +1

<aryman> +0

<hsolbrig> wooden, of course

RESOLUTION: publish a pro-forma document as a stake in the ground for the namespace along with FPWD

ISSUE-65: nomenclature consistency

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> http://w3c.github.io/data-shapes/shacl/#terms

Arnaud: the question is (putting aside the fact the spec is sometimes not consistent with itself) when it comes to the nomenclature itself, is the glossary we are using enough to call the issue resolved?

pfps: I think the current nomenclature or organization is currently somehow troubling
... everytime I read the document I get confused (but I don't know exactly why)
... in particular, shapes are both inside and outside of constraints
... and behave there differently
... scopes and filters are another issue, you've to remember which apply when and if they are actually mattering

aryman: I think what we are seeing is design entropy, shapes are basically a set of constraints and things that are added to them like scopes and filters

<pfps> shapes also have names and comments and ......

<pfps> +1 to Arthur

aryman: QFC are another example, they are like the other constraints but not quite the same

<pfps> and min and max cardinality are described almost like other bits of property constraints, but not exactly

Arnaud: I just wanted to check where we stood in this regard

<aryman> also Closed Shape is very different from other constraints

<pfps> the issue with shapes inside constraints is a shape "Can have zero or more scopes that select the nodes that the shape applies to." [Glossary] but this does not apply when a shape is inside a constraint

Misc

Arnaud: harold mentioned some "issues" that seem like actual issues that should be raised

<aryman> nice work Simon

aryman: how do you indicate the subject of a requirement?

ericP: the language specification tells you how to interpret strings of that language

<pfps> I'm sad to say that OWL 2 uses MUST for both the language and to constrain tools

ericP: we could look at the turtle, SPARQL or OWL spec that are all kind of handling this issue differently

Arnaud: we could allocate time in the future to address it

Additive repeated properties

eric's proposal : https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Sep/0107.html

<pfps> SPARQL 1.1 query language doesn't use RFC2119 at all

holger's proposal: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Sep/0128.html

Arnaud: Karen has been looking at her use cases and checked whether they are currently realizable using SHACL
... I want at least to clarify if there is a problem here or not

pfps: I've been staying out of this discussion, because I don't see the problem at hand

<pfps> my problem with the discussion is that I don't know what is being asked for - it seems to me that the request is to change each individual constraint and that this change results in a change to the natural combination algebra for constraints

ISSUE-92

<trackbot> ISSUE-92 -- Should repeated properties be interpreted as additive or conjunctive? -- raised

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

Arnaud: with the current draft, the example in the issue is invalid
... both property constraints are evaluated for the same property

<pfps> in ShEx, an isolated constraint :p @<s> [1,1] is satisfied by a node that has p links to two other nodes that satisfy <s>

TallTed: eric's example should definitely be expressible

<hknublau> In the current spec this would look like two qualifiedValueShapes at the same shape, i.e. ex:MyShape sh:property [ QCR1] ; sh:property [QCR2] .

Arnaud: we somehow have to figure out how to address both of the mentioned use cases

<Arnaud> trackbot, end meeting