RE: Lists of Values [OEP}

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

Received on Monday, 14 June 2004 06:34:18 UTC