See also: IRC log
<pano> Hi all, FYI, due to holidays I will most likely not be able to attend the next 2 calls.
<scribe> scribenick: ericP
PROPOSED: Approve minutes of the 9 June 2016 Telecon: http://www.w3.org/2016/06/09-shapes-minutes.html
APPROVED: Approve minutes of the 9 June 2016 Telecon: http://www.w3.org/2016/06/09-shapes-minutes.html
Next meeting: 2016.06.23
ISSUE-168
<trackbot> ISSUE-168 -- How to constrain number of instances of a class in a graph -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/168
Arnaud: is there a use case for issue-168?
<simonstey> +1
kcoyle: not in the doc now
<TallTed> +1
<Arnaud> PROPOSED: Open ISSUE-168
<Dimitris> +1
<kcoyle> +1
<hknublau> +1
<pfps> +1
RESOLUTION: Open ISSUE-168
+?
<simonstey> +1
Arnaud: does ShEx do this?
<pfps> I fixed the pointer to the spec in the meeting agenda (sh:valueShape is now sh:shape and the section number has changed)
ericP: not as such. we're working on a UNIQUE constraint which would work for the stated use cases of exactly one
<trackbot> Notes added to ISSUE-22 Treatment of recursive shape definitions.
<pfps> Just reload the agenda - I fixed the reference
Dimitris: last time we decided that recursion is forbidden and shapes graph with a cycle is invalid
Dimitris: we could take a conservative approach and close the issue on that, or we could say the it's valid but we don't say how recursion works
<Dimitris> https://www.w3.org/2015/12/16-shapes-minutes.html#resolution04
<Dimitris> previous resolution: The starting point for recursion in SHACL is that shapes graphs with dependency loops are invalid, suitable limitations of this will be explored
Arnaud: iirc, we resolved saying "we're not doing recursion" but we left it open hoping someone would propose a solution to recursion
... arthur expressed interest but has left the WG
hknublau: we were waiting for arthur to come up with a proposal, no one else wanted to
... we were hoping for something from ShEx
... there's a page of use cases
... this week I ran into another use case in SHACL itself: path expressions which can recursively include other paths
-> http://shexspec.github.io/semantics/ ShEx semantics
ericP: it's not that hard; just follow Ёвка's rules on what makes a sound shapes graph
Dimitris: because there is no time, we could say that it's not forbidden
Arnaud: last time we thought we could leave it to implementors
hknublau: even if we forbid it, we'd have to do some work
... we'd have to define a recursive shape
... we also have the hasShape function which has some use cases
<TallTed> "Effects of recursion (within shapes, path expressions, etc.) are undefined in SHACL 1."
hknublau: e.g. path expressions which are an RDF Collection
... this adds to the engine's work load
... it needs to do static analysis or it may crash
... we could say it's an invalid shapes graph
... that would allow people to compile to a single SPARQL query
... also allow implementations like mine which support recursion
Arnaud: we're not exactly silent on recursion
Dimitris: there's some mention of recursion in sh:shape and sh:hasShape
Arnaud: our current text isn't REC-ready "the WG will explore..."
... we can change the text to say it's implementation-dependent
... to be "silent", we'd have to remove that section, which would probably leave people wondering
<Arnaud> PROPOSED: Close ISSUE-22, leaving recursion to implementations
<hknublau> +1
<simonstey> +0.5
<Dimitris> +1
-.5
<kcoyle> +1
<pfps> 0
<TallTed> +0.5
<pfps> Does this mean that you, Eric, are willing to convert the ShEx solution to a SHACL solution?
RESOLUTION: Close ISSUE-22, leaving recursion to implementations
<pfps> Having an explicit gap is better than having an error in the spec (like in SPARQL)
<trackbot> issue-128 -- sh:defaultValueType is rdfs:range -- closed
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/128
Arnaud: technically closed, but Dimitris pointed out a problem with the earlier resolution
Dimitris: this problem came an editorial issue raised by peter
... specifically, "we don't allow inference and graphs are immutable"
<pfps> I'm not sure that I was the one pointing out the "immutability" problem.
Dimitris: i propose we remove sh:defaultValueType
hknublau: why do we explicitly have to tie those nodes?
... there's still a predicate which allows us to determine the type at run-time
Dimitris: how do we do that without inference?
hknublau: if the edge were sh:property, i'd just execute it as a sh:PropertyConstraint
Dimitris: we can remove it and meet the explicit type
hknublau: if we force the type to be used everywhere, we'd overload e.g. ORs
... it would be redundent where there's only one possibility
Arnaud: what if we alter the claim that the graph is immutable?
<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0057.html
TallTed: Dimitris's email has an alternative proposal changing the requirement regarding graph immutability
<Dimitris> I would prefer to remove sh:defaultValueType but would be ok with the other options as well
TallTed: if we change it, we have to be explicit about how it's mutable
Arnaud: Dimitris offered 3 proposals: (1) drop sh:defaultValueType, (2) change defn of sh:defaultValueType, (3) change the claim about the immutability
<Dimitris> Peter, if we say something like property constraints are shacl instances of sh:PropertyConstraint or nodes linked with sh:property, would we be fine?
<pfps> Problems arise if the shapes graph is also the data graph.
ericP: if you decide that schemas or data is mutable, you have to decide what happens when you validate data out there on the web
Arnaud: dropping it requires dropping accepted use cases, which were accepted sometimes not without pushback
hknublau: the use cases have changed; we were using it to discriminate between SPARQL constraint and node constraint
Arnaud: if we're not losing anything, let's kill it
hknublau: we'd have to write stuff; currently we change the semantics based on the type.
... we could infer based on whether there's an sh:property
<pfps> It would be possible to say that constraints are those nodes in the shapes graph that are RDFS instances of sh:Constraint in the union of the shapes graph and the SHACL "ontology", which would include things like sh:property rdfs:range sh:<whatever>
Arnaud: do we need a proposal or should we agree on this and leave it up to [the editors] to implement?
<Arnaud> PROPOSED: Change resolution of ISSUE-128, dropping sh:defautValueType
<hknublau> 0
<simonstey> +0
<Dimitris> +0.5
<pfps> +1
<kcoyle> +.5
<TallTed> +1
Dimitris: in general, i agree; it may be the best of the three options
hknublau: i hope this doesn't make rdf:type triples mandatory
Arnaud: good point. in Dimitris's email, he said we could no longer elide type triples
<pfps> A property constraint in the the shapes graph is a node that is an RDFS instance of sh:PropertyConstraint in the graph that is the union of the shapes graph and the SHACL syntax graph.
Dimitris: pfps proposed wording to leave type triples optional
<Arnaud> PROPOSED: Change resolution of ISSUE-128, dropping sh:defautValueType, without mandating the rdf:type triple on constraints
<pfps> +1
<TallTed> +0.5
<hknublau> (constraints and sh:Shapes)
<Dimitris> +1
<hknublau> 0.5
RESOLUTION: Change resolution of ISSUE-128, dropping sh:defautValueType, without mandating the rdf:type triple on constraints
<trackbot> issue-41 -- Using property paths to refer to values/types? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/41
Arnaud: we agreed to add property paths and holger got to work on it
hknublau: there were two changes in the first round:
... .. result format no longer makes sense -- it was oriented towards single triples rather than path expressions. propose just (focus node, path, value)
<pfps> The change from fn,s,prop,o to fn,path,val is a good one - it is more uniform and also makes implementation easier
hknublau: .. instead of differnt props linking, we could have just one property, sh:validator, which points to a Validator object
... it seems to me that single value data is sufficient which would simplify the data model
... vendor's can extend their own extensions to sneak in optimizations specific to their platform
<simonstey> I second pfps' comment
Dimitris: i had an offline discussion with hknublau about syntax about the metamodel and how it addresses path expressions
... we wanted to simplify the user syntax and then fix the metamodel
hknublau: are you referring to replacing inverseProperty with a path?
... the language was originally designed to have paths, there's overlap
... this implies that there are now two syntaxes for the same thing
... we could get rid of inverse property -- the value isn't that great and we can leave it to a path expression
... the specific syntax we'd favor is:...
<hknublau> ex:MyShape sh:property [ sh:predicate|sh:path ... ]
hknublau: this would eliminate a lot of redundancy.
... we could say that a predicate is an IRI and a path is a blank node
<pfps> Why not sh:path IRI|list?
<Dimitris> ericP, I think you got it wrong, sh:property would have either sh:predicate as IRI or sh:path as rdf:List
ericP: i'm reluctant to have the RDF syntax (bnode vs. IRI) affect the interpretation. prefer not caring about bnode vs. IRI for paths with some extra discriminators for paths
pfps: i think having sh:predictate vs. sh:path might be better
... i agree that IRIs vs. bnodes is the obvious approach but agree with ericP that it's fragile
<simonstey> not me
<simonstey> yes
<pfps> No recursion here, I think. Instead this is a way of elminating many needs for recursion.
ericP: we have to think about recursion, e.g. ^foaf:knows/foaf:knows
pfps: recursion isn't coming back to the same node, it's coming back to the same shape
... there are problemantic recursive graphs, but don't show up with finite graphs
... (i.e. not graphs which abide by the RDF semantics)
<trackbot> issue-139 -- Can all constraint properties be applied in all scenarios? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/139
hknublau: i believe there are 3 topics under this issue:
... .. boiler plate in queries
... .. whether all constraints can be applied everwhere
... .. .. whether tools can have hints about what's allowed
... .. change in the meaning of node constraint from a single set to a set of nodes in-scope
... pfps pointed out that most or all of the core components can be expressed with a boilerplate macro inserted into the queries
<pfps> Not.
Arnaud: i thought i saw convergence
hknublau: pfps always wants the boiler plate in the start of the query
... also wants to inject it into the middle, which seems better to me
Dimitris: started this because of nodeConstaaint, inverseNodeConstraint, propertyConstraint, invPropertyconstraint, pathConstraint
... simplifying this could make the macro very short and reduce need for the macro
pfps: i guess the boilerplate solution comes from me
... my impl only uses macro expansion
... but now we have both macro and pre-binding
... if we're going to use macros we shouldn't also have pre-binding
... that's one issue with the current proposal
... on the other side, it's possible to implement all core components without macro expansion as long as you have a fixed version of pre-binding
... there's a YUGE problem with pre-binding
... i was looking back at old SPARQL discussions: there's a problem with substitution in pre-binding
... in some sense, if we're going to make this work, we have to roll our own:
... .. macro expansion
... .. a version of pre-binding defined as initial solution sequences
<pfps> The solution should be EITHER macro expansion or a version of pre-binding defined as initial solution sequences
<pfps> and NOT BOTH
<Dimitris> I agree to use one option
hknublau: not sure why this is related here. (may be, but i don't see it yet)
... i'm happy with a better definition which covers a similar set of use cases
... prob i see is bnodes
Dimitris: we need to pass bnodes to the sh:hasShape function
hknublau: if someone wants to validate a specif bnode and not the whole graph, how can you pass it in?
<pfps> Aah, you are saying that macro expansion doesn't work when the focus node is a blank node. Yeah, that's a problem.
Dimitris: you can't
... the purposes of a bnode is that you can't address it from outside your database. you can't solve this problem
hknublau: is most cases, [you can address bnodes]
<pfps> OK, macro expansion into the source is not adequate, you have to expand in the algebra where blank nodes are permissable.
Dimitris: *some* implementations [support told nodes]
Arnaud: if macro expansion doesn't work for bnodes, that leaves pre-bindings
pfps: macro expansion directly into the SPARQL source is problematic
... could do macro expansion into the SPARQL algebra because that allows bnodes
... but i believe that initial VALUES solution is what we need
... SPARQL algebra name is "solution sequence"
... you may lose some power and certain things become more difficult, but i don't view that as a bad thing
hknublau: as pfps said, there is the option to do that macro expansion on the data structure level
... that's what i always wanted
... start with a SPARQL string; this gets compile into an abstract syntax.
... at that stage, the macro expansion occurs, so you get to utter bnodes
pfps: it appears that are irreconcilable value differences (affecting us for quite some time)
... i don't see those changing so i don't know if progress is possible
Dimitris: what hknublau proposes is substitution but done in a special way which can inject bnodes?
hknublau: in Jena, it's called "syntax transforms"
Dimitris: this could be done with string substituion?
hknublau: this gets more complex, e.g. substituting into a BIND(X AS ?y)
... the spec tries to be general without prescribing how it's supposed to be implemented
<hknublau> (e.g. bound(?preBoundVar) would produce syntax error
<pfps> There are multiple problems with syntax transformations - all related to the use of variable names as variables as opposed to the use of variable names as their value.
FILTER(?o = "ab ?o ")
<pfps> Unfortunately SPARQL has many places where the fact that a bit of syntax is a variable is important, not just in BIND and SELECT but also in MINUS.
pfps: there's quite a lot of discussion on "substitute" which is part of the SPARQL defn which has a description which is open to multiple interpretations
<Arnaud> trackbot, end meeting