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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-metadata message

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


Subject: Re: [office-metadata] Multiple content nodes representing on RDF subject



Hi Michael,

On Dec 28, 2006, at 12:09 PM, Michael Brauer wrote:

> the intention behind Svante's example was to show that there is no
> one-to-one relation between XML elements and RDF subjects. An RDF  
> subject actually may be composed of several XML elements. This is  
> at least the case if the subject is a text fragment. That's the  
> reason why Svante proposed to add something like a <content>  
> element that combines the individual <text:span> elements into a  
> single RDF subject.

Yes, I understand the problem (I think). I just don't agree with the  
solution :-)

The way that one binds statements to a subject in RDF is through the  
names you give the subjects; the URIs.

For example, from the RDF perspective, this ....

<rdf:Description rdf:about="x">
   <ex:foo>one</ex:foo>
</rdf:Description>

<rdf:Description rdf:about="x">
   <ex:bar>two</ex:bar>
</rdf:Description>

... is fully equilalent to this:

<rdf:Description rdf:about="x">
   <ex:foo>one</ex:foo>
   <ex:bar>two</ex:bar>
</rdf:Description>

The reason is because you're using the name/URI to do the  
association, and each property is -- from the model standpoint -- a  
discrete statement about that resource. It doesn't matter where it is.

Svante was wanting to use a completely different mechanism (XPointer)  
to do association that will not mix well here.

> I agree that in his example it would be valid to interpret the  
> three <text:span> elements as individual subjects, but I don't  
> think this is valid in all cases. If the meta data is for instance  
> a description of some text (for instance for accessibility  
> purposes), then you must not break the text into pieces, because  
> this changes the meaning.

I think the practical use case examples here are useful. Can you  
explain this a bit more?

When I wrote the accessibility use case, I was thinking of fairly  
simple examples, like an embedded image includes a fuller RDF/XML  
description in the package that can be used to present further  
information to the user.

An analog for the in-content case might be if a document has a link  
to a client resource. So maybe we have:

<text:p xml:id="1">Some client <text:link meta:resource="http:// 
ex.net/people/1" meta:property="ex:client">Jane Doe</text:link>

There might be further metadata in the package that can be useful for  
accessibility purposes to present further information about the  
resource named <http://ex.net/people/1> (and labeled "Jane Doe").

So the question is, how to identify the subject, such that one can  
make further statements about that subject elsewhere in the document.

One answer is meta:about.

> Other cases are annotations that may be added to arbitrary text the  
> user selects, and which may include paragraph breaks. And I'm sure  
> there are other use cases where an RDF subject must consists of  
> several XML elements. Please let me know if you would like to have  
> more detailed examples for this, and I will provide them next year.

See above. Some more detailed examples of the problem would be helpful.

On annotations, for example, I would expect to do:

<text:p xml:id="1">...</text:p>

... and:

<rdf:Description rdf:about="content.xml#x">
   <ex:foo>one</ex:foo>
</rdf:Description>

IF we want to allow the user to select text that spans paragraphs and  
then to annotate THOSE (do we??), then I agree we might have to do  
some gymnastics. But I'd prefer to keep them standard RDF (and get  
some feedback from the RDF experts on it).

Not sure, but maybe something like:

<text:p xml:id="1">...<text:span xml:id="2">beginning, and ...</ 
text:span></text:p>
<text:p xml:id="3"><text:span xml:id="4">end.</text:span>...</text:p>

<rdf:Description rdf:about="content.xml#2">
   <ex:foo>one</ex:foo>
</rdf:Description>

<rdf:Description rdf:about="content.xml#4">
   <owl:sameAs rdf:resource="content.xml#2"/>
</rdf:Description>

As I said, I'd want some feedback from people like Elias and Dan on  
this, but I do think there are ways to address it.

> I think we have to consider this, regardless whether the preferred  
> solution is RDF/A or RDF/XML files in a package.

Agreed.

> Earlier in this thread you wrote
>
> > Note that there's no way to derive this statement from what you
> > presented above. All you are doing above in the XML is  
> identifying the
> > node (as a *possible* subject).
>
> I personally think to have the possibility to add IDs (or similar  
> attributes) to identify *possible* subjects is important, because  
> this allows to add meta data to a document without touching the  
> content.xml stream.

Correct.

> That's why I personally think that we must have the possibility to  
> assign meta data to subjects in the content.xml by IDs. Please note  
> that this does not mean that we may not have something like RDF/A's  
> inline attributes in addition, if we find use cases where they are  
> advantageous or required (that's something we should discuss  
> separately), but only that I think that RDF/A's inline attributes  
> are not sufficient. If I did understand Elias correctly, then RDF/A  
> includes the possibility to assign meta data using IDs.

Yes. The xml:id identifies the content node. The meta:about would  
identify other subjects that are described with the content node. In  
his example, you would use the about attribute to identify the row.

Think also of:

<text:p xml:id="1" meta:about="http://ex.net/patients/1";>...</text:p>

... and:

<rdf:Description rdf:about="content.xml#1">
   <ex:status rdf:resource="http://ex.net/status/Important"/>
</rdf:Description>

<v:VCard rdf:about="http://ex.net/patients/1";>
   <v:fn>Jane Doe</v:fn>
</v:VCard>

Does that make sense?

> Best wishes for 2007!

You too!

Bruce


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