Re: Problems removing hasDimension and hasMetric as abstract properties from Riccardo Albertoni on 2016-01-26 (public-dwbp-wg@w3.org from January 2016)

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