Re: Lists of Values [OEP}

Brian

Thanks for the comments.

"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.

Height  as an example has caused problems for both you and Natasha, so it ought to be changed, at least in the final version.  I'll try to get it done in time for the first working draft.

I wanted to keep to something that was a named individual. If I can find the time, I'll switch to has_health_status: Good_health, Fair_health, Poor_health.

>
>
> 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.

I'll fiddle with them.  They come out slightly scruffy but entirely legible on my machine.   (Nothing like as neat as Natasha's but I don't have the standard Mac drawing package she uses)

Does anybody have a suggestion on a better drawing package? I am generating .jpg from PowerPoint and then resizing then cropping them with an old version of Adobe Photoshop to eliminate large blank spaces, and then pasting them in Amaya.  Amaya's resizing doesn't seem to work, so I'll try to use a higher res and resize them in a different HTML editor and see if that helps.

>
>
> 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.

I am not sure which this is referring to. I assume Pattern 1 Variant 1.
If so,  this corresponds precisely to the diagram.  But I agree, if doing it by hand, you would rarely define John's height explicitly.  On the other hand, many tools require an instance to be defined before use.

I'll try to get a third variant in in the text - if not for this version for the next.  I agree, that unless it is a side-effect of the tool one is using, defining URI's for what are, in effect, skolem constants, is tedious at best.

I'll try to get the third variant worked into the next version if there is time.

Regards

Alan


>
>
> :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.

 Thanks.  Can you be specific as to which RDF specific tools. Can I make that broad a generalisation or do I need to name which ones.  I am nervous about such broad generalisations. Or could I say "Many RDF specific tools 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.

Oops - copy-and-paste error.

>
>
> 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.

I am happy to put the information under whatever heading, but I'd like some general guidance on this from the Group..

 I think it important that people be able to view things in tools as well as look at them on paper. So I would be reluctant not to include the extra bits to make that possible someplace.

Part of the reason for the note is that not everything works in either of the common tools I use, OilEd and Protege-OWL. Sadly, I think this is generally true. I wanted to indicate which needed which.

More fundamentally,  I have trouble understanding this stuff without tools, and I suspect most other people do.  Even more I know I don't get it right without tools to check the consequences of what I do. I've been surprised by bugs too often to want to put out anything that hadn't been through tools, and there are enough variations that I think people should know which tools were used.

>
>
> Brian

Again, thanks for the careful comments

Regards

Alan


--
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

Received on Tuesday, 15 June 2004 06:52:08 UTC