- From: simon.steyskal <simon.steyskal@wu.ac.at>
- Date: Thu, 19 May 2016 19:30:25 +0200
- To: Arnaud Le Hors <lehors@us.ibm.com>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <os4b8xlu1l8ivue8sburipn6.1463679025353@email.android.com>
regrets from my side too.. I'm currently travelling and my hotel's internet connection is way worse than expected. will join (and scribe) again next week. simon-------- Ursprüngliche Nachricht --------Von: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> Datum: 19.05.2016 08:43 (GMT+01:00) An: Arnaud Le Hors <lehors@us.ibm.com> Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org> Betreff: Re: RDF Data Shapes WG agenda for 19 May 2016 Regrets for missing today's telco All my votes are in the proposals page, regarding the agenda issues issue 141: I would prefer to keep the current design (sh:class / sh:datatype), if this is not possible, I would favor 3cthe behavior of 3a is non-deterministic and depends on data on the data graphe.g. ex:A ex:p "asdf"^^ex:myDTmight or might not pass validation depending on if ex:myDT a rdfs:Literal exists in the data graphand here we also have the inference issue for subclasses of rdfs:Literal which complicates the constrainte.g. one might have ex:myDT a ex:Literal in the data graph and ex:Literal rdfs:subClassOf rdfs:Literal somewhere else 3b cannot express non-xsd datatypes which, imho is out of the question The behavior of 3c is consistent and depends only on shape definitionsthe equivalent shapes definition would beex:S sh:property [ sh:predicate ex:p sh:type ex:myDT sh:nodeKind sh:Literal] 3c needs 2 constraints (sh:type / sh:nodeKind) but so does the existing design (sh:class / sh:datatype) we cannot simplify definitions without loosing something issue 133: I would favor my proposal of courseI also have a draft revision ready on a separate branch if acceptedhttps://github.com/w3c/data-shapes/compare/editorial-dk Regarding the draft publicationI think the resolution of issue 133 needs to be integrated in the spec before publicationwe also need to discuss where to position the current section 3 (shapes & validation) or how this needs to changeif sections 1-3 become consistent and flow well, the rest of the spec will be easy to manage On Wed, May 18, 2016 at 10:46 PM, Arnaud Le Hors <lehors@us.ibm.com> wrote: Here is the agenda for tomorrow. FYI, I put ISSUE-133 on it as a reference for a syntax related discussion although it's clear that there are several related issues. https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.05.19 -- Arnaud Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Cloud -- Dimitris Kontokostas Department of Computer Science, University of Leipzig & DBpedia AssociationProjects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu Homepage: http://aksw.org/DimitrisKontokostas Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Thursday, 19 May 2016 17:30:54 UTC