- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Thu, 28 Jan 2016 00:28:41 +0100
- To: Riccardo Albertoni <albertoni@ge.imati.cnr.it>, DWBP Public List <public-dwbp-wg@w3.org>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>
Hi, Huge thanks to Riccardo for re-starting this discussion! I'd like to add something about Solution B. We don't need to declare dqv:hasCategory a subproperty of skos:broader. This would allow to define (SKOS) hierarchies of dimensions and categories without mixing them in a single bag of concepts. Such a clearner separation can be very useful for extensions, e.g. if a specific quality concern requires to refine an existing quality dimension (say, ex:structuralConsistency as a specialization of ex:consistency). Btw I believe such extensions are more difficult with solution A. E.g., it feels odd to define ex:StructuralConsistency as subclass of ex:Consistency if that class was more or less a modeling trick and looks much like a singleton class, i.e. ex:consistency should be its only instance (which is no longer the case if there is ex:structuralConsistency instance of ex:StructuralConsistency). Cheers, Antoine On 1/26/16 5:11 PM, Riccardo Albertoni wrote: > 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 <mailto: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 <mailto:albertoni@ge.imati.cnr.it>> > Cc: Christoph LANGE <math.semantic.web@gmail.com <mailto:math.semantic.web@gmail.com>>, Antoine Isaac <aisaac@few.vu.nl <mailto: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 <mailto: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 <tel:%2B39-010-6475624> - fax +39-010-6475660 <tel:%2B39-010-6475660> > e-mail: Riccardo.Albertoni@ge.imati.cnr.it <mailto: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 <mailto: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 Wednesday, 27 January 2016 23:29:14 UTC