Re: [office-metadata] [issue] split object literals

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

On Jan 8, 2007, at 9:10 AM, Svante Schubert wrote:

>> Second, as I mentioned to Michael off-list, this problem is  
>> conceptually quite similar to a recent discussion in the TC about  
>> handling split-lists. If I am right about that, I would suggest  
>> that we treat it as a general issue rather than one specific to  
>> metadata.
>
> Right now, I see no real similarity of the metadata and the list  
> issues. Therefore I suggest that we wait how the list experts  
> indent to solve their issue, and check then whether there is a  
> similarity to a metadata use case.

David Faure was proposing an ID (IIRC list:id) that could be used on  
multiple list nodes (so xml:id would not work), to denote that they  
are in fact part of the same conceptual structure.

At the time I had mentioned that our work might overlap/conflict, but  
I wasn't quite sure. Exactly how we address the possible overlap here  
isn't that critical to me; but we do need to keep it in mind. Perhaps  
Michael has some thoughts?

>> I see two reasonable solutions:
>>
>> 1) the in-context approach
>>
>> Use an attribute like object:id. One could use the same attribute  
>> for lists as well, and so have a general solution to this problem.  
>> Where a node has such an attribute, a processor would know to look  
>> for one or more additional nodes with the same attribute value,  
>> and to treat them as a single object (list, or property value).
>
> This is a valid approach. In the case of in-content meta data:  
> Which of the nodes would actually carry the other meta data  
> attributes? All nodes, or only the first?

Probably all relevant nodes.

> Would you use the same id then referencing the nodes from metadata  
> in the package?

If referencing them from the package, probably just xml:id. Not sure;  
this is just an idea I came up with this morning.

>> 2) the package approach
>>
>> This is what Michael and Svante have been talking about, where  
>> you'd have pointers to the parts in some separate XML chunk. You'd  
>> need xml:id attributes on the property nodes to do this association.
>>
>
> Yes, that's the approach we are talking about. Using this approach,  
> if you want to have in-content metadata, you may add the additional  
> meta data to the new XML element that contains the links to the  
> property nodes.

As I have been talking about this with Michael (if I understand  
conversation correctly), the ONLY thing this XML does is link *split*  
property nodes. It would otherwise not be needed.

In other words, it is a solution to account for what I would hope  
would be the exceptional case; not the common one.

>> Both of these approaches would still need the meta attributes;  
>> they are just two approaches to solving a very narrow problem  
>> specific to using them in an office file format.
>>
>> Is the above characterization fair?
>
> Yes, it is, except that their naming is confusing. Since the two  
> approaches can be combined with in-content and with package metadata.

One never has to worry about split property nodes in RDF/XML, which  
is why I am focusing on it as a problem of the in-content encoding.

Basically, what I am proposing here is two options:

Option 1 (what I was calling in-content)
========================================

<text:p>
   <text:span object:id="xyz" meta:about="http://ex.net/x";  
meta:property="ex:title">Some </text:span>
</text:p>
<text:p>
   <text:span object:id="xyz" meta:about="http://ex.net/x";  
meta:property="ex:title">Title</text:span>
</text:p>

[note: no extra XML in the package; it's all in the content, and easy  
to process with XSLT and such]

Option 2 (what I was calling in-package)
========================================

<text:p>
   <text:span xml:id="x" meta:about="http://ex.net/x";  
meta:property="ex:title">Some </text:span>
</text:p>
<text:p>
   <text:span xml:id="y" meta:about="http://ex.net/x";  
meta:property="ex:title">Title</text:span>
</text:p>

... and in the package, using something like Michael's example:

<office:meta-subject>
   <office:part idref="x"/>
   <office:part idref="y"/>
</office:meta-subject>

[note: by default, basically, a processor would understand those as  
two statements, and would have to look up in the package whether they  
would need to merge/concatenate the literal content]

Something just occurred to me, which is that RDF actually has more  
than one kind of literal. There are also XML literals. We need to  
think about that.

Bruce