See also: IRC log
<Arnaud> webex doesn't work
<Arnaud> we'll use a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239
<Arnaud> beware, check the call-in info: we are using a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239
<simonstey> have you joined webex alreadxy?
<Arnaud> hi simon
<Arnaud> no webex today
<Arnaud> we are using a different teleconference bridge: Passcode: 406-4254 Tel: 888-426-6840/215-861-6239 More access numbers: https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239
<simonstey> is there a way to dial in via voip/sip?
<Arnaud> I'm afraid not
<pfps> the access code is not recognized
<simonstey> oh..
<pfps> because you need the passcode
<aryman> hi, the access code works for me
<Arnaud> pfps, did you try what I just put on irc?
<hknublau> I am using the Aussie toll-free number via Skype. No idea yet if Skype charges me for that…
<Arnaud> webex isn't working
<Arnaud> hknublau, it shouldn't
<aryman> this worked for me: 406-4254 Tel: 888-426-6840
<hsolbrig> Skype isn't charging for the US toll free
<pfps> You need to enter the passcode when it asks for the access code.
<Arnaud> simonstey, can you try skype?
<Arnaud> you should be able to have a toll free number from https://www.teleconference.att.com/servlet/glbAccess?process=1&accessCode=4064254&accessNumber=2158616239
<Arnaud> you don't have a phone at all?
<simonstey> I'm joining via skype
<Arnaud> sounds good
<pfps> You need to enter the "passcode" when it asks for the "access code".
<simonstey> and after that?
<Arnaud> you should be on
<pfps> I edited the meeting page to get rid of the webex information.
<simonstey> can you hear me?
<hknublau> no
<pfps> no
<simonstey> ok mom
<simonstey> ive joined
<simonstey> trying to get the mic working
<simonstey> yes
<simonstey> skype tells me my mic is working
<simonstey> ;)
<iovka> scribenick: iovka
Arnaud: we should go closer to a first working draft
... one way to go is to scale down the document to something on which we all agree
<hknublau> lol
pfps: I sent an e-mail with the problems in the document
... the introduction is not a consensus and is misleading for what shacl is
... another issue are technical flaws, terminology issues
... missing a less technical introduction of what shacl is supposed to be
... relationship between shacl and rdfs, recursive shapes
<ericP> Arnaud: summarizing pfps
<ericP> Arnaud: summarizing pfps's issues:
kcoyle: does not understand what is behind the 3 bullets
arthur: the draft is very influenced by holger's implementation
... things are there that have not been discussed by the wg
aryman: holger is making sparql much more essencial for the draft than what the wg agreed on (namely, defining semantics in sparql as much as possible, and extension language)
... calling the built-in features "templates" is misleading, templates are supposed to be extnesions
... extension API does not need to be defined in detail, it can be implementation specific
<kcoyle> +1 to what Arthur says
aryman: we need a precise description of the syntax and semantics of shacl, and that's the essential thing
Arnaud: resolutions we took regarding sparql are: define the semantics with sparql as much as possible
... use sparql as extension mechanism
... the core does not require implementation in sparql
hknublau: everything aryman said is already in the spec
... very little sparql left, don't understand what aryman is talking about
aryman: if hknublau already addressed my comments, then it's fine for me
aryman and hknublau discussing on what is currently in the spec
hknublau explains in details how templates work
aryman: putting the abstract classes for templates makes them a kind of an api
Arnaud: we could not solve all these issues today, but we can agree on a plan for getting something that is good enough to be published
pfps: explains what he thinks is the main issue with the spec
... this is the example in the introduction, which relates classes with shapes
Arnaud: agrees that this example is not appropriate, as it is on a contraversial topic
hknublau: how much longer do we plan to delay this problem ? why not solve it right now
... let's decide whether we delete or not shapeclass, and if the wg decides not to delete it, then why removing the example ?
Arnaud: even if we resolve the issue, and we keep shape class, still this is not the best first and foremost example
<pfps> a big +1 to Arnaud's comments about not emphasizing shapes as classes
pfps: totally disagree
<Zakim> ericP, you wanted to disagree about class
ericP: totally disagree with holger's assertion that having a class in the leading example is more instructive for people using owl and rdf classes
<pfps> +1 to eric
aryman: the first example should be as simple and useful and possible, to illustrate some key point and one point at a time, and not several points at a time
<ericP> ericP: the majority of users of OWL and RDFS classes intend them to defined reusable classes, and this is contrary to the use of shapeClass
hknublau: the most important thing is to publish this document, so I can remove the example if it is necessary
... let's resorve it now
... I would prefer to remove any example, and leave it to a primer
Arnaud: specs do have examples
pfps: maybe in the final version, there might not be a need for examples. But we have better examples
<simonstey> +1 to arthur's comment
aryman: a spec w/o examples is unreadable. for the first publication we need examples, and even for the final. otherwise people won't refer to the spec, but to the primer
<pfps> my feeling is that the first technical document on SHACL needs a comprehensible introduction to SHACL and that this requires an example, at least for now
hknublau: I can make an introduction similar to what pfps suggested
<ericP> +1
kcoyle: strongly believe that the current introduction should be removed, and the pfps wording would be used as an introduction
hknublau: the introduction was written to give a high level idea of shacl is, mentioning different features of shacl
kcoyle: asks to pfps to make precise what edit he proposes
pfps: replace 1.1, 1,2, 1.3
kcoyle: we should have a document outline (explains what's in the document) which would be 1.1
... it's different from an outline on the specification and the points being addressed
Arnaud: proposes that pfps's text is integrated in the current introduction
... I would propose to consider now aryman's concerns
there should be a core of the language that addresses 80% of the use cases
scribe: sparql is an extension
<aryman> +1 to Arnaud's summary of the role of SPARQL
hknublau: sparql could be mentioned in the introduction
... or move it to Secti. 6 (extension)
ericP: agrees with moving sparql to section 6
kcoyle: agrees
Arnaud: the introduction should talk about whole shacl, not only core
kcoyle: still we do not need to explain sparql extension in the introduction, we can simply mention it is an extension mechanism
hknublau: we could have an abstract section before the introduction, and mention there what is in the document
Arnaud: propose to give hknublau a chance to edit the introduction in the sense we propesed, and see what we get
... let's get to pfps's concern that the current document does not describe what shacl is
... how can we solve it, is it an nomenclature issue
pfps: my comments refered to the version I read
... I didn't recognize shacl
Arnaud: can you give an example ?
pfps: shacl is presented as an rdf vocabulary. it is a language, not a vocabulary
... shacl does not describe graph structures, this is not its purpose
... shacl is a constraint language, it is not to describe to graph structures, but to validate rdf graphs
... i turns out that it has to describe graph strucutres, but it not its purpose
... towards the document "shacl mandates ..."
... it checks constraints, it does not mandate
... regarding the relationshipe between shapes and constraints, didn't understand what the wording wanted to say, I didn't understand how to read it (referring to the version form August 10)
... don't know how it was changed
Arnaud: hknublau is making edits to reflect our comments, so we can hope the wording goes in your direction
<simonstey> there is a revision history in the beginning of the document
Arnaud: so the question is : how do we collectively descibe what shacl is, so that we know what to write in the introduction and a first-time reader gets the right idea of shacl
... maybe the further sections are more controversal, the introduction should give the right idea
... validation is not the primary purpose of all users
... e.g. people from the linked data platforms want to describe the data
... are there other interests ?
pfps: who wants shacl for primarily describe structures ?
ericP: me. first you describe the data, then this description can be used for validation. Cites the introductory sentence for XMLSchema
... shacl is a language for describing the graph structure, and a validation mechanism for checking whether a graph satisfies the structure
kcoyle: is not convinced that "structure" is the best wording
hknublau: definitely, describing the sttructure is important
<Zakim> ericP, you wanted to disagree with one of pfps's points: whether shacl "describes" structure
<pfps> I agree with Eric that conflating "describing graph structures" and "modelling" is a stretch
aryman: oslc is a description language for rdf data
... many of our users are not familiar with rdf and want description of the data
... also having a pragmatic way of validating rdf data
kcoyle: our primary need is to describe data. we do not separate validation and description. the word 'validation' is hard to find in the current introduction. if people do not need to validate, then they would not use shacl
pfps: agrees that one does not use shacl for only description. The design of shacl was oriented towards valdiation.
<hsolbrig> +1 on description is not modeling
pfps: description is not modelling4
Arnaud: we can talk about description, validation, constraints
... no modelling
hknublau: agree with that
Arnaud: would that address the primary concerns about the current draft and its introduction of what shacl is
pfps: it appears so
... there is also the issue for the relationship between shacl and rdfs
... it's also about terminology. the document uses the words classes, rdf:type, rdfs:subClass etc, but not in a way RDFS does
... these uses are not conform with RDFS, so I fear that people would misunderstand shacl
... at the very minimum, we need a disclaimer. explain to people that shacl does not use RDFS as it is
<simonstey> to what extend is the current spec using subclassof wrong wrt to the official spec?
pfps: misunderstanding of shacl would discourage people from using it
hknublau: pfps, maybe you can suggest a paragraph that explains to RDFS-aware people woh to read the document in order to avoid the misunderstanding ?
... not sure that our understanding is so different
pfps: very different. the usage of subclass is different
... also, does not use domain and range from RDFS
... also, no subProperty in shacl
hknublau: we had an agreement that if one wants inference, it should be done on the graph level, by turning inference on
pfps: this is not the unique differences. the document should state it explicitly how shacl uses the rdfs vocabulary
Arnaud: pfps, can you write this explanation
pfps: agrees
aryman: from a pragmatic point of view, ce nannot rely on entailment being turned on or turned off
<hknublau> http://w3c.github.io/data-shapes/shacl/#entailment
aryman: we could have an entailment property, that specifies whether entailment is supposed to be used
... when we say that A is subclass of B, we simply require a subclass triple, we are not interested to know whether it is explicit or obtained by inference
... sublcass can be also implemented as a transitive closure
... which is a pragmatic solution
<hknublau> +1 to arthur
aryman: for me this would describe our relation to rdfs
pfps: agree with aryman, except can't seay we both require explicit rdfs:subclass links, and we compute a transitive closure
<Dimitris> +q
pfps: rdfs:subclass not being uniformly applied
aryman: you can be pragmatic, explain it, and see how people from RDFS community react
Arnaud: let's peter make a first draft, and we see how it goes
Dimitris: scribe didn't get the point because of bad phone connexion
<Dimitris> we should also define how rdfs reasoning is applied inside the shacl graph for the shape / template definition
Arnaud: we have a general plan: change teh introduction using peter's text, add a section on relatioship with rdfs, and remove the reference to classes in the leading example
... peter, is that ok for you ?
pfps: other things are missing, the document does not talk about recursive shapes, the relationship with sparql is incorrect
... these are very serious technical problems
Arnaud: we've got issues for most of these
... if not, raise an issue
pfps: enumerates some technical problems, e.g. the documents talks about 'matching' and 'typing' and these are not defined. shall I raise an issue for that ?
Arnaud: agrees this is a serious issue, the document suffers from consistency
pfps: also missing how do you start a validation
<hknublau> +q to say that most of this is already fixed
Arnaud: wonders how deep we should go in the spec. for instance, should we describe the api in the spec, or how errors are reported ?
<Zakim> hknublau, you wanted to say that most of this is already fixed
hknublau: I believe that pfps's issues and yours have been addressed now
... I'm trying to improve it, but it will never be perfect
... difficult situation to keep the document consistent whereas things are changing so often
... I'm waiting for resolutions before editing the document
aryman: there should be a description of what input and output is
... but not going into so much details as hknublau
<simonstey> +q
aryman: we should have the relationship between the input and the output
hknublau: trying to do that, but we need to describe it with sparql queries
simonstey: also think that section 10 is not needed in the main document, all the operations are not referenced anywhere else in the document
... agree that we should remove that from the normative document
Arnaud: maybe we can agree to move it to another document
... let's try to address some of the aryman's concerns
... for instance the role of sparql in the document and for shacl
... for instance, notions of template definition and execution engine which is sparql
... shouldn't 'engine' be replaced by 'extension' ?
hknublau: asks for a clarification
Arnaud: for instance title of sect 13: Sparql execution to be replaced by sparql extension
... templates are part of the extension mechanism.
... we have the core and the extensions
... two kinds of extensions, one of which is templates
<aryman> can't hear holger
<simonstey> the core elements are also defined in terms of templates (which are defined using sparql queries)
aryman: agrees with Arnaud. refers to an e-mail in which hknublau does not agree that sparql is just an extension language
<pfps> I was going to make the point that the other document has a definition of recursive shapes.
hknublau: sparql has a special role because we are defining the semantics of shacl using sparql
... so that it is special
<pfps> The current document gives the impression that SHACL can be implemented in SPARQL, which is not currently correct.
Arnaud: want to clarify this
... sparql has two roles
... one is defining the semantics
... the other is an extension mechanism
... I do not think that sparql should be presented as the foundation of the core
... I know that in your implementation, holger, you do use it as the foundation of the core. But this is your implementation choice, and we should not impose this to everybody
<simonstey> wouldn't we then have to decouple the .ttl from the spec? since it uses sparql to define those constructs
pfps: scribe didn't hear the question of pfps
aryman: we are using sparql as a precise formalism, but not an execution mechanism
<pfps> my comment was that SPARQL is inadequate for the definition of SHACL
hknublau: doesn't understand the issue with sparql, it is not mentioned before section ??
<pfps> Arthur noted that large chunks of SHACL (i.e. almost all of SHACL) can be formalized as SPARQL, and I agreed.
Arnaud: the proposal is just to rename 'execution' to 'extension'
hknublau: I do not understand why I should do that
Arnaud: because it gives the impression that sparql is the foundation
hknublau: does not agree with this statement
kcoyle: you are saying it in Sect. 13
<simonstey> then make it a subsection instead of a section
<simonstey> \section(extension/execution languages) -> \subsection{SPARQL-based ...}
Arnaud: insists that we only ask to rename execution by extension, because now this gives the impression that it is the foundation
kcoyle: maybe it should be a seperate document
+q
hknublau: how can we have a self contained document if we do not give the semantics in sparql
kcoyle: the details of any implementation do not belong to the spec
-q
+q
<kcoyle> +1 to Arthur
aryman: sparql should be used to specify the semantics independently on any implementation
-q wanted to say basically what aryman says
-q
<ericP> iovka: you can specify without executing it. a declarative specification doesn't need an "execution"
Arnaud: maybe a solution is to move it out
... and go forward to a publishable working draft
hknublau: asks whether peter agrees
pfps: it would be a shame to remove from the document the connexion between shacl and sparql
... but I agree that giving the impression that the execution mechanism of shacl is sparql is problematic
hknublau: asks that somebody points him the precise sentences to be removed
Arnaud: the consensus seems to be to move this section to a separate document
<pfps> I think that there needs to be some discussion of the formal basis of SHACL in the document.
Arnaud: we should edit the changes that we already discussed, review the resulting document, and see whether we get closer to a public working draft
aryman: in some specs, you can have separate document for the formal semantics
... in order to keep the spec readable from the largest part
... the semantics document is read by people who are making an implementation
... i think we should keep the extension mechanism in the main document, and sparql is the preferred extension language
Arnaud: we stop for a lunch break, the topic is apparently not closed
<hsolbrig> No sunrise here yet
<hknublau> Yes I used Skype. The Australian toll-free number :)
<simonstey> try 0800-000-1018 for germany
<simonstey> * and loud
<hsolbrig> Isn't this the sort of thing they play to prisoners to get them to confess?
<aryman> just in "A Clockwork Orange"
<hsolbrig> I want to strangle the happy "Your conference will begin momentarily..." woman
<simonstey> especially when she repeats herself 3-4 times within a few seconds
<hsolbrig> And strange warbly distortions, like she isn't quite sane
<simonstey> haha
<hsolbrig> Welcome Arnaud. The conference woman has worked us into a killing frenzy
<aryman> @Arnaud, please tell us when to call back in
<hsolbrig> All that music and then the happy woman just hangs up!
<Arnaud> now
<Arnaud> sorry guys, we're a bit behind
<kcoyle> scribenick: kcoyle
<Arnaud> service wasn't quite as fast as iovka led us to believe
Arnaud: Can we have additional editors on the spec?
... arthur?
aryman: Yes, I could devote some time to it; esp. if we split off semantics from rest of document
... could do pure editorial work
Arnaud: should be able to make use of github for changes; fork and pull
... Idea of profiles in the spec; way to define a set of templates
... but doens't seem to be defined in spec
hknublau: No, not in spec; informal; could be used to check if a file fits a profile
... could be used by compact syntax to say what it addresses
... you don't specify anything, just what features you support
aryman: shouldn't subset core; not clear what is meant by profile
hknublau: reading too much; nothing depends on them; could be dropped; just says what you support and do not
pfps: profiles can be useful, but this mechanism is underpowered. can you use this to say you don't use recursive shapes?
hk
pfps: all this says is: I have following templates. excludes useful situations
hknublau: if we want to take this further, we could say use profiles to point to constraints , e.g. any shape could not mention same property twice
pfps: you could exclude recursive shapes by saying no data shapes
Arnaud: may have to decide if it is useful at all, or if it is worth doing more work to make it useful; raises questions, has few answers
<pfps> if SHACL had a constraint that forbid data loops, then it might be able to use it to create a profile that excluded recursive shapes
<aryman> +1 for deferring Profiles
<pfps> +1 for deferring profiles
<pfps> Note that this is not deferring profiles, just deferring the section on profiles
<simonstey> +1 to peter's addition
<Dimitris> +1
pfps: core is a profile; section 9 is a particular mechanism
Arnaud: agreed: remove section 9 for now
... return to template conversation: Holger says if removed the rest of document will not work
hknublau: wishes to make sure that sparql is part of the standard; group has received agreement on many things
... if stuff is in a separate document someone could say: let's get rid of that document
Arnaud_: being in a different document shouldn't matter; the content matters
... extension is a template - the template should be the same regardless of the execution mechansim
hknublau: yes, that's the case, templates are an envelope; template mechanism should remain in the main document
<pfps> currently the document states " Each constraint needs to be backed by at least one executable body in SPARQL". This is a strong statement about the role of SPARQL in SHACL.
Arnaud_: so, templates work without section 13
hknublau: yes, agrees; sparql document will be short and could be published at the same time
<simonstey> @pfps if we are dropping this statement we shouldn't aim to publish the .ttl as normative document, right?
pfps: current doc does not match resolutions of the working group "should be specified in sparql as much as possible' & 'sparql is a / the execution language'
... should stay or else is misleading; possibly section 13 should survive in a modified form but without the parts people object to
... renaming section 13, as per Arnaud, would go a long way
<simonstey> +q
aryman: what is section 13? semantics or execution
pfps: it should primarily be about the meaning of SHACL
<simonstey> -q
simonstey: problem sh:sparql property serves two functions: both defines SHACL functions and is also an extension
aryman: If section 13 is about the semantics then the sparql defintion should be in the document not the turtle file
hknublau: if you instantiate shacl you need a schema; and the ttl file provides that schema, can validate against it
... can be used at run time; means no difference between core and template execution
... shacl is written using shacl
pfps: there's no file that carries any evaluation semantics for OWL
aryman: we are confusing the semantics of shacl with the implementation; vocab document should be rdfs of shacl as a vocabulary, without the sparql
... that's bad because you can't fully describe the semantics in sparql, so there's no place to specify those; doesn't provide what is needed for a non-sparql implementation
... the turtle doc is normative, so shouldn't contain implementation; this combines semantics with implementation
... difference between describing implement and describing semantics; latter should not require sparql or java or any particular language
Arnaud: there are other specs that rely on sparql, e.g. graph store protocol. then people believe that sparql is required and miss that they can implement it in another language
... convenience is there, but also mis-understanding
... so we need to find a mid-point
ericP: the sparql graph store protocol: its behavior is exactly what sparql does so that was easy and natural;perfect alignment between gsp and sparql
... no composition within that language - no combining of gsp functions; was much easier to define than shacl
<Zakim> pfps, you wanted to ask where the definition of the SPARQL extension function is
pfps: definition of sh:hasShape -- not good; description there doesn't make possible implemention of function. Other functions around it are not similar. This one requires work.
<Arnaud> http://w3c.github.io/data-shapes/shacl-ref/#hasShape
pfps: problem therefore with description of relationship between shacl and sparql.
hknublau: this is independent of sparql, which is why it is here
... it's in validate node against shape
<Arnaud> https://w3c.github.io/data-shapes/shacl/#operation-validateNodeAgainstShape
pfps: sh:hasShape is needed to handle recursive shapes, but is used to handle all shape embeddings
<pfps> I don't see that 10.2 has anything to do with the sh:hasShape
pfps: 10.2 validatenodeagainstshape is not about that
hknublau: 10.2 is independent from sparql
pfps: the information isn't there; Holger agrees; it's an issue (issue-22)
<Arnaud> https://w3c.github.io/data-shapes/shacl/#AbstractValueShapePropertyConstraint
aryman: operations described in section 10 do not expose the context - may reflect your use of Jena
hknublau: hasShape needs to be specified in main doc; but included in SPARQL document
<simonstey> "Suggested redesign of Operations section"
Arnaud: review must also include ttl or its transformation
<Zakim> pfps, you wanted to talk about implementation details in http://w3c.github.io/data-shapes/shacl-ref/
pfps: sympathize with arthur's comments - there are many implmentation details in the turtle document; that are unrelated to the work group's view of shacl
... that's not necessarily bad as long as there is a good description of what needs to be mirrored (?) or what doesn't
... danger is that specification of shacl includes every feature in this document
hknublau: abstract classes are not used directly, but are part of the language
aryman: the vocab doc exposes a lot of terms; including that templates can be inherited; the build-in constraints are implemented are templates and are exposed in the vocab
... thus they can be the subject of inheritance; this makes a difference for people creating implementations in other languages
hknublau: inheritance is additive
aryman: implementations have to support this - and it defines what makes for a valid implementation
... what are the benefits? we haven't discussed this as a group
hknublau: early version had sh:private so people could use private classes; was rejected; exposure of abstract functions necessary for those implementing in another language
... needs a stable URI
Arnaud: vocab doc should be normative reference in main spec
... to be compliant with shacl i have to implement the vocabulary
<simonstey> it's the "textual" representation of the .ttl file
<Zakim> pfps, you wanted to say that it is possible to write the first document so that the second does not have to be normative
<aryman_> http://w3c.github.io/data-shapes/shacl/
<aryman_> http://w3c.github.io/data-shapes/shacl-ref/
pfps: it would be possible to write the shacl spec in a way that does not require the vocabulary ref to be normative. - english wording in former would need to be precise
... for the core vocabulary there was a sparql extension = sparql as much as possible
aryman_: this reflect holger's work on the spec, which is based on his implementation. many people do not have sparql end points. so what is in that file is not going to be useful.
hknublau: just attach to the templates
aryman_: focus on the language, not try to make life easier for others
pfps: agrees with arthur
<simonstey> +q
simonstey: need to untangle the ttl file from the normative part; use sparql snippets to define semantics in regular doc. ; don't publish ttl as normative reference
pfps: a reference implementation is valuable; shows what can be done; putting details of implementation in the spec is a bad idea because it prevents improvement
... if ttl had only the things to implement shacl it could be a normative ref; but has problematic aspects
<Arnaud> PROPOSED: fix the spec so that it doesn't depend on shacl-ref, adding SPARQL snippets to the spec where possible and english language as appropriate
pfps: may only be possible for first half; the extension mechanism may have an intertwining with some aspects of an implementation
aryman_: when we talk about a language extension, we have to fully define the language bindings - it may be necessary to define hasShape, but that belongs to the binding
<Arnaud> PROPOSED: fix the spec so that the Core doesn't depend on shacl-ref, adding definitions in english along with SPARQL snippets where possible
<aryman_> +1
<Labra> +1
+1
<ericP> +1
<iovka> +1
<hsolbrig> +1
<pfps> +1
<simonstey> +0.5
<Dimitris> +0.5
pfps: earlier versions had snippets; but not the group sees the consequence of that;
<pfps> I'm now sure whether this change should happen before or after FPWD publication
<pfps> ??
<hknublau> -1
<hsolbrig> wow -- a really soothing dishwasher
<pfps> I did agree with Holger here. This is a big issue, with many technical ramifications. However, Holger is misrepresenting the proposal, and in a very serious matter.
Arnaud: holger, I'm going to overrule your objection, you can file a formal objection if you want [Note: Holger actually withdrew his objection the next day]
RESOLUTION: fix the spec so that the Core doesn't depend on shacl-ref, adding definitions in english along with SPARQL snippets where possible
<pfps> ISSUE-23
<trackbot> ISSUE-23 -- Shapes, classes and punning -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/23
<pfps> I also eradicated punning from the title and description
<Arnaud> https://w3c.github.io/data-shapes/shacl/#scopeClass
Arnaud: shapes and classes can be separate or a class can be a shape
pfps: shape as class is harmful; it will be used to muscle in another modeling language that is incompatible with RDFS
... should not create a modeling language
... ref to ttl file that uses this to use shacl as modeling language
<simonstey> maybe we should clarify what does a language actually make a modeling language
ericP: primary use of rdf is to describe objects with the intent that they get re-used; people frequently use classes in diff. contexts;
... attaching the constraints to a class is nuanced to context; some classes are "record" classes where class is structure, and those tend not to be used with constraints
... the danger of using classes of shapes matters for the semantic web and data exchange
... should only connect shape and class for certain kinds of uses of the class, and what that means for different contexts, and when it is useful
... needs to be made clearly in an rdf triple; and make sure no one will re-use this class with different constraints
aryman_: this is syntactic sure for something that is core to shacl; can scope a shape to certain type arcs
<aryman_> holger is breaking up
hknublau: very common to have instances of a class and a shape; shapeClass removes two triples; template classes are like eric's record classes
<Dimitris> +q
Dimitris: preferable to have the shortcut, but define class only within the shacl spec
<pfps> I'm not arguing against classes as the scope of shapes. Class scopes are valuable in two ways: 1/ they can be used with an external model to provide local constraints 2/ they can be used in a model to provide constraints that should be used by all consumers of a class. If one is building a model, the one should use a modelling language, like RDFS, and not SHACL alone.
Dimitris: assume that rdfs class is defined elsewhere, on the net;
<aryman_> note that if you have a triple X rdf:type Y then Y is inferred to by a Class
<aryman_> s /by/be/
<aryman_> see http://www.w3.org/TR/rdf-schema/#ch_type
<Dimitris> see the fist part of this email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015May/0025.html
aryman_: if you use rdf:type then the object is a class
<Dimitris> ex:ClassA a rdfs:Class, sh:ClassShape .
<Dimitris> ex:ClassA a sh:ClassShape . when the class definition is defined externaly
<ericP> scribenick: ericP
kcoyle: can you say what the difference is between 1 and 2?
Dimitris: 1 when you wnat shapes and classes i the same doc
... 2 when you want them in different docs
kcoyle: but the meaning is the same, but with fewer triples
Dimitris: yes but i'm not adding the rdfs class in the triple
<simonstey> 2. is actually sh:ShapeClass
scribenick ericP
kcoyle: i don't understand why we'd go through this to save triples if the end meaning is the same
... i had the impression that one of the issues is whether this declaration of the shape as a class leaks into the web and, to ericP's point, affects with the interaction of your data with the larger world
Dimitris: no one has to specify it manually
kcoyle: matter of counting triples
Arnaud: we need to differentiate between what we allow and what we think is the best thing to do
... we have disagreement on what's best so we have to allow people to shoot themselves in the foot if they want to
... in the first doc, everything depended on the class.
... the current doc allows both views
... in order to address concearns, we should not make this a prominent feature
... don't put it in the top because that's starting on the wrong foot
<hknublau> +1
Arnaud: and maybe write a note about the unintended consequences
<hknublau> These consequences already happen with sh:scopeClass.
Arnaud: let's allow poeple to do what they want
pfps: i'm unconvinced by that argument because one can get the same effect by adding in the extra node and triples
... if you want to do this thing which is problematic, you can still do it.
... all you have to do is add one triple
<pfps> If you want shapes as classes without any support for SHACL all you need is a sh:classScope triple from the class to itself
hknublau: classes can't have constraints
... they have to be attached to the shape
Arnaud: your class would have to be a shape
... in which case it could ahve constraints
<pfps> hmm, you may also need the correct typing, as SHACL can't infer it
hknublau: any decent RDFS tools should treat @@1 as a class because it's a meta-class
pfps: if shacl had RDFS (domains and ranges) then all you'd need is one triple to assert that a class is a shape
<iovka> ericP: we resolved that we do not have a type arc on the shape
hknublau: most databaes don't implement RDFS or you can't control it
... we'd still need to triples
Arnaud: in TBC, wouldn't that be hidden from users?
hknublau: in TBC, everything is class-driven
<pfps> With the new resolution on optional typing in SHACL the type links would be optional, so only one triple is needed overall
hknublau: most people will start with an existing class and need to add shape constriants
Arnaud: i think a dummy user will understand adding the shapeClass to merge two concepts
hknublau: we spin, we had only classes and constraints and folks were happy about it
Arnaud: if folks only have classes, then they have to be happy about it.
... but i appreciate that your customers are using classes
ericP: how much extra work is it to use X sh:shapeClass X insetad of X a sh:ShapeClass?
<pfps> Then how does no typing on blank nodes work?
hknublau: it requires inferencing so we need another layer arbound databases
kcoyle: is this issue going to be hidden in the draft?
Arnaud: we can resolve this and then it disappears (though nothing prevents us from asking for comments)
... but if we want feedback, it's better to ask for feedback with a pointer to an issue
... if we ask the question, we'll just keep getting the same responses. we alrady know the spectrum
<Arnaud> PROPOSED: Close ISSUE-23 allowing for ShapeClass, adding a note about the possible pitfalls of conflating classes and shapes
<pfps> one feedback that we might get is that we are stepping on RDFS's tender toes
<hknublau> +1
<aryman_> +0
<pfps> -0.9 the writing on the note is going to be tricky
<simonstey> +0 (seeing peter's point wrt. rdfs)
<Dimitris> +0
-1
<hsolbrig> -.5
<Labra> -1
<kcoyle> +0
<simonstey> what should be possible is a) to associate shapes on the instance level or b) on the class level
<iovka> -1
<pfps> we do have both instance-level shapes and class-level shapes already
<simonstey> therefore I'm happy ;)
Arnaud: clearly can't close this now. we'll go with kcoyle's proposal to publish and ask for opinions, though i think we already know the what we'll hear.
<pfps> I had some sympathy for Holger's complaint.
<aryman_> I am OK with syntactic sugar given that there is no change to expressive power
<Arnaud> pfps, are you back?
<pfps> almost
Arnaud: pfps, you objected to closing issue-74 and i wanted to give you an op to make your case
<Arnaud> issue-74
<trackbot> issue-74 -- Should SHACL support validating RDF graphs accessible via unmodified SPARQL endpoints -- closed
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/74
pfps: i sympathize with Dimitris's position (at least from reading the minutes).
... one thing i'd like to do is to run validation on external data, e.g. dbpedia
... there are some probs with dbpedia data. i'd like to be able to examine that with shacl, but i need it to work over SPARQL
Arnaud: that seems desirable, but the bar seems to high
<Zakim> ericP, you wanted to point out that the same prob applies to local SPARQL queries
ericP: blah blah blah told blank nodes blah blah blah
pfps: there are more issues not related to blank nodes but just resource considerations
... i'm in favor of Dimitris's proposal to have a summary mode
<Arnaud> PROPOSED: Confirm resolution of ISSUE-74 as is
+1
<hknublau> +1
<simonstey> +0
<iovka> +1
RESOLUTION: Confirm resolution of ISSUE-74 as is
<Arnaud> issue-22
<trackbot> issue-22 -- Treatment of recursive shape definitions -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/22
Arnaud: hknublau, what's the current editor's draft say?
hknublau: we've implemented a guard mechanism which when it seems the same node/shape combination, it throws an error
Arnaud: we've been through this before and it came down to three options when you detect a cycle:
... 1 i've been here before so it's valid
... 2 i've been here before so it's not valid
<pfps> this is, of course, if you want to have recursive shapes
Arnaud: 3 i've been here before so there's an error
hknublau: and we ignore e.g. disjunction
Arnaud: some people want to have recursive shapes.
... pfps said in a previous call that you could handle recursion in some cases
aryman: support recursion:
... need migration path for OSLC
... possible to give recursion a defined meaning. created a wiki page for use cases
<pfps> I have not had a chance to look at that wiki after the first week or so
<pfps> pointer to document??
aryman: i wrote up recursion as it exists in OSLC but it doesn't include negation
... negation available in SHACL as NOT and XOR
<Arnaud> http://arxiv.org/abs/1505.04972
aryman: iovka, what's the status of the semantics doc?
iovka: i'm not working on that doc anymore.
... there are one or two typos, but it's stable
... we are continuing to work on a well-founded semantics for ShEx.
Arnaud: do we want some level of recursion?
... do we want some form of recursion? if so, what are the limitations?
<pfps> arthur - is there a description of recursion in the OSLC documents?
Arnaud: do we make a general rule and deal with corner cases?
<aryman> @pfps - the OSLC specs are very informal
iovka: recursion can work as long as there is no negation to be verified
... negation can be hidden
<pfps> @arthur - even an informal discussion of recursion? - or even an implementation that handles recursion?
iovka: if i define <S> EXTRA :shoeSize { :shoeSize xsd:integer {1} }, we have a hidden negation.
... if it's an integer, that's easy; harder when it's a shape ref
<pfps> s/least/greatest/?
iovka: there is a maximal typing which corresponds to a greatest fixed point in which every node gets all of its possible shapes
... if i have nodes and want them to satisfy shapes, i can create a least fixed typing
<aryman> @pfps - the OSLC specs don't discuss recursion explicitly, and don't exclude recursive shapes
iovka: there is also a notion of minimal typing if i call the algorithm with some initial requirements
... so now two meanings for recursion (least/greatest)?
<pfps> I'm confused
iovka: for me, recursion is visiting the same node with the same type, but apparently there's a definition that involves any cycle in the graph.
... whether a shape is negated can be tested by evaluating a finite neighborhood.
Arnaud: so you limit negation to make it work?
iovka: you can include negation, but not if there's a recursion.
Arnaud: what happens if i violate this?
ericP: static analysis error -- property of the shape, not the pairing of the shape and the class
iovka: you have a lattice of typing which associates typing to nodes.
... in this lattice there is a greatest fixed point typing
... there is no least fixed point in this lattice
<pfps> the question is whether <s> { ex:a @<s> [1,1] } is "satisfied" by ex:a ex:b ex: a . from an empty initial typing
iovka: but if we give an initial typing and we suppose that there is an ordering on the neighborhood, e.g. that of the SPARQL ORDER BY, then this lattice provides a least fixed point.
<pfps> the question is whether <s> { ex:b @<s> [1,1] } is "satisfied" by ex:a ex:b ex: a . from an empty initial typing
pfps: suppose we turn this into a shacl opperation.
... under one proposal, the answer could be yes
... saying that ex:a belongs to <s> doesn't map to shacl.
Arnaud: there are two qs:
... .. does that shape <s> apply to ex:a?
... .. does ex:a satisfy <s>
<Arnaud> is <s> { ex:b @<s> [1,1] } "satisfied" by ex:a sh:nodeShape <s>; ex:b ex:a .
<pfps> the claim is that there is a unique consensus view of what certain kinds of recursion "mean". I had thought that ShEx had a particular viewpoint on this, but now I'm confused.
Arnaud: if we make the link between the node and the shape explicit, [see shape above]
<pfps> so can you ask about partial assignments?
iovka: the ShEx POV is "yes" because there is a way to make ex:a match <S>
... there is at least one in which ex:a satisfies <s>
<pfps> I'm coming to the viewpoint that we have to yet again defer this issue
<aryman> @simonstey thx
Arnaud: i don't expect us to close this but i'd like some sort of direction
pfps: one way forward with some WG support is, for the non-controversial cases, SHACL takes the same view of reality as everyone else does
... that's recursion with no negation at all
... now i'm not even sure that that's the case.
... a way forward:
... when someone wants recursion in SHACL, come up with a proposal for it.
... we have a proposal from hknublau
... it's reasonably well-defined
... the gist is whenever you encounter a dataloop in negation, you get an error
... SHACL will fail some cases where ShEx won't: a non-negated cycle
<pfps> I have several examples that show how hard recursion through negation is
pfps: ShEx will fail some cases where SHACL won't: a negated recursion tested against a graph without a cycle
aryman: let's punt with static analysis
... i'd be happy to write up the added runtime context
pfps: if they're willing to work on it, sure.
... my last reading of OSLC, it doesn't talk about recursion
... this is aryman's paper
Arnaud: aryman has volunteered to document OSLC plus the ShEx static analysis
<pfps> fine by me, as I don't have anything to do :-)
<scribe> ACTION: aryman to provide a proposal for recursion (from OSCL + ShEx static analysis) [recorded in http://www.w3.org/2015/09/08-shapes-minutes.html#action01]
<trackbot> Created ACTION-29 - Provide a proposal for recursion (from oscl + shex static analysis) [on Arthur Ryman - due 2015-09-15].
<pfps> I've already done my action from before
hknublau: there are 84 proposed extensions to be added to the core
... how do we define core? macro mechanism? spin off anothehr library?
Arnaud: kcoyle_ asked on the mailing list "who defines the core?"
... i said "we do"
... there are different extremes that we can adopt.
... .. no core: start with nothing and let the community decide
... .. phat core: put everything in hoping we satisfy everyone
... .. middle ground
... there's no hard rule for how to do this.
... we started with a smaller core, but several features where added based on feedback from WG members
... every time someone says "how do i do this?" and the answer is "extension" and you disagree, you can make a case for adding it to the core.
... we won't find a general rule for what's in/out of core
... working on the test-suite and the user-friendly syntax will clarify
hknublau: in SPIN we have multiple namespaces
... .. "core" has everything that needs hard-coding
... .. "spl" has stuff that's not as central -- doesn't require hard-coding
... much easier to add to "spl"
... we have probably covered 80%. do we open another library for the next 5% with a different delivery ccyle
... ?
Arnaud: there's a standard library for C, but it's not part of the languauge
kcoyle_: what would that consist of?
Arnaud: stuff we find useful
kcoyle_: templates? extensions?
Arnaud: features we'd expect every implementation to support
... unless someone wants to make a strong case for splitting it, let's just use core
... right now i think our q is do we have enough in the core to satisfy everyone?
<simonstey> all built-in concepts -> core; custom functions, custom templates, native constraints -> advanced part
kcoyle_: we had two mechanisms brough up by philA and myself
... do we careate issues for those?
Arnaud: i think so
aryman: OSLC experience with creating multiple namespaces proved to be problematic
... we strech the analogy between package names and namespaces a little too far
... don't create too many namespaces
Arnaud: my proposal is to stick with one core
<Labra> scribenick: Labra
<trackbot> issue-84 -- Constraint to limit IRIs of focus nodes to a given enumeration (similar to owl:oneOf) -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/84
hknublau: ... The use case is that you have a list of values equivalent to oneOf constraint in OWL
ericP: OSLC has hasValue or something like that
... in SHACL we have the same thing
hknublau: the difference is that this one is global
... an example in Peter's review is that you don't need to create a class to enumerate...you specify that a class has those values
EricP: with nodekind and a valueset we don't need that mechanism
hknublau: we don't want to repeat the same enumeration
<pfps> you don't have to repeat in SHACL - you can just reuse
hknublau: it is global
Arnaud: asks if it is true that it can be done with an or
pfps: maybe
... it falls to the notion of what is a shape, what is a constraint and how you combine them
<pfps> hmm, I may have been done in twice by the odd syntax of SHACL
<aryman> fyi, OSLC uses oslc:AllowedValues class to specify closed sets of values. http://www.w3.org/Submission/2014/SUBM-shapes-20140211/#AllowedValues
pfps: they are neither shapes nor constraints
... what is sh:minCount 1 ? is it a constraint?
<simonstey> sh:PropertyConstraint a sh:ConstraintTemplate ; rdfs:subClassOf sh:AbstractAllowedValuesPropertyConstraint ; etc.
hknublau: it is something that gets instantiated
<simonstey> it works afaik
pfps: you have to wrap it into a constraint
<simonstey> yes
aryman: OSLC had a similar feature
... it was useful to predefine things
... you could refer to those resources to store common used categories
pfps: why we should pick just on this one
ericP: we did that in shex in the grammar
... you can define a valueConstraint and reuse it and we were wondering how to translate that to SHACL
... and asks why only on value sets
<pfps> but I think that what Eric is saying can be done already
karen: how to constrain values to vocabularies
<pfps> I think, however, is what Eric wants is to have not just enumerated sets, but also the "set" of numbers between 1 and 20
ericP: you can enumerate the values even dynamically
... it can be a macro
... instead of having another property...you can have other property where you capture all that stuff
... it is not a proposal as such....but I can write it
... if you apply a context to JSON-LD it falls out of it
<ericP> PROPOSAL: a sh:Property class have an sh:value property which points to a value class. all restrictions on values go into an instance of that class.
hsolbrig: we had another requirement where the valueclass could be external
... and the engine could look for it...
... and you could capture that stuff in SHACL
<ericP> <S> a sh:Shape ; sh:property my:juvenileAge ; sh:value [ a sh:ValueConstraint ; sh:pattern "..." ] ] .
<simonstey> sh:property [ sh:predicate my:
<ericP> <S> a sh:Shape ; sh:property [ sh:predicate my:juvenileAge ; sh:value [ a sh:ValueConstraint ; sh:pattern "..." ] ] ] .
<hsolbrig> Rochester, MN (CDT). 10:45 AM
<simonstey> http://w3c.github.io/data-shapes/shacl/#AbstractPatternPropertyConstraint
<ericP> <S> a sh:Shape ; sh:property [ sh:predicate my:juvenileAge ; sh:value [ a sh:ValueConstraint ; sh:nodeType xsd:integer ; sh:minExclusive 1; sh:pattern "..." ] ] ] .
ericP: you stick all the things that you stick in an object in a node
... you take advantage of the RDF graph...for reusability
<aryman> sh:hasValue restricts the value
<simonstey> +1 to extend the hasvalue concept
hknublau: the closest concept to this is functions
... in principle we could allow people to use instances of those evaluation functions
<hknublau> sh:validationFunction
<ericP> http://www.w3.org/2005/01/yacker/uploads/ShEx3?lang=perl&markup=html#prod-ShEx3-valueClassDefinition
Arnaud: we should leave it as is...it seems there is a gap in the spec that is missing
<ericP> http://www.w3.org/2005/01/yacker/uploads/ShEx3?lang=perl&markup=html#prod-ShEx3-valueClass
Arnaud: tomorrow we will talk about the user friendly syntax
and how we could have a proposal to put on the table
we will also talk about the test-suite
PhilA will join us tomorrow
<Arnaud> trackbot, end meeting