W3C home > Mailing lists > Public > public-swbp-wg@w3.org > June 2004

Re: Lists of Values [OEP}

From: Alan Rector <rector@cs.man.ac.uk>
Date: Wed, 16 Jun 2004 09:30:05 +0100
Message-ID: <40D0050D.BAACCED0@cs.man.ac.uk>
To: "McBride, Brian" <brian.mcbride@hp.com>
Cc: Guus Schreiber <schreiber@cs.vu.nl>, Natasha Noy <noy@smi.stanford.edu>, best-practice <public-swbp-wg@w3.org>

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.



"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

Received on Wednesday, 16 June 2004 04:43:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:39 UTC