[Orechem] Ontology comments

[Carl Lagoze]

Jim,

Thanks for looking at things and the questions.  Responses below.
On Nov 4, 2009, at 12:03 PM, Jim Downing wrote:

> Hi Carl, all,
>
> We've been looking through the ontology and had a few comments.
> Apologies if these have been asked and dealt with before now, I'm only
> just getting up to speed with the ontological modeling.
>
> * The "referencesExperiment" and "referencesMolecularEntity"
> predicates seem misplaced. If these are references, shouldn't they be
> subPropertyOf references, rather than aggregates? We probably need
> both - we might want to link to an entry on PubChem for a molecule and
> / or to a data file that is part of the enhanced publication.

I see your point here.  It probably should be both.  I do want it to  
be a sub-class of 'aggregates' because the two entities should be part  
of the compound document.

>
> * Should / could we use chemaxiomChemDomain:MolecularEntity as the
> range of the molecular entity properties?

Yes, I was thinking of that myself.  I was hoping for guidance from  
you guys on this area.

>
> * There's something screwy going on with the dcterms in protege - they
> seem to be sub-classes of themselves - any idea what's going on?

Frankly, none of these %$##@!! RDF/tools work as you want them to.   
They seem to have problems when you move from orthodox owl to messy  
owl and rdf like I have.  dcterms is messy rdf unfortunately.

>
> * The hasDataRepresentation/hasFigure, hasTable, hasDataSet seems
> either too detailed or too brief - if tables, why not sections,
> appendices etc, which will be also be useful for our analysis?

Note that these are subclasses of hasComponent that is a subclass of  
ore:aggregates.  I wanted to make the components of the compound doc.  
but semantically distinct aas "things within".   There may be better  
ways I recognize.

>
> In my mind this is related to the issue of whether we include
> "aboutness" semantics - I think we need to if we want to represent a
> full provenance chain for the distributed process (which would be very
> cool to do). I'd imagined something like: -
>
> psu:publication1 orechem:hasComponent psu:narrative1.ps .
> psu:narrative1.ps orechem:hasComponent soton:experimentalSection1 .
> soton:experimentalSection1 orechem:about cam:moleculeX .
> cam:moleculeX a chemaxiom:MolecularEntity ; orechem:referenceMolecule
> crystaleye:actae/foo/bar/234 .
> iu:gauin1 a chemaxiom:ComputationalInput; orechem:derivedFrom  
> cam:moleculeX .
> iu:gauout1 orechem:derivedFrom iu:gauin1.
>
> To do this I get the impression we need to use classes from chemaxiom,
> and to define some more of our own.
>
> * In a sense we are generating multiple, incrementally enhanced
> manifestations of the same work. Bibo doesn't seem to have the power
> to describe the FRBR notions of Work, Manifestation and Representation
> as separate, related abstractions. Do we need to?

Note sure of wisdom of going to this level of complexity yet.  We can  
go there in the future and migrate to it as long as we do something  
machine readable and unambiguous now.  Other people have covered the  
FRBR stuff including CIDOC/CRM and my own abc stuff.

BTW, bibo 1.3 just came out but haven't had time to look at it.
>
> More tomorrow after more analysis!


Later.
>
> Best regards,
> jim
>
> _______________________________________________
> Orechem mailing list
> Orechem at openarchives.org
> http://www.openarchives.org/mailman/listinfo/orechem