See also: IRC log
<Arnaud> hi all
<Arnaud> I'm trying to get connected
<Arnaud> I'm running on a crippled env so, not sure how this is going to work out
It's Brussels, Arnaud. You can't connect from Brussels
<Arnaud> especially when you don't have internet installed yet :)
<ericP> PROPOSED: Approve minutes of the 25 August 2016 Telecon: http://www.w3.org/2016/08/25-shapes-minutes
<hknublau> +1
<pano> +1
<simonstey> +1
RESOLUTION: Approve minutes of the 25 August 2016 Telecon: http://www.w3.org/2016/08/25-shapes-minutes
+1
<Dimitris> +1
<ericP> DONE: Dimitris to send a thank you to pfps, linking https://www.w3.org/2014/data-shapes/wiki/Public_Comments#Peter.27s_Email_2016-08-16
<ericP> no regrets for next meeting
<ericP> in last week's exciting espisode, we conclused that SHACL does not treat sh:Violation differently from other severities to determine if a node validates against a shape
<scribe> scribenick:kcoyle
<Dimitris> in section 3: validation definition
eric: question - is there any place in spec where there is idea of declaring whether node validations against shape
<Dimitris> no, it is standalone
eric: asking Dimitris re: nesting of errors: Dimitris prefers least severe "win" when validating; kcoyld and Arnaud prefer most severe;
... other options is to base on nesting position
<Arnaud> no, Arnaud prefers outermost wins
Dimitris: prefer that outer shape overrides all; this is simplest solutionl
<Arnaud> but I can live with the other way around
eric: simplist is that inner defines it - don't have to pass parameters or filter erros
Dimitris: when severity defined in nesting would not be allowed; if severity defined then nesting position not taken into account
eric: inner shape wins; can validate without awareness of cntext of outer severity
Dimitris: nesting is subjective; simple approach should win
eric: what you do gets more complicated as you nest down
<simonstey> it's def. better than ignoring the sev. of the nested shape(s)
eric: smplest approach - severity defined by innermost shape
<simonstey> what if there's no "inner most" shape?
<ericP> PROPOSED: the severity of violations of nested shapes is determined only by the severity of the constraint in which the violation occured
<Dimitris> recursion is undefined anyway in SHACL
<simonstey> +1
eric: much of this depends on recursion
+0
<Dimitris> +.05
<Dimitris> +.5
holger: what about a case with A or B? and both are validated?
eric: explaining a nested constraint
hknublau: I would prefer not to have any relationship between these. Whatever is defined locally is used
Dimitris: if I have a nested shape and both fail, if inner shape has two severities
hknublau: system will have to evaluate all of them to find out what the severity is
Dimitris: neither solution is perfect
<simonstey> that was also my understanding
<hknublau> +1
hknublau: this is compatible with current SPARQL queries
<marqh> +1
<pano> +1
RESOLUTION: the severity of violations of nested shapes is determined only by the severity of the constraint in which the violation occured
<Arnaud_crippled> holger is right
<Arnaud_crippled> issue-150 can be closed
<ericP> PROPOSED: close issue-150
<hknublau> +1
<Dimitris> +1
<marqh> +1
_1
RESOLUTION: close issue-150 based on previous two resolutions
<simonstey> +1
<pano> +1
+1
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
hknublau: introduction: raised by Peter; for SPARQL extension; is curently unspecified
... should sparql queries reference prexies that are used somewhere else?
... SELECT ... WEHRE... rdfs:label...
... conservative is either use whole URI or always include prefix in sparql query - thus always self-contained
... other approaches: have mechanism in graph holding shapes to declare prefixes globallyt (H's preference)
... means don't need to repeat prefixes
<hknublau> <http://namespace#> sh:prefix "ex"
hknublau: examples of namespace declaration
engine would use those prefix declarations into query
hknublau: would put it in OWL ontology - will be there when OWL import used
ericP: you are making assertions about someone else namespace?
hknublau: most files already have namespace declarations; usually clear one-to-one mapping
TallTed: in my experience collisions happen - multiple prefixes for same namespace are used
... i can see this as an import mechansim, but not sure how to make this work
... enviornmental setting could be specific, but on large scale more problem than solution
hknublau: in case of dcterms/dct can declare both prefixes for same namespace
... problem lies where same prefix used for different namespaces
<ericP> Turtle:
<ericP> PREFIX ex: <http://a.example/>
<ericP> <> sh:globalPrefixDeclList ([sh:prefix "ex"; sh:ns <http://a.example/>]).
<ericP> <S1> sh:constraint "ASK { ex:...}" .
ericP: either way we have to duplicate prefixes both in turtle prolog and in an rdf structure
... this is a variation of holger's proposal - made global list
... not stick assertions onto nodes where describing someone else's namespace
TallTed: no, this doesn't assuage my concern; point is to provide shorthand for sparql
... when you have multiply declared prefix, whether or not same namespace, sparql 1.1 kicks back an error
... anyone who makes conformant sparql queries (including prefixes) runs risk of error
marqh: don't see extra benefit; might write this in a tool that makes complicated shapes, but not if doing quick by hand
... feels like this comes at a price
hknublau: benefit is for people writing turtle files by hand; believe majority of rdf developers are writing turtle by hand
... in a tool, you could extend prefixes; or insert them in the beginning
... believe users want to see only minimal
TallTed: the tool can hide prefix declarations; turtle file that results must include jprefix declarations
... even most common namespaces
hknublau: prefixes of turtle files are unrelated
TallTed: prefix declaration does not survive serialization
... but if prefix not there, it's an error
hknublau: when someone writes a shape, they know what graph they are in
TallTed: but reuse... then what happens?
Dimitris: see Ted's point, just re-use parameters, which would minimize need to re-write sparql queries
simonstey: see both points; implementation-wise see Holger's point
... but also see Ted's because easier to implement but can cause problems
... more in favor of an error-proof solution;
pano: same as simon, but leaning towards what Holger is saying - it should also be easy to write sparql
... queries and use prefixes
... if you want to re-use shapes need to be careful
TallTed: the shapes that you produce will not be reusable because not conformant
<ericP> STRAWPOLL: a: some prefix mechanism, b: no no no!
<ericP> STRAWPOLL: a: some prefix mechanism, b: no prefix mechanism
<hknublau> a) +1 b) -1
Dimitris: This is another which has precedence issue
simonstey: can we say - you have to write correct sparql queries in your shacl constraints including prefix declarations
... you have to specify respective namespaces; you might want to consider using a tool to
... automatically include this in all sparql queries
... this is where tools improve user experience
<TallTed> for example... four namespaces are in fact associated with `dc:`, in the wild -- http://prefix.cc/dc
<marqh> a) 0 b) +1
hknublau: there is a safe mechanism because the sparql queries are embeded in objects
... tools could use standard and local prefixes
TallTed: what's "standard"?
<TallTed> http://prefix.cc/sh
<TallTed> has two wild namespaces
a) -1 b) +1
<simonstey> a) 0 b) 1
<TallTed> a: -0.9 b: +0.9
<pano> a) +0.1 b) -0.1
<Dimitris> a) 0 b) 0.5
hknublau: prefix declaration extends other prefix declaration
TallTed: concatenates sh:prefix with sh:query... or something like that;
... there might be various levels, subpredicates like system, user, etc.
hknublau: I will write proposal for next week
ISSUE-137
<trackbot> ISSUE-137 -- Missing constraint for language tag -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/137
<ericP> sh:hasLanguageTag
<ericP> kcoyle: it's not just that it has *a* language tag, or even a specific language tag, but also unique language tag
ericP: uniqueLang does #3 of kcoyle's three
... 'hasLanguageTag" - can it use the more complex language tags?
<Dimitris> that is sh:datatype rdf:langString
<hknublau> For that we already have sh:datatype rdf:langString
<Dimitris> I think that a sh:languageTagIn ( "en" "fr" ... ) is more useful
I like that, Dimitris
ericP: there's class and type includes to see if it's in a particular set
... analogous to what we do already with typing
hknublau: don't hhave classIn anymore; using or
<TallTed> need to check... 1. every value has unique langtag; 2. there's a value for every langtag in list; 3. there are no values with langtags not in this list; 4. there is at least one value with a langtag in list; 5. ?
ericP: sh:in is an enumerative property; value must be in list
good list Ted. Maybe we need to put this in wiki
ericP: this is a matrix
<ericP> STRAWPOLL: a: pursue Bart's language tags, b: drop for now
a: +1 b: -.5
<TallTed> "none of" , "at least one of" , "at least all of" , "no more than" ; "uniqueness" is distinct
<hknublau> a) -0.5 b) +1 (easily handled by extension mechanism)
<simonstey> a) 0.8 b) 0.1
<Dimitris> a) +.5 b) 0
<pano> a)0 b)0
<TallTed> a: +0.5 b: -0.5
<ericP> ACTION: kcoyle to create some wiki documentation exploring the requirements [recorded in http://www.w3.org/2016/09/01-shapes-minutes.html#action01]
<trackbot> Created ACTION-41 - Create some wiki documentation exploring the requirements [on Karen Coyle - due 2016-09-08].
ISSUE-71
<trackbot> ISSUE-71 -- SHACL Endpoint Protocol -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/71
hknublau: similar to what sparql endpoints provide - a web proptocal that would define how people can
send a complete shapes graph to a database and shacl would return result
scribe: willing to withdraw it
ericP: using something like this in shex; can be used to evaluate sets you don't want to move around
... i'm going to test this node against this remote shape
... it's simple - there's a shape, a node,
kcoyle: is this the library case? going against remote vocabularies?
hknublau: yes, same use case
kcoyle: is this part of the standard? or separate?
... could this be a related standard?
<hknublau> Without a standard, each database vendor will invent their own protocol.
ericP: a way in shex to say that this is external
<ericP> ACTION: kcoyle to document library use cases for (remote) validation protocol [recorded in http://www.w3.org/2016/09/01-shapes-minutes.html#action02]
<trackbot> Created ACTION-42 - Document library use cases for (remote) validation protocol [on Karen Coyle - due 2016-09-08].
kcoyle: opposes closing this without more investigation of use cases
<ericP> ADJOURNED
<Arnaud_crippled> trackbot, end meeting