W3C

RDF Data Shapes Working Group Teleconference

12 Mar 2015

Agenda

See also: IRC log

Attendees

Present
kcoyle, ericP, Arnaud, cygri, SimonSteyskal, pfps, hsolbrig, labra, ArthurRyman, Dimitris, hknublau, TallTed
Regrets
Chair
Arnaud
Scribe
kcoyle

Contents


<hknublau> zakim [IPcaller] is me

Arnaud: I can scribe today

<scribe> scribe: kcoyle

Admin

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

Tracking of Actions and Issues

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

Primer

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

UCR document

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

Requirements

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

SHACL spec

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.

Summary of Action Items

[NEW] 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]
 

Summary of Resolutions

  1. Approve minutes of the 05 March Telecon: http://www.w3.org/2015/03/05-shapes-minutes.html
  2. Close Action 16
  3. close action-12
  4. Approve requirements 2.12.1, 2.12.2, 2.12.3, with 2.12.1 renamed "Select whole graph"
  5. Approve requirements 2.5.9.1, 2.5.9.2, 2.5.9.3, without implying how/where it is addressed
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-03-24 18:15:36 $