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

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

Hi Bruce,

find my notes in line.

Bruce D'Arcus wrote:
> Last week I flagged one issue to resolve (concern about broken 
> subject-object association), and here I'd like to flag a related one: 
> the problem of what to do with in-context object literals that get 
> split across document nodes.
>
> The case that Svante and Michael seem to be concerned about is this:
>
> <text:p>
>   <text:span meta:about="http://ex.net/x"; 
> meta:property="ex:title">Some </text:span>
> </text:p>
> <text:p>
>   <text:span meta:about="http://ex.net/x"; 
> meta:property="ex:title">Title</text:span>
> </text:p>
>
> So the idea here is the user means to highlight that content as a 
> single property of the specified subject.
>
> To be clear, then, this is a narrow problem specific to object 
> literals. I doubt, for example, that right now ODF allows a link node 
> to span paragraphs, and if that's true, I would the same constraints 
> would apply to objects that are resources.
>
> The first point I'd like to make is that this then suggests that the 
> ideas Svante and Michael have been proposing are not in conflict with 
> the RDFa-like approach, but supplements to that. Perhaps they have 
> been intending that all along and it has just escaped me, but I hope 
> we can clarify this.

Good that we could clarify this. Our approach is indeed supplemental to 
RDFa or whatever approach we take and intends to solve this specific 
problem. And it is therefore also not in conflict with RDFa.

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

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

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

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

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

> Bruce
>

Bests,
Svante