- From: Irene Polikoff <irene@topquadrant.com>
- Date: Thu, 17 Dec 2015 15:10:02 -0500
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Holger Knublauch <holger@topquadrant.com>, <public-data-shapes-wg@w3.org>
Peter, There are so many different aspects of the “world” that could be modeled - from business processes to simulation of behavior and functions in the engineering and manufacturing. For this reason, I find the use of the word “modeling” in this discussion indeed very confusing. I believe you are talking about KR, not modeling in general. A classic definition of knowledge representation is: Knowledge representation and reasoning (KR) is the field of artificial intelligence (AI) dedicated to representing information about the world in a form that a computer system can utilize to solve complex tasks such as diagnosing a medical condition or having a dialog in a natural language. This definition, as far as I know, has its roots in the expert systems. Using this classic definition, it would be a stretch to call SHACL a knowledge representation language. I don’t think it should be positioned or marketed in this way and I don’t think anyone is advocating this. But a modeling language - yes, most certainly. The boundary fuzziness comes in the actual use. I have been working with RDF and OWL and with customers using RDF and OWL for many years. Only a small percentage of them are using these languages to create expert systems. Many more are using them to bring data together. They are leveraging, RDF’s flexibility. In bringing the data together, they need to describe information (do data modeling) and, often, validate it. In my experience, majority of users today are using RDF and OWL for data modeling. And it would be a big negative for them not to be able to somehow leverage the models they have built and have some kind of a forward path to SHACL. (As an aside, expert systems are sort of passé these days and where AI used to essentially stand for knowledge representation, today it is increasingly stands for machine learning, neural networks and other things that may have no or very light connection to knowledge representation). Further, the boundary between knowledge representation and data modeling is not, by any means, set in stone. I believe you are well aware of this fuzziness because you were a proponent of using OWL Closed Word for data validation purposes. That is a good example of a language that was, perhaps, originally conceived as a KR language being used for data modeling. Users have a range of needs when they develop software applications and their preference is to use a single modeling framework whenever possible or, at minimum, have an integration that is flexible. Another good example is UML. It was originally designed as a graphical modeling notation for objects (as in in OO programming). Methods, interaction diagrams, etc. Initially, it wasn’t really for data modeling, but this is what the majority of people use it for today. The use of UML for data modeling far outweights its use for anything else. And some people have used UML to describe business processes. And some people have used it for knowledge representation. Each of these are sizable communities. In practice, people will adopt whatever they have available to accomplish the tasks they want to accomplish. This is the reality and it is a good reality. Why should some philosophical beliefs of one person or a very small group of people in certain (often obscure and even outdated) "pure principles" stand in a way of usefulness and progress? Irene Polikoff On 12/17/15, 11:54 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com> wrote: >My view is that modelling language, in this context, is modelling of the >world, i.e., representation, and not data modelling. So I count >first-order >logic and OWL as modelling languages. I also count RDFS as a modelling >language in this sense. > >This is quite different, I agree, from data modelling, and maybe that is >the >source of some misunderstandings. > >I would view a data validation language as a language designed to write >constructs for data validation. Data validation, in my view, ranges from >the >quite mundane, e.g., validating check digits, to the sophisticated, >including >things like checking that data conforms to a specific shape. > >peter > > >On 12/17/2015 08:18 AM, Irene Polikoff wrote: >> I know what data validation is as a process. I am not at all familiar >>with >> the term “data validation language”. >> >> Is it something that is well understood in the industry? Does it have a >> commonly accepted definition? I don’t believe I ever came across it. If >> you search for this term on Google, no definition is found. >> >> “Data modeling language”, on the other hand, is a very common term. >>There >> are many hits for a “data modeling language” including >> https://en.wikipedia.org/wiki/Category:Data_modeling_languages. As you >>can >> see, people view languages like RelaxNG, XML Schema, etc. which are all >> used for data validation as data modeling languages. This is the view >> that, in my experience, is prevalent in the industry. Modeling is always >> done for a purpose. And data validation is one of the key purposes for >> doing data modeling. >> >> What is your definition of a modeling language? >> >> >> Irene >> >> >> >> >> >> >> On 12/17/15, 10:57 AM, "Peter F. Patel-Schneider" >><pfpschneider@gmail.com> >> wrote: >> >>> I view SHACL as a validation language. I view validation as quite >>> different >>>from modelling. I don't think that SHACL should be a modelling >>> language, and >>> I do not agree that the shape language in SHACL is a modelling >>>language. >>> I do >>> agree that validation and modelling are similar - my input to the >>>working >>> group used (nearly) the same syntax for both. >>> >>> I am now hearing statements that the current version of SHACL is a >>> modelling >>> language, and that SHACL is already being marketed as a modelling >>> language. I >>> am also hearing arguments to the effect that more modelling features >>>are >>> needed in SHACL and that there is no reason to not include them because >>> SHACL >>> is already a modelling language. >>> >>> I believe that the current version of SHACL is not a modelling >>>language. >>> However, technical judgments of this sort are not the only ones that >>> matter. >>> Marketing also matters. >>> >>> So it may be reasonable to base SHACL on ShEx instead of SPIN. It >>> certainly >>> appears that the ShEx community does not view ShEx as a modelling >>> language. >>> >>> peter >>> >>> PS: I don't think that I have misunderstood Holger's email. >>> >>> >>> On 12/17/2015 06:52 AM, Irene Polikoff wrote: >>>> Peter, >>>> >>>> You either misunderstood Holger¹s e-mail or are pretending to >>>> misunderstand it. I know you are smart, so I suspect it is latter >>>>rather >>>> than former. If so, I find your use of demagogic tactics very >>>> regrettable >>>> and unworthy. >>>> >>>> The fact that SHACL is a modeling language has nothing to do with what >>>> it >>>> is based on. Rather, it has to do with the capabilities it provides. >>>>It >>>> provides capabilities for modeling data. >>>> >>>> As Ted said during December 3rd meeting: >>>> >>>> "<TallTed> tallted: >>>> >>>> >>>> ... a shapes language is a modelling language so I don't understand >>>>the >>>> objection >>>> what else is a modelling language, but a way to describe a bunch of >>>> shapes? what else is a shape description language, but a way to model >>>>a >>>> space?" >>>> >>>> >>>> If you don¹t think the capabilities provided by SHACL are needed, I >>>> believe you should have objected against the working group instead of >>>> participating in it. >>>> >>>> It may be that given the fact that SHACL provides modeling >>>>capabilities, >>>> your goal in participating was to ensure that SHACL is based on OWL. I >>>> believe you stated that preference in the beginning. I also believe >>>>you >>>> ³given up² on such a position for a variety of reasons. >>>> >>>> I see three options: >>>> >>>> 1. Pretend that SHACL is not a modeling language and hope that no one >>>> will >>>> not see through this. To me this is counterproductive and dishonest. >>>> 2. Say that RDFS/OWL are completely separate and can¹t be used >>>> together. I >>>> see such approach as only serving a purpose of splitting the community >>>> and >>>> introducing a big discontinuity >>>> 3. Provide a way for people to use them together to address the full >>>> range >>>> of needs these two modeling approaches can deliver on >>>> >>>> Regards, >>>> >>>> >>>> Irene Polikoff >>>> >>>> >>>> >>>> >>>> On 12/17/15, 9:02 AM, "Peter F. Patel-Schneider" >>>> <pfpschneider@gmail.com> >>>> wrote: >>>> >>>>> Thank you for pointing out that the current design of SHACL is >>>>>largely >>>>> based >>>>> on SPIN and that it is your contention that this means that the >>>>>current >>>>> design >>>>> of SHACL makes it be a modelling language. >>>>> >>>>> Arnaud, can we use this a s new information to reopen the decision to >>>>> base >>>>> SHACL on SPIN instead of ShEx? ShEx is looking much better to me >>>>>now. >>>>> >>>>> peter >>>>> >>>>> >>>>> On 12/16/2015 11:32 PM, Holger Knublauch wrote: >>>>>> During yesterday's discussions, several people agreed that the real >>>>>> topic >>>>>> behind ISSUE-23 ("classes vs shapes") is that some members believe >>>>>> that >>>>>> the WG >>>>>> should not produce a competitor to already established W3C modeling >>>>>> languages. >>>>>> We believe the WG has already "failed" on this respect, because >>>>>>SHACL >>>>>> can >>>>>> already be used as a modeling language. >>>>>> >>>>>> Instead of using classes, people can use shapes (with >>>>>>sh:scopeClass). >>>>>> Instead >>>>>> of defining OWL restrictions, people can use property constraints. >>>>>> Ranges have >>>>>> become sh:datatype and sh:class. The syntax of SHACL only spells >>>>>>out a >>>>>> different way of how most people interpret OWL anyway. There is an >>>>>> almost >>>>>> one-to-one mapping between OWL and SHACL features. >>>>>> >>>>>> By actively blocking a realistic bridge between those two worlds, >>>>>>the >>>>>> SHACL >>>>>> community risks producing two unconnected silos. At TopQuadrant we >>>>>> would like >>>>>> to promote an evolutionary strategy in which existing RDFS and OWL >>>>>> ontologies >>>>>> can be expanded to be also meaningful for closed-world constraint >>>>>> checking. >>>>>> The choice between using owl:Restriction or sh:property (or both!) >>>>>> should be >>>>>> left to the user community, and not be pre-determined by a handful >>>>>>of >>>>>> people >>>>>> who believe they can predict the future from their little WG. The >>>>>> approach of >>>>>> attaching constraints to classes has already been successfully >>>>>> explored >>>>>> in >>>>>> SPIN. It is perfectly fine to combine the inferencing role of OWL >>>>>>with >>>>>> the >>>>>> constraint checking role of SHACL into the same models. >>>>>> >>>>>> I consider this topic absolutely mission-critical for SHACL. I >>>>>> appreciate that >>>>>> those who have no strong opinion at least not block the view point >>>>>>of >>>>>> TopQuadrant and many of our customers. >>>>>> >>>>>> Thanks, >>>>>> Holger >>>>>> >>>>>> PS: At some stage we had discussed to produce a document to compare >>>>>> the >>>>>> roles >>>>>> of SHACL and OWL. What ever happened to that? Without answering >>>>>>what a >>>>>> modeling language really is, we should not close ISSUE-23. >>>>>> >>>>>> >>>>> >>>> >>>> >> >>
Received on Thursday, 17 December 2015 20:10:38 UTC