search

enpkg / enpkg_graph_builder

ENPKG graph builder
GNU General Public License v3.0
1 stars 0 forks source link

enpkg:VGF138_A02_pos.mzXML enpkg:has_lcms_feature_list enpkg:VGF138_A02_lcms_feature_list_pos . #13

Closed mpagni12 closed 1 year ago

mpagni12 commented 1 year ago

I don't understand why enpkg:VGF138_A02_pos.mzXML and enpkg:VGF138_A02_lcms_feature_list_pos are considered as distinct concepts. I would merge them into a single entity and drop the predicate enpkg:has_lcms_feature_list

In addition, enpkg:VGF138_A02_pos.mzXML has no rdf:type

oolonek commented 1 year ago

The .mzXML file passes by a treatment (with specific parameters) to yield a feature list. A feature list has less information than the .mzXML.

See ex. of treatment steps below for an illustration of these steps. So they are surely two different concepts.

From (https://ccms-ucsd.github.io/GNPSDocumentation/featurebasedmolecularnetworking-with-mzmine2/)

mpagni12 commented 1 year ago

So in the near future, I can expect more than one feature list per XML file, with different parameters? If yes, it is Ok like this. Otherwise, I still don't see the necessity of introducing a one-to-one relation in the graph, that is not terribly useful.

ArnaudGaudry commented 1 year ago

Yes @mpagni12, it's possible to have multiple feature lists that originate from a single mzML. Unlikely in our current project, but feature lists and raw mzML are too different to me merged in a single entity IMO.

Adafede commented 1 year ago

Even if in the future they always remain 1:1, they are really different indeed.

Mapping the overall process would be (MS-->) RAWFILE -(conversion software + version + parameters)-> MZML -(processing sotware + version + parameters)-> FEATURELIST (-->...)