See also: IRC log
+present
<Arnaud> scribenick: hsolbrig
<Arnaud> PROPOSED: Approve minutes of the 15 October Telecon: http://www.w3.org/2015/10/15-shapes-minutes.html
<pfps> minutes look fine by me (not being there)
RESOLUTION: Approve minutes of the 15 October Telecon: http://www.w3.org/2015/10/15-shapes-minutes.html
Arnaud: I will not be present next week, but Eric will chair
kcoyle: Simon and I are connecting requirements to SHACL functions to check for coverage
<pfps> is there any chance of looking at this information in a more web-friendly way? right now each requirement consumes quite a bit of space - it would be nice to see this in a compact view
kcoyle: Set up as a google doc. Anyone who wants to go in and edit, feel free
<pfps> I would say that more of the requirements have solutions than are listed on the document - for example there is a higher-level language (the "core") and maybe even a concise language (the RDF encoding of the core)
<pfps> at least, we could claim that the RDF encoding is the concise language in the absence of a more-compact language
<pfps> that leads to a question about how to add in these sorts of claims
<Arnaud> PROPOSED: Open ISSUE-103
<pfps> 103 is reasonable as an issue
Arnaud: Issue 103 -- proposal to simplify syntax
<TallTed> +1
+1
<Dimitris> +1
<kcoyle> pfps: use the google doc as a draft and just write in whatever is on your mind - we'll make it into a real document later
<pfps> +1
<simonstey> others would argue that "higher-level language" refers to something like shex
<simonstey> +1
<kcoyle> +1
RESOLUTION: Open ISSUE-103
<pfps> - karen - OK
Arnaud: Holger suggested that we use the wiki to gather requirements, opinions and votes... can we do the same with issues?
... I spent some time yesterday putting together a sample page.
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals
Arnaud: Basic idea is to list all open issues. Peoples could make proposals against issues and we could collect the votes
... A more convenient way to collect positions offline and use for discussion on the calls.
<hknublau> Looks good to me.
<kcoyle> Seems worth a try - helps focus the discussion
I would prefer it over trying to chase email threads.
<aryman> +1
<pfps> probably worth a try
pfps: It would be nice to have people type more...
Arnaud: If you object, say why and, if possible, make a counter proposal
... Recommend not using it for long threaded discussions -- use mailer instead for dialogs
<Dimitris> +1
Arnaud: Will proceed with old format today, but will move forward with the wiki
... Most of the open issues are populated in a comment, just move out if you have a proposal ...
<simonstey> ISSUE-95
<trackbot> ISSUE-95 -- Proposed simplification and clean up of template mechanism -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/95
pfps: I don't see any need for guidance in this area at all
<pfps> Oops, sorry, I was looking at ISSUE-86
hknublau: This is about incremental improvement to current template syntax. Current is quite verbose, trying to simplify
pfps: Two issues. 1) Abstract classes -- implementation machinery is bleeding into spec, abstract is one of these cases
... ... there should be no vestiges of reference implementation in the actual spec
aryman: I think this is a good simplifcation, but I object to reuse of term "scopeClass"...
... ... explanation involved implementation choice that might change which might make scopeClass no longer applicable
... ... it would be clearer if you created a new term to indicate relation between node constraint and template.
Arnaud: I keep hearing that the specification is more like documentation of implementation rather than a specification...
... ... good to have a working implementation, but need to draw the line between implementation specific and what needs to be in the spec...
... ... should be responsibility of the rest of the WG, as Holger is too close to the issue
hknublau: SHACL is a way to describe data structures. scopeClass, etc. makes sense from this perspective...
<pfps> Arthur has expressed concerns about the specification being too tied to an implementation several times in the past
hknublau: ... you need to provide a counter proposal. Allows any programmer to reuse a lot of machinery
Is a spec about reuse of machinery?
<aryman> quote for note: I know the rationale behind this design isn't entirely obvious - HK
aryman: I would submit that we are designing a language and we should adopt terms that are obvious
... ... I'd be happy to coin a term and remove my objection. The meaning of the term should be obvious from the term to the reader
Arnaud: Is the rest of the proposal ok?
aryman: It is moving in the right direction and I'd remove my objection if we didn't overload scopeClass
pfps: Arthur and I don't want spec tied to a particular implementation methodology so that other people can do a better job...
... ... if tied too closely to one implementation, it is a detrement to other implementations.
Arnaud: Specify just what you need and not more
pfps: Reducing number of abstract class from 10 to 3 is better, but the goal should be 0
Arnaud: Lets put this on the wiki page and see whether we can't resolve. We may need more but this may be a good start.
<pfps> the move from n abstract classes to n/2 (or whatever) might be on the path towards 0, so I don't know whether this change is an improvement
Arnaud; ISSUE-86
<TallTed> with incremental improvements, I think we stand a chance of reaching (or at least approaching, as Zeno would insist) desired goals. it seems to me that requiring perfection of any/every change is a sure path to failure.
<hknublau> Very disappointing discussion. I had no chance to speak up.
<aryman> I will propose an alternative to sh:scopeClass for use in templates
https://www.w3.org/2014/data-shapes/track/issues/86
Dimitris: We developed some ontologies and wanted to define some constraints that couldn't be covered with OWL...
Dimitirs: ... we need a light-weight way to link from the ontology to the shapes
Dimitris: Fine with "may" as a mechanism vs "should"
pfps: If it doesn't mean anything to SHACL, there is no reason you can't define your own link..
Dimitris: If everyone defines their own, then no way to do the link when needed.
pfps: Why not use rdfs:seeAlso?
Dimitris: Because you don't know that the link is a shapes graph.
<pfps> I still think that this is a bad idea, but I'm not going to be a singleton objector.
TallTed: There is clearly a use case and a desire to do it. It won't cause problems because it is a "may"...
<simonstey> I thought that's already resolved by using sh:shapesGraph?
<pfps> if this is going to be done, then I don't see a requirement to limit it to linking from an ontology graph
hsolbrig: is this specific to an ontology or general for any graph
<pfps> there also needs to be consideration of what happens when there are multiple links
<simonstey> merging everything together
Dimitris: Never know how people will use it, they may use it in the wrong way...
... This has different meaning than shapesGraph.
... Shapes graph is from data graph to shapes graph
<simonstey> +q
<Arnaud> http://w3c.github.io/data-shapes/shacl/#shapesGraph
simonstey: How does your ontology differ from a data graph?
<pfps> It appears to me that sh:shapesGraph has precisely the meaning that is being proposed here
Dimitris: A data graph may or may not include an ontology in a shapes graph (? hard to hear)
TallTed: An ontology is just an rdf graph -- there is a triple that says "This is an ontology" but ...
(can't hear Dimitris)
pfps: When you are validating an ontology against a shape, it is just a data graph.
Dimitris: It is how to validate the data that uses the ontology -- every graph that "uses" the ontology...
hknublau: Motivation for new property was existing ontologies -- myconceptgraph imports skos:core, would get exactly the same effect if you imported skos as a shapes graph
... If someone really wants certain shapes to be used in skos, put them in skos. I think we have most of what we need...
Arnaud: How to differentiate a shape graph that applies to ontology itself vs. one that applies to data that uses the ontology
<simonstey> +q
simonstey: If I have a shapes graph that skos has to conform to, then the shapes that I'm defining on my data can only be a refinement on shapes for skos itself. Data shapes must be conformant to shapes that apply to skos itself...
... ... I don't see why we need to distinguish that.
<simonstey> Declaring the Shapes Graph A data graph MAY link to one or more shapes graphs via the property sh:shapesGraph.
<simonstey> http://w3c.github.io/data-shapes/shacl/#shapesGraph
dimitris: If spec recommends that shapesGraph be used to link ontology to shapes, then I'm ok. We just need a recommendation
pfps: spec currently doesn't mention ontology anywhere. This is good -- why a separate design pattern?
<Arnaud> PROPOSED: Close ISSUE-86, one can use sh:shapesGraph for this purpose
<hknublau> +1
Arnaud: Maybe this belongs in a best practices or primer
<simonstey> +1
<TallTed> +1
<pfps> +0
+1
<Dimitris> +1
<kcoyle> +1
RESOLUTION: Close ISSUE-86, one can use sh:shapesGraph for this purpose
<simonstey> ISSUE-61
<trackbot> ISSUE-61 -- Direction of individual scoping: sh:nodeShape vs. sh:individualScope -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/61
<trackbot> ISSUE-61 -- Direction of individual scoping: sh:nodeShape vs. sh:individualScope -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/61
pfps: I much prefer shapes being in control of the universe rather than the data. I have issues with dual purposes of shapes, but that is a separate issue...
hknublau: I'm in favor having link from shape to instance. We shouldn't pollute the data, but we already have rdf type for that.
<TallTed> rdf:type says "this entity is of that class". it doesn't necessarily say "this description conforms to that shape".
<pfps> I'm in favour of having scope links go from shapes to classes/nodes/.... The qualm I have here has to do with the dual nature of shapes - as both control nexuses and pieces of other shapes (where their control nature is ignored)
aryman: OSLC uses this triple today. Data is self describing, it has type information in it... it is natural to link data graphs to the data that describes it.
<TallTed> in the general case, a shape should not be expected to enumerate all (or any!) of the data graphs which conform to that shape
aryman: ... how could links to data make sense in a shapes graph. Shape is independent of the data... look at XML. Documents are linked to schemas. This is that purpose
... ... the issue is where do we want the link triple? Don't call it "polluting", there is historical precedence
<pfps> what is the linked data use case that indicates that node-shape links are in the data graph?
<aryman> HTTP GET
<TallTed> pfps - any data graph might internally assert that it (or part of it) conforms to a shape. I expect that many will.
hknublau: Proposal isn't to put triples into shapes graph.... conceptually they belong to the shapes graph
<pfps> so the shape control information is in the data graph - why not then just use the data graph as the control graph as well in this case?
hsolbrig: different use cases -- data has shape specification, data *type* has shape specification and shapes as a simple predicate
TallTed: I define a shape, someone else wants to reuse it. Shape graph is in my space. You have no control over it... you can only read it. I don't see the part that says that that the declaration belongs in the shape graph
<aryman> +1 to Ted re rdf:type
TallTed: I don't see that rdf:type has anything to do with shape graphs. rdf:type does nothing to do with shaping.
<pfps> -1 to Ted
<aryman> sh:nodeShape is a reference
TallTed: owl:sameAs still doesn't mean that these URI's point to the same entity
... ... there needs to be a way to say that this data graph conforms to this shape.
aryman: No shape is just a reference. In any oo language you can go from an instance of a class to a class
... ... it is a reference from a data graph to a shape.
<Dimitris> +q
aryman: ... holger says rdf:type is enough, but we agreed that shapes and classes are different animals.
... ... holger proposed an extension to our language where we allow literals to be focus nodes for shapes. How do you make a literal a subject of rdf:type... that alone should tell you we are dealing with something different.
... ... often you have no control over the data. rdf:type is not good enough for this purpose
<pfps> so instead of having rdf:type triples added to the data graph we need to have sh:nodeShape triples added to the graph?
hknublau: If you can't expect people to add rdf:type, you can't exped node triple as well...
Dimitris: I would prefer reverse relation, don't mind if info goes into shapes graph or data graph, if you use literals, then reverse relation covers this
aryman: Everytime you define a subshape, you have to define a corresponding class and introduce a type triple. Would blank nodes have to have named types in data?
<Arnaud> PROPOSED: Close ISSUE-61, adopting Holger's proposal: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Oct/0097.html
<Dimitris> http get can return both reverse relations
aryman: I'm talking about HTTP GET case, where application is producing data that is declared to have a specific shape so that clent can interpret and update it.
<pfps> +1
<simonstey> +1
<aryman> -1
<Arnaud> PROPOSED: replace sh:scopeNode with sh:nodeShape, reversing the direction
<kcoyle> 0
<hknublau> +1
<aryman> -1
<Dimitris> +1
<pfps> +1
<simonstey> 0
0
<Dimitris> but HTTP GET can return inverse relations
Arnaud: Put proposals on the wiki page along with counter proposals. If people aren't clear, ask for clarification
<TallTed> -1 because as it stands, I do not understand this (two-pronged) proposal
(interesting -- should you "-1" something you don't understand or "0". I tend to go with "0"...)
Arnaud: would like to hear ideas on what to do to separate requirements for the engine from the ones for the language
<TallTed> @hsolbrig - depends on whether I see potential trouble by adopting the proposal.
<aryman> +1 for clearing separating syntax of shapes graph versus semantics
TallTed: There is a difference between validating a graph against shapes, ? for inputs, ... There isn't really such a thing as a SHACL engine, there is a validator engine
... The labels and the comments are part of the UI space. Using the labels as the thing in front, comments are going to turn into mouseover, etc. We need to be thinking about this as well. Validation is not our only use case
Arnaud: This is absolutely correct. Will put that at the beginning of next week agenda
... it would be good to come to an agreement on what to do
<aryman> re sh:scopeNode the reverse of direction is justified as Dimitris pointed out since focus nodes may now be literal
<Arnaud> trackbot, end meeting