See also: IRC log
<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
+1
<kcoyle> +1
<hknublau> +1
<Labra> +1
RESOLUTION: Put F2F6 on hold indefinitely, we'll have ad hoc calls instead
<Dimitris> +1
<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
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
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
+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
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
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