See also: IRC log
<simonstey> http://www.w3.org/2008/04/scribe.html
<scribe> scribe: aryman
<scribe> scribeNick: aryman
<Arnaud> PROPOSED: Approve minutes of the 4 February 2016 Telecon: http://www.w3.org/2016/02/04-shapes-minutes.html
<pfps> minutes looked OK to me
RESOLUTION: Approve minutes of the 4 February 2016 Telecon: http://www.w3.org/2016/02/04-shapes-minutes.html
Arnaud: Welcome Jim Amsden from IBM, working on OSLC
Jim: I've had a long-term interest in semantic web and it has recently become a job responsibility at OSLC and Linked Data.
kcoyle: We do not have a mailing list that has the usual name, specifically DC people expected "comments" in the name
... We have been using the mailing from the initial workshop
<Arnaud> https://lists.w3.org/Archives/Public/public-rdf-shapes/
Arnaud: Eric and I decided to continue to use that public list for comments
kcoyle: We should update the description displayed by the archives
Arnaud: Eric will update the mailing list description to include comments on the specs
<Arnaud> PROPOSED: Open ISSUE-121 Should the SHACL owl:Ontology include the # character
<TallTed> https://www.w3.org/TR/swbp-vocab-pub/#naming as Simon noted in the Agenda...
<simonstey> -q
<TallTed> +1 open it
<simonstey> +1
<Labra> +1
+1
<kcoyle> +1
<Jim> +1
<pfps> +1
RESOLUTION: Open ISSUE-121 Should the SHACL owl:Ontology include the # character
<Arnaud> issue-122
<trackbot> issue-122 -- Should we postpone publishing a SHACL shapes file (indefinitely)? -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/122
<kcoyle> no, shows sound coming from you on webex
<ericP> aryman: i see no reason not to publish a shapes file
<ericP> Jim: we use these a lot in OSLC, makes the tools more dynamic
aryman: we should allow another WG member to create the shapes file
Arnaud: let's see how much time this takes away from the WG
<Arnaud> PROPOSED: Close ISSUE-122, as is, we can revisit this if it becomes a problem later on
+1
<pfps> +1
<ericP> +1
<simonstey> +1
<Jim> +1
<kcoyle> +1
<hknublau> 0
<TallTed> +0
RESOLUTION: Close ISSUE-122, as is, we can revisit this if it becomes a problem later on
<simonstey> issue-78
<trackbot> issue-78 -- Should SHACL support marking classes as abstract -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/78
aryman: You could create a shape that checked for direct instances of a class and reported a violation.
ericP: We considered doing this in ShEx but pulled it out. It was used to prevent matching a base class instead of a subclass.
Arnaud: do we have a Use Case or Requirement?
Jim: this could be useful in Change Management
<simonstey> we dont have a uc for that
Arnaud: Do we have an accepted Requirement in our UCR spec?
<simonstey> *no recorded one
<pfps> I don't remember any use cases for this
<kcoyle> I don't see anything explicit in the use cases
<ericP> the use case could start "suppose there were a language for constraining RDF graphs..."
TallTed: several people have expressed requirements, and expressed possibly ways to address them, so we should discuss it further and work towards adding a Requirement
Arnaud: we need someone who cares enough to work on it further
aryman: If the solution to this requirement could be based on a shape then that would remove the objection to Holger's solution which encroaches on the modelling space
hknublau: A shape solution would break down in the presence of RDFS inferencing since rdf:type links would be added
Arnaud: Simon raised the requirement to apply constraints to each member of an rdf:List
<simonstey> http://w3c.github.io/data-shapes/data-shapes-ucr/#r6.12-expressivity-checking-for-well-formed-rdf-lists
Arnaud: Holger objected on the grounds that this further expands the scope and can be solved using the extension mechanism
Simon: we do have use cases but the spec is unclear about how to handle lists
<TallTed> issue-119?
<trackbot> issue-119 -- Defining constraints on (values of) rdf:Lists -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/119
<Arnaud> yes
Simon: I am concerned that the spec is currently not addressing the accepted List requirements
hknublau: the language is already large and adding Lists were require more development and test cases. I can imagine many more similar types of requirements. We have the extension mechanism so we can defer it or let the community address it?
<pfps> got to go
Arnaud: You ask for more features so what is you criterion for making the language larger?
<simonstey> +q
hknublau: I proposed the sh:abstract feature a long time ago. I now want the language to stabilize.
Arnaud: Yet you disagreed when I proposed to close the sh:abstract issue.
simonstey: We do have the List requirements so we need to make a statement about how to address them.
Arnaud: We could add a section to the spec about how to deal with Lists.
kcoyle: Lists are very important in the DC community but we don't have enough experience about how to deal with them in shapes. I am OK to leave this to the extension mechanism.
TallTed: We still have one year so I don't see the need to close this issue now.
<simonstey> which suffices my issue btw
Arnaud: We have a lot of issues open and we need to close some.
<Arnaud> PROPOSED: Close ISSUE-119, not expanding core to handle lists but adding a section on how to do so using the extension mechanism
<hknublau> +1
<ericP> +1
+1
<simonstey> +1
<kcoyle> +1
<Labra> 0
<TallTed> +0
<Jim> +1
RESOLUTION: Close ISSUE-119, not expanding core to handle lists but adding a section on how to do so using the extension mechanism
<trackbot> ISSUE-47 -- Can SPARQL-based constraints access the shape graph, and how? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/47
hknublau: There are many use cases that having access to the shapes graph helps.
<ericP> aryman: the fact that we have the shapes graph as an RDF graph is actually an accident
<ericP> ... we could have taken a different tragectory that doesn't use an RDF graph (e.g. ShEx)
<ericP> ... but since we used love RDF, we used RDF
<ericP> ... in order to get access to the shapes graph, the shacl processor has to be tightly coupled to the store
<ericP> ... access to the shapes graph would eliminate loose-coupling e.g. queries to dbpedia
<ericP> ... in principle, you could do that, but the SHACL processor would have to generate more complex SPARQL queries
<ericP> ... i think we should have one language binding providing access to the shapes graph
hknublau: Agree that this is a language binding issue. A SHACL processor can analyze each query and detect access to the shapes graph.
<kcoyle> +q
Arnaud: Should access to the shapes graph be the default?
hknublau: I would support having different levels of compliance, e.g. built-in only, extension in SPARQL, extension is SPARQL with shapes graph
kcoyle: In the DC meeting the issue of Linked Data Platform came up. Is this related.
<ericP> aryman: i don't think this is really a Linked Data issue because LDP is often implemented on non-RDF systems, e.g. relational databases.
<ericP> ... but you could use this when there's a triple store
Arnaud: the proposal should be more neutral and specify what happens if the shapes graph is not available. We can't persuade everyone that the shapes graph must be present.
<ericP> "if he shapes graph is accessible..."
<Arnaud> issue-57
<trackbot> issue-57 -- Cardinalities on expressions or groups of triple constraints -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/57
ericP: this feature is based on patterns that frequently occur in languages, i.e. a group of things that together are optional
Arnaud: does the sh:partition constraint address this?
ericP: no
aryman: sh:partition would let you express an optional group
ericP: I'll try that
Arnaud: I've added an Implementations section to our WG wiki page. There are three known implementations (or plans for one).
... Please add implementations that you are aware of.
<Arnaud> trackbot, end meeting