See also: IRC log
<scribe> scribenick: ericP
<Arnaud> PROPOSED: Approve minutes of the 9 July Telecon: http://www.w3.org/2015/07/09-shapes-minutes.html
RESOLUTION: Approve minutes of the 9 July Telecon: http://www.w3.org/2015/07/09-shapes-minutes.html
<pfps> minutes looked OK to me
Arnaud: discussing new issues 73-76
hknublau: is support for large data instances part of issue 76?
pfps: SPARQL endpoints often restrict the number of results they return
... this is not [intended to be part of] the requirement
... should reword to "This should work if the data graph is very large."
... could explicity that some SPARQL enpoints only return 1K results so any solution which requires 1B results isn't a solution
Arnaud: is that specific to implementations on top of SPARQL?
<Dimitris> +q
pfps: it's specific to remote data.
... one can always dump the entire dataset, except that for many endpoints, you are "result-limited".
... could restate this caveat as "it is not acceptable to have to dump the entire database."
Arnaud: that still sounds like a requirement
pfps: i'm happy to drop this line
aryman: we need to keep the functional and the non-functional separate
... you're saying that the presence of BNodes keeps you from making two+ queries
<simonstey> +
<Arnaud> PROPOSED: Open ISSUE-73-76
<simonstey> +1
<Dimitris> +1
<kcoyle> +1
<TallTed> +1
+1
<Labra> +1
<hsolbrig> +1
<aryman> +1
RESOLUTION: Open ISSUE-73-76
<pfps> The point of the last sentence of ISSUE-74 was to prevent a methodology of issuing a single SPARQL query that transfers the entire graph or dataset and then works on it locally. I struck that sentence to permit progress.
Arnaud: we now have 35 open issues
... we may have a couple that don't really matter
... we haven't managed to close one issue/call (/week)
... We have some issues that pfps wanted to resolve before FPWD
<trackbot> ISSUE-66 -- SHACL spec ill-founded due to non-convergence on data loops -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/66
Arnaud: we want readers to understand what the WG is up to
... we discussed this issue's title
... the link has an example which pfps says is undecidable
pfps: my pref is to say that recursion is illegal
hknublau: i sent a link to my latest proposal
<simonstey> ref guide: http://w3c.github.io/data-shapes/shacl-ref/
hknublau: the ref guide includes my latest SPARQL queries
... this implements aryman's proposal that recursion is only permitted on valueShape
Arnaud: the WG isn't in favor of prohibitiung recursion
... so we need a recursion solution that addresses some minimal needs
aryman: this solution has well-defined semantics
... the algorithm:
... .. start with a node/shape
... .. put that pair on a stack
... .. evaluate local constraints
... .. evaluate recursive shapes
... .. revisiting the same node/shape pair returns true
pfps: this isn't shacl
... aryman's impl strategy says "when you get back to the same place, say 'yes'"
... that works in this example
... (this doesn't)
Arnaud: we had tree ways:
... .. max recursion
... .. true recursion
... .. mixed
... it seemed folks wanted true recursion, but we were interested in the mixed approach
aryman: when you say it doesn't work for SHACL, that presupposes @@1
... if we say that that general shape structure has a defined answer
... if we want to expand this, we can
... iovka's semantics appear to address this, but we'll know more when she returns
<pfps> iovka may have a well-defined semantics for negative recursion, but that's not the end of the story - is this semantics reasonable? is this semantics implementable?
Arnaud: it seems we need to agree on the solution or a way to get to the solution
... some folks say "give me examples"
... pfps says "i want a general solution"
<simonstey> allowing recursion only through valueshape removes potential problems that not/disjunction might produce.. so I'm fine with that approach
<hsolbrig> @simonstey - where else would it be possible to do recursion?
aryman: is it the case that the candidate FPWD will allow unrestricted negation/disjunction of shapes?
Arnaud: would prohibiting disjunction and negation address your issue?
pfps: you're asking me to throw out something i consider useful to define something i consider useless
<simonstey> @hsolbrig true that..
<Dimitris> +q
hknublau: i think we should try to be pragmatic here
... we can talk about theory and soundness and whatnot, but in the end folks want the language to get work done.
hsolbrig: i'm interested in SHACL to reallize UML class/relation semantics as RDF
... UML abounds with recursion, from dog-ears to complex evaluation to make sure that a recursion terminates.
<pfps> UML self-reference does not necessarily translate into SHACL self-reference of shapes
Arnaud: are you convinced by pfps's assertion that you can work-around these needs?
pfps: UML should not translate into SHACL shapes
hsolbrig: so do we have an example of how it's done right?
pfps: i'll type a general notion in a sec...
<pfps> a UML definition of a "box" B that has a property back to the box translates into a type property to B and then a constraint that says that the value for B's are B's - B is *not* a shape here
pfps: UML classes aren't shapes, they're classes
<simonstey> @hsolbrig http://stackoverflow.com/questions/14015305/recursion-in-ocl
<pfps> using SHACL shapes for UML classes ends up with *totally* incorrect behaviour - in the example above an isolated shape would be recognized as B
<Arnaud> ack pf`
Dimitris: pretty much agree with peter. can we hear use cases where the work-arounds don't work?
pfps: i'm saying that's not been working so far
Dimitris: sure, in email, but maybe a wiki will help
Arnaud: can we ask folks who are interested in recursion to post some examples into a wiki page?
... they pfps can say how else it could work
<pfps> recursive shapes *do* add extra expressive power - Polentoni is an example - but are there any use cases that need to do this
aryman: pfps's point is that if you attach a type arc to a shape, you don't need another way to recognize those shapes
<pfps> the point *for UML* is that UML data *is* done that way -
aryman: that works if your data has these type args, but we don't want to require type arcs
... ericP and I have been using the example where the same node is used for different purposes
<pfps> I want to see a worked-out example of this FOAF story
<Dimitris> *with proper scoping and filtering this can be done*
<pfps> agree with Dimitris
<hsolbrig> UML identifies the classifier, but it makes no assertions about instances including a reference to or name of the classifier.
aryman: e.g. a contact database may require certain fields, but all instances of foaf:Person don't require those fields
<hsolbrig> You *could* assert that, in order to be a valid UML instance a type must be present, but that isn't our situation.
<pfps> I *protest* - this argument has come up in the past and has been rebutted
<hsolbrig> reference?
ericP: requiring that nodes are annotated with every type arc to capture the purposes they might use for, we are over-constraining the use of these semweb objects
pfps: if you say "i need recursive shape recognition to capture UML", it's not UML
ted: there are certain things that people need to do and maybe they're "UML" and maybe that's not exactly the right label but it's important that they do what they need to do
<pfps> when people say "UML" they should be doing UML
Arnaud: we shouldn't get hung up on whether this is true UML or not
aryman: do you think sh:valueShape is useful?
pfps: with out recursion, you can always macro-expand valueShape?
aryman: sure, but as an authoring tool, is it useful?
pfps: ok if they're treating it as a macro-expansion
aryman: it keeps folks from having to repeat themselves
... it's not problematic in certain siutations.
... even if the shapes graph is recursive, it will still terminate unless the data is circular
... so do you think the defn [we proposed] is correct?
... is it acceptable if the spec has well-founded semantics?
pfps: iovka's spec is "interesting" [in a pajorative sense]
... as soon as you get to negated recursion, you have to do a lot of work to figure out the situation.
... it's different from anything anyone's done.
... should we go with it?
... someone has to go with a deep investigation before we buy it.
hknublau: i have the impression that this whole discussion is an academic dance
<pfps> The question is who in the working group Holger is talking about.
hknublau: some folks have a specific solution strategy, macro expansion, but would rather throw the requirements under the bus than change the impl strategy
Arnaud: we'll doc use cases in the wiki; pfps and Dimitris will show how they can be done without recursion
<trackbot> ISSUE-62 -- Selection or filtering by arbitrary expressions and shapes -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/62
<hknublau> http://w3c.github.io/data-shapes/shacl/index-2015-07-13.html#scopesAndFilters
<hknublau> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jun/0036.html
Arnaud: we have a proposal from hknublau.
... we discussed this before.
hknublau: the above link (with the image correction) is my current proposal
... this was an attempt to integrate pfps's scoping mechanism
... i took pfps's shapeScope or scopeShape and crated filterShape
... this provides a clean mechanism to defined global properties
... e.g. dublin core saying that every utterance of a property must be a string or in some language
<Dimitris> +q
<Dimitris> cannot hear
<Dimitris> will rejoin
Dimitris: i agree with holger's approach
<Dimitris> http://www.w3.org/2014/data-shapes/track/issues/49
Dimitris: concearned with issue 49
<pfps> this looks promising - I'm not sure if it goes quite far enough - I would like to be able select objects of a property, not just subjects
Dimitris: if we allow SPARQL templates, we have to decide if the filtering will be evaluated when we have a value shape
... if we permit it, i'm not sure how SPARQL templates will work
<aryman> +1 for the proposal to allow more flexible scoping
Arnaud: none of this is new. it's been on the list before.
pfps: i think this goes in the right direction
... i'd like the ability to select all those nodes that are values from a property.
<aryman> @pfps - could you select values using an inverse property?
Arnaud: back to your issue 49 issue, can we close 62 with the proposal and see about 49 pater?
Dimitris: sure
hknublau: i agree that 49 can be handled seperately
... scopes have to be evaluatable either way, so they can be used as a filter
<Arnaud> PROPOSED: Close ISSUE-62 adopting Holger's proposal, drafted in http://w3c.github.io/data-shapes/shacl/index-2015-07-13.html#scopesAndFilters
<hknublau> +1
<simonstey> +1
<aryman> +1
<Dimitris> +1
<kcoyle> +1
<pfps> +0.9, as I would also like property values
<Labra> 0
0
<TallTed> +1
<hsolbrig> 0
RESOLUTION: Close ISSUE-62 adopting Holger's proposal, drafted in http://w3c.github.io/data-shapes/shacl/index-2015-07-13.html#scopesAndFilters
<trackbot> issue-47 -- Can SPARQL-based constraints access the shape graph, and how? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/47
pfps: having recursion is independent of whether access to the shapes graph is needed when you're performing validation.
<pfps> I don't see how the *need* for recursion has anything to do with access to the shape graph when doing validation
aryman: suppose we have a non-RDF representation, like ShExC or some other non-RDF representation, we'd not even be contemplating providing access to the shapes graph
... what is access to the shapes graph required for recursion
hknublau: we need it for closed shapes, lists of arguments, templates...
<pfps> I see no *need* for access to the shape graph when validating shapes at all - it is only a particular implementation that requires this access
hknublau: when we want to mix SPARQL with javascript, we need a callback to the server
<Dimitris> +q
hknublau: i'm not against supporting a subset of SHACL that works against remote SPARQL endpoints.
... we need a profile
... given that some folks want to work with remote endpoints and others have a richer framework
Dimitris: how is javascript related? it' can't see the graph
pfps: i'm hearing a claim that access to the data graph is necessary, which i don't believe is true.
hknublau: things like accessing an RDF list of arguments.
<pfps> q_
hknublau: it's clearly the fasted approach to have the data graph and the shapes graph in named graphs
pfps: i'm not hearing an answer
aryman: we've accepted as a requirement that the core language be implemented in languages other than SPARQL.
... every statement seems to be that it's easier, not that it's required.
... if it's required, we've lost language neutrality
<pfps> there is a big difference between something that is necessary and something that is elegant or nice - if access to the shape graph is necessary for SHACL (particularly the core) then we need to have this access, if this is only elegant or nice then it is not necessary and may not be desirable
hknublau: we could have an outer loop that does an SPO query, but maybe we want it more integrated
<pfps> what is supposed to be worked out off-line?
<Dimitris> +q
<pfps> ericP: in ShEx there are both lists and recursion, but there is no access to the shapes graph during ShEx execution
Arnaud: it would be odd if the core of the impl required a switch that not everyone implemented
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Main_Page#Useful_Working_Group_Wiki_pages_and_documents
<hknublau> @ericP ShEx doesn’t have templates, and this was my use case.
<hknublau> (Arguments such as lists of operands in AND and OR)
<pfps> I'm still not sure what is supposed to be worked out
Dimitris: we need distinguish three things:
... .. specification
... .. access inside core
... access outside core
<hknublau> -q
hknublau: i'm happy to start that wiki page
... but i see many months going by [before FPWD]
pfps: i see lots of "see ShEx" in this new document
... ShEx is an example of how to implement something very SHACL-like without access to the shapes graph
<Arnaud> trackbot, end meeting