- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sat, 24 Mar 2018 16:47:51 -0700
- To: public-dxwg-wg@w3.org
Note that if properties are defined without domains and ranges, then it should be possible to add those to the property when it is included in an application profile. I agree that reasoning is not commonly used, but some applications make use of domains and ranges in their validation routines. (I won't go into whether that is a "proper" use of D&R or not; just that one commonly sees this kind of use of the declarations.) This therefore may become a requirement on profiles that has not been made explicit. kc On 3/21/18 10:30 AM, Annette Greiner wrote: > Yes, I think reviewing them is fine and wise. So far I haven't seen > anything that makes me worry, just the statement about reasoning in > general. > -Annette > > > On 3/20/18 9:55 PM, Simon.Cox@csiro.au wrote: >>> really don't need to be bound to a particular class - dcat:theme and >>> dcat:keyword. >> What I mean is, I can't see anyone relying on an entailment like "this >> resource has a dcat:keyword therefore it must be a dcat:Dataset", right? >> >> -----Original Message----- >> From: Simon.Cox@csiro.au [mailto:Simon.Cox@csiro.au] >> Sent: Wednesday, 21 March, 2018 15:23 >> To: amgreiner@lbl.gov; public-dxwg-wg@w3.org >> Subject: [ExternalEmail] RE: reasoning with DCAT >> >> Hi Annette - >> >> Thanks for your comments. It's good that my provocation triggered >> someone. The whole reasoning thing - which was one of the big selling >> points of semweb early, has fallen into some disrepute. But it's good >> to hear that there are still applications looking to leverage it. >> >> The point of the UC is to explain the motivation for doing a wholesale >> review of global domain/range constraints. It is not to motivate a >> wholesale elimination of global domain/range constraints. So we can >> evaluate them one at a time, retain the ones that the group thinks >> matters, and move the ones that we think are unhelpful into a separate >> graph (where people who want DCAT 1.0 axiomatization can still access >> them [1]). >> >> I recorded my 'votes' against a bunch of them today, and went with 4 >> 'no change' vs 2 'relax the domain constraint'. Both of the latter >> relate to what are essentially _annotations_ which really don't need >> to be bound to a particular class - dcat:theme and dcat:keyword. >> >> - Simon >> >> [1] e.g. https://github.com/w3c/dxwg/blob/gh-pages/dcat/rdf/dcat10.ttl >> >> -----Original Message----- >> From: Annette Greiner [mailto:amgreiner@lbl.gov] >> Sent: Wednesday, 21 March, 2018 09:19 >> To: public-dxwg-wg@w3.org >> Subject: reasoning with DCAT >> >> Sorry, this doesn't really fit into one single github issue. >> >> One sentence in the use case about relaxing axiomatization concerns me. >> I know we just voted on it, but I didn't get to read it carefully >> until just now. We are saying "...we are not aware of any catalogs in >> which reasoning is an important part of their operation." >> >> That statement worries me, since part of the potential value of a >> vocabulary is to enable reasoning if someone wants to build an >> application that does that. I may even have a counterexample use case. >> I've been working on an application that works on log data from >> supercomputing systems, where the various log files are described >> using DCAT. We have logs for a wide variety of subsystems, like >> networking, node operation, job scheduling, boot cycles, etc. We want >> to be able to reason about relationships between these different log >> sets (e.g., if a network link went down, we want to find log data >> about the nodes on the ends of that link.) At this point, I'm not sure >> that our use case requires us to keep stricter axiomatization than the >> group is planning to preserve, but it's probably worth thinking through. >> >> -Annette >> >> -- >> Annette Greiner >> NERSC Data and Analytics Services >> Lawrence Berkeley National Laboratory >> >> > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 (Signal) skype: kcoylenet/+1-510-984-3600
Received on Saturday, 24 March 2018 23:48:20 UTC