Re: Lists of Values [OEP}

All

Here is yet another revised version using Health rather than anything intrinsically quantitative as the quality and with, I hope, the other comments responded to.  The diagrams seem bigger now here.  I hope they come through for others.  There remain some odd things with comments some of which have come out underlined instead of italicised in some browsers for reasons I haven't had time to dig into the HTML to spot.

Comments and touch ups please. I hope this can now go out as a first working draft.

Good luck.

Regards

Alan

"McBride, Brian" wrote:

> Summary: A few comments; figure 3 must be fixed but nothing else that should
> stand in the way of WD publication.
>
> 1. I'm a little nervous about not considering datatypes lest it have an
> impact on the other approaches.  If the editors are happy the risk of this
> is small, than I'm happy.
>
> 2. Under General Issue it says
>
> [[
> 3. As datatypes. Data types will more usually be used when there is a
> literal, numeric or derived dfata types rather than when there is an
> enumerated list of values. They will not be considered further in this paper
> although a supplement may be issued.
> ]]
>
> I'm not clear what this means.  Given the worked example is height, which
> normally has a numerical value, we should be clear there is no apparent
> inconsistency.  Later it says that height means qualitative height, but this
> still feels awkward to me.  An example which does not immediately conjour up
> qualitative values might be better.  Other possible examples might be colour
> (though that risks getting caught up in the complexity of colour science) or
> severity.  How about the severity levels associated with errors, e.g. the
> Java logging values.  I'm not sure its worth the effort to change though.
>
> 3. Diagramming conventions
>
> I suppose we are aiming to have a common convention across all the notes.
>
> The diagrams are illegible in explorer on my machine, and only barely so in
> mozilla.  Need some adjustment.
>
> 4. Caption on figure 2 is overlong.
>
> 5. n3 representation of variant 1.  The comment makes the line too long.
>
> 6. representation of John's height:  Suggest using a bnode rather than a
> named resource.  Folks in the past have said that it is a pain to define
> URIs for these things.
>
> :Person
>       a       owl:Class.:John
>       a       :Person ;
>       :has_height [a :tall] .
>
> My N3 is ropey, so I may have got that wrong, but hopefully my intent is
> clear.  That is still in OWL DL, right?
>
> 7. Considerations using Pattern 1: consideration about anonymous values in
> database schema.  Might be worth mentioning that RDF specific tools
> implemented on top of databases take care of this automatically.
>
> 8. Pattern 2, first para, type "tal".
>
> 9. Representation for pattern 2.
>
> This should include example instance data, e.g. for John.
>
> 10. In pattern 1 I wonder about attaching an rdf:value property to an
> instance of Tall_value to indicate the actual height.  If I wondered about
> it, others will and might be worth saying whether or not it's a good idea.
>
> 11. I'm uncomfortable with Note1.  It suggests dropping the caps for the
> name of class.  Is that a good idea?
>
> 12. I'm concerned that the note promotes the tools used in its production
> too strongly.  I'm uncomfortable with including stuff in the protégé/OWL
> format.  I suggest Note 2 be turned into an acknowledgements section.
>
> Brian

--
Alan L Rector
Professor of Medical Informatics
Department of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL: +44-161-275-6188/6149/7183
FAX: +44-161-275-6236/6204
Room: 2.88a, Kilburn Building
email: rector@cs.man.ac.uk
web: www.cs.man.ac.uk/mig
        www.opengalen.org
        www.clinical-escience.org