17:57:14 <RRSAgent> RRSAgent has joined #shapes
17:57:14 <RRSAgent> logging to http://www.w3.org/2016/04/21-shapes-irc
17:57:16 <trackbot> RRSAgent, make logs rdf-data-shapes
17:57:16 <Zakim> Zakim has joined #shapes
17:57:18 <trackbot> Zakim, this will be SHAPES
17:57:18 <Zakim> ok, trackbot
17:57:19 <trackbot> Meeting: RDF Data Shapes Working Group Teleconference
17:57:19 <trackbot> Date: 21 April 2016
17:57:28 <simonstey> simonstey has joined #shapes
17:59:30 <simonstey_> simonstey_ has joined #shapes
17:59:50 <Arnaud> chair: Arnaud
18:00:00 <Arnaud> agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.04.21
18:00:03 <Arnaud> present+
18:00:15 <Arnaud> regrets: pfps (partial), hsolbrig
18:00:21 <kcoyle> present+
18:00:28 <Arnaud> Arnaud has changed the topic to: agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.04.21
18:01:03 <Arnaud> Arnaud has changed the topic to: Shapes WG: https://www.w3.org/2014/data-shapes Next agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.04.21
18:01:26 <simonstey_> present+
18:02:24 <pfps> present+
18:02:55 <Dimitris> Dimitris has joined #shapes
18:03:35 <jamsden> jamsden has joined #shapes
18:03:45 <Labra> Labra has joined #shapes
18:03:52 <TallTed> TallTed has joined #shapes
18:03:59 <Labra> present+ labra
18:04:47 <Arnaud> present+ labra
18:04:53 <Dimitris> present+
18:04:55 <Labra> ** ok
18:04:57 <Arnaud> present+ jamsden
18:05:36 <TallTed> present+
18:06:18 <hknublau> hknublau has joined #shapes
18:07:04 <ericP> scribenick: ericP
<ericP> topic: Admin
18:07:56 <Arnaud> PROPOSED: Approve minutes of the 14 April 2016 Telecon: http://www.w3.org/2016/04/14-shapes-minutes.html
18:08:02 <markh> markh has joined #shapes
18:08:50 <pfps> look ok to me
18:09:05 <Arnaud> RESOLVED: Approve minutes of the 14 April 2016 Telecon: http://www.w3.org/2016/04/14-shapes-minutes.html
18:10:12 <ericP> topic: Disposal of Raised Issues
18:10:24 <ericP> Arnaud: appreciate pfps keeping track of things
18:10:30 <Arnaud> PROPOSED: Open ISSUE-148, ISSUE-149, ISSUE-150, ISSUE-151
18:10:33 <ericP> ... 149 seems to be editorial so the editors can handle it
18:10:39 <TallTed> +1
18:10:40 <simonstey_> +1
18:10:44 <jamsden> +1
18:10:44 <Labra> +1
18:10:46 <ericP> +1
18:10:49 <kcoyle> +1
18:10:49 <Dimitris> +1
18:11:12 <Arnaud> RESOLVED: Open ISSUE-148, ISSUE-149, ISSUE-150, ISSUE-151
18:12:23 <ericP> topic: ISSUE-101
18:12:29 <Arnaud> issue-101
18:12:29 <trackbot> issue-101 -- use of rdfs:subClassOf for template inheritance -- open
18:12:29 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/101
18:12:29 <jamsden> +1
18:12:34 <Arnaud> PROPOSED: Close ISSUE-101, as no longer relevant.
18:12:38 <hknublau> +1
18:12:41 <TallTed> +1
18:12:42 <ericP> Arnaud: sinnce we don't use subClassOf, let's close it
18:12:44 <ericP> +1
18:12:47 <simonstey_> +1
18:12:49 <Dimitris> +1
18:12:53 <kcoyle> +1
18:12:59 <Labra> +1
18:13:09 <Arnaud> RESOLVED: Close ISSUE-101, as no longer relevant.
18:13:13 <Dimitris> we can also close ISSUE-144, Peter said it can be closed with e current spec
18:13:39 <Arnaud> topic: ISSUE-144
18:13:39 <trackbot> issue-144 -- substitution is sometimes used instead of pre-binding -- open
18:13:39 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/144
18:14:13 <Arnaud> PROPOSED: Close ISSUE-144, addressed in the latest draft
18:14:28 <ericP> dimitris: issue 144 was addressed in latest draft
18:14:29 <hknublau> +1
18:14:31 <Dimitris> +1
18:14:37 <jamsden> +1
18:14:40 <ericP> ... this was acknowledged by pfps who approved it being closed
18:14:44 <kcoyle> +1
18:14:47 <ericP> pfps, you agree?
18:14:54 <simonstey_> +1
18:14:55 <TallTed> +1
18:14:57 <Labra> +1
18:15:20 <ericP> +1
18:15:25 <Arnaud> RESOLVED: Close ISSUE-144, addressed in the latest draft
18:15:39 <pfps> +0.5, I don't see any offending "substitute" any more, but maybe there is some other similar word lurking around
18:16:55 <ericP> topic: ISSUE-125
18:16:10 <Arnaud> issue-125
18:16:10 <trackbot> issue-125 -- sh:NodeConstraint is mentioned but never defined -- open
18:16:10 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/125
18:17:03 <jamsden> +1
18:17:16 <Arnaud> PROPOSED: Close ISSUE-125, as fixed in the latest draft.
18:17:17 <ericP> pfps, do you believe this issue is addressed?
18:17:24 <hknublau> +1
18:17:33 <pfps> it looks as if there is an adequate description of the purpose of node constraint
18:17:36 <pfps> +1
18:17:41 <simonstey_> +1
18:17:45 <TallTed> +1
18:17:47 <Dimitris> +1
18:17:50 <ericP> +1
18:17:56 <kcoyle> +21
18:17:58 <Labra> +1
18:18:19 <Arnaud> RESOLVED: Close ISSUE-125, as fixed in the latest draft.
18:18:33 <ericP> topic: ISSUE-129
18:18:37 <Arnaud> issue-129
18:18:37 <trackbot> issue-129 -- Existential constraints should be consistent -- open
18:18:37 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/129
18:18:55 <ericP> Arnaud: this wasn't just an issue of changing something in the draft
18:19:02 <ericP> ... we've discussed this before without resolution
18:19:07 <ericP> ... there was a push to do nothing
18:19:18 <Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-129:_Existential_constraints
18:19:22 <ericP> ... the votes on the proposals page still reflects that
18:19:50 <Arnaud> PROPOSED: Close ISSUE-129, as is.
18:19:56 <jamsden> +1
18:19:58 <Dimitris> +1
18:19:58 <TallTed> +1
18:19:59 <hknublau> +1
18:20:02 <ericP> +0
18:20:11 <pfps> +1
18:20:31 <kcoyle> +1
18:21:07 <simonstey_> +1
18:20:55 <Arnaud> RESOLVED: Close ISSUE-129, as addressed by the change of sh:notEquals to sh:disjoint
18:21:22 <ericP> topic: ISSUE-57
18:21:23 <ericP> ISSUE-57
18:21:23 <trackbot> ISSUE-57 -- Cardinalities on expressions or groups of triple constraints -- open
18:21:23 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/57
18:22:46 <Labra> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-57:_Group_cardinality
18:25:28 <jamsden> q+
18:25:58 <Arnaud> labra: will add a lot of complexity, willing to give up on this for this version of SHACL
18:26:05 <Arnaud> ericP: sorry to give up on this
18:26:25 <ericP> ericP: optional groups and (A | B | C)+ are common constraints
18:26:32 <Arnaud> ack jamsden
18:27:01 <ericP> jamsden: these could be considered syntactic sugar
18:27:13 <ericP> ... seems good that ShEx adds value on that
18:27:46 <ericP> ... it is possible for us to describe the shapes on SHACL itself using cardinality, and iirc, we've agreed not to do that
18:27:53 <ericP> ... i'm ok with leaving this out for now.
18:27:56 <Arnaud> PROPOSED: Close ISSUE-57, this won't be addressed in this version of SHACL
18:28:09 <jamsden> +1
18:28:09 <ericP> -0.5
18:28:12 <pfps> +0.9999
18:28:17 <Labra> -0.5
18:28:21 <kcoyle> +1
18:28:23 <simonstey_> -0.5
18:28:31 <TallTed> +0.5
18:28:38 <Dimitris> +1
18:28:42 <hknublau> 0.9999
18:29:11 <Arnaud> RESOLVED: Close ISSUE-57, group cardinality won't be addressed in this version of SHACL
18:29:29 <pfps> it would be nice to have this feature, but the pain is likely to be severe
18:29:56 <ericP> topic: ISSUE-68
18:30:07 <ericP> Arnaud: wanted to see where we've gotten on this
18:30:10 <Arnaud> issue-68
18:30:10 <trackbot> issue-68 -- pre-binding not defined in SHACL spec -- open
18:30:10 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/68
18:30:39 <ericP> hknublau: my impression is that we've made progress but it's a matter of voting -- whether pfps can live with it or not
18:30:49 <ericP> ... seems to be about wording and not substance
18:30:57 <ericP> ... i don't see tenchical obstacles
18:31:16 <ericP> Arnaud: i think pfps's last email said "i don't know what i need to implement"
18:31:27 <ericP> ... not sure if that's general or specific to this issue
18:31:32 <pfps> the current definition is still broken - it doesn't conform with how SPARQ works - SPARQL does not evaluate variables in basic graph patterns
18:31:44 <ericP> hknublau: we could add some test cases using SPARQL-based constraints
18:31:54 <jamsden> q+
18:32:07 <ericP> ... hard to judge without specific examples
18:32:13 <Arnaud> ack jamsden
18:32:27 <ericP> Arnaud: given pfps's irc comment, i guess you need to continue working with him on this
18:32:38 <ericP> jamsden: we asked if we had a definition of pre-binding that works
18:32:43 <pfps> test cases are only going to provide point examples - what is the basic thing that is going on? -can't depend on SPARQL implementations because their documentation is criminally deficient here
18:33:00 <ericP> ... not regarding the language of the spec
18:33:32 <ericP> ... (let's not worry about beauty at this point)
18:34:34 <ericP> pfps, do you think there's still a substantial issue, separate from the documentation?
18:34:36 <pfps> as far as I can tell the only thing in this vicinity in SPARQL implementations that could be considered to be interoperable is texual subsitution, but that does not appear to be what is needed here
18:35:27 <pfps> yes, I still don't know what is supposed to happen - someone who knows SPARQL is going to have to take a look at all this - the description and the examples that are supposed to work, and figure out how to describe it
18:36:06 <ericP> Arnaud: hknublau, can you explain this mechanism [for those here]?
18:36:08 <pfps> each time I look at it it takes me a minute or two to knock huge holes in it, but I don't know enough about SPARQL to proclaim that it will work right
18:36:21 <ericP> hknublau: my approach does NOT work on text substitution
18:36:40 <ericP> ... i.e. replacing text in a SPARQL string
18:36:49 <ericP> ... i propose to go a level deeper
18:37:02 <pfps> except, of course, that I do know how textual substitution works, but that is not what appears to be wanted here
18:37:18 <ericP> ... define in terms of the SPARQL query as compiled to SPARQL algebra
18:37:37 <ericP> ... BGPs create bindings with filters limiting them
18:37:55 <pfps> of course, it would probably be possible to rewrite the SPARQL examples in the spec and the template implementations so that textual substitution (plus a way of stating bnodes) would work
18:38:00 <ericP> ... the approach would say that the binding flow that goes from step to step would include these bindings.
18:38:08 <ericP> q+
18:38:18 <ericP> ... we wouldn't limit the implementation approach
18:38:19 <Arnaud> ack ericP
18:41:11 <ericP> ericP: [description of BINDINGS definition in SPARQL Federation]
18:41:46 <ericP> hknublau: doesn't work for BIND which can't e.g. add one to an unbound variable
18:42:53 <ericP> ericP: that's true, with SPARQL Federation, you can't use a BIND directive using a variable that was passed in through the BINDINGS syntax
18:43:45 <ericP> Arnaud: i think that hknublau has the burden of defining the mechansim so that others can understand it
18:44:12 <ericP> ericP: the bottom-up algebra makes this extremely challenging
18:44:23 <ericP> topic: ISSUE-124
18:44:25 <Arnaud> issue-124
18:44:25 <trackbot> issue-124 -- sh:group is only mentioned in examples -- open
18:44:25 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/124
18:44:51 <ericP> Arnaud: pfps pointed out another construct that's not defined
18:45:02 <ericP> ... do the editors agree?
18:45:15 <hknublau> I think it's covered now
18:45:36 <kcoyle> section 3.9 - uses it, is that a definition?
18:45:57 <ericP> Arnaud: hknublau, did you add something which defines this?
18:46:10 <ericP> hknublau: yes, just search for the term. i believe it's there now
18:47:33 <pfps> a paragraph or so was added to 3.9 in response to this issue - given that sh:group doesn't actually do anything this paragraph is probably sufficient
18:48:09 <ericP> ericP: i propose that the explainatory text make it clear that it's an annotation property
18:48:23 <ericP> Arnaud: agreed. note that it doesn't play a role in validation
18:48:33 <ericP> Dimitris: it's in a section about non-validating constraints
18:48:38 <pfps> it would be nice to see whether the whole order/group/whatever passes the "burst-of-laughter" test from someone who does interface design for a living
18:49:15 <Arnaud> PROPOSED: Close ISSUE-124, as addressed by the current draft
18:49:27 <pfps> +0
18:50:10 <ericP> ericP: is "annotationProperty" a defined term and should we have it in P1 of 3.9?
18:50:41 <ericP> hknublau: i wouldn't use it because folks will confuse it with owl:AnnotationProperty
18:50:48 <kcoyle> 6.4 annotations
18:50:50 <ericP> Arnaud: i see it elsewhere
18:50:50 <pfps> sh:annotationProperty has a completely different meaning
18:50:58 <ericP> hknublau: those are annotations on the results
18:51:08 <kcoyle> +1
18:51:15 <Dimitris> +1
18:51:15 <hknublau> +1
18:51:19 <jamsden> +1
18:51:20 <ericP> Arnaud: ok, so we're probably better off not using "annotation property" for this
18:51:23 <ericP> +1
18:51:23 <Labra> +1
18:51:25 <simonstey_> +1
18:51:25 <TallTed> +1
18:51:42 <Arnaud> RESOLVED: Close ISSUE-124, as addressed by the current draft
18:51:59 <ericP> topic: ISSUE-105
18:52:00 <ericP> ISSUE-105
18:52:00 <trackbot> ISSUE-105 -- SHACL SPARQL constraints depend on namespaces in a graph, which is not defined -- open
18:52:00 <trackbot> http://www.w3.org/2014/data-shapes/track/issues/105
18:52:36 <ericP> q+
18:52:45 <Dimitris> q+
18:52:47 <pfps> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-105:_Defined_prefixes
18:52:52 <Arnaud> ack ericP
18:53:43 <Arnaud> ericP: tempting to reuse the prefixes from turtle when embedded in turtle
18:53:53 <Arnaud> ... but that's not RDF
18:54:19 <Arnaud> ... won't work when graph doesn't come from turtle
18:55:01 <pfps> also doesn't work (well) when the graph is cobbled together from different sources
18:55:29 <ericP> ericP: three approaches:
18:55:52 <TallTed> it doesn't matter whether a *graph* is cobbled together from different sources. a *graph* has no prefixes!
18:55:58 <ericP> ... 1 don't share prefix declarations between SPARQL literals in SHACL Turtle doc (do nothing)
18:56:23 <ericP> ... 2 define some pre-declared prefixes for parsing every embedded SPARQL literal
18:57:11 <ericP> ... 3 declare that SHACL is written in Turtle++Prefixes language which defines some API for getting at the prefix decls
18:57:18 <hknublau> We certainly need something like sh:prefix, tools can help users enter them.
18:57:24 <Arnaud> ack Dimitris
18:57:31 <ericP> Dimitris: one more:
18:57:42 <TallTed> how do these approaches align with the proposals?
18:57:47 <ericP> ... special vocabulary to declare the prefixes in the graph
18:58:04 <ericP> ericP: that's kinda slick, actually
18:58:25 <pfps> agreed that the graph doesn't have prefixes, but one might want to say that the prefixes are lifted from the document used to transfer the graph - but this doesn't work well either
18:58:33 <ericP> Arnaud: there are 3 proposals on the proposals page, one acceptable
18:58:57 <hknublau> q+
18:59:11 <ericP> TallTed: we're not talking about graphs. a graph doesn't have prefixes. prefixes only exist in particular serializations
19:00:03 <ericP> Arnaud: i don't think the question is whether prefixes exist in RDF; it's how do we deal with that?
19:00:21 <ericP> TallTed: why is this SHACL's responsibility?
19:00:29 <ericP> ... we don't need another mechanism
19:01:27 <Arnaud> ack hknublau
19:01:43 <ericP> hknublau: propose to close this adding sh:prefix
19:02:01 <ericP> ... the shapes graph would define those prefixes in a machine-readable form
19:02:20 <ericP> ... when you define e.g. an ontology, attach an sh:prefix arc
19:02:37 <ericP> Arnaud: that would be in line with the proposals page
19:03:21 <ericP> hknublau: in our own namespace, we add sh:prefix. in the SHACL vocabulary, we could pre-define a couple prefixes for ease of use
19:03:31 <ericP> ... tools can look for conflicts
19:03:36 <ericP> TallTed: and then?
19:03:55 <ericP> hknublau: invalid schema, we already have this
19:04:23 <pfps> an unquote mechanism would work nicely here - curies in the SPARQL strings in a SHACL document would be expanded as if they were node identifiers - however that opens up another can of worms
19:04:45 <Dimitris> if you import from external sources you may get a clash in a shape IRI as well
19:04:48 <ericP> TallTed: so if i import from two external sources both of which declare the same prefix, i'm sunk?
19:05:28 <ericP> hknublau: yes, worthwhile because users won't use SPARQL if we don't have pre-defined prefixes
19:06:06 <ericP> TallTed: i'd rather use what some SPARQL engines use with pre-canned prefixes
19:06:54 <ericP> ... as soon as external people around the world are defining ontologies and wanting short prefixes
19:07:07 <ericP> ... if an engine wants to extend it, great
19:07:18 <jamsden> q+
19:07:33 <ericP> ... if we can add it sideways, maybe folks can stick their prefixes in an external doc
19:07:48 <pfps> in the end, the only time that this matters is when writing SPARQL parameterized queries - it is astonishing to me that having to add prefix declarations to these queries, which are intellectually challenging to write, would be a severe problm
19:07:57 <Arnaud> ack jamsden
19:08:41 <ericP> jamsden: to me, prefixes have no semantic meaning; they never appear in any graph; they are simply a syntactic shortcut used by various serializations
19:09:14 <ericP> ... each of these formats provides a conflict resolution [i.e. redefinition]
19:09:28 <ericP> Arnaud: the prob is that in SHACL, you can embed SPARQL queries
19:09:45 <ericP> ... from an RDF perspective, these are just strings
19:09:47 <simonstey_> +q
19:10:07 <pfps> ... a reallly nice syntactic shortcut when writing lots of triples, but it's not as if there are going to be lots of triples in the SPARQL parameterized queries needed to implement SHACL templates
19:10:32 <ericP> jamsden: who's writing them and when?
19:10:41 <simonstey_> -q
19:10:42 <ericP> ... it's extension mechanisms, right?
19:11:26 <ericP> jamsden: like embedding C and not having a mechanism to expand macros
19:12:06 <markh> +q
19:12:33 <simonstey_> +q
19:13:09 <Arnaud> ack markh
19:13:11 <ericP> ... there's no context in which to share prefixes in string literals
19:14:01 <ericP> markh: if i have a SHACL doc and I've included a SPARQL query (a string from the point of view of the doc), is it valid for me to include specific prefixes in the SPARQL literals?
19:14:08 <ericP> hknublau, ericP: yes
19:14:22 <simonstey_> -q
19:14:47 <jamsden> q+
19:14:52 <Arnaud> ack jamsden
19:14:53 <TallTed> q+
19:14:54 <ericP> markh: i don't see a huge value in factoring these prefix decls
19:15:03 <pfps> sure - the SPARQL string can define prefixes
19:15:42 <ericP> jamsden: but you have to say them over and over because there's no context for sharing them
19:15:57 <ericP> Arnaud: i'm seeing a growing do-nothing camp
19:16:13 <Arnaud> ack TallTed
19:16:30 <ericP> ... what's the scope of the sh:prefix proposal
19:16:57 <ericP> TallTed: sh:import to import your prefixes file.
19:17:57 <ericP> ... this would have to be processed by the "SHACL parser"
19:18:10 <ericP> hknublau: we have the concept of a shapes graph
19:18:20 <ericP> ... the construction of a shapes graph is outside our control
19:18:32 <ericP> ... it's the responsibility of the application to assemble it
19:19:06 <ericP> ... if someone wants to combose a shacl doc, they have control over the owl:imports, sh:prefix, etc
19:19:47 <ericP> Arnaud: there's an sh:prefix proposal on the proposals page
19:20:19 <ericP> ... it would build a mapping table which is available for the SPARQL query parser
19:20:35 <ericP> hknublau: i've implemented this over and over, i see no practical problem
19:20:41 <ericP> ... no one's forced to use it
19:20:57 <ericP> Arnaud: sure, btu the question is "do you require implementations to support it"
19:21:56 <jamsden> What if the embedded extension isn't sparql, doesn't use XML style prefixes, but has some other import mechanism that needs to be supported e.g., packages?
19:22:28 <Arnaud> STRAWPOLL: a) do nothing - no prefix definition mechanism to SHACL, b) define some prefix definition mechanism
19:22:51 <ericP> a:+1 b:-.5
19:22:52 <jamsden> a:+1, b:-.9
19:22:56 <hknublau> a: -1 b: +1
19:22:57 <TallTed> a: +1, b: -0.9
19:23:04 <kcoyle> a: +1 b:-.75
19:23:04 <Dimitris> a) -1, b) +1
19:23:07 <Labra> a: +1, b: -0.5
19:23:10 <simonstey_> a: +1 b: -0.9
19:23:15 <pfps> a: +1, b: -0
19:23:31 <markh> a: +1, b: -0.5
19:24:20 <ericP> Arnaud: why do you -1 on nothing?
19:24:29 <simonstey_> +q
19:24:30 <ericP> Dimitris: because it's a pain to write constraints without prefixes
19:24:37 <ericP> ... i know this first-hand
19:25:26 <markh> +q
19:25:28 <ericP> Arnaud: what do you say to markh's point; practically speaking, you've got a SPARQL query you want to cut and paste which needs those prefixes
19:25:33 <pfps> actually it's a pain to write constraints, period - the added pain to put prefix declarations at the beginning of each of the is so minor in comparison
19:25:33 <Arnaud> ack simonstey_
19:25:40 <ericP> hknublau: but any SPARQL tool already had pre-defined SPARQL prefixes
19:26:07 <pfps> it's like we are saying that c programs get a set of predefined includes
19:26:15 <ericP> simonstey_: i agree with jamsden other extension mechanism like packages wouldn't work with sh:prefix
19:26:39 <hknublau> For JavaScript people can add another property such as shjs:requireLibrary
19:26:52 <ericP> ... if you use a serialization format like Turtle, can't you use the prefixes from Turtle?
19:26:52 <jamsden> but there's no semantics for applying prefixes in any syntax to object string literals
19:27:00 <Arnaud> ack markh
19:27:08 <ericP> ... maybe that's too handwave-y, btu that would be a way to deal with that
19:27:19 <TallTed> +1 pfps re `predefined C includes`
19:27:40 <ericP> markh: the impls that i use commonly provide pre-defined prefixes but they're embedded in the query.
19:28:01 <ericP> ... they're part of the query; the user can edit them with the query
19:28:11 <ericP> ... this encourages good practice
19:28:14 <simonstey_> +q
19:28:35 <Arnaud> ack simonstey_
19:28:51 <ericP> Arnaud: so we don't have concensus around doing nothing; we don't have any objections to continuing the investigation
19:29:28 <markh> +q
19:29:40 <ericP> simonstey_: i agree with markh's; we define some default prefixes like rdf, rdfs, xsd
19:29:52 <ericP> ericP: i thought that was in contradiction with markh's observation
19:30:01 <hknublau> Nobody is forced to use sh:prefix. I am disappointed about the votes that try to prohibit an optional feature.
19:30:01 <ericP> simonstey_: we could be explicit about it
19:30:24 <Arnaud> ack markh
19:30:27 <ericP> Arnaud: the 2nd proposal says that, if we agree on the first one, we can have a bunch of pre-defined ones
<ericP> ... but in fact it is not dependent on 1st proposal
19:30:37 <ericP> markh: i don't think that's what i was proposing
19:30:55 <ericP> ... in my mind, i'd expect to see the prefix decls in every SPARQL query
19:31:27 <pfps> actually the second proposal says to have a bunch of pre-defined prefixes (rdf rdfs ...) and if there is a way of setting up prefixes then this can be done using that mechanism instead of just by fiat
19:31:58 <Arnaud> trackbot, end meeting
19:31:58 <trackbot> Zakim, list attendees
19:31:58 <Zakim> As of this point the attendees have been Arnaud, kcoyle, simonstey, pfps, labra, Dimitris, jamsden, TallTed, ericP, markh, hknublau
19:32:06 <trackbot> RRSAgent, please draft minutes
19:32:06 <RRSAgent> I have made the request to generate http://www.w3.org/2016/04/21-shapes-minutes.html trackbot
19:32:07 <trackbot> RRSAgent, bye
19:32:07 <RRSAgent> I see no action items