See also: IRC log
<scribe> scribe: SimonSteyskal
<Labra> I was
<Arnaud> PROPOSED: Approve minutes of the 19 March Telecon: http://www.w3.org/2015/03/19-shapes-minutes.html
<pfps> The minutes looked OK.
<ArthurRyman> +1
RESOLUTION: Approve minutes of the 19 March Telecon: http://www.w3.org/2015/03/19-shapes-minutes.html
Arnaud: im unable to confirm, that we can host it at the IBM lab in toronto
<pfps> Which week is the preferred one?
pfps: we still have the possibility of a room in waterloo
Arnaud: we are in pretty good shape regarding actions
... maybe we should trying to be more formal in what issues are being addressed
Arnaud: we agreed last week to publish it
... publishing is still pending
... hopefully we can publish it next week
... there are other new user stories that have been proposed, so we may take some time to discuss them now
<Arnaud> PROPOSED: approve S39 Arbitrary Cardinality https://www.w3.org/2014/data-shapes/wiki/User_Stories#S39_Arbitrary_Cardinality
ericP: a model like in resource shapes is too limited
+1
<ericP> +1
<ArthurRyman> +1
<kcoyle> +1
<cygri> +1
<hknublau> +1
<Dimitris> +1
<TallTed> +1
<pfps> +1
<Labra> +1
RESOLUTION: approve S39 Arbitrary Cardinality https://www.w3.org/2014/data-shapes/wiki/User_Stories#S39_Arbitrary_Cardinality
<Arnaud> S40 Describing Inline Content versus References https://www.w3.org/2014/data-shapes/wiki/User_Stories#S41?_Describing_Inline_Content_versus_References
<Zakim> pfps, you wanted to ask whether this would give rise to a requirement that there be a SHACL construct that goes out and grabs some external information?
ArthurRyman: it tries to describe what's the content of the graph
cygri: it's really just informative in a sense that it describes that something should link to a resource of a particular shape but doesn't really enforce it
<pfps> I'm still unsure as to just what is supposed to be going on. I really don't see any connection to SHACL here.
ArthurRyman: it would be validateable by checking if unknown content is returned
<ericP> +1 to cygri's "human-readable" distinction
<ericP> perhaps "non-semantic"
<pfps> If this is non-constraint construct then it needs to be connected to one of the other purposes of SHACL.
kcoyle: are we rejecting this kind of requirements here?
ArthurRyman:
<cygri> pfps, I think it speaks to this point in the charter: “Developers of data-providing systems can read the shape definitions (and possibly related RDF Vocabulary definitions) to learn what they need to provide”
<pfps> cygri, yes, but what is supposed to be provided?
<Arnaud> S41: Validating schema.org instances against model and metamodel https://www.w3.org/2014/data-shapes/wiki/User_Stories#S41:_Validating_schema.org_instances_against_model_and_metamodel
cygri: this story is about the model level of schema.org
... schema.org uses some constructs that are not specified
<pfps> Does anyone know what the semantics of schema.org is?
<ArthurRyman> +q
cygri: there are a few issues like not using datatypes in a way defined by rdfs, or not using rdfs domain/range but domainincludes/rangeincludes
<kcoyle> peter: they are whatever you want them to be, afaik
<pfps> karen: that's my feeling as well
<pfps> However, it is then hard to figure out just that SHACL constructs are needed for schema.org validation
<ericP> ArthurRyman: OSLC valueClass was intended to capture a union
<Zakim> ericP, you wanted to ask what :p1 schema:rangeIncludes :Class1 , :Class2 . means if you see :p1 [ a :Class3 ]
<pfps> eric: there is no invalid schema.org
ericP: i was wondering how to violate a rangeincludes
cygri: schema.org has no formal semantics
<pfps> This is something like the kind of validation that Wikidata is starting to do.
cygri: but someone might want to add some custom constraints, i.e. wants to validate whether certain parts conform to those constraints
pfps: although domain/rangeincludes might be easy to check, the datatypes constraint might be not
... so you might want to use regexp to check those datatypes constraints
<Arnaud> PROPOSED: Approve S41: Validating schema.org instances against model and metamodel https://www.w3.org/2014/data-shapes/wiki/User_Stories#S41:_Validating_schema.org_instances_against_model_and_metamodel
<pfps> if this is regular expressions, then I'm fine with ti
<pfps> +0.9
<michel> +1
<kcoyle> +1
<Dimitris> +1
ArthurRyman: this user story line sup with the facets requirements
+1
<cygri> +1
<ArthurRyman> +1
<ericP> +1
<Labra> +1
<pfps> this may or may not line up with facets - it also may require some weird facets to get right
<TallTed> +1
RESOLUTION: Approve S41: Validating schema.org instances against model and metamodel https://www.w3.org/2014/data-shapes/wiki/User_Stories#S41:_Validating_schema.org_instances_against_model_and_metamodel
Arnaud: lets switch to requirements
... 5 requirements left that are under consideration
<cygri> https://www.w3.org/2014/data-shapes/wiki/Requirements#Evaluating_Constraints_for_a_Single_Node_Only
<Arnaud> 2.11.8 Evaluating Constraints for a Single Node Only https://www.w3.org/2014/data-shapes/wiki/Requirements#Evaluating_Constraints_for_a_Single_Node_Only
<pfps> The new comment from RC (Richard?) indicates that this is a new language construct. However, it seems to me that all that is needed is a different API call, with no change to the language.
<TallTed> 2.11.8 seems very much the same as 2.12.3
<ArthurRyman> +q
<cygri> pfps, no, my comment doesn’t indicate that it’s a new language construct
<cygri> pfps, it says that the language must be designed in a way that a certain implementation behaviour must be possible
hknublau: it was mostly about the operations level; you can start the validation given a particular node
<ArthurRyman> sounds like this is the same as "focus" or "root" node concept
hknublau: so if you have a form, you can just check this instance
pfps: you can implement this by keeping track changes on the graph and only check those nodes that have changed
<michel> seems like it talks to applying the shape against a subject URI?
<Zakim> ericP, you wanted to ask if validation is permitted to reach subshapes
cygri: should actually be a easy to check requirement
<cygri> scribe, last comment was me, not cygri
<hknublau> +q
hknublau: it would go into the valueshape
<hknublau> +q
kcoyle: my question is, how far do you follow the graph? have we defined the boundaries?
Arnaud: it's undecided yet
<Arnaud> PROPOSED: Approve 2.11.8 Evaluating Constraints for a Single Node Only https://www.w3.org/2014/data-shapes/wiki/Requirements#Evaluating_Constraints_for_a_Single_Node_Only
<hknublau> +1
<BartvanLeeuwen> +1
<TallTed> +1
+1
<Dimitris> +1
<ArthurRyman> +1
<Labra> +1
<michel> +1
<cygri> +0.5 … almost too light a requirement to be worth spelling out
<kcoyle> +1
RESOLUTION: Approve 2.11.8 Evaluating Constraints for a Single Node Only https://www.w3.org/2014/data-shapes/wiki/Requirements#Evaluating_Constraints_for_a_Single_Node_Only
<ericP> +1
<Arnaud> 2.8 Specialization of Shapes https://www.w3.org/2014/data-shapes/wiki/Requirements#Specialization_of_Shapes
<pfps> My objection has been resolved. I'll change its status.
ericP: most schema languages add stuff and allow you to remove stuff as well
<pfps> The current description forbids modification and replacement, so most of what Eric is saying is not germane to this requirements.
Labra: i remove my objection
<Arnaud> PROPOSED: Approve 2.8 Specialization of Shapes https://www.w3.org/2014/data-shapes/wiki/Requirements#Specialization_of_Shapes
+1
<hknublau> +1
<Labra> +1
<BartvanLeeuwen> +1
<TallTed> +1
<cygri> +1
<Dimitris> +1
<michel> +1
<kcoyle> +1
<ArthurRyman> +1
<ericP> +1
<pfps> 0
RESOLUTION: Approve 2.8 Specialization of Shapes https://www.w3.org/2014/data-shapes/wiki/Requirements#Specialization_of_Shapes
<pfps> I'm hoping that we are reading requirements as "we can do this" as opposed to "we can do this in exactly this way"
<hknublau> @pfps yes a follow up question would be sh:extends vs rdfs:subClassOf
<pfps> or even just attaching to a subclass
Arnaud: we have made a resolution: Define semantics using SPARQL as much as possible
<hknublau> @pfps that’s my preference
Arnaud: but there is some room for interpretation
... but we can use other options if applicable or preferred
... (that's my view on this)
... whether if conceptually we have 2 documents (1 high level description, 1 extensions) which one would be referencing the other?
<hknublau> +q
ArthurRyman: the extension mechanism should refer to the high level description
pfps: if the high level stuff works in one way and the extensions in the other way thats probably not going to work
<Zakim> ericP, you wanted to say that getting that marriage right will enable other extensions
<pfps> I'm not saying that the ability to express constraints depends on SPARQL at all.
<pfps> I was saying that designing a small part of a language independent of designing the entire language risks ending up with a broken language.
<ArthurRyman> @pfps yes it's a risk, but it's under our control
<pfps> +1 to richard
cygri: i dont see any proposals on how to use javascript as a substitution of SPARQL
<Labra> +q
cygri: i dont see the urge of doing that split, since I havent seen any proposals on replacements for sparql (other extension mechanisms)
<pfps> I think that calling it an extension mechanism for a SPARQL is a bad idea. The extension mechanism is really a way of extending the high-level language.
Arnaud: i think it's more of a question of if we should let the door open or not
<pfps> ... not extending SHACL.
<hknublau> @pfps yes I objected to the term “extension mechanism” before too
michel: it makes sense to me to have the sparql implementation in its own document
<ericP> note that the ShExDemo has a few extensions, including one called "js" which tests stuff beyond ShEx's expressivity
<cygri> ericP, is there documentation how the extension mechanism works?
<Labra> labra: what I defend is that the extension mechanism supports "any" external language processor...but SPARQL there should be optional, not mandatory
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Main_Page#Proposals
<hknublau> @labra I could live with that. Some people may have constraints in their local system that use custom JavaScript.
<Labra> so could call external language processors in SPARQL, javascript, or whatever...but there could be SHACL implementations that don't support extenal calls to SPARQL
<pfps> I don't think that decisions can be made without a number of proposals, so I see the multiplicity as a good thing.
Arnaud: we dont have made any decisions yet; so we have a set of proposals that are listed on this wiki page
... we additionally have shex, we have peter's proposal which is similar to SPIN, ...
<hknublau> @labra yes this (some engines would not support SPRQL) is the intention of my proposal.
Arnaud: practically we could just have a vote and decide which road to follow
kcoyle: my question is, if we decide there is one draft.. how can we collaborate on that?
Arnaud: once we have a draft, the editors have to make changes according to issues others raise against the document
... so basically they implement the resolutions the WG makes
<cygri> ericP, I take it there’s no documentation for the js extension in the ShExDemo?
ArthurRyman: i dont think that splitting the document has something to do with the role of SPARQL
... we should be able to manage 2 documents as long as we agree on the content
<pfps> It's not the split itself that I found problematic, but the description of the split-off document.
<hknublau> +q
Arnaud: there seems to be a preference on keeping everything in one document
<pfps> If we don't agree to a general approach then how can we vote for a particular part of SHACL? Consider, for example, recursive shapes - they may appear to be fine in a very small part of SHACL but they are extremely problematic for SHACL as a whole.
<pfps> Along the lines of Holger's comment - let's put together a document that says SHACL includes SPARQL - that would be easy to write, would cover a large part of the WG output, and be a win all around!
hknublau: i dont agree with the assumption that we can publish faster if we split the document because the core part might be less controversial as the extension (i.e. sparql)
<pfps> Sure, come up with a document that defines OSLC shapes so that people can implement it and put it forward as a proposal
<ArthurRyman> @pfps I read your comment as asking for a more precise spec of OSLC Resource Shapes since there are already informal descriptions which have led to some implementations
Arnaud: maybe we should agree on a schedule, i.e. one or two weeks from now we have a contest and pick the "best" proposal
<ericP> cygri, (sorry, had eyes elsewhere) -- no docs at all. you can play with http://www.w3.org/2013/ShEx/FancyShExDemo?schemaURL=test/Issue-js-test-date-triple.shex&dataURL=test/Issue-fail-date.ttl&colorize=true and write some for me
pfps: somehow someone has to come up with a complete proposal; if a popular proposal has fundamental issues this isnt the right way to go
<Zakim> ericP, you wanted to say that we could work on test cases
ericP: we could solve this issue by defining a number of test cases which SHACL should be able to solve
<Labra> http://w3c.github.io/data-shapes/data-shapes-test-suite/
<pfps> Test cases can be illuminating, but only in how they illustrate the issues that are problematic.
Arnaud: i suggest people to raise issues in the tracker
<pfps> I was kind of hoping that some one besides me would raise an issue :-)
<hknublau> For test cases we first need a draft for a syntax
Arnaud: they can even be in terms of test cases
<Labra> right
<hknublau> Differences like union/or don’t help at this stage.
<Dimitris> I agree with Holger, we need to settle on the core vocabulary at least
<Arnaud> trackbot, end meeting