OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Re: [office-metadata] [issue] split object literals(resend)


Hi Bruce,

Bruce D'Arcus wrote:
> 
> 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.

I think we still talk about different things. But see below.

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

No, that does not distract me.
> 
> 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";

I agree. But the case I'm talking about is that I want to say something
about the text "Some Title", for instance, add the author or an
additional description. Maybe I have overseen something, but isn't the
subject in this case the text "Some title"? If so, how do you represent
this?

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

I trust you that two ex:foo nodes result in two properties in RDF/XML.
But in my example, I only have on <ex:title> element. I therefore have
one property. Or what is wrong with this example?

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

No, I did not. But probably because we are talking about different things.

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

So, do you think it is a reasonable example, if we take aside that it is
not RDFa?

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

XML ids have to be unique. That is, there must not be more than one
attributes of datatype ID that have the same value. We may of course
take some attribute datatype, but then, the fragment identifier do now
work anymore, because they operate on attributes of type ID only
.
> 
>> 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?

For the office application it is enough, because it knows that the spans
belong together. But a RDF application that processes the document takes
the two spans as different properties (correct me if I'm wrong, but
that's what you said above). So it would interpret the metadata
differently than intended.

Michael



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]