RDF Data Shapes Working Group Teleconference

12 May 2016


See also: IRC log


Arnaud, kcoyle, simonstey, hknublau, TallTed, Dimitris, ericP, jamsden, labra
pfps, hsolbrig


<Arnaud> scribe: kcoyle


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


<Dimitris> yes

<TallTed> they look like minutes...

RESOLUTION: Approve minutes of the 5 May 2016 Telecon: http://www.w3.org/2016/05/05-shapes-minutes.html

Disposal of Raised Issues

<Arnaud> PROPOSED: Open ISSUE-160

<Dimitris> +1

<TallTed> +1


<hknublau> +1

<simonstey> +1

<Labra> +1

<ericP> +1


Draft publication

Arnaud: get an update from editors - lots of discussion of new terminology seciton

hknublau: Currently in limbo; good idea to have terminology section; needs to be clear, though. Has been asking for alternative terms
... esp. around terms class, instance. Perhaps "shacl class" "shacl instance'

Arnaud: still being actively worked on? or ready to go?

<simonstey> +q

hknublau: Not consistent at this point. Will take more work because "instance' for example is used all over

<Dimitris> +q

hknublau: So far no other suggestions than adding SHACL

simonstey: We might be vulnerable to comments if we publish it as is without fixing this, then that will bring criticism
... needs to be well-defined for next publication cycle, or left out altogether
... perhaps not include terminology section for next cycle; or only include those we are sure of

Dimitris: compromise: use linking instead of adding SHACL (makes document hard to read)

Dimitris - you need to mute because we are getting echo

TallTed: Working drafts are not carved in stone; having a disclaimer is ok; working draft is a heartbeat; and to get feedback from outside

Arnaud: should be at least coherent for the WD - if terminology doesn't make sense, maybe we shouldn't include it

hknublau: goal of terminology section makes it easier to rename things later; every usage would be linked to definition,
... Not possible to delete terminology seciton now - things are integrated into it

Arnaud: Should try to have something that makes sense

hknublau: Set a deadline? e.g. next week?

Arnaud: Status quo is draft today; others need to make proposals on terminology section; otherwise will stay how it is.

hknublau: could split the document and put in hyperlinks - perhaps in a few days

Arnaud: either next week or the one after


<trackbot> ISSUE-141 -- How to represent mixed datatype-or-class ranges -- open

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

hknublau: currently have dataType and datatypeIn; class, and classIn. Disjoint. OWL and others have only one property for these
... three proposals (in issue document); would be good to have this before publication
... if value of type is one of known
... types, would be a datatype property; else would be a class

Dimitris: if simplify, makes ... unknown datatypes

hknublau: alternative would be to check for user-defined datatypes; not not used often so not needed for core
... needs to be easy to use for schema.org where the 'or' is used a lot

Arnaud: there's a separate issue for OR and for sh:shape; what needs to be done?

<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-141:_Mixed_ranges

hknublau: proposal 3 has three options; peter and holger are ok with this

simonstey: voted on a - b and c were added later

hknublau: separate of sh:class and sh:datatype makes it easy to see what kind of datatype one has; but if you have to look at shapes or data graph, then it's harder
... don't need to cover user-defined data types because rare

ericP: sparql doesn't support comparisons of custom data types, but you can do graph patterns on them. This is used.
... if you mix class and datatype in the same property, and you are validating, you can see what it has;
... but if you are generating web forms, how do you prompt for the data if it's either/or?

hknublau: form builder would look for data type

ericP: if it's a known sparql datatype, then you can do this; but if there's a custom type,you couldn't prompt the user for the correct type

hknublau: that's ok if people want them in the core. that would be 3a

Dimitris: there's no way for shacl to know to ask for either a datatype or a class

hknublau: in 3a you would have to declare it with a types triple

Arnaud: seems to be a preference for 3a

jamsden; no opinion on 3b 3c; 3a seems fine

TallTed: it must be a known datatype or an rdf:type statement that makes it known

<Dimitris> I would prefer 0 (do nothing) or if we selected one of 3*, 3c looks better than the other two

hknublau: known datatypes are the XML ones; otherwise its under the control of the shapes graph

TallTed: shapes graph must be a complete defined/shaped ontology

Arnaud: what about doing nothing?

kcoyle: put off until after WD?

Arnaud: obvious preference for 3a; will be on agenda for next week
... others can still be considered

TallTed: issue page is out of date; needs to be updated, esp. examples
... other option: close this issue and open new one that is up to date
... decision; modify and put note at the top that it has changed. Holger will do.


<trackbot> ISSUE-78 -- Should SHACL support marking classes as abstract -- open

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

jamsden: I didn't fully understand Holger's issues; I've said my piece; up to Holger if it can be implemented

hknublau: I proposed th eoriginal feature; I favor the use case, but I don't see a solution that works because of weak link between classes and shapes

jamsden: link is weak?

hknublau: if you narrow to sh:scopeClass; but you can link instances to other scopes, and should apply to those; so it becomes too narrow

jamsden: ok, see that there are other examples where it doesn't work as easily
... not ok with things that impact rdf and rdfschema

<Arnaud> PROPOSED: Close ISSUE-78, dropping sh:abstract

<jamsden> +1

<Dimitris> +1


<TallTed> +1

<Labra> +1

<simonstey> +1

<hknublau> +1 (sadly)

<ericP> +1 (ambivalently)

RESOLUTION: Close ISSUE-78, dropping sh:abstract

<ericP> +ε ?


<trackbot> ISSUE-135 -- Should sh:and/sh:or/sh:not/sh:valueShape support constraints too? -- open

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

<ericP> issue-135

<trackbot> issue-135 -- Should sh:and/sh:or/sh:not/sh:valueShape support constraints too? -- open

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

<Arnaud> chair: ericP

<ericP> proposals

hknublau: introduction -> simplify syntax so do not have to point to a shape inside an or; seems not worth it
... first, need to generalize sh:or sh:not so they can also be used as property constraints (not justn ode constraints)
... so, that's the proposal: extend
... e.g. address is either a string or an instance (mixed range)
... this means you do not have to repeat the predicate
... end up with too many options to express the same thing - leads to confusion and difficulty
... proposal is to extend context of sh:or to also be allowed in property and inverse property constraints

<simonstey> +q

simonstey: this is for or, not, and (clarifying)

ericP: shex does this with an expression at the far end of a triple constraint where you can have an expression of arbitrary complexity

hknublau: that's a very different syntax; too different from what we currently have

<hknublau> ex:MyShape a sh:Shape ; sh:property [ sh:predicate schema:address ; sh:or ( [ sh:constraint [ sh:datatype xsd:string ] ] [ sh:constraint [ sh:class schema:Address ]] ) ] .

<ericP> ex:MyShape a sh:Shape ;

<ericP> sh:property [

<ericP> sh:predicate schema:address ;

<ericP> sh:or (

<ericP> [ sh:constraint [sh:datatype xsd:string ] ]

<ericP> [ sh:constraint [ sh:class schema:Address ] ]

<ericP> )

<ericP> ] .

<ericP> --done--

Dimitris: does his affect proposal relating to sh:constraint?

hknublau: No, no affect

<ericP> hknublau: this proposal leaves the door open to further simplifications

ericP: can vote w/o Peter because leaves open possibility of more revision.

<simonstey> +q

hknublau: issue can be left open

simonstey: seconding solution

<Dimitris> I also agree

hknublau: added property constraints and inverse prop constraints to cntext of sh:or/and/not

<ericP> PROPOSED: amend property constraint take logical operations sh:and, sh:or, sh:not

<simonstey> +1

<hknublau> +1

<Dimitris> also inverse


<jamsden> +1

<Labra> +0.5

<ericP> +1

<Dimitris> +1

RESOLUTION: amend property constraint and inverse property constraint to take logical operations sh:and, sh:or, sh:not


<trackbot> issue-134 -- does SHACL syntax distinguish inverse property constraints -- open

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

ericP: difference between prop and invProp is an issue... from Peter

hknublau: dimitris proposed a solution that would simplify this
... you don't know what kind of constraint you are getting

<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016May/0080.html

ericP: one issue being able to know if constraint is inverse or not? cannot have flag that is boolean - inverse T/F?

hknublau: with boolean you can have multiple values; will need a type arc? all constraint types are disjoint

ericP: all require something in the graph that doesn't have a default - ?

hknublau: if you put nothing, then it's like rdfs:range, and it infers a default type
... property defines constraint type sh:property, sh:inverseProperty
... separate sparql constraint form node constraint; then sh:constraint is separate - may be renamed in future

simonstey: a good idea; not strong about splitting off sparql cnstraints
... might help when we hae a different execution language (not sparql)
... do we want to name it 'sparql constraint" or a more generic "execution language constraint"?

<ericP> <S> sh:sparqlConstraint [ ... ] vs. <S> sh:scriptConstraint [ sh:lang sh:SPARQL ]

<Dimitris> or sh:native ?

<ericP> nice

Dimitris: no problem with naming

hknublau: generalizing has a benefit, but not sure if it's a strong argument; it's the split that matters

<Dimitris> STRAWPOLL: adjust sh:constraint and make it link only to sh:NodeConstraints, SPARQL constraints will be linked with another propoerty e.g. sh:sparqlConstraint

<hknublau> +1

<Dimitris> +1

<TallTed> +1

<jamsden> +1

<simonstey> +1

<Labra> +1

<ericP> +1


<ericP> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 5 May 2016 Telecon: http://www.w3.org/2016/05/05-shapes-minutes.html
  2. Open ISSUE-160
  3. Close ISSUE-78, dropping sh:abstract
  4. amend property constraint and inverse property constraint to take logical operations sh:and, sh:or, sh:not
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/05/24 15:36:41 $