See also: IRC log
<Dimitris> πρεσεντ+ διμιτρισ
<simonstey> I've another meeting @ 13:00 CEST but will return afterwards
<Arnaud> ok
<hsolbrig> Uh, guys...
<hsolbrig> the phone number above appears to be a phone sex line.
<aryman> that's just Arnaud talking sexy
<hsolbrig> Never mind.
<pfps> which one? - not that I'm saying that you are wrong, but I'm listening to the people in Lille :-)
<Dimitris> scribenick: dimitris
<pfps> didn't that bleed into the IRC? I see something very strange from Dimitris
<aryman> that's Greek to me
arnaud: we decided to work on a compact syntax along the lines of shex
... Eric has some material he wants to present
<ericP> http://www.w3.org/2015/Talks/0909-shex-egp/#%281%29
ericP: (presenting the slides)
<pfps> As far as I know, ShEx repetition is not a part of SHACL
<pfps> This appears to be strangely missing the possibility of following property links
pfps: this page (slide 3) is missing the idea of following property links
<pfps> actually that is hidden as part of "triple constraint"
pfps: (ok found it)
<aryman> Can we settle on an agreed term for a collections of shapes?. i.e. schema, shapes graphs, ...
<pfps> The basic algebra of ShEx is very different from SHACL - conjunction vs addition
<pfps> EXTRA doesn't add any power, as far as I know
ericP: (answering aruman on slide 3) extra allows other values
<pfps> doesn't SHACL handle IRI stems using patterns?
<pfps> doesn't SHACL handle inclusion via AndConstraint?
ericP: semantic actions can do validation among other things
<pfps> SHACL has EXTRA on by default
<pfps> as far as I know the only significant differences between SHACL and ShEx is the combination algebra and semantic actions
<pfps> yes, ShEx partitions, and this makes ShEx processing hard
aryman: you have to compute all the partitions of each triples?
ericP: yes, when compute multiple occurences
iovka: we have a smart algorithm, worst case is np-complete
aryman: this feature is different from shacl
pfps: shacl supports IRI stems from patterns and inclusion from and constraints
... you can achieve this using a union
ericp: the question is to figure out how to compile shex into shacl
pfps: shex doesn't have conjunctions
... SHACL has both a universal and a counted construct
... you 2-4 shoes that belongs to class A and 2-4 shoes belong to class B
... in shex algebra you would count it once
... as far as I can see the biggest difference between SHACL and ShEx is the combination algebra
iovka: if you want the same and it is additive then you would have to add negation
pfps: yes you would have to exclude the middle
iovka: I don't know what happens in you have unbound cardinality
pfps: in SHACL, values satisfiy different constraints independently; in ShEx, values can only satisfy one of a set of constraints
ericP: inclusion is like substituting, more like a macro
aryman: is there nesting in shex?
<pfps> again, SHACL has this via AndConstraint,
ericP: you can do nesting with AND and OR in the same way with shacl
<pfps> it's not an "AND" it's a "PLUS"
aryman: is there an implicit and and if you want an or you would explicit state it?
ericP: yes
aryman: your meaning of AND is different than SHACL
ericP: on multi occurrence it is obvious
... (discussing with pfps about ways to translate between shacl and shex)
... it is easier to map from shex to shacl (rdf)
<pfps> Is there a connection from here to a user-friendly syntax for SHACL?
arnaud: we have two different animals and we need a way to combine shex with shacl and how we deal with differences
kcoyle: is shex a user-friendly language? we didn't see much syntax
ericP: we shown the syntax quite a few times in the past
pfps: shex syntax is fairly compact, easy to write & read, has a few peculiarities
<iovka> +q
pfps: are the shex people in favor to remove conjuction?
<iovka> to ask whether the shacl people are ready to turn conjunction into grouping ?
ericP: conjunction is the major issue
... conjunction breaks user intuition. if shacl has features that are better for users we can go in that direction
aryman: I am with peter. I find it odd that people in this WG that develop their own tools. Let's see the differences and create a unified language
iovka: what would it take for shacl people to translate conjunction in to grouping?
... we should avoid having the same syntax for different languages
PhilA: good to see consensus, the will be one W3C standard and we need to converge
pfps: I don't see compromise reg. conjunction. Ideally we could add both approaches but not easy to implement
arnaud: we can discuss with examples and test cases to see both approaches and decide later
pfps: in the RDF(S) view point conjunction in the only way to go
... shex is a difficult language from a computation perspective
<iovka> +q
pfps: according to iovka it is np-complete in worse case or maybe more
<iovka> according to iovka it is in NP, perdiod. not more
pfps: if we go for a union someone has to make the argument if the computation and implementation cost worth it
aryman: shacl is consistent with oslc
... we have to understand the reality and see use cases
... regarding complexity I trust iovka on optimizations
iovka: people are working on np-complete every day.
... academics found complexity problems in SPARQL property paths and OPTIONAL
... in practice worst-case complexity doesn't happen
arnaud: we can try to converge point by point
labra: the differences are not that big
... only in multi occurrence
PhilA: it's a year since you started 5 months ago
... you published the UCR and I hear there are new use cases
ericP: the use case document does not capture this distinction
... we have these in the wiki
PhilA: should be included in the UCR document
... you have 1 year left
<PhilA> Correction, you have nearly 2 years left (to June 2017)
arnaud: the ball is in shex people, the wg is open
ericP: if we can include multioccurrence it's fine, otherwise there is nothing else shex can give to the WG
... multioccurrence is a very common pattern in shex
... only lately we understood that there would be a single semantics for multi occurrence
<pfps> which decision made two weeks ago?
<hknublau> @pfps qcrs
<pfps> aah - four weeks ago
arnuad: I am concerned with take it or leave it approach. The path forward is clear. you need to make an effort to convince the group that your approach is better
<aryman> I believe the main difference is that SHACL does not include the GroupShape operator defined in http://w3c.github.io/data-shapes/semantics/
<pfps> it appears to me that the current SHACL semantics handles S47
<pfps> ... which is the use case underlying the multioccurence issue - ISSUE-53
aryman: GroupShape is what is missing from shacl. If we add that to shacl would it satisfy you
<Labra> The decision was: http://www.w3.org/2015/08/13-shapes-minutes.html#resolution04
ericP: that's true
<Labra> The open issue was closed at that meeting
iovka: adding groupShape might be possible but we need to understand the semantics of the rest of shacl
<Labra> And the issue was about multi-occurrance of the same predicates
<pfps> the underlying operations in ShEx are different from those in SHACL
kcoyle: does the first working draft depend on this?
PhilA: it's not good to hear from any WG member "either we do this or we walk away". We all need each other and have to do compromises
pfps: sorry if I sound bitter but the WG has been working without the shex people for some time now and we are not less viable
... shacl is a result of quite a few compromises already
... one solution would be to combine rdfs with recognition but it requires an owl reasoner and I don't think anyone would go with this approach
<pfps> I perfect way to proceed here is to show that S47 is not currently handled in SHACL
pfps: the basic design in shacl had one change with the qualified cardinality
... in the past months
ericP: do I have to prove that the behaviour in slide 4 would act different in shacl?
pfps: you need to show that there is a use case that cannot handled by shacl
... S47 is a good example
<PhilA> S47
<Arnaud_> http://www.w3.org/2015/Talks/0909-shex-egp/#%284%29
ericP: (discussing about slide 4 with Peter and Arthur)
<simonstey> I'll join again later this afternoon
<Arnaud> we're back on, you guys call in
<hsolbrig> scribenick: hsolbrig
arnaud: we need to know who is in charge and who we can depend on to lead the test suite and what needs to be done
<ericP> https://github.com/shexSpec/shexTest
ericP: the goal of the ShEx test suite is to test a given node in a given graph on a given shape in a given schema
... Fail or pass, but if pass we've defined a preferred solution so we can move the "semantic actions" out of band
... we expect this group will be interested in just pass or fail
... covers ShEx language features first, but will be happy to do the non-ShEx SHACL stuff as well
... one issue is to what degree we can standardize errors. If we treat it as yes, here's a proof and no, here's an error, we need consistent error reporting
Arnaud: XML Schema stayed away from trying to dictate how an implementation functions. Have an open issue on results and are having second thoughts on whether we should go there at all...
... If spec says "This error returns this information", we need to test that, but maybe simpe T/F is good enough for the test suite
ericP: We haven't done anything in ShEx yet. True is give a proof, false is just false
pfps: It is not "errors" - it is violation reports.
... it is very important to get back information on the violations.
... test suite needs to say what violations are reported.
... example, SHACL says "Hey, check whether everyone has a name", an answer of "No" isn't useful.
ericp: Does this work when you get into complicated shapes?
Arnaud: If I have a graph with 2 violations, do both need to be reported?
pfps: Editor's draft says what happens there.
Arnaud: Some implementation may keep on going, some may report first error only
<PhilA> +1 to Arnaud
hknublau: We've had resolutions on that topic and want the ability to specify details including invalid value and details. Has been decided.
... look at test cases in link above, each can have more mf result objects, data that comes back from validation
<pfps> I would view SHACL engines that don't produce violation results as broken
ericP: Answer seems to be there. Engines that are just interested in T/F can just detect and don't need to emulate details.
hknublau: I have a solution, but we should really have a different pair of eyes build the test cases.
ericP: I can work on the test suite and maintain it.
kcoyle: Issue 51, types of validation results, only stated type of validation is open and people could develop their own. Don't know about details
Arnaud: Details are part of issue 51 discussion
kcoyle: Would love to provide tests, but don't have SHACL writers, how can we provide
<hknublau> (BTW the test results are an example where a detailed data model of constraints (schema) may be needed - each violation should point back to the constraint instance, e.g. the object holding the minCount property).
Labra: We have ShEx to SHACL translator.
<ericP> s/ericP: We have ShEx to SHACL translator./labra: We have ShEx to SHACL translator./
Labra: In general, translation works.
Arnaud: We need to know what is needed to contribute a test
Labra: Some new things in ShEx I don't know how to translate to SHACL...
... don't what the methodology will be to add new tests.
<Labra> A tool to convert between syntaxes: http://rdfshape.herokuapp.com/converter/schema
<simonstey> holger has a lot of tests for his SHACL API
hknublau: Link to manifest file is all we have right now... the rest haven't been integrated.
... ... new tests would be new folder w/ manifest file w/ results and instructions along with tests and data
... data is in one folder up from manifest
<simonstey> @jose Bad request For request 'GET /converter/schema' [Missing parameter: schema]
hknublau: I've put SHACL and data in same file, but they don't have to be. I wish results would be in same file but...
<Labra> http://rdfshape.herokuapp.com/
<Labra> That's the right link
hknublau: there is a meta-manifest file a couple of folders up that you need to add manifest to
<simonstey> thx
<Labra> Example of a conversion from compact syntax to SHACL (Turtle): http://goo.gl/JnAJiT
ericP: Manifest format comes from multiple groups. Usually run with manifest file, meta-manifest file, instance data and some representation of results. Tests generate "ERL" (eval and reporting language) reports
... pushes off the task of result interpretation
Arnaud: We have a framework, Eric will contribute tests.
ericP: Tests are amethodical exploration of the language.
Arnaud: How much do you think you really cover in the language?
ericP: I'm about 10% of the way through. Have parser tests for ShEx and then several different tests for inputs. Meant to be pretty rigorous..
... also have tests to cover different logical permutations
hknublau: If the process just becomes a dump from ShEx, not helpful. Should be custom designed for SHACL, not ShEx
... someone needs to try to come up with test cases from the SHACL point of view. I don't want to have to guess whether this test is supposed to work or not.
Arnaud: I'm not going to turn down offers. Are there other volunteers?
<pfps> I expect to be contributing tests, but probably not systematically
Arnaud: we should start with ShEx and find areas that need to be beefed up for SHACL
... we need to resolved issues as tests.
ericp: In SPARQL, an issue was presented with two mutually exclusive tests -- only one of which would pass depending on how the issue was resolved.
Arnaud: Will you contribute as you go or will it be incremental?
ericP: naming conventions, etc. require periodic refactoring ... easier to do in one place ... don't want to have vestigial crap lying around from renaming.
Arnaud: as ShEx will merge w/ SHACL, can't we just have one repository?
ericP: In the DAWG we had tests that said "Unextended SPARQL did this" but we also had tests that could be annotated as being extended by specific features. We could do that here
... e.g. EXTRA being ShEx only
... testing could be modal.
PhilA: Part of a test case is use cases, use cases should be part of test suite.
... RDF data that you are checking could be submitted w/o necessarily writing ShEx. Data could or be provided that did and didn't pass use cases.
pfps: Lets get Karen to dump some examples and the rest of us can circle around it to build SHACL tests.
Arnaud: Can Karen create a sub-directory under tests directory and start adding data?
Kcoyle: Will create identified directory (e.g. dcmi) underneath -- so people can track source
Arnaud: How do people feel about eric using a repo w/ stuff that belongs to ShEx only?
hknublau: I'm skeptical. Will lead to a dump of files that don't work and will require a lot of energy. Wouldn't count on this happening or working
... Would recommend that actual test cases only use TTL. ShEx will just be parser tests
<pfps> as long as there is a clear distinction saying what is what how does it harm things if there is some other stuff there
hknublau: We shouldn't force anyone to use compact syntax.
Arnaud: Will keep repo separate for now.
hknublau: By the way, I'm withdrawing objection to yesterday's resolution on the specification including SPARQL definitions.
<trackbot> issue-44 -- How to express dependencies between graphs -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/44
hknublau: Suppose you want to validate something against a controlled list of terms (e.g. country codes). 3 graphs -- reference data, definition of macro and data graph itself. How can a tool that just gets a data graph
... get instructions on how to get what it is supposed to use?
... I've suggested a mechanism similar to OWL:Import w/ local mechanisms.
pfps: RDF should have resolved this but they didn't.
... does SHACL need to again, take out this "RDF garbage" or should we just say "not our problem -- marshalling is done elsewhere"
... another option would be to supply information in invocation
... ya option would be to just use owl:imports
... problem is if data or control IS OWL, what should owl do?
... no good way forward. Only a least bad way, which is to "be an ostrich" and say not our problem.
<pfps> one problem with an imports directive is how to handle redirection
hknublau: Two different types of imports, can't just rely on owl:imports
<ericP> scribenick: ericP
Arnaud: why do we need to have two different imports?
... why is it important to distinguish the import of data or schema?
hknublau: the opperation requires two graphs
... the transitive closure of the imports graph would create the input graph
... we don't want the validation to always include the shapes graph
<hsolbrig> aryman: I thought we already had a property that linked a graph to a shape...
aryman: why do we need another property to connect data to shapes?
... in a linked data world, you can just follow the link
... i think that dictating how you build up the data graph is outside the WG
hknublau: of course it would be nicer to have the import in the rdf namespaces
... in many cases, you can't dereference.
aryman: the assumption in XML was that your document could point to a schema
... you didn't need to GET that graph.
... there's a standard for XML catalogs supported by e.g. Protege
... can we standardize schema, shapes graph
hknublau: pfps uses "control graph" but there are other controls
aryman: so why another imports?
hknublau: so in TBC, a user starts an empty file and they need to link to the shapes graph
aryman: don't we have a property that links a graph to a shapes graph?
... these URIs should be dereferencable. if they're not, we need an e.g. catalog mechanism
Arnaud: when we talk about inferencing, we say "it's outside shacl. is there's inferencing to be done, do it before. likewise e.g. HTTP GET"
... so we can say "we don't go there; it must be done before"
hknublau: we have a hint property called sh:entailment
... nobody's forced to use them.
... i feel we're not looking at my needs
Arnaud: by the same token, if no one else supports it, what's the good of calling it a standard?
pfps: do we have a use case for this?
Dimitris: i find this useful but i would limit it to certain graphs
... so if i have a library of definitions, it would be nice to include other shapes
... but i wouldn't extend that to the instance graph
... i think the data import is out of scope
hknublau: so use owl:imports?
<pfps> I also agree that being able to use external information in shapes graphs is useful - I think that there is a use case on this somewhere
Arnaud: apart from the fact that we're not using anything from OWL, what would happen to e.g. composer?
hknublau: TBC respects owl:imports. at a minimum, i'd need the shapes import
Arnaud: there seems to be less resistance to the shapes import?
hknublau: then how do we distinguish a shapes graph?
<hknublau> https://www.w3.org/2014/data-shapes/wiki/Requirements#Including_Named_Graphs_for_Query_Evaluation
aryman: if we adopt "library", can we call it something other than "library" and define it beying a grab of triples?
hknublau: spec out of data on his
... [ details on RDFS for this ]
... if TBC encounters a link to a link, it dereferences it "somehow"
aryman: you also need the library include in the shapes graph?
hknublau: use for e.g. country code example
pfps: there was a dc (or cataloging)-related one for pointing to a slew of valid stuff
... partly to reuse and partly because they were painful to include
... i would not be opposed to a mechanism to build up the shapes graph
kcoyle: since pfps ref'd cc, most of our stuff is too big to actually be included.
... we deference one URI at a time
... some of it isn't easily includable
... we pull in pieces at a time, not the whole file
pfps: you want the validation process to work in an impoverished env
kcoyle: we live in an impoverished env
... our programmars are assuming they'll have to do the imports manually
... we don't have a mechanism to know what we have to derefernce
<hknublau> Karen talks about http://www.w3.org/2014/data-shapes/track/issues/80
pfps: so taking LoC, we have a shape that says your LoC catalog number has to be in the reference
kcoyle: order 300M
pfps: so the use case is going to be that "the value exist in the value set", and thus painful to include
... so it's better to isolate the LoC catalog
kcoyle: this will be externally ref'd e.g. by Z39.50
pfps: right, it's part of the control information
Dimitris: we shuold see if we can include something similar for ontologies
... e.g. my FOAF definition includes this source of shapes
hknublau: so similar to the class owl:Ontology?
Dimitris: so i have some FOAF and i reference the shapes file to which my FOAF complies
hknublau: when you use these class definitions, because they're needed for validation, you include them by sh:dataGraph - sh:includes...
Dimitris: could use sh:include or find another property for ontologies
Labra: in ShEx, you can import a schema from another
... we have the notion of shapes graph in ShEx, which is i think the same as a shapes graph
... i'm not opposed to an import mechanism for schemas, but i think data importers are out of scope
<hknublau> <> sh:shapesGraph <…>
Labra: but to what node is the import property attached?
... if we have to the notion of a shapes graph, how do we know that shapes are in a schema?
aryman: replying to kcoyle, the feature that i was describing only applies to the data graph
... you can link to say that a node conforms to a shape, but a validator isn't support to do anything with that
... we should have a mechanism to address kcoyle's case with large amounts of data using SERVICE
... or we could extend the notion of allowed values to match a URL pattern
... but for kcoyle's use case we need to do distributed computing
hknublau: the proposal is two properies sh:include and sh:shapesGraph, used for pre-processing before validation
... we could add a class called sh:Graph to give the range a type
Arnaud: this proposal never got enough support to get beyond "proposed"
<scribe> scribenick: hsolbrig
ericP: owl:imports doesn't do anything semantically...
pfps: correct. Just "do this"
ericP: analog for us would be document #include schema / schema #include schema. No need to connect content of document with document itself..
<hknublau> rdfs:isDefinedBy?
Labra: If we are talking about including a shapes graph in another, we need to know what shapes were imported...
Arnaud: Will SHACL engine do anything different or is it just useful information?
ericP: @pfps - was there any discussion about connections between descriptions in document with document itself?
pfps: Social meaning discussion -- if you used whitehouse.gov you were obligated to assert that bush was great president...
... ... requires social meaning contract that whitehouse.gov website is about whitehouse
ericP: If we do it the owl way, there is no way to make this connection.
doublespeak
Arnaud: Consensus about sh:shapesGraph, but not about sh:include...
pfps: I thought it was the opposite? shapesGraph goes from data to shapesGraph. Eric should barf about this one
... consensus that we want to put something in a shapes graph that pulls another graph in.
Arnaud: equiv to the XML omission of a way to say "this is my schema"
... inclusion of one graph is non-controversial. We can fight over names later.
<pfps> I'm not wildly enthusiastic about it, but it's probably a good idea to be able to split the shapes graph.
ericp: 3 things? Data -> schema, schema->schema, data->data. Schema is non-controversial, maybe same pred for data->schema, but hands off data->data
hknublau: blib, click, burble, cliatter
... Topbraid people open shapes graph directly and edit it as data. Not always clear whether it is shape or data graph. Implementation uses owl:imports, sh:include, sh:shapesgraph together ... click clatter bloop
Arnaud: is anyone fighting for data to data?
... I understand special link for data to schema, but why data to data ... is it because links aren't typed?
ericP: The issue is whether or not you work with systems where schema and data are mixed. If they are mixed, they have different effects.
kcoyle: won't there be a difference in the target as well -- data graph vs. schema graph.
ericP: both of these things are unordered, no artifact left
kcoyle: yesterday we talked about a mechanism to create a named value stack?
... allowed value into macro. Wouldn't that perform same function as include?
<pfps> can we have a split proposal?
<pfps> the problem with one link is what do you do if you want to validate a schema graph?
ericP: data to schema and schema to schema are both schema triples, do we need to differentiate?
<Arnaud> PROPOSED: have a mechanism to include a schema into another schema
<hknublau> +1
<simonstey> +1
<pfps> +1
<Dimitris> +1
<ericP> +1
+1
<kcoyle> +1
<Labra> +1
<aryman> +1
RESOLUTION: have a mechanism to include a schema into another schema
<Arnaud> PROPOSED: have a mechanism to link a data graph to a schema
<hknublau> +1
<pfps> -0.7
+1
<aryman> +1
<ericP> +0
<kcoyle> +1
<Dimitris> +1
<simonstey> +1
<Labra> 0
RESOLUTION: have a mechanism to link a data graph to a schema
ericP: I've got schema X and the datashapes schema for shapes and want to test that X is compliant with that. Schema X has a schema include and a data to schema include...
,,, one of those is for sucking down stuff and the other is for validation.
<Arnaud> PROPOSED: call the mechanism to link a data graph to a schema sh:shapesGraph
<hknublau> +1
<aryman> +1
<Dimitris> +1
<ericP> 0
<kcoyle> kcoyle +0
+1
<Labra> 0
<pfps> +0 I don't care what this is called, as long as it is different from the schema inclusion link
<Arnaud> ED: call the mechanism to link a data graph to a schema sh:shapesGraph
RESOLUTION: call the mechanism to link a data graph to a schema sh:shapesGraph
<Arnaud> PROPOSED: have a mechanism to include a data graph into another data graph
<aryman> +0
<pfps> -1
<simonstey> -0.5
<Dimitris> -.05
<kcoyle> -0
-1
<Labra> -0.5
hknublau: that means people would continue to use owl:imports?
a: that or something external
<aryman> sh:includeShapes
<simonstey> sh:includeShapesGraph
<pfps> I like incudeShapes
<Dimitris> sh:includes should do, sh: implies shapes
hknublau: Just creating a union graph by all the includes.
aryman: how would all the data in value lists be referenced by the shapes? SPARQL query?
<Arnaud> PROPOSED: call the mechanism to include a schema into another schema sh:includeShapes
hnkublau: that, walk a path and other use cases.
+1
<kcoyle> +1
<aryman> +1
<Labra> 0
<Dimitris> +1
<simonstey> +1
<ericP> +1
<hknublau> -1
<ericP> ±1
<ericP> ∓
<pfps> +1
hknublau: I don't see why we just don't do sh:include....
Arnaud: 20 minute break. Resume at the hour.
<aryman> scribeNick: aryman
<Arnaud> pfps, we
<Arnaud> 're back
<Arnaud> if you don't hear us there is a problem
Arnaud: if we want a generic include mechanism then use owl:imports
<pfps> owl:imports is a general inclusion mechanism, albeit one tilted towards ontology inclusion
<kcoyle> +q
<simonstey> what should happen if one uses shacl with owl and then uses owl:imports&sh:include together?
knublau: we might as well use owl:imports instead of defining sh:includeShapes
<Dimitris> why don't we make the reverse proposal?
Arnaud: why are people opposed to sh:include?
hsolbrig: it's a general RDF requirement and is out-of-scope for SHACL
<ericP> it's arguable that SPARQL would have been the place to define this
pfps: there is no argument against SHACL using owl:imports
<ericP> i want to unionize RDF graphs
<simonstey> I've the same argument as peter
<hsolbrig> triples of the world unite!
hknublau: I can live with owl:imports
<Arnaud> PROPOSED: add a note stating that owl:imports can be used for general inclusion (data to data and schema to schema)
<simonstey> +1
<hknublau> +1
+1
<hsolbrig> +1
<ericP> +1
<Labra> +0.5
<pfps> +0
<Dimitris> does this mean we will drop sh:includeSHapes?
Arnaud: yes, this means drop sh:includeShapes
<Dimitris> 0
<kcoyle> +1
RESOLUTION: add a note stating that owl:imports can be used for general inclusion (data to data and schema to schema)
<Arnaud> PROPOSED: Close ISSUE-44, based on the last two resolutions (sh:shapesGraph and owl:imports)
<hknublau> +1
<pfps> +0
+1
<hsolbrig> +1
<simonstey> +1
<kcoyle> +1
<ericP> +0
<Dimitris> +0.5
RESOLUTION: Close ISSUE-44, based on the last two resolutions (sh:shapesGraph and owl:imports)
<pfps> issue-29
<trackbot> issue-29 -- Formalism for definition of high-level language -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/29
<Arnaud> issue-29
<trackbot> issue-29 -- Formalism for definition of high-level language -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/29
pfps: We have decided to use SPARQL (like options c or d in description of issue)
<pfps> I think that the answer that has been chosen is "SPARQL plus an extension function for recursive shapes"
<Arnaud> PROPOSED: Close ISSUE-29, as already resolved using "SPARQL plus an extension function for recursive shapes"
<hknublau> rdf:rest*/rdf:first
<hknublau> +1
+1
<simonstey> +1
<kcoyle> +1
<Labra> -0.99
<pfps> +1
<Dimitris> +1
<ericP> -0.99
<simonstey> didn't we agree on using sparql for defining the semantics? (except of certain corner cases like recursive shapes)
RESOLUTION: Close ISSUE-29, as already resolved using "SPARQL plus an extension function for recursive shapes"
<Arnaud> issue-28
<trackbot> issue-28 -- Is the macro facility part of the high-level language or of the extension mechanism? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/28
<Arnaud> PROPOSED: Close ISSUE-28, as no longer relevant
<pfps> +1
+1
<simonstey> +1
<kcoyle> +1
<hknublau> +1
<Dimitris> +1
<ericP> +
<Labra> 0
<hsolbrig> +1
RESOLUTION: Close ISSUE-28, as no longer relevant
<pfps> issue-41
<trackbot> issue-41 -- Using property paths to refer to values/types? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/41
lot of static
Simon: describes using property paths to refer to values instead of using literal constants
<Dimitris> even without a property path we can have multiple values
Arnaud: who else finds this useful?
<pfps> the age of people's parents are greater than 21
<Dimitris> property paths could be expanded to all sh:property facets
<pfps> one problem with all this (which SHACL sort of already has) is what happens with empty sets
<simonstey> +q
hknublau: looks useful but may be too powerful
<Dimitris> +q
pfps: this feature would introduce a complex syntax (property paths) into the core
<pfps> the cost here is adding a complex and powerful mechanism to the core (which is supposed to be small)
pfps: we should keep the core as simple as possible
Simon: I proposed just using this for the value constraint instead of everywhere a property is used in order to minimize complexity
hknublau: this feature would lead to more similar features, leading us to reproduce a lot of SPARQL
kcoyle: what are the criteria for deciding what is Core?
Arnaud: the criteria are determined by the WG
pfps: Our goal is for the Core to cover 80% of use cases
Arnaud: who else supports this use case?
<hknublau> That is http://www.w3.org/2014/data-shapes/track/issues/81
hsolbrig: Comparing the values of two paths/predicates is useful
<Arnaud> STRAWPOLL: a) Close ISSUE-41, add support for property paths to Core, b) Close ISSUE-41, do not add support for property paths to Core
<pfps> a:0 b:0
<simonstey> a) +1 b) -0.5
<Dimitris> a)+0.5, b) 0
a:-0.5 b:+0.5
<kcoyle> a) +0.5 b) 0
<hknublau> a) -1 b) 0 I think we need such a feature, but as a separate deliverable, outside of Core.
<Labra> a) +0.5 b) 0
<ericP> a) -.5 b) +1
<hsolbrig> a) -.8 b) +1
RESOLUTION: Close ISSUE-41, do not add support for property paths to Core
<Dimitris> you can emulate notEquals with not(hasValue)
<simonstey> i know
<pfps> sh:notEqual as opposed to sh:minExclusive, I think
<simonstey> but it's more verbose
<Arnaud> issue-81
<trackbot> issue-81 -- Shall SHACL Core include support for disjoint properties and other property pair constraints? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/81
hknublau: describes feature to compare values of pairs of properties on the same subject node, e.g. different values, ordering
<Arnaud> PROPOSED: Close ISSUE-81, resolved as proposed, including sh:OrderedPropertyPairConstraint
<hsolbrig> +1
+0
<Dimitris> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0133.html
<Dimitris> +q
<simonstey> you could add an "sh:operator" property
Dimitris: proposes adding the comparison operator
<simonstey> *with predefined operators
<ericP> https://xkcd.com/327/
hknublau: that would add a limited kind of template mechanism to the Core and expose it to injection attacks
Arnaud: why not allow only an enumerated set of operator names?
hknublau: since we have a small number of operators, the extra argument has limited use
kcoyle: I dislike like the name "Disjoint". Why not "NotEqual" ?
... What if only one predicate has values?
knublau: We need to specify that
<Arnaud> PROPOSED: Close ISSUE-81, resolved as proposed in Holger's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0133.html, pending better suggestions for the names
+0
<hknublau> +1
<simonstey> +1
<hsolbrig> +1
<kcoyle> +1
<pfps> if the number of characters required to do this in the high-level language is more than directly using SPARQL, then it shouldn't be in the high-level language
<pfps> -0.1
<Dimitris> +0.5
<Labra> 0
<ericP> 0
<pfps> if one cares about this, then one should care enough to develop short names
RESOLUTION: Close ISSUE-81, resolved as proposed in Holger's email https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0133.html, pending better suggestions for the names
<simonstey> fine with closing it
<pfps> close as being subsumbed by 81
<Arnaud> PROPOSED: Close ISSUE-42, as no longer relevant, given resolutions of ISSUE-41 and ISSUE-81
<ericP> +1
<hknublau> +1
<kcoyle> +1
+2
<Dimitris> +1
<simonstey> +1
<pfps> +1
<hsolbrig> +1
RESOLUTION: Close ISSUE-42, as no longer relevant, given resolutions of ISSUE-41 and ISSUE-81
Aranud: low attendance, but the remote participation seems to be working
pfps: travel budgets are an issue, poor job collocating at other events, e.g. at WWW conference
<simonstey> http://www2016.ca/
<simonstey> montreal
hknublau: suggest having 3 hr meetings every other week in order to make more progress
... this year I will be in Germany in December
<hknublau> I know. Kids are looking forward to the snow
Arnaud: 3 hr meetings won't work for many people
pfps: F2F meetings have a positive effect since it forces preparation
... people need to do more homework to prepare for these meetings
kcoyle: We should at least have a virtual F2F when Holger is in the Germany TZ
pfps: I can offer to host a F2F at Nuance if we colocate in Montreal with WWW 2016
<pfps> Nuance can host in Montreal before/after WWW2016
<pfps> I would have to check my end-of-year schedule
Arnaud: Propose virtual F2F Dec. 16-17-18, Newfoundland time
<hsolbrig> rubber duckie, you're the one
<Arnaud> trackbot, end meeting