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

["Bruce D'Arcus" <bdarcus@gmail.com>]

On Feb 20, 2007, at 10:57 AM, Svante Schubert wrote:

> Hi Bruce,
>
> many thanks for your instant feed-back.

Sure thing.

> 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?

OK, there are two aspects to this issue: the easy part, and the hard  
part.

The easy part is just that for in content metadata we don't want to  
use the rdf namespace. That's what I was referring to above.

The hard part is the identifier stuff: what kind of a URI (local vs.  
global) do we assign to content nodes, to represent what? Does it  
represent the ODF document object (paragraph, table, etc.) or does it  
represent the content of that object? When is it valuable to identify  
these items?

This is a deep philosophical question, ultimately, but we need to  
make a clear statement on 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

As above, does it identify the "element", or the thing described by  
that element?

> , 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.

It's still unclear, mostly because this is complicated.

>> 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. ;-)

Yes, but this isn't literal content from the model perspective. See  
below ...

>> 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?

Just a human-readable description of a resource, as opposed to the  
content of a property.

By analogy, the content of a hyperlink element is a label for the  
linked resource.

Does that make sense?

Basiclaly, what I am saying is:

1) an object literal

<meta:field
	meta:about="http://ex.net/1";
	meta:property="http://ex.net/foo";>hello world</meta:field>

triple is:

<http://ex.net/1> <http://ex.net/foo> "hello world" .

2) an object resource

<meta:field
	meta:about="http://ex.net/1";
	meta:property="http://ex.net/foo";
	meta:resource="http://ex.net/2";>hello world</meta:field>

triple is:

<http://ex.net/1> <http://ex.net/foo> <http://ex.net/2> .

In this case, "hello world" is just for display basically.

> 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.

No, you've understood correctly. We just need to tighten up the  
language a little I think.

>> 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.

OK, goes back to the need to define thee identifier smore clearly. It  
sound analogous to using xml:id, yes?

> 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?

I don't really knowing anything about them, actually. Elias brought  
that up.

To me, I've always thougth a UUID URN is a good fallback where you  
need an easy globally unique URI. We could mention that. For my area,  
there are also info URIs.

Bruce