RDF Data Shapes Working Group Teleconference

12 Mar 2015


See also: IRC log


kcoyle, ericP, Arnaud, cygri, SimonSteyskal, pfps, hsolbrig, labra, ArthurRyman, Dimitris, hknublau, TallTed


<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

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


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


PROPOSED: Approve requirements 2.12.1, 2.12.2, 2.12.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


<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,,

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


Arnaud: hard on users

<Arnaud> PROPOSED: Approve requirements,,, 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


<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,,, 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


<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


<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,,, 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 $