RDF Data Shapes Working Group Teleconference

04 Feb 2016


See also: IRC log


pfps, Arnaud, simonstey, Dimitris, aryman, hknublau, ericP, labra, TallTed, kcoyle


<pfps> I see that there have been responses from the WG to questions in the public mailing list. This should be discussed today.

<scribe> scribenick: ericP


<Arnaud> PROPOSED: Approve minutes of the 28 January 2016 Telecon: http://www.w3.org/2016/01/28-shapes-minutes.html

<pfps> minutes looked fine

<aryman> +1

RESOLUTION: Approve minutes of the 28 January 2016 Telecon: http://www.w3.org/2016/01/28-shapes-minutes.html


Arnaud: jose and i have conflict end of March
... Doodle indicates March 15-17 is the only candidate
... though several people marked it if-need-be
... we can accept this or look later into April

<pfps> There will be times during 15-17 March when I will have to be in different meetings. I do not know how many hours this will consume.

Arnaud: we can aim for another meeting in June
... which leaves the summer off

<kcoyle> march seems fine

<Zakim> pfps, you wanted to talk about the public mailing list at the end of the admin section

<simonstey> +1 for march 15-17

Arnaud: is there a set of issues that require a f2f issues to resolve?

<pfps> recursive shapes??

Arnaud: holger asserted that there's one major issue left - issue 23
... having f2f's is not manditory.

<hknublau> I am not keen on F2F meetings unless needed (time zone is killing me).

Arnaud: f2fs are a way to make more progress

aryman: i wonder if instead of a F2F meeting we could have extended meetings with required prep
... it might not interest everyone

<hknublau> +1 to longer regular meetings

Arnaud: reserving peoples' time is difficult
... i'm afraid it will drag on
... that said, i'm here to help, not to force people to meet

hknublau: my impression is that we have all the open issues behind us

Arnaud: we could say "after the weekly call, i want to discuss X; those interersted please linger"

kcoyle: it seems that during the weekly calls, we discuss stuff without completing them

Arnaud: apart from the end of the call, in most weekly calls, if we don't resolve something it's because folks need more time
... f2fs don't help much in that regard
... it's more to do with extracting bigger bandwidth for a few days
... i'm hearing several folks propose that we don't schedule a F2F

aryman: i like the idea of using the regular call to go deeper into specific issues

<simonstey> +30 minutes after the regular call for certain topics seems reasonable

aryman: easier to leverage this time slot than to schedule others

<pfps> fine by me to not schedule the march F2F

Arnaud: so do we cancel the next F2F?

<Arnaud> PROPOSED: Put F2F6 on hold indefinitely, we'll have ad hoc calls instead

<pfps> +1

<aryman> +1

<simonstey> +1


<kcoyle> +1

<hknublau> +1

<Labra> +1

RESOLUTION: Put F2F6 on hold indefinitely, we'll have ad hoc calls instead

<Dimitris> +1

DC shapes meeting

<Arnaud> http://www.meetup.com/semweb-31/events/228584769/

Arnaud: Dave McComb and Dan Carey giving a DC meeting talk "SHACL Up with Shapely RDF" about their implementation
... if they have one, maybe there are others

hknublau: i saw a discussion on a ruby mailing list

Arnaud: we could have a wiki page about impls

<hknublau> https://github.com/ruby-rdf/rdf/issues/268

aryman: it would be great if the whole WG attended because apparently he will say exactly what SHACL is ;-)

Arnaud: i'll put a section on the homepage for links to impls.
... at CR time, we can reach out to those folks

Handling of comments sent to the public mailing list

pfps: we've flub everything respect to comments and we're continuing
... if you're going to reply to a q on the public mailing list, even trivial, you should tell the WG what you're going to do

Arnaud: i don't know that W3C has a policy

ericP: i think in SPARQL, we could answer non-controversial q's
... i don't think anyone asked non-controversial q's on the RDF public list

Arnaud: i propose a policy where you speak for yourself. if you know the answer, go ahead and help
... if the issue is controversial, answer with care and/or bring to the WG for discussion

pfps: though this mesage appears to not be substantive, it is
... robert is owed a WG response
... it's substantive, the first, all the things that indicate that the WG should be responding with care

Arnaud: doesn't have to be so rigid. we can follow the list and if we disagree, we can respond with "not discussed yet; follow-up pending"

