See also: IRC log
hello?
<Labra> +present labra
<hsolbrig> what is the webex password?
<scribe> scribenick: pfps
<Arnaud> PROPOSED: Approve minutes of the 11 February 2016 Telecon: http://www.w3.org/2016/02/11-shapes-minutes.html
<aryman> excellent scribing!
minutes looked OK
RESOLUTION: Approve minutes of the 11 February 2016 Telecon: http://www.w3.org/2016/02/11-shapes-minutes.html
arnaud: next meeting next week
arnaud: I added pointers to last discussion of issues
... there are some issues that have not had any discussion
... we should try to look at them
ISSUE-68
<trackbot> ISSUE-68 -- pre-binding not defined in SHACL spec -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/68
arnaud: the last time this was discussed was in July 2015
... holger sent out an email with a proposal
holger: I had conversations on this with Andy Seabourne (sp?)
... There needs to be something done - there is no formal definition of pre-binding in SPARQL
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-68:_Definition_of_Pre-Binding
holger: initial bindings are supported in implementations
... I don't see how to avoid something like pre-bindings
<ericP> TallTed, does virtuoso support pre-binding?
holger: andy suggested to use an algebra specification, using the operators there to get the effect of pre-bindings
eric: you could use bindings for this if you didn't rely on told b-nodes
... if you don't use b-nodes then you could get by
pfps: I don't think that this is the issue - this is not getting things in from the outside, it is for internal communication
holger: we agreed not to support SPARQL endpoints
arnaud: so this has not yet been addressed, there is a proposal
pfps: we do depend on this quite a bit as the internal need it
arnaud: it's not that the problem is not important, it's that it is not controversial
pfps: the current stuff is very hand-waving, and this needs to be nailed down sometime
... it is possible that something in the SPARQL algebra works, I don't know whether ToMultiSet is the right thing
arnaud: if that is the right thing then that could be put into the spec
holger: OK
arthur: this is only an issue for the SPARQL binding
holger: right
arthur: this came up in SPARQL update, where they use SELECT clauses to get at blank node
... it seems to me that the nodes that we need to identify are accessible in this manner
... if you wanted to implement this on a remote endpoint then you could use this method
holger: this would work sometimes
arnaud: holger will update the draft and we can see if the result is acceptable
issue-92
<trackbot> issue-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/92
arnaud: there has been discussion on this topic
... we may not be able to get to the bottom of this today, but let's have an update
arthur: our discussion had to do with meta-model aspects
... we have come to the conclusion to focus on the user-visible terms
... I have just rewritten the text to eliminate non-visible stuff
http://w3c.github.io/data-shapes/shacl/#PartitionConstraint
eric: we have some amendmants to consider to match our needs
arthur: what's the status
eric: we are hoping to match this construct
... we have nestings of expressions to consider
... we have arbitrary expressivity of groups,
... we want to make nesting of expressions simple
arnaud: that's encouraging
holger: if we add this we also need to think about qualified cardinality expressions
arnaud: at some point we should think about removing things that are not needed
arthur: peter - on the proposal page you voted -1
<aryman> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-92:_additive_repeated_properties
pfps: at some point I will have to look at it again
arnaud: I don't know if looking at this next week is doable
issue-47
<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
arnaud: we discussed this last week
... in some cases it is not possible to access the shapes graph
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-47:_.24shapesGraph
arnaud: there is a new proposal
pfps: my action in this area was to come up with a counter proposal but I have been to busy to do so
<ericP> PROPOSED: Close ISSUE-47, stating that: Not all execution environments can support $shapesGraph access, just like not all platforms have to support SPARQL extensions in general. However, for those environments that do, the spec should define $shapesGraph access and clarify that it is an optional feature. Implementations that do not support it may report a Failure. For the core built-ins, these implementations may use alternative approaches such as custom SPARQL code generators but that is left as an implementation detail.
<hknublau> +1
<aryman> +1
0
<jamsden> +1
<ericP> 0
<hsolbrig> 0
<Labra> 0
<kcoyle> 0
pfps: why all the 0's people will use this feature
RESOLUTION: Close ISSUE-47, stating that: Not all execution environments can support $shapesGraph access, just like not all platforms have to support SPARQL extensions in general. However, for those environments that do, the spec should define $shapesGraph access and clarify that it is an optional feature. Implementations that do not support it may report a Failure. For the core built-ins, these implementations may use alternative approaches such as custom SPARQL code generators but that is left as an implementation detail.
<ericP> issue-121
<trackbot> issue-121 -- Should the SHACL owl:Ontology include the # character -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/121
issue-121
<trackbot> issue-121 -- Should the SHACL owl:Ontology include the # character -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/121
arnaud: there is a disagreement as to whether the # should be included
... there is little guidance to be found elsewhere
arthur: the best practice document doesn't bear on this issue, as we have already agreed to use # URIs
... the document talks about whether to use # URIs or / URIs
... W3C vocabularies use # URIs, mostly, which allows for a single document
... the document says to use either a # or a slash at the end of the namespace names
... # URIs end up being simpler
<Arnaud> STRAWPOLL: Should the SHACL owl:Ontology include the # character? Y/N
arthur: the question is whether to include the # in the name of the ontology
holger: I agree that the OWL ontology should be the base URI and that this should not have #
... I asked Richard Cy... what the trend is, he says that the ontology does not not have #
arthur: let's not have two URIs
holger: W3C no longer uses that practice
arthur: I don't care
<Arnaud> STRAWPOLL: Should the SHACL owl:Ontology include the # character? Y/N
<Zakim> ericP, you wanted to say that it depends on constellation size
eric: the decision on # or / depended on the size of the ontology, / for large
<ericP> Y
? - go with the flow
<hknublau> N
<hsolbrig> 0 (do not care)
<kcoyle> Y
eric: it seems to me that it is easier of the prefix and the ontology are the same
<Labra> Y (0,5)
<Labra> N (0)
<aryman> dropped off
holger: if we include # then we also need to include the imports statement
<aryman> please repeat the straw poll question
<Arnaud> STRAWPOLL: Should the SHACL owl:Ontology include the # character? Y/N
<aryman> Y
<jamsden> 0
arnaud: more Y than N
<Arnaud> PROPOSED: Close ISSUE-121, the SHACL owl:Ontology include the # character
<aryman> +1
<hknublau> -0.9
<Labra> +0.5
0
<ericP> +1
<hsolbrig> 0
<kcoyle> +1
jamsden: I ran into this when building the OSLC vocabulary
... i liked not having the # in the vocabulary name and having # at the beginning of the local names
arthur: for short URLs you can use relative URLs or CURIES
... is # allowed at the beginning of a CURIE?
RESOLUTION: Close ISSUE-121, the SHACL owl:Ontology include the # character
issue-99
<trackbot> issue-99 -- special treatment of rdfs:Resource and rdf:List in sh:valueClass (and possibly elsewhere) -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/99
arnaud: there was a proposal on the proposals page on this issue
... I would like to get more eyes on this
holger: this is about whether sh:valueClass should work for lists that are untyped and other special cases
<Arnaud> pfps: completely disagree, why treating lists any differently? what's so special about them?
pfps: there is nothing special about lists
... we have decided not to use inferencing
holger: but Turtle doesn't put type statements on lists
<Arnaud> pfps: this is the result of not doing inferencing
<Arnaud> pfps: this is just adding to the ugliness
arthur: what is the semantics of the collection construct
eric: just a bunch of triple - not the type triple
arthur: I think that this indicates a special treatment of lists
pfps: then the way to go is to have special syntax in SHACL for lsits
<aryman> sounds promising
eric: agreed
<aryman> what do you propose?
pfps: i guess it is on me
<scribe> ACTION: pfps to proposal for lists [recorded in http://www.w3.org/2016/02/18-shapes-minutes.html#action01]
<trackbot> Created ACTION-35 - Proposal for lists [on Peter Patel-Schneider - due 2016-02-25].
issue-105
<trackbot> issue-105 -- SHACL SPARQL constraints depend on namespaces in a graph, which is not defined -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/105
arnaud: peter raised this issue
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-105:_Defined_prefixes
holger: I have a proposal on the proposals page
pfps: this is a major change to how SHACL works
... SHACL used to take RDF graphs and now it takes something else
arthur: I am both worried about and sympathetic to this proposal
... within files there are prefixes, most processors remember these prefixes
... holger is saying that we should take advantage of this
... if the SHACL processor uses a prefix that is not in the RDF graph document
... but if there is a prefix in the document then that can be used
holger: I don't think that this is changing much
... this can be done in a pre-processing stage
... we could also have a triple linking
pfps: this requires a 1-1 correspondence between SHACL inputs and documents, which is a bad idea
holger: if prefixes were part of RDF then that would be the best solution
... at a certain stage you have to have assumptions on how the data was processed
... if there are conflicting prefixes then the engine can throw an error
arthur: in OSLC we have triples for the prefixes
... when you print a graph you want to use CURIEs so we put triples in the file to give preferred prefixes
<aryman> # Triples needed for code generation (to be deleted prior to final publication) <#process-prefix> a <http://open-services.net/ns/core#PrefixDefinition> ; <http://open-services.net/ns/core#prefix> "sh" ; <http://open-services.net/ns/core#prefixBase> sh: .
arthur: the advantage here is that they only have to be done once and we are in an RDF world
... any prefix in the SPARQL would override this
<Zakim> pfps, you wanted to argue against pre-defined prefixes
pfps: I actually don't have any particular problem with special syntax that injects prefix declarations into the generated SPARQL
...
<Arnaud> trackbot, end meeting