Relationship between files in the manifest

[Florent Yvon]

Hello,

I am working for the DDMoRe project and there is something that we could find convenient while using COMBINE Archive specification.

We would like to have the possibility of having multiple metadata files, or more exactly 1 metadata for each data file within the archive. The current CA specification does not disallow this possibility even if it is encouraged. I understand the convenience of having 1 unique metadata file for the whole archive, but in the DDMoRe context, several different files will be generated individually with their own enclosed metadata. And I am quiet sure that these files will only be bundled into a CA at a late stage of their processing.

The main problem with this solution would be the need to read all the different metadata files by the softwares to find the one that is relevant. This could be solved by mentioning relationships between files in the manifest, like "This file is metadata of this file". What do you think about this ? Could it be an extension of the ongoing XSD file for the manifest ?


Regards,
Florent

[Frank T. Bergmann]

Hello Florent,

 

You can add actually as many metadata files to the archive as you like. You would list the individual metadata files in the manifest. Then you would use the rdf:about tag in the individual meta data files to assign them to the various locations in the manifest. For example, say you had a data file (data.csv) , and a model  (model.xml) in the archive, then you could have three metadata files in the archive as well. One with rdf:about=”.” that refers to the archive itself, one with the rdf:about=”data.csv” that describes information about the data file, and another with rdf:about=”model.xml” that describes the model.

 

I hope this helps,

All the best

Frank

 

--
You received this message because you are subscribed to the Google Groups "COMBINE archive" group.
To unsubscribe from this group and stop receiving emails from it, send an email to combine-archi...@googlegroups.com.
Visit this group at http://groups.google.com/group/combine-archive.
For more options, visit https://groups.google.com/d/optout.

[Florent Yvon]

Hello Frank,

the problem with this solution is that a tool would need to parse all the individual metadata files to find the one that is relevant for the input model, which is not convenient.

Florent

[Stian Soiland-Reyes]

The Open Annotation model
http://www.openannotation.org/spec/core/

is made just for this purpose. It also allows additional properties
on the annotation relation itself to describe its motivation (e.g.
oa:highlighting or oa:classifying) -
http://www.openannotation.org/spec/core/core.html#Motivations


In a standard for Research Object Bundle archives, we list each
annotations using the OA model:

http://wf4ever.github.io/ro/bundle/draft/#manifest-annotations


e.g. in

"annotations": [
{ "uri": "urn:uuid:d67466b4-3aeb-4855-8203-90febe71abdf",
"about": "/folder/soup.jpeg",
"content": "annotations/soup-properties.ttl" }

it means the annotations in "annotations/soup-properties.ttl" talk
about "/folder/soup.jpeg". This means you can narrow down which
annotation contents to parse - but it also means you can have
"non-semantic" annotations, e.g. a README file can be "somewhat about"
the CSV file.




COMBINE archives can co-exist as an RO Bundle having two alternative
manifests - see also the converter tool at:
https://github.com/stain/ro-combine-archive

(This tool actually picks out all subjects from the COMBINE annotation
RDF files, and generates "annotations" links as above.
Src: https://github.com/wf4ever/robundle/blob/master/src/main/java/org/purl/wf4ever/robundle/manifest/combine/CombineManifest.java#L298
)

--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718

[Stian Soiland-Reyes]

(Did you mean to CC the list..? Hope it's OK if I add it..)


On 15 September 2014 12:42, <n.len...@gmail.com> wrote:
> I agree about part of that. The relationships are metadata. They could be stored in the main metadata file. That would be one file to read (in addition to the manifest ok). Using the ro vocabulary is fine.


Yes, a reasonable approach - just using the oa: statements in the main
metadata.rdf file.

If this becomes a pattern, I can pick it up in my ro-combine translator code.


In OA - the body is "somewhat about" the target. So:

<oa:Annotation xmlns:oa="http://www.w3.org/ns/oa#"
rdf:about="urn:uuid:28d1d834-fc97-42e6-b1c5-a03b8dad6eb3"> <!--
random uuid -->
<oa:hasBody rdf:resource="annotations/about-data-csv.rdf" />
<oa:hasTarget rdf:resource="data.csv" />
</oa:Annotation>

(In this particular example, within annotations/about-data-csv.rdf,
remember to use the correct relative path for ../data.csv )


NOTE: multiple hasBody and hasTarget allowed - although multiples of
both at the same time might better be represented as several
oa:Annotations..





In manifest.xml

<content location="data.csv"
format="http://purl.org/NET/mediatypes/text/csv" />
<content location="annotations/about-data-csv.rdf"
format="http://purl.org/NET/mediatypes/application/rdf+xml" />


(The body can be in any format, but obviously semantic annotations
should be in a recognized RDF format like text/turtle or
application/rdf+xml)



Another example - here the PDF talks about 2 resources:

<oa:Annotation xmlns:oa="http://www.w3.org/ns/oa#"
rdf:about="urn:uuid:ecd69a23-b97d-4726-88e4-d1e0c636d74e">
<oa:hasBody rdf:resource="doc/article.pdf" />
<oa:hasTarget rdf:resource="model/model.xml" />
<oa:hasTarget rdf:resource="simulation.xml" />
</oa:Annotation>


If the body talks about everything in the archive in a way (or the
archive as a whole), then one would rather just use:

<oa:hasTarget rdf:resource="." />