[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-metadata] Rough Proposal for RDFa + RDF/XML/XForms +xml:id
Michael, Sorry! American usage. I was agreeing with your "and" but said it poorly. Patrick Michael Brauer wrote: > Patrick, > > Patrick Durusau wrote: > >> Michael, >> >> BTW, thanks for your post on the support of "unknown" content issue. >> That was very helpful, at least for me. >> >> I look forward to hearing your explanation of your proposal as I >> don't think the choice of RDFa or RDF/XML + XForms is an either/or one. > > > I'm confused. I'm actually proposing a support of RDFa *and* > RDF/XML+Forms at the same time. > > I will attend to the call today and may say a little bit about the > proposal. But don't expect too much. It's really only a rough proposal. > > Michael > >> >> Hope you are having a great day! >> >> Patrick >> >> Michael Brauer wrote: >> >>> Hi, >>> >>> this rather long mail at its end contains a proposal for supporting >>> meta >>> data via RDF/XML+XForms, a subset of RDFa, and XML-Ids. Unfortunately, >>> this proposal is not understandable without reading the longer >>> introduction text:-( >>> >>> Svante Schubert wrote: >>> >>>> Hello Bruce, >>>> >>>> Bruce D'Arcus wrote: >>>> >>>>> >>>>> On Feb 6, 2007, at 10:14 AM, Svante Schubert wrote: >>>>> >>>>>> As far as I know there was agreement to figure out these >>>>>> advantages by providing implementations for the examples Bernd >>>>>> has given http://wiki.oasis-open.org/office/ExampleDocument. >>>>>> Do we still agree on that? >>>>> >>>>> >>>>> >>>>> I and Elias already provided tons of examples. >>>>> >>>>> <http://wiki.oasis-open.org/office/Metadata_Examples> >>>>> >>>>> I don't have time to do more. So if someone else wants to adapt >>>>> them to Benrd's page (through links or whatever) that's fine, but >>>>> it's not likely going to be me. >>>>> >>>>> I really don't think we have time for more discussion. Even if we >>>>> agree today that we need both the attribute and RDF/XML approach, >>>>> we still have a lot of work to do. >>>>> >>>> I agree that there is little time left. Believe me I try to focus >>>> with my questions on this list on the remaining problems. >>>> >>>> We might split the RDF metadata problematic into two general areas, >>>> which affect ODF >>>> >>>> 1. The subject is in the content >>>> 2. The object is a literal and in the content. >>> >>> >>> >>> I agree to Svante regarding these two general cases, but would like to >>> know if this a common understanding of the SC, or just Svante's and my >>> understanding. >>> >>> The first use case is the case where a document contains some text, an >>> image, a table cell, etc., and where the user wants to add additional >>> information about this text (for instance an annotation, author >>> information, whether it is important, and so on). It is also the use >>> case where a document is converted from other document formats, and >>> where additional information about the text, etc. that does not have a >>> counterpart in ODF should be preserved. >>> >>> My understanding is that one possibility to store these metadata is >>> - to add an id to an appropriate element that contains the text, table >>> cell, etc., and >>> - to use the either relative or absolute URI of the content.xml with >>> the >>> id attached as fragment identifier as subject in the RDF triples that >>> are stored in a RDF-XML stream next to the content.xml. >>> >>> Is that correct? >>> >>> Bruce, am I right that this is exactly what you propose in your Image >>> and Table examples? >>> >>> This first use case is actually the case where I think subjects may be >>> splitted: The user may select some text regardless of paragraph or >>> boundaries and the like, and may then attach author information to it. >>> >>> However, the only extension to the above we would need in this case is >>> the possibility to identify these selection with a singe id. That's >>> something we have to add at the ODF content level, not at the meta data >>> level. There are many option how to do that. One is the start- and >>> end-element solution we use for bookmarks already, that we may want to >>> reuse in order to remain consistent with the remaining >>> specification. But that's an issue we may work on in detail if we >>> agree that RDF-XML + ids is the right solution for this use case. >>> >>> >>> Regarding the 2nd use case: This is the use case where the literal >>> object of an RDF triple is either in the content, or displayed there. >>> >>> The task to display such content is not new in ODF. ODF therefore >>> already has concepts that we may use as basis. >>> >>> The first one are text fields. They display some text content, and >>> contain a description where this text content comes from. On the XML >>> level they are just XML elements, whose text content is the text to be >>> displayed, and that have some attributes that specify what shall be >>> displayed. >>> >>> We therefore could add a meta data field. There are two options for >>> this: First we may add attributes for the RDF subject and >>> predicates, and may define that the text content of the field is the >>> literal RDF object. I think that is very similar to a subset RDFa, >>> except that the meta data attributes are not attached to arbitrary >>> elements, but that there is a specific element that carries the meta >>> data attributes, and that these elements cannot nested. >>> >>> The other option is to have the meta data in separate stream (including >>> the literal object), and to have attributes that specify what RDF >>> literal objects shall be displayed. This takes us directly to XForms, >>> the 2nd feature that we may reuse, as Svante is pointing out: XForms >>> can >>> be used to bind controls and text fields (although we don't have the >>> later right now) to RDF objects in an RDF-XML stream. This works >>> already in ODF 1.1 (but for controls only). It therefore seems to be >>> reasonable to reuse XForms for all those cases where the metadata >>> is in a separate stream in the package, and where we want to display >>> some of the RDF objects in the content. >>> >>> If we want to reuse existing concepts, we therefore have two options: >>> 1. Some kind of RDFa-text-field as descibed above. >>> 2. RDF/XML+XForms >>> >>> Actually, I think an RDFa based text field and RDF/XML + XForms >>> supplement each other. The RDFa text field is a good choice if the data >>> duplication of literal objects is a concern, or if there is no RDF/XML >>> instance already existing. The XForms solution is a good choice if one >>> already has an RDF/XML document that should be included, if the meta >>> data is very complex, or if a strict separation between meta data and >>> office content is requested. >>> >>> I therefore propose that we support both options, and additionally of >>> cause what is required for the "subject is in the content" case. >>> >>> Best regards >>> >>> Michael >>> >>> >>> >>> >> > > > > -- 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]