pfps: if it works; it works. if not, it can fail very badly
... controversial hides in lots of places
... the public-rdf-shapes list is the way for the public to address the WG
... when we go to the end, we need to go through a very formal process

Arnaud: pfps is referring to "disposition of comments"
... we used to have a phase called "last call" where folks have to say whether the commenter was satisfied with the response to their comment
... it's a way to make sure that W3C hasn't closed itself from the rest of the world

aryman: i saw that note and no one replied for three days, and since it was about an edit i'd just made, ithoguht i was qualified to respond

ericP: in RDF and SPARQL, I'd negotiate a wording change (or none) and when the commenter was satisfied, take it to the WG

Arnaud: i think pfps's issue is in the case where there is no change

kcoyle: if we want to get comments, we have to respond or folks will get discouraged
... we need someone to at least say that we've seen the comment and that we're thinking about it

Arnaud: from that point of view, i was happy to see that aryman responded

kcoyle: but within ourselves, we haven't agreed on a mechanism for responding to comments

<kcoyle> I nominate Arthur for that

Arnaud: does anyone want to volunteer to respond?

<pfps> I'm happy to provide acks as necessary.

<aryman> @kcoyle what have I done to offend you?

<simonstey> which again will cost us some precious wg time

Arnaud: if you think it's controversial, you can say "good question; i've raised an issue"
... i think 99% of the cases will be fine
... of course anyone can respond if they see an email sitting there

pfps: i'll wait for the next train to jump off the tracks

ISSUE-117: non-classes as classes

Arnaud: we might have resolved 117 given more time -- resuming conversation
... there was an issue with how the spec says that the object sh:class MUST be classes
... propose to make this MUST a SHOULD

hknublau: we should lift the requirement that has sh:property

<pfps> Holger appears to be arguing against SHOULD

hknublau: the cases where the range is supposed to be an rdfs:Class or an rdfs:Property shoule be turned into a warning

<hknublau> no, should is good

Arnaud: just saying "SHOULD" doesn't say how implementors admonish users

<Arnaud> PROPOSED: Close ISSUE-117, changing MUST to SHOULD in: Section 3.1.1 sh:class "The values of sh:class must be classes (instances of rdfs:Class)." and changing MUST to SHOULD where we say that sh:predicate must be rdf:Property

pfps: i think that's too strong

<simonstey> http://w3c.github.io/data-shapes/shacl/#template-arguments

<aryman> neither the shapes graph nor the data graph may have a triple like ex:loves a rdf:Property

<aryman> say "is expected to be" or "is normally"

aryman: i think that pfps is that there's really no requirement that a validator GET the ontology or that a data graph contain the ontology

<pfps> there is no need for an ontology in SHACL validation

aryman: SHOULD is misleading
... we're not doing inferencing

<TallTed> { :John :Mary :loves } ?

aryman: i think we should SHOULDn't say "should"

<simonstey> is assumed to be a property?

aryman: we could say "the object of the sh:property is typically a property"

hknublau: i can live with that
... all we need is an RDFS range on sh:property to know that the object is a property

pfps: hknublau is talking about a particular use of SHACL
... there are others, e.g. describing the output of web processes, which don't expect anything about rdf:Properties

Arnaud: if we can't agree, we can remove it altogether

hknublau: so what about the range statement?

aryman: this is near the vocab discussion around issue-95
... we're discussing what sh:Class or sh:predicate means
... it's appropriate for us to add a range to say that the object of sh:predicate is a property
... unless we were expecting a reasoner to do something with it, it has no impact
... we're free to put that sort of information in the vocabulary

Arnaud: we have a section on the relationship between SHACL and RDFS
... can we add a bit of text here?

aryman: we've already said that we don't rely on a reasoner
... so whatever we put in the vocabulary will have no effect
... the whole point of issue-23 was to figure out what reasoning we do
... we count on 0 inferencing

<simonstey> +1 to rdfs:range

pfps: literals and blank nodes can be properties
... nothing prevents them from being properties

hknublau: let's not get into philosophy

pfps: if you declare it, you're making a strong statement about the future

<Arnaud> PROPOSED: Close ISSUE-117, dropping from Section 3.1.1 sh:class the sentence "The values of sh:class must be classes (instances of rdfs:Class)." and any assertions that sh:predicate must be an rdfs:Property

aryman: there's benefit either way

hknublau: with TBC, we'll add triples

<pfps> close enough

<aryman> +1

<hknublau> +1

<simonstey> +1


<Dimitris> +1

<Labra> +1

<TallTed> +0.5

<pfps> +1

<kcoyle> +1

RESOLUTION: Close ISSUE-117, dropping from Section 3.1.1 sh:class the sentence "The values of sh:class must be classes (instances of rdfs:Class)." and any assertions that sh:predicate must be an rdfs:Property

ISSUE-95: Template Simplifications

Arnaud: hknublau raised an issue about how we manage the vocab and turtle files

hknublau: as i was editing the turtle files -- up to six files:
... .. RDFS vocab distinct from shapes files
... .. shapes which constriant for SHACL-based tools how these shapes can be composed
... .. extension mechanism
... .. SPARQL-related extension

Arnaud: i don't think we want to overshoot.

aryman: i did reply:
... any term in our vocab should be in a vocab file
... for constraints, we have built-in constraints and we have extensions
... we could still stick the sparql defns in another file, importing the basing turtle file
... shapes go into a separate file
... all i'm suggesting is that the sparql implementations go in a separate file as they're not normative; just an example implementation

hknublau, i'd want to implement them in SHACL

hknublau: i'd want to implement them in SHACL
... people who are using shacl typically need to owl:import soemthing
... if every implementiaton has their own SPARQL queries, that's not going to be helpful
... i think this requires digging into the details

Arnaud: i'd like the two editors to come up with some options for us to choose from

hknublau: three files is complicated but not so bad

aryman: we have a normative core vocab
... we have another vocab file which inlcludes SPARQL defns
... if TQ wants to improve upon them, they can import the core vocab

Arnaud: if there are points of contention (between hknublau and aryman), bring them to the group for resolution
... otherwise, on the issue, i understand you're working out the details of holding a meeting

ISSUE-92: additive repeated properties

Arnaud: i believe this is the most important issue left so we need to make progress on this
... this is important to the shex folks
... we need to discuss how we address this

<Arnaud> ericP: ShEx has experimented with aryman's proposed greedy algorithm and that meets our most important needs

<Arnaud> ... this could be extended later to something more exhaustive

Arnaud: so you've experimented with aryman's greedy algorithm and you're satisfied with it?

ericP: yes, we can extend in the future if needed

Arnaud: what do we need to do to make progress?

aryman: we just need other impls, like hknublau's

hknublau: i'm ok with this
... we just need a precise definition

Arnaud: it seems this is more pallatible to most people

aryman: i can give this a precise definiton
... you can think of this as a generalized definition of QCRs.

Arnaud: if you can draft the section in the spec, that'd be great

pfps: the syntax appears to be rather byzantine
... it probably indicates that our syntax needs refactoring in any case
... it would be ugly if we address this without a general syntax fefactoring
... now aryman's issue @@ may entail refactoring
... it would be silly to hide QCRs inside partition just because they're available in partition
... adding it to our already baroque syntax makes this too expensive
... it would be nice to see a worked out proposal
... folks will have to implement this; it would be nice to make it easier

Arnaud: if we can get a draft from aryman, we can take that as the first step

pfps: this doesn't appear to add expressive power

<hknublau> I think we should drop QCRs if we have partitions. Too redundant, and QCRs are not all that common IMHO.

pfps: i.e. subsequent conjoints need a conjunction and a negation

aryman: i think the QCRs complicated the vocab

<pfps> It appears to me that (partition (qcc min1 max1 r1) ... (qcc minn maxn rn)) is the same as

aryman: partition allows us to just include min/max/constraint
... we don't have to introduce new vocab terms for the same concepts

<pfps> (and (qcc min1 max1 r1) ... (qcc minn maxn (and (not r1) ... (not rn-1) rn))

<Arnaud> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 28 January 2016 Telecon: http://www.w3.org/2016/01/28-shapes-minutes.html
  2. Put F2F6 on hold indefinitely, we'll have ad hoc calls instead
  3. Close ISSUE-117, dropping from Section 3.1.1 sh:class the sentence "The values of sh:class must be classes (instances of rdfs:Class)." and any assertions that sh:predicate must be an rdfs:Property
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/02/11 21:18:36 $