Ticket #53 (new defect)
Attachment as logical containment
|Reported by:||phreedom_||Owned by:||phreedom_|
|Keywords:||mime||Cc:||mylka, pvanhoof, m4db0b|
We have two very similar, highly-correlated and, as a consequence, confusing concepts of embedding and attachment:
* HTML page can have an embedded stylesheet or svg picture, but it's "attached" form the POV of the user.
* Email can contain/embed PGP signature, but it's not an attachment from the POV of the user.
* Email can contain some document and it's an attachment from the POV of the user.
* HTML page like this ticket can have an attachment from the POV of the user, but it can reside on another server, so no containment.
The key here is "POV of the user": attachment is not about how it's stored, it's about what role it's intended to play. Attachment is a relation between InformationElements?.
Embedding is about how it's stored. Embedding is storage of "helper" resources which are used by the containing resource, but may be and often are useless all by themselves = a kind of physical containment.
If email application puts email message into its database and stores attachments as files, the current model breaks because it confuses the concepts of embedding and attachment
The proposal is to:
Remove nfo:Attachment as it fails to provide any useful properties that are specific to files embedded in messages.
nmo:hasAttachment a rdf:Property ; rdfs:comment "Links a message with files that were sent as attachments." ; rdfs:domain nmo:Message ; rdfs:label "hasAttachment" ; rdfs:range nie:InformationElement ; rdfs:subPropertyOf nie:hasLogicalPart .
This is one of issues raised in ticket:38. I'm submitting it separately to document it better and speed up the resolution.
P.S. Also I see that NCAL basically reinvents attachment. We should share the implementation between NCAL and NMO as soon as we decide on this issue