- From: Riccardo Albertoni <albertoni@ge.imati.cnr.it>
- Date: Tue, 26 Jan 2016 17:11:36 +0100
- To: DWBP Public List <public-dwbp-wg@w3.org>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>
- Cc: Antoine Isaac <aisaac@few.vu.nl>
- Message-ID: <CAOHhXmRVRwf8YBBa7NRnUgNeKG12DgJeni1WZjzp6hYPx5tX4A@mail.gmail.com>
Dear Jeremy and All, according to the DQV plan [1], we should solve issues 204 and 205 by the end of this week. A month ago, we were stuck in discussing two possible modelling solutions, I have summarized them below, with some new info in reply to Jeremy's objections. I kindly ask to the group members and in particular, RDF/OWL enthusiasts to help us making up our minds ;) In the previous mails, you can also find a discussion of pros and cons related to the two modelling solutions. Cheers, Riccardo *****MODELING SOLUTION A***** the modelling solution currently adopted from DAQ, which defines the classes Dimension and Category as "Abstract classes", and requires that each time you want to have a new dimension or category you define a subclass and an instance of that subclass, For example, assuming you want to add two categories ( ex:Accessibility, ex:Intrinsic) , two Dimensions ( ex:Availability, ex:Consistency), You are expected - to define two subclasses of category ex:Accessibility rdfs:subClassOf dqv:Category . ex:Intrinsic rdfs:subClassOf dqv:Category . -to define two subclasses of Dimension ex:Availability rdfs:subClassOf dqv:Dimension . ex:Consistency rdfs:subClassOf dqv:Dimension . -And then, to define one instance of each of the classes you have defined. ex:accessibility a ex:Accessibility . ex:intrinsic a ex:Intrinsic . So that you can relate dimensions with categories. ex:availability a ex:Availability ; dqv:hasCategory ex:accessibility . ex:consistency a ex:Consistency ; dqv:hasCategory ex:intrisic. *****MODELING SOLUTION B ***** the one exploiting skos instead of Subclassing, which assumes that the following new statements are added to DQV dqv:Category rdfs:subclass skos:Concept dqv:Dimension rdfs:subclass skos:Concept . dqv:hasCategory rdfs:subPropertyOf skos:broader . So that each time you need to add categories and dimensions, they can be directly instantiated as SKOS concepts ex:accessibility a dqv:Category. ex:intrinsic a dqv:Category . ex:availability a dqv:Dimension ; dqv:hasCategory ex:accessibility . ex:consistency a dqv:Dimension ; dqv:hasCategory ex:intrisic. @Jeremy, concerning your last mail, - I have tried to implement the design solution B) and I don't see the reasoning problem you have mentioned. Of course, there is the possibility that I have not completely understood your point, so you are more than welcome if you want to double-check, You find the materialization of the reasoning obtained with B in [2]. - concerning the possibility to have extra-properties, I think you still can have it, actually you can use subclassing as you planned in the daq in order to model extra properties, If I have correctly understood the main difference is that you don't have to use subclasses, if you don't want extra properties. Let's see the example below, ( you can find it in [3]) if we want to have a further dimension X which is expected to have an extra-property Y, and a subclass X1 of X which is expected to have at least a property Y1, in analogy with what you would have done on the original Daq design, we can state X rdfs:subClassOf dqv:Dimension , [ rdf:type owl:Restriction ; owl:onProperty < http://example.com/ex#Y> ; owl:cardinality "1"^^xsd:nonNegativeInteger ] . X1 rdfs:subClassOf X, [ rdf:type owl:Restriction ; owl:onProperty < http://example.com/ex#Y1> ; owl:minCardinality "1"^^xsd:nonNegativeInteger ] . ### http://example.com/ex#x <http://example.com/ex#x> rdf:type <http://example.com/ex#X> , <http://example.com/ex#Y> < http://example.com/ex#ex4> ; <http://www.w3.org/ns/dqv#hasCategory > ex:accessibility . ### http://example.com/ex#x1 <http://example.com/ex#x1> rdf:type <http://example.com/ex#X1> ; <http://example.com/ex#Y1> < http://example.com/ex#ex2> ; <http://example.com/ex#Y> < http://example.com/ex#ex3> ; <http://www.w3.org/ns/dqv#hasCategory> ex:accessibility . Am I wrong? Does it capture what you meant? [1]https://www.w3.org/2013/dwbp/wiki/Data_quality_schedule [2]https://goo.gl/qqEft3 [3]https://goo.gl/sdDySK ---------- Forwarded message ---------- > From: Debattista, Jeremy <Jeremy.Debattista@iais.fraunhofer.de> > Date: 26 November 2015 at 10:44 > Subject: Re: Problems removing hasDimension and hasMetric as abstract > properties > To: Riccardo Albertoni <albertoni@ge.imati.cnr.it> > Cc: Christoph LANGE <math.semantic.web@gmail.com>, Antoine Isaac < > aisaac@few.vu.nl> > > > HI Riccardo, Antoine, > > Sorry for my late reply. I was also busy with other (more important) > stuff. I think we are not agreeing on how we perceive the concept classes > “Category” - “Dimension” - “Metric”. For me (and in daq), these are > abstract classes as they cannot really represent anything - just a concept > with some attributes. On the other hand, Accessibility is a concrete (as > opposed to abstract) category and not an instance of the more abstract > category, because it might have some (extra) properties which are different > than another category, say Intrinsic. Therefore, this is more a design > choice, which ensures that all future “quality metadata” is structured in > the same way. I usually explain this with the Mammal -> Dog and Human > analogy. Metrics (and the same for dimensions and categories) are similar > to each other (Dog and Human are both Mammals) but in nature different from > each other (I hope :)). Yes, it is a bit of a pain for curators who want > to add such metadata, but at the end of the day this will all be done > automatically. > > In any case, the examples you gave still give a problem when querying and > inferring data as I said in my first email. > > I hope this explains my view better. > > Cheers, > Jer > > > On 24 Nov 2015, at 15:43, Riccardo Albertoni <albertoni@ge.imati.cnr.it> > wrote: > > > > > > Hi Jeremy, > > sorry for my late reply but the last two weeks I was completely > overwhelmed by other stuff. > > > > I agree with Antoine, it seems that we don’t have this kind of > problems if we move from “abstract classes” to the SKOS modelling > pattern, as we are discussing in Issue 204 and 205. > > > > Let me complement the Antoine’s reply showing how your example looks > like if we move to skos .. > > > > # New modelling in DQV /DAQ > > dqv:Category rdfs:subclass skos:Concept > > dqv:Dimension rdfs:subclass skos:Concept . > > dqv:hasCategory rdfs:subPropertyOf skos:broader . > > > > #some dimensions and categories from ZAVERI et al. > > ex:accessibility a dqv:Category. > > ex:intrinsic a dqv:Category . > > > > ex:availability a dqv:Dimension ; > > dqv:hasCategory ex:accessibility ; > > # you have a standard set of skos properties to annotate dimension and > categories.. > > skos:prefLabel “Data Availability”@en; > > skos:altLabel “Availability”@en; > > skos:definition “Availability of a dataset is the extent to which data ( > or some portion of it) is present, obtainable and ready for use.”@en. > > > > ex:consistency a dqv:Dimension ; > > dqv:hasCategory ex:intrisic > > ....... > > . > > > > #we can still state sub type relation between dimension and category, > for example, supposing the inverse-property consistency is considered as a > subdimensions of consistency, we can state > > > > ex:inversePropertyConsistency a dqv:Dimension ; > > skos:broader ex:consistency; > > skos:prefLabel “Inverse Property Consistency”@en; > > > > > > #we can state relations among dimensions from different quality > frameworks ( using standard matching relation as skos:closeMatch, > skos:closeMatch, skos:exactMatch, skos:narrowerMatch), for example, if we > have that “consistency”, the dimension in the ISO, is known to be > equivalent to the “consistency” defined by zaveri, we can state > > > > iso:consistency skos:exactMatch ex:consistency. > > > > #and then the part related to metric > > > > ex:endPointAvailablity a dqv:Metric . > > ex:ontologyHijacking a dqv:Metric . > > > > ex:ontologyHijacking dqv:hasDimension ex:consistency > > ex:endPointAvailablity dqv:hasDimension ex:availability > > > > > > Let me try to list some of the advantages this modelling pattern seems > to exhibit : > > - We are still using forcing a kind of structure for dimensions and > categories, so that, dimensions and categories from different quality > frameworks can be lately reconciled: they are skos:Concepts grouped in > dqv:Dimension dqv:Category; > > - No need of abstract classes / properties. No need for > Dimension/Category subclasses. You can still use subclasses for Dimension > and Category if you want but you don’t have necessary to do it. Thus when > you have to insert a new dimension or category you can just add it as an > new instance; > > - Quite rich set of matching relations to say, this dimension is > equivalent to/a sub dimension of the one adopted by another system; > > - Quite rich set of relation to express definitions, alternative and > preferred labels, editorial notes , history note about the considered > dimension and categories. > > > > Besides, from the modelling point of view, there are other adjustments > we might consider: > > -we might want to declare dqv:Category dqv:Dimension, dqv:Metric > disjoint. > > -we are still discussing whether or not dqv:Metric should be a > skos:Concept, in that case, we will add the statement, dqv:hasDimension > rdfs:subPropertyOf skos:broader . > > > > What do you think? > > Is there any specific scenario DAQ needs to address which is not > addressable with the aforementioned SKOS modeling? > > > > > > Cheers, > > Riccardo > > > > -- > This message has been scanned by E.F.A. Project and is believed to be > clean. > > > > > > -- > > ---------------------------------------------------------------------------- > Riccardo Albertoni > Istituto per la Matematica Applicata e Tecnologie Informatiche "Enrico > Magenes" > Consiglio Nazionale delle Ricerche > via de Marini 6 - 16149 GENOVA - ITALIA > tel. +39-010-6475624 - fax +39-010-6475660 > e-mail: Riccardo.Albertoni@ge.imati.cnr.it > Skype: callto://riccardoalbertoni/ > LinkedIn: http://www.linkedin.com/in/riccardoalbertoni > www: http://www.ge.imati.cnr.it/Albertoni > http://purl.oclc.org/NET/riccardoAlbertoni > FOAF:http://purl.oclc.org/NET/RiccardoAlbertoni/foaf > -- ---------------------------------------------------------------------------- Riccardo Albertoni Istituto per la Matematica Applicata e Tecnologie Informatiche "Enrico Magenes" Consiglio Nazionale delle Ricerche via de Marini 6 - 16149 GENOVA - ITALIA tel. +39-010-6475624 - fax +39-010-6475660 e-mail: Riccardo.Albertoni@ge.imati.cnr.it Skype: callto://riccardoalbertoni/ LinkedIn: http://www.linkedin.com/in/riccardoalbertoni www: http://www.ge.imati.cnr.it/Albertoni http://purl.oclc.org/NET/riccardoAlbertoni FOAF:http://purl.oclc.org/NET/RiccardoAlbertoni/foaf
Received on Tuesday, 26 January 2016 16:12:03 UTC