Re: [office-metadata] Groups - Metadata_Model_Proposal(07-02-19-ODF-MetaData.odt) uploaded

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

Hi Bruce,

many thanks for your instant feed-back.

Bruce D'Arcus wrote:
> Thanks for the work guys.
>
> On Feb 19, 2007, at 4:51 PM, patrick@durusau.net wrote:
>
>> Please send comments and suggestions along with *proposed* revision
>> language keyed to the section that you think needs revision.
>
> Some quick things that jump out:
>
> 1) Section 1.2.2
>
> a. The metadata attributes for about and property need to be in a 
> namespace other than the rdf namespace. I have typically been assuming 
> meta.
Yes, you might be correct on this. Actually, we swifted the name in the 
last hour from 'meta:id' to 'rdf:about', as we wanted to reuse existing 
tags.
I assume the rdf:about is used in a slightly different way in RDF. What 
we intended to do was to 'tag'/assign an IRI to the ODF element. 
Therefore it might be used multiple times from various vocabularies, 
which simply would relate to this ODF element via this IRI. As we 
described by this IRI always an ODF element, we suggested even to create 
a set of IRI for our purposes, to make this RDF subject/object group 
more distinguishable.
Perhaps you might give us some more details about the problem as you see 
it?
>
> b. We need a meta:resource attribute to support objects that are 
> resources (not literals) in content (like citations).
I hope this question has clarified, by the answer above. The IRI from 
the current rdf:about is describing the element it has been attached to, 
therefore it's IRI can than be used as a RDF subject or object in the 
RDF graph, from an RDF/XML file or a meta text field using RDFa.
As it was uncertain for you after reading, we should rephrase the draft 
to make it clear.
>
> 2) The field stuff is confusing to me. For example:
>> If a text literal is being created based on metadata, the text 
>> literal should be embedded into the element 'meta:text-get'.
> I can't see where a "text literal" would be "created" in any of our 
> use cases. The only agent that will be creating in-content literals 
> are users. Elias' demo is an example of this.
If the user wants to switch from a long citation formatting to a short 
citation formatting, the citation plugin will change all citation fields 
according to it's style.
If I remember correctly it was your use case, I assumed you still might 
need it. ;-)
>
> What might be created in many cases are *labels* for object 
> *resources*. The citation case is an example of this.
>
> As I have been thinking of it, there are two kinds of in-content 
> metadata statements: ones where the objects are literals (strings, 
> say), and ones where they are resources (IRIs). The former is encoded 
> using meta:about and meta:property attributes, where the content of 
> the element (or the value attribute) is the object, while in the 
> second the content of the element is just a (in many cases generated) 
> label for display.
This is possible, but don't you think that is already quite specific to 
the RDF IRI vocabulary being used?
>
> I don't have a suggested change because this section is not (yet) 
> clear to me. It might be as simple as changing the word "literal" to 
> "label" above?
Sorry, I do not fully understand. How do you define a label?
I thought that the formatting and rules being used to create the content 
of the meta text field, might be quite complex and therefore - at least 
for our first version - regarded as part of the plugin logic.
But your feedback is welcome, perhaps I have not correctly understood 
what you meant.
>
> 3) On this comment:
> [Patrick: We might want to create a own IRI ODF Schema]
>
> I doubt we need to. I suggest we might list some good ones to use 
> (LSIDs, etc.)
The idea behind was that we are always giving IRIs for ODF elements to 
describe them.. To make this clear for everyone, it might be good to use 
an own ODF element specific.
LSID might be a choice, but I am uncertain about it, did you really mean 
LifeSciencesIdentifier? Maybe you have chance to give a more details on 
this?
>
> 4) run spellcheck in U.S. English ;-)
My fault, it had been a long week-end/Monday and I simply forgot to do 
the final checking and Patrick was working on his chapter in parallel, 
so it happened. At least we were in schedule ;-)
There certainly some formal enhancements to be done, the draft is able 
to mature in the next days, but at least we have one first milestone.
>
> Will take a closer look later.
>
> BTW, I'm going to be late for the meeting this week, so will try to 
> raise any issues here.
Hope you find the time, your feedback is most welcome!

Bests,
Svante
>
> Bruce
>