[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] Multiple content nodes representing on RDFsubject
Svante, Just an understanding check: So you are saying that there are discontinous (in the sense of being contained in separate ODF elements) segments of text that I want to treat as a single subject. Yes? So I need a mechanism to gather them up so that set of segments can be treated as a single entity for purposes of attaching RDF metadata. Yes? Just want to make sure I understand the example. Hope you are having a great evening! Patrick Svante Schubert wrote: > Happy new year 2007! > > Recuperated let's continue to find a solution for the handling of our > latest problem scenario: > "The content of multiple ODF nodes are represented by the content of a > single RDF XML node". > The examples later given will clarify this scenario. > > (I ignored Bernd's recent example as I received it after I finished > this mail). > > Bruce D'Arcus wrote: > >> 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. > > Just to be sure that are talking about the same scenario: > The RDF/XML example given above is a valid example about abbreviations > for RDF subjects using multiple property elements, it does not reflect > the problematic scenario I intended to show, when I started this thread. > A renaming of the predicates will clarify it: If ex:foo is the > ex:forename "one", and ex:bar is the ex:surname "two", there is no > real problem to be solved. But if one of those string literals is > split into various ODF elements - possibly scattered over the document > - our problem scenario arises. > > A example earlier in this thread showed it, where I split the name > "Bruce D' Arcus" by a table element. In the end of the mail, I picked > it up again and improved this example. > >>> 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??), > > In the opposite we might ask ourselves how shall the application > disallow it? How does an ODF metadata application should handle these > cases? > A solution embraces these scenarios, it will certain ease the life of > ODF application developers and enlarge the feature set of the end user. > Furthermore, imagine if someone receives a ODF document containing > metadata, but he has no plug-in for the contained metadata. > If there is a fall-back instance for handling unkown metadata, how > should a default plug-in be aware, if the metadata is similar to the > content (e.g. surname) or something as an 'important' flag? We can not > ignore this cases. > >> 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). > > I completely agree on this. Only standard RDF should be used. > Let us assume that to solve this scenario, the ODF application (or > it's metadata extension) would handle the scattering of a single > metadata by ODF elements as an ODF implementation detail. Splitting > and concatenation of the scattered metadata would be encapsulated by > the ODF application and shielded from RDF aware implementation, which > are only interested in the concatenated literal. > > Here a modification of the earlier used example in the thread, which > shows a draft a first design using xml:id to solve this specific > scenario: > > In the content.xml something similar to this is used : > > <text:p xml:id="_foo1">Dave </text:p> > <table:table>...</table:table> > <text:p xml:id="_foo2">Beckett</text:p> > > We have the literal "Dave Beckett" splitted by a table, which is > equivalent to the content of a metadata RDF XML node. > (Obviously there are more realistic scenarios for this problem, for > simplicity I stick on this.) > > We have in RDF XML metadata the following > <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar";> > <ex:editor> > <rdf:Description> > <ex:fullName>Dave Beckett</ex:fullName> > </rdf:Description> > </ex:editor> > </rdf:Description> > > And as an implementation detail the following - not aware for RDF > applications - a relation between the XML snipplets above: > Representing the relation of the metadata and content: > <meta:relation xml:id="_fooA"> <content> > <part xlink:href="content.xml#_foo1"/> > <part xlink:href="content.xml#_foo2"/> > </content> > <metadata > xlink:href="mymeta.xml#xpointer(rdf:Description[rdf:about='http://www.w3.org/TR/rdf-syntax-grammar']/ex:editor/rdf:Description/ex:fullName)"/> > > </meta:relation> > > In this first design step several problems and simplifications have > been neglected (e.g. content duplication). It should only show the > possibility of using such a design to solve this problem scenario. > > Regards, > Svante > > > -- Patrick Durusau Patrick@Durusau.net Chair, V1 - Text Processing: Office and Publishing Systems Interface Co-Editor, ISO 13250, Topic Maps -- Reference Model Member, Text Encoding Initiative Board of Directors, 2003-2005 Topic Maps: Human, not artificial, intelligence at work!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]