[Orechem] Ontology comments

[Marlon Pierce]

I am wondering about the service framework for moving these documents 
around.  We suggested an Atom Publishing Protocol-based system might 
work, but I'm concerned that there isn't a good implementation.  We 
maybe could use something like Apache Sling or maybe better MS Azure's 
Blob Service to put, get, and describe in RESTful ways.  The advantage 
to Sling however is that we could probably modify it to support OAuth 
more easily than Azure services.


And where is the triple store? 



Marlon


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.
>
> * Should / could we use chemaxiomChemDomain:MolecularEntity as the
> range of the molecular entity properties?
>
> * 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?
>
> * 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?
>
> 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?
>
> More tomorrow after more analysis!
>
> Best regards,
> jim
>
> _______________________________________________
> Orechem mailing list
> Orechem at openarchives.org
> http://www.openarchives.org/mailman/listinfo/orechem
>