- From: Riccardo Albertoni <albertoni@ge.imati.cnr.it>
- Date: Thu, 28 Jan 2016 15:30:55 +0100
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: DWBP Public List <public-dwbp-wg@w3.org>, "Debattista, Jeremy" <Jeremy.Debattista@iais.fraunhofer.de>
- Message-ID: <CAOHhXmT_=_o7dKJ5atJWNhGfo65xPOS6-Zdj+fyzhQF_D=tuEw@mail.gmail.com>
On 28 January 2016 at 00:28, Antoine Isaac <aisaac@few.vu.nl> wrote: > Hi, > > Huge thanks to Riccardo for re-starting this discussion! > it was my pleasure ;) > > 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). > it is OK for me. > 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). > I tend to agree, BTW, I want to stress that with solution B, it is still possible enforcing the "property structure" in case the adopters need extra-properties. so solution C = B + deleting the broader subclassing sounds like a good compromise to me. Are Jeremy and the rest of the group buying into this solution? if we agree on solution C, we can claim victory on ***** https://www.w3.org/2013/dwbp/track/issues/205 Answering YES to the related question: "Should we represent dimensions and categories as instances of skos:Concept ? This would allow publishers of quality framework to express (hierarchical) relations between dimensions or categories. This could also enable to align with quality-focused categorizations less focused on metrics. Including the DWBP Best Practices dimensions, or even the parts of DQV about annotations." and we are also almost done with the issue ***** https://www.w3.org/2013/dwbp/track/issues/204 saying "Is there any reason for turning the classes dqv:Dimension, dqv:Metric and dqv:Category as well as the properties dqv:hasDimension and dqv:hasCategory into "abstract" classes and properties as they were defined in daQ ? " with solution C the answer would be NO for dqv:Category, dqv:Dimension, we haven't yet truly discussed about dqv:Metric, ... what about applying the same pattern also for metric? Cheers Riccardo > > 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 >> > > > -- > > 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
Received on Thursday, 28 January 2016 14:31:24 UTC