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

[Bruce D'Arcus <bruce.darcus@OpenDocument.us>]

On Jan 10, 2007, at 3:39 AM, Michael Brauer wrote:

...

>> In other words, it is a solution to account for what I would hope 
>> would be the exceptional case; not the common one.
>
> First of all, what I was talking about were RDF subjects. You examples 
> are about RDF objects. So we may talk about different things actually.

What I have been showing is that there is no problem with split 
subjects, particularly if we require that the subject always be 
included on the node.

> Regarding RDF subjects: Whether splitted subjects are the common case 
> or the exceptional case depends on the documents in question and use 
> cases. What's important to me is that we cover this "exceptional" 
> case.

Yes, I understand that.

> We may of cause provide some kind of shortcut for the case that the 
> RDF subject in question consists of a single span. Whether this 
> simplifies the processing of the metadata is something we would have 
> to analyze, because we then would have two ways to address the 
> subjects/objects (or three, if we provide in-content and package meta 
> data),
> and all metadata aware applications would have to implement this.

Yes, but the whole point of what we've been arguing here is they 
implement a single model.

> Regarding RDF objects: I do understand that there are use cases where 
> a RDF object shall be displayed or shall even be editable within the 
> content. Putting the RDF object into the content is one option. Other 
> options in my opinions are to keep them separate from the content and 
> to use text fields and/or XForms to display them or to create a 
> binding between the two. Right now, I don't know what the best 
> solution is, but I think we should consider them all.

That's what we've been doing.

> But in any case, we should discuss the cases where the *RDF subject* 
> is in the content separately from the case that the *RDF object* is in 
> the content, or is displayed there. These are in my opion two 
> different aspects of the to be defined metadata feature. They must of 
> cause fit together, but the markup we define for the two aspects does 
> not have to be the same.
>
> I further would like to note that I think that it is essential that 
> RDF *subjects* can be splitted. Right now, I don't have an opinion 
> whether this also applies to RDF *objects*, because I even don't have 
> a clear opinion whether RDF objects should appear in the content, or 
> should only be displayed there as mentioned above.

As I mentioned above, and I want to underline this, there is no problem 
with split subjects in the example I posted:

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

I think you guys were getting distracted by an RDFa short-hand, which 
is that one can resolve the subject by looking at ancestor nodes. But 
that's just a short-hand.

Consider if I expand this example to include your other use case:

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

... and in the package:

<rdf:Description rdf:about="http://ex.net/foo";>
   <ex:status rdf:resource="http://ex.net/Important"/>
</rdf:Description>

There are three subjects here:

1) two blank node paragraphs
2) an external resource (another document) represent by the URI 
"http://ex.net/x";

>>>> 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.
>
> What do you mean by "worry"? That one doesn't have to care about 
> splitted property nodes, or that there will be a solution?

I mean it is not possible. RDF/XML is a more structured syntax. If you 
have two ex:foo nodes, you have two properties, without exception.

...

> As said above, I was taking about subjects rather than objects. That's 
> in fact the reason why I have called the above element <meta-subject> 
> rather than <meta-object>.

Do you understand why I keep saying we have presented a solution for 
this problem?

> The <meta-subject> element actually would appear in the content rather 
> than in the metadata. That means, I would consider the combination of 
> text spans to a single metadata subject (or object) to be a real 
> feature of the content, and not be a metadata implementation detail.

OK.

> In other words: The metadata reference a single subject. That this 
> subject does not contain the text inline, but contains references to 
> it, is the implementation detail.
>
> For the RDF subject case, the content.xml would look like this:
>
> <office:meta-subject xml:id="xyz">
>   <office:part idref="x"/>
>   <office:part idref="y"/>
> </office:meta-subject>
>
> <text:p>
>   <text:span object:id="x">Some </text:span>
> </text:p>
> <text:p>
>   <text:span object:id="y">Title</text:span>
> </text:p>
>
> The metadata would look like this:
>
> <rdf:Description rdf:about="content.xml#xyz"
>  <ex:title>My Title</ex:Title>
> </ref:Description>
>
> In the in-package case the metadata fragment would appear in some 
> stream next to the content.xml. For the in-content case one could 
> simply move the metadata fragment into the content.xml and adapt the 
> "about" URI. It is probably also possible to mix the metadata markup 
> with the content (I assume that is what RDFa does), but I don't know 
> how this will look like. Bruce, can you provide an example for this?

Yes, the example above does this. In RDFa, your example would not 
generate any triples, because a literal can only be the value for a 
property. Your text would essentially just be a label (provided by the 
user in this case) for the resource.

> Anyway, I like the idea of identifying the spans that belong to a 
> certain object by a single id as it is the case in your option 1:
>
> <office:meta-subject xml:id="xyz"/>
>
> <text:p>
>   <text:span office:belongs-to="xyz">Some </text:span>
> </text:p>
> <text:p>
>   <text:span office:belongs-to="xyz">Title</text:span>
> </text:p>
>
> The attribute that defines the id (in terms of XML) is xml:id. The 
> office:belongs-to attributes are references to this id only. Although 
> only a single id is used here, we cannot omit the 
> <office:meta-subject> element, because we need to define the id that 
> has to be unique.

Why this last requirement?

> The advantage this example has is that the application thats saves the 
> document does not need to know in advance how many <text:span> 
> elements make up a subject. ...

Yes, but I'm not clear why we need the separate subject structure. 
Isn't it enough to know that two nodes share the same id?

...

>> 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.
>
> I think this depends on whether the use cases the SC has collected 
> actually require that. My understanding is that the SC wants to define 
> a markup that allows to represent the use cases, and that RDF-XML (or 
> RDFa) are options for this, but what it is not the goal of the SC to 
> add a full RDF_XML support to ODF.

I just mean, what if the content of a literal is XML markup supported 
by ODF? I'll split this off as a separate issue.

Bruce