W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

AW: Re: RDF Data Shapes WG agenda for 19 May 2016

From: simon.steyskal <simon.steyskal@wu.ac.at>
Date: Thu, 19 May 2016 19:30:25 +0200
Message-ID: <os4b8xlu1l8ivue8sburipn6.1463679025353@email.android.com>
To: Arnaud Le Hors <lehors@us.ibm.com>
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
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.
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC