See also: IRC log
<hknublau> zakim [IPcaller] is me
Arnaud: I can scribe today
<scribe> scribe: kcoyle
Arnaud: Minutes from last meeting
<pfps> minutes looked fine to me
PROPOSED: Approve minutes of the 05 March Telecon: http://www.w3.org/2015/03/05-shapes-minutes.html
RESOLUTION: Approve minutes of the 05 March Telecon: http://www.w3.org/2015/03/05-shapes-minutes.html
Check doodle poll for next F2F
RESOLUTION: Close Action 16
Harold's actions
<hsolbrig> https://www.w3.org/2014/data-shapes/wiki/Requirement/Concise_Language
proposed alternative to the requirement using semantic media wiki
<TallTed> doodle poll link -- http://doodle.com/4u8626tmapfxv6iw
<hsolbrig> [[page]]
<hsolbrig> {{:page}}
<hsolbrig> {{page}}
<hsolbrig> Templage:page
{{ is transclusion
<ericP> {{page}} (without ':') is like load-and-eval
scribe: Semantic wiki templates -- includes description and votes
hsolbrig: includes RDF feed; facts about requirement
Arnaud: it seems a bit late to put everything into this format
hsolbrig: is there a value to convert it? fairly easy to do, except for page structure 1. do we need this for requirements? 2. are there other areas where we could use this?
Arnaud: editors working on working draft for wiki page
<pfps> As far as I can tell, there are not going to be many future changes to the requirements
ericP: my guess is that the editors will get a stronger vote than the rest of us; as per Harold's statement, editors get a notice when major changes are made
Arnaud: how would we update the whole doc?
hsolbrig: we'd take page with requirements and cruft together perl/py or something and turn it into pages -> export into xml; estimates 4 hours of work
... i'm volunteering "conditionally"
ArthurRyman: this is all very cool; there was discussion before that there was a dependency - what was that?
pfps: the problem before was that when we added new requirements the numbers all changed
ArthurRyman: original motivation no longer exists?
pfps: effect of number changes can be reduced by way change is done
ArthurRyman: inclined to let hsolbrig go ahead and do this
hsolbrig: will affect this transformation in 'low priority time'
Arnaud: hsolbrig's offer accepted
<Arnaud> http://www.w3.org/2015/02/17-shapes-minutes.html#action02
<scribe> ACTION: 11 to revise based on 'his ideas' - Story 17 (which is in limbo) [recorded in http://www.w3.org/2015/03/12-shapes-minutes.html#action01]
<trackbot> Error finding '11'. You can review and register nicknames at <http://www.w3.org/2014/data-shapes/track/users>.
open action 12 - merge 17 and 18 (stories) - we removed 18 last week
<Arnaud> action-11
<trackbot> action-11 -- Harold Solbrig to Revise based on his ideas; we'll review and accept/or not -- due 2015-02-24 -- OPEN
<trackbot> http://www.w3.org/2014/data-shapes/track/actions/11
<Arnaud> action-12
<trackbot> action-12 -- Harold Solbrig to Merge 17 and 18 -- due 2015-02-24 -- OPEN
<trackbot> http://www.w3.org/2014/data-shapes/track/actions/12
Arnaud: inclined to close these two
pfps: hsolbrig was going to try to rescue story 17 - if not, it should be removed
hsolbrig: will look at over the next few days; if no rescue, goes away
Arnaud: let's keep action-11 and close action-12 then
RESOLUTION: close action-12
Arnaud: created by hknublau, edit by ericP ; work has been done on spec. are we close to publishing primer?
... discuss: what will it take to publish as first public working draft? with related disclaimers
<Arnaud> http://w3c.github.io/data-shapes/data-shapes-primer/
ericP: status of the draft: good enough to go to the world. completed tasks from f2f
... issue of templates: no classes templates addresses objections from Jose, and removed templates
Arnaud: there is a requirement for atemplate mechanism
cygri: clarify - what happens after the 1st public w draft? do revisions just follow wg decisions? or are there style edits?
ericP: no plan to make changes other than wg decisions
cygri: i'm uncomfortable about overlap in the two documents (primer and spec)
... and editors have different opinions on some issues; we may be chasing down inconsistencies between the documents
<cygri> Arnaud, the primer usually looks very different from this
Arnaud: that's a common situation in most working groups - both a primer and spec that need to be kept in sync
... primer is usually an informative doc
... the spec is definitive
pfps: i share richard's concerns. in my experience, primers tend to be generated later; i thought that the group thought we should do a spec first, leave the primer for later
<hknublau> +1
<TallTed> +1 primer should usually be written *from* the spec, not in parallel nor before
<Dimitris> +1
<hsolbrig> +0
Arnaud: seems to be a feeling that spec should be done first, do not publish primer until later
<pfps> I think that we should be trying to get a FPWD of the UCR document out.
<SimonSteyskal> +0
<cygri> +1 to pfps, get UC&R out of the door ASAP
<pfps> I'm also concerned that the primer and the spec diverge so significantly.
<Labra> +q
<ArthurRyman> +
Labra: primer is an opportunity to see what are the common functions in the language;
<pfps> My view is that getting a primer out early is a good way of deluding ourselves that there is agreement.
Labra: do not delay it too much
ArthurRyman: the primer still reads too much like a spec; this one has tables of definitions
<SimonSteyskal> +q
Arnaud: first doc should have been published in December
<pfps> I think that the UCR document is ready for FPWD as it stands.
SimonSteyskal: we can have a publishable by next Thursday as long as editors can update the document in the future
<pfps> The whole idea of WDs is that they are changed later. This is especially true for FPWDs.
SimonSteyskal: remove 'to do done' refs and link to requirements
<pfps> The bar for FPWD is "acceptable", and here the enemy of "acceptable" is "good".
Arnaud: drafts always could be edited
cygri: is there a date for proposed new stories should be finished and added?
<pfps> New stories and requirements can be added after FPWD.
Arnaud: will look at on a case by case basis
PROPOSED: Approve requirements 2.12.1, 2.12.2, 2.12.3
2.12.1-.3
pfps: approval of requirements problem: not clear what all of the requirements mean, so need to be able to open them later on
Arnaud: yes, we should approve, but they can be clarified later
... also, does approval of requirement mean has to be in main spec? we can define as a group
<Zakim> ericP, you wanted to say that it would be more clear if we understood what was in the core (profile)
<pfps> That said, I'm happy with the proposal
<pfps> ... on the table
ericP: wondering if it would be more productive if we knew whether requirements were in the core?
Arnaud: we can't go back to decide which ones are core; maybe someone can take a crack at this later
... asume that when we approve a requirement we mean we will try to address it in some way, yet to be determined
<pfps> +1
<cygri> +1
<TallTed> +1
<Labra> +1
<hsolbrig> +0
ArthurRyman: unclear what global selection means
... relates to what a shape is before 'global' makes sense
pfps: the spec describes this
<cygri> I think this is exactly the same as the “global constraints” requirement.
pfps: global constraints are sparql queries that are run across the entire graph (tho' not necessarily sparql)
... shape is evaluated on every node of the graph
ArthurRyman: constraint applies to entire graph
hknublau: hard to distinguish this from global constraint requirement that we have elsewhere
<TallTed> there's nothing wrong with having a redundant requirement.... which sounds like the concern
hknublau: we can skip global selection, since redundant
<TallTed> it helps with clarity of understanding/explanation
ericP: is a selection of the whole graph
ArthurRyman: don't like how global selection is worded
TallTed: change to "select by graph"
<cygri> Rename “Global selection” to “Select whole graph”?
<TallTed> +1 with or without renaming :-)
<Labra> +1 for Select whole graph
<Arnaud> PROPOSAL: Approve requirements 2.12.1, 2.12.2, 2.12.3, with 2.12.1 renamed "Select whole graph"
<SimonSteyskal> +1
<pfps> +1
<Labra> +1
+1
<ArthurRyman> +1
<ericP> +1
<hknublau> +1
<cygri> +1
<hsolbrig> +0
<Dimitris> +1
RESOLUTION: Approve requirements 2.12.1, 2.12.2, 2.12.3, with 2.12.1 renamed "Select whole graph"
<hknublau> I will rename it now.
PROPOSED: Approve requirements 2.5.9.1, 2.5.9.2, 2.5.9.3
ericP: objection was because this shouldn't be core
pfps: clarifying hknublau's clarification... 2.5.9 has to be part of high level language
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Requirements#Datatype_Property_Facets
<Labra> +q
Labra: I agree with this not being part of core language
... but if we aren't specifying core, then this is ok
Arnaud: not everyone agrees on what is 'high level' or 'core'
... some high level could be extensions
... we can split the spec into pieces, but every piece hurts iinteroperability
<cygri> We can have SHACL-LABRA, SHACL-ERICP, SHACL-CYGRI, …
Arnaud: hard on users
<Arnaud> PROPOSED: Approve requirements 2.5.9.1, 2.5.9.2, 2.5.9.3, without implying how/where it is addressed
<hknublau> +1
ArthurRyman: can we defer core to later? first identify requirements, discuss core when we get further toward implementation
<SimonSteyskal> +1
+1
<Labra> +1
<ArthurRyman> +1
<hknublau> +1
<pfps> +1 - someone should put in a breadcrumb in the requirements to this effect
<cygri> Profiles are already approved, so I don’t see the issue here.
<cygri> +1
<ericP> +1
<TallTed> +1
<Dimitris> +1
<hsolbrig> +1 (although i'm ambivalent on RE and String length --- it format vs. semantics)
RESOLUTION: Approve requirements 2.5.9.1, 2.5.9.2, 2.5.9.3, without implying how/where it is addressed
scribe: other requirements will be carried forward
Arnaud: disagreement on the role of sparql; from required to optional to ??
... only pfps is voting for sparql only
... other questions seem to have to do with methodology rather than end product
<pfps> I was not initially in favour of using SPARQL, it is just that it seems to me that SPARQL is the only technology that covers enough of the requirements.
Arnaud: hknublau starts from sparql as bottom-up approach, but we could also accommodate other things
... others say sparql is an implementation detail
... others say: we should have top-down, from abstract definition, high-level declarative language for constraints, then define extensions
<pfps> A high-level vocabulary is not adequate by itself - there needs to be some way of saying what this vocabulary means.
Arnaud: these are two approaches, the end product could be the same, but it's how we get there
<Labra> +q
hsolbrig: the bottom-up approach bothers me because we're saying that we have language that does what we need
... so we will develop a syntactic sugar on top of it; but i'm not looking for a high-level sparql;
... i have an interest in starting with what we want to do
Labra: i agree with Arnaud 's description of situation; we should focus on high level language that we need
... i have not problem with there being an implementation that uses sparql
... i don't know how to develop tests because we have no high level language definition
... i prefer a high-level declarative language
<hknublau> Jose, the high-level language already exists, no?
ArthurRyman: We do want to build on w3c specs that work here
<hknublau> I already implemented some test cases against that.
ArthurRyman: however, there are areas that we want to support that go beyond simple sparql - may require a series of sparql queries
<Labra> hknublau: where is it in the spec?
ArthurRyman: don't limit to what a single sparql query can do
<hknublau> sh:minCount etc.
Arnaud: ?? protocol uses sparql to define semantics
<Arnaud> Graph Store Protocol
pfps: i'm sympathetic with the top-down approach, but the only bottom I see is sparql
... could someone come up with an alternative to sparql?
<hsolbrig> I use RDFLIB
<ericP> pfps, didn't you come up with a formal definition?
<Labra> +q
Arnaud: if we have a formal definition then people could do various implementations
<hsolbrig> Are we talking specify in SPARQL or implment in SPARQL
<hsolbrig> (I use RDFLIB to implement)
Labra: for formal definition need first main constructs
Arnaud: straw polls
<Arnaud> STRAWPOLL: SHACL shall define a set of higher-level language constructs that addresses the most common use cases without requiring SPARQL support
<pfps> I had a partial semantic definition. I like it, but it can't do quite a few of the requirements that the working group has approved or are under consideration, at least without major changes
<ArthurRyman> +1
<cygri> +1
<pfps> ??
<hsolbrig> +1
<hknublau> +1
+1
<Labra> +1
<Dimitris> +1
<ericP> +1
pfps: is this all of sparql, or part of sparql, or equivalent of sparql?
<SimonSteyskal> +1
<pfps> +0 because I don't know that the high-level language is going to look like
Arnaud: question is: what do we mean by sparql support?
<pfps> I'm happy with a non-SPARQL syntax that doesn't cover all of SPARQL
<pfps> The question here is how the high-level language gets defined
<Arnaud> STRAWPOLL: SHACL shall include a SPARQL based extension mechanism for addressing more complex cases
ArthurRyman: do I need a sparql engine? if part of high level lang is not: take a sparql query and...
<hknublau> +1
<ArthurRyman> +1
<ericP> +1
+0
<SimonSteyskal> +1
<Labra> +1
<Dimitris> +1
<pfps> -1 - if someone comes up with a different technology for SHACL then by all means let's dump SPARQL
<ArthurRyman> SPARQL should be a supported extension mechanism
<ArthurRyman> Javascript is also an interesting extension language
<cygri> +1 (assuming it means: a mechanism for extending the high-level language)
pfps: if someone came up with a new language we are all happy with, i'd say: let's dump sparql because it is too big and too complex
<TallTed> +1
ericP: we have functionality that we need to describe... e.g. minOccur, a new executive model would be "use xpath"
pfps: or javascript
ericP: what is it was written in algebraic form?
<hsolbrig> -1
pfps: worried that sparql is required, even if new solution comes later
<ArthurRyman> there are possible alternatives, e.g. represent triples as RDF/XML and use XQuery - but that's not very attractive
<pfps> -0 as SPARQL is the only path I see going forward
hsolbrig: makes sense to specify what needs to be done using sparql; but an extension mechanism could mean that shacl does everything that sparql does and more
<hknublau> +q
hsolbrig: you could implement with a subset of sparql
... non-mandatory extension mechansim would be ok
<pfps> but then where are the boundaries? SPARQL exists, and appears to be a reasonable choice for constraints, so we should use it
Arnaud: point is whether extension is mandatory
... similar to HTML - although allows other scripting, etc., everyone uses javascript. spec does not require these extensions
<ericP> pfps, there are lots of graph APIs for e.g. Jena, Sesame, Virtuoso, etc, which provide useful functionality for extensions
??: is it shall? does it require sparql?
<pfps> eric: but do any of work well for SHACL?
hknublau: all of the features in the requirements are backed by user stories; the subset will converge with sparql anyway
ArthurRyman: could hsolbrig elaborate by writing user story for something sparql cannot do? functionality, performance, scaling?
<ericP> pfps, i implemented shex with the ubiquitous triplesMatching function (you find that in most APIs)
hsolbrig: No, not what I said; i anticipate that nearly everything in shacl can be implemented in sparql
... but there is a lot that you can do in sparql that i don't need in shacl; so i'm looking for a simplified view
<ericP> pfps, there's still a lot of logic in the code that works with the results of triplesMatching, but mapping that logic to SPARQL is pretty complex and opaque
<Labra> +q
hsolbrig: i use RDFLIB, which has worked well;
<Arnaud> STRAWPOLL: a) The main specification shall include everything and a set of profiles shall define appropriate subsets b) The main specification shall include the higher-level language constructs only and the rest shall be defined in add-ons (answer with a:x b:y)
<pfps> eric: so you are programming in some language that uses a very low-level primitives
<SimonSteyskal> a:+1 b:+0
<cygri> a: +1 b: -1
<pfps> a:+1 b:-1
<hknublau> a: +1 b: -1
<ericP> a:-1 b:+1
<hsolbrig> a: +1 b:-1
<ArthurRyman> a: -1 b: +1
a: +0 b: +1
<Dimitris> a: +1 b: -1
<Labra> a: -1, b: +1
<cygri> We should have a look at the charter again…
<hknublau> @cygri, agreed. b violates the charter.
<Arnaud> trackbot, end meeting
<cygri> hknublau, I’m not sure that it does. But the charter says that the “extensibility mechanism” is Recommendation Track.