Re: [office-metadata] Editing files post metadata

[Svante Schubert <Svante.Schubert@Sun.COM>]

Hi Bernd,

I fully agree, it is a good to separate these two requirements.
Some comments in line.

Bernd Schuster wrote:
> Hi Patrick,
> thank you for bringing back the discussion on an emotional level on 
> which constructive work can be done.
> I agreee in what you are saying with one exception:
> I propose to differentiate between the use case
> 1)  of splitting of literals, which are tagged with metadata
> and
> 2) the use case, where a given plugin is missing.
>
> because the handling of a missing plugin is a more general problem 
> which applies to many use cases, where content editing interferes with 
> metadata concerns.
>
> Given the above use cases, 2 requirements can be defined, which from 
> point of view should be added to our proposal
>
> 1) The splitting problem must be handled by the editing application in 
> that it has first to recognize that some kind of inconsistency is 
> going to occur and second it has to generate some kind of software 
> event which might be processed by a piece of software (i.e. a plugin).
In the first part we could define the splitting problem. That it might 
happen by splitting the ODF element, related to metadata. This might 
occur when:
a) forced by user interaction independent to metadata (e.g. insertion of 
a table in between)
b) forced by user interaction when metadata have intersection (e.g. 
three ODF elements (A, B, C). The content of A and B is equivalent to 
one RDF literal, the content of B and C another RDF literal.
The second part of your proposal might be no longer a requirement, more 
an implementation advise and might be neglected.
>
>
>
> 2) The use case, where a given plugin is missing must be solved by 
> some kind of default plugin which is able to handle the software event 
> adequately (Of course, one reaction of this default plugin can be 
> warning the user. But this, for me, is not in the scope of this 
> discussion.).
> Maybe the requirement can be formulated like. "The user must be at any 
> time aware of what impact his work has, or the application must 
> provide mechanisms which ensure, that the consistency of the metatdata 
> is guranteed".
Although the fallback metadata handler (default plug-in) is not direct 
part of our work (the proposal of an ODF extension for metadata), our 
proposal could ease the work for ODF applications, by providing 
flexibility and informations for later scenarios.
In this scenario the default plug-in have to handle different types of 
metadata - i.e. equal (e.g. ex:fullName) and additional (e.g. 
ex:important) - in the same consistent manner.

>
> Maybe this proposal will help us to go ahead with this subject.
>
Best regards,
Svante
>
>
> Patrick Durusau schrieb:
>> Greetings!
>>
>> I think, possibly incorrectly, that I understand at least one of the 
>> issues that Svante has been trying to raise.
>>
>> Assume that a user get a file that has already had metadata attached 
>> to the content and in the process of editing that file, splits the 
>> content that was the marked as having metadata?
>>
>> I think that is what Svante was suggesting when he said asked about 
>> the user that has no metadata plugin and is editing the file.
>>
>> To some degree I think all the examples that have been discussed 
>> presume that metadata is being attached to relatively small snippets 
>> of content that are unlikely to be split in later editing.
>>
>> Note there is no disagreement that we should be using standard RDF or 
>> that and RDFa-like mechanism should not be used when applicable.
>>
>> The question I understand that is being asked by Svante is a more 
>> subtle one about post imposition of metadata editing.
>>
>> I am not entirely sure that there is a solution that can handle every 
>> post-imposition of metadata editing issue but I think it is worth 
>> discussing. Even if the solution is to simply warn the user that 
>> metadata has been attached to the content that is being edited.
>>
>> Hope everyone is having a great day!
>>
>> Patrick
>>
>
>