IRC meeting minutes - 05/30

[Svante Schubert <Svante.Schubert@Sun.COM>]

Here are the rough IRC notes we made during the call.

Participants on IRC:

Elias Torres
Gary Edwards
Patrick Durusau
Svante Schubert


Participants on phone:

Gary Edwards
John Madden
Patrick Durusau
Svante Schubert


Note:
In the end of the log - just after the call - Elias confirmed that in 
content RDF is the only way to use content literals as metadata without 
duplicating them in the RDF/XML files.

Svante





Session Start: Wed May 30 10:50:08 2007
Session Ident: #odf-metadata
[Wed:16:59:38] * EliasT has joined #odf-metadata
[Wed:16:59:43] <EliasT> hi Svante,
[Wed:16:59:49] <Svante> Hi Elias
[Wed:16:59:50] <EliasT> I'm overloaded with work, but I'll stay here on IM
[Wed:16:59:56] <EliasT> if you have any questions..
[Wed:17:00:15] <Svante> Ok. Thanks for coming
[Wed:17:05:37] * patrick has joined #odf-metadata
[Wed:17:11:34] * garyedwards has joined #odf-metadata
[Wed:17:12:35] <Svante> Our issue list of today:
[Wed:17:12:36] <Svante> Issues List
[Wed:17:12:36] <Svante> 1.7 PathName in the Manifest	
[Wed:17:12:36] <Svante> 1.8 in the content vs. in content	
[Wed:17:12:36] <Svante> 1.9 Redefinition of Content for text:bookmark-start	
[Wed:17:12:36] <Svante> 1.10 Standalone element <text:bookmark/> should not be alloed to use in-content attributes	
[Wed:17:12:36] <Svante> 1.11 Removal of the word 'Root element' 	
[Wed:17:13:03] <Svante> .
[Wed:17:13:10] <Svante> 1.7 PathName in the Manifest
[Wed:17:13:10] <Svante> In section 1.1.1 Declaration of Metadata Files in the Metadata Manifest, the following reference occurs to the metadata manifest file: “The metadata manifest file shall be stored at the pathname /manifest.rdf.”
[Wed:17:13:10] <Svante> That is incorrect. A pathname does not include a filename. The path should be defined with reference to the ODF package and separately the name of the manifest file defined. 
[Wed:17:13:10] <Svante> (Patrick Durusau)
[Wed:17:13:10] <Svante> Resolution
[Wed:17:13:27] <Svante> .
[Wed:17:15:58] <Svante> The metadata manifest file is stored as '/'. The metadata manifest file shall be named "manifest.rdf".
[Wed:17:16:17] <Svante> Patrick suggested wording ^^
[Wed:17:16:33] <Svante> .
[Wed:17:16:56] <Svante> Next issue 1.8
[Wed:17:16:57] <Svante> in the content vs. in content
[Wed:17:16:57] <Svante> Minor editorial change. In 1 and 1.1, the phrase “in the content of the document” is used. 
[Wed:17:16:57] <Svante> (Patrick Durusau)
[Wed:17:16:57] <Svante> Suggest simply “in content of the document.”  
[Wed:17:16:57] <Svante> Resolution:
[Wed:17:17:21] <Svante> all: No objections from the group
[Wed:17:17:27] <Svante> .
[Wed:17:17:31] <Svante> Next issue 1.9
[Wed:17:17:40] <Svante> Redefinition of Content for text:bookmark-start
[Wed:17:17:40] <Svante> Usually xml:id and m:about/m:property refer to the content of the OpenDocument element, that is not correct for text:bookmark-start, which is a stand-alone element. (John Madden)
[Wed:17:17:40] <Svante> On two locations we reconsider wording: 1.2.2 mentioning "...the literal content of the OpenDocument element" and 1.1.1 "...the content literal of the OpenDocument element the RDF object."
[Wed:17:17:40] <Svante> Suggestion: Add “..in case of bookmarks the RDF literal is between the text:bookmark-start and text:bookmark-end element.”
[Wed:17:17:40] <Svante> Resolution:
[Wed:17:23:19] <Svante> Patrick suggestion to add: "In the case of bookmarks the content literal is between <text:bookmark-start/> and text:bookmark-end/>,"
[Wed:17:23:49] <Svante> Suggested wording: In the case of bookmarks the content literal is between <text:bookmark-start/> and text:bookmark-end/>.
[Wed:17:24:37] <Svante> No objections from the group.
[Wed:17:24:37] <Svante> .
[Wed:17:24:39] <Svante> .
[Wed:17:24:46] <Svante> Next issue 1.10
[Wed:17:24:48] <Svante> Standalone element <text:bookmark/> should not be alloed to use in-content attributes
[Wed:17:24:48] <Svante> Currently an empty text:bookmark element is allowed to use the in content metadata. It makes no sense to allow a m:data-value when there is no content. (Svante Schubert)
[Wed:17:24:48] <Svante> Suggestion: Remove text:bookmark from the list of in-content attributes (m:about/m:property/m:data-type/m:data-value), but still allow the use of xml:id for metadata on all bookmarks.
[Wed:17:24:48] <Svante> Resolution:
[Wed:17:25:00] <Svante> Elias ^^
[Wed:17:25:25] <Svante> This might interest you, but it is just that we allowed metadata on an empty element.
[Wed:17:25:58] <Svante> Correction ^^
[Wed:17:26:07] <Svante> This might interest you, but it is just that we allowed IN-CONTENT metadata on an empty element.
[Wed:17:26:44] <Svante> Proposal: We would remove this stand-alone element from the set of in-content metadata elements
[Wed:17:27:19] <EliasT> I'm here.
[Wed:17:27:41] <EliasT> which element?
[Wed:17:27:45] <EliasT> text:bookmark/
[Wed:17:27:47] <Svante> EliasT this is about the stand-alone bookmark elmeent
[Wed:17:27:49] <Svante> yes
[Wed:17:28:12] <EliasT> we allow IN-CONTENT metadata? meaning what? m:about m:property?
[Wed:17:28:22] <Svante> Which has not text content, what was mistakenly assumed earlier. Yes, currently we do
[Wed:17:28:27] <Svante> We want to fix that
[Wed:17:28:44] <EliasT> only allow what?
[Wed:17:28:46] <EliasT> xml:id?
[Wed:17:29:03] <Svante> Yes, to allow metadata on all possible bookmarks
[Wed:17:29:15] <EliasT> sounds good. if that's what bookmark is used for...
[Wed:17:29:23] <EliasT> let's attach metadata to the bookmark not its content
[Wed:17:29:41] <EliasT> we can later solve the problem of attaching metadata to the content of the bookmark.
[Wed:17:29:52] <EliasT> did I understand the issue correctly?
[Wed:17:30:23] <Svante> The bookmark-start and bookmark-end still have in content metadata, but not the stand-alone marker.
[Wed:17:31:04] <EliasT> examples of all of those three?
[Wed:17:31:14] <EliasT> a short one..
[Wed:17:32:06] <Svante> SemiShort ->
[Wed:17:32:07] <Svante> <text:p>
[Wed:17:32:07] <Svante> 	<text:bookmark-start text:name="Mark 1" xml:id="ID_SELECTION"/>	First part selection
[Wed:17:32:07] <Svante> </text:p>
[Wed:17:32:07] <Svante> <text:p text:style-name="P1">
[Wed:17:32:07] <Svante> 	Middle part of selection
[Wed:17:32:07] <Svante> </text:p>
[Wed:17:32:07] <Svante> <text:p text:style-name="P1">
[Wed:17:32:07] <Svante> 	Last part of selections
[Wed:17:32:07] <Svante> 	<text:bookmark-end text:name="Mark 1"/>
[Wed:17:32:07] <Svante> </text:p>
[Wed:17:32:31] <Svante> Three paragraphs where the content is embraced by bookmarks (end/start) version
[Wed:17:33:21] <Svante> Stand alone version:
[Wed:17:33:22] <Svante> <text:p text:style-name="P1">
[Wed:17:33:22] <Svante> 	Important note <text:bookmark text:name="I-Note"/>
[Wed:17:33:22] <Svante> </text:p>
[Wed:17:33:48] <Svante> Just a 'jump address' for the application
[Wed:17:34:33] <Svante> The above would allow xml:id and in-content metadata the latter standalone one xml:id (to be able use bookmarks all together in a metadata scenario describing bookmarks).
[Wed:17:35:36] <Svante> EliasT? Does this clarify the difference and the reason for our chance? 
[Wed:17:38:19] <Svante> Exchange the line with bookmark-start above with the following:
[Wed:17:38:20] <Svante> <text:bookmark-start text:name="Mark 1" m:about="someIRI" m:property="someIRI" xml:id="ID_SELECTION"/>	First part selection
[Wed:17:38:46] <Svante> Now it has m:about/m:property, which is still allowed
[Wed:17:39:28] <EliasT> I'm back.
[Wed:17:39:30] <EliasT> sorry sorry
[Wed:17:39:34] <EliasT> looking
[Wed:17:40:03] <EliasT> why does start and end need content?
[Wed:17:40:21] <EliasT> what's object literal for?
[Wed:17:40:28] <EliasT> <text:bookmark-start text:name="Mark 1" m:about="someIRI" m:property="someIRI" xml:id="ID_SELECTION"/>
[Wed:17:40:31] <EliasT> in that one
[Wed:17:41:43] <Svante> The content between start and end
[Wed:17:42:36] <EliasT> and end?
[Wed:17:42:37] <Svante> Actually this was issue 1.9, where we redefined
[Wed:17:42:38] <Svante> 1.1.1In the case of bookmarks the content literal is between <text:bookmark-start/> and text:bookmark-end/>,
[Wed:17:42:49] <EliasT> can end have m:about and m:property?
[Wed:17:43:09] <Svante> No, as it is defined by text:name
[Wed:17:43:19] <Svante> No, as the binding to the start is defined by text:name
[Wed:17:43:53] <Svante> And m:about/m:property/m:data-value/m:data-type and xml:id is only on start
[Wed:17:44:46] <EliasT> k. soudns good to me
[Wed:17:44:51] <Svante> Great!
[Wed:17:44:53] <EliasT> and xml:id on standalone
[Wed:17:44:59] <Svante> Exactly
[Wed:17:45:11] <EliasT> good good
[Wed:17:45:18] <EliasT> don't mind me.. then carry on
[Wed:17:45:35] <Svante> We are through with our issue list, thank you Elias
[Wed:17:45:47] <EliasT> cool
[Wed:17:46:09] <Svante> Resolution 1.10: Agreement of the group
[Wed:17:46:27] <Svante> One more..
[Wed:17:46:35] <Svante> Minor issue..
[Wed:17:46:38] <Svante> 1.11 Removal of the word 'Root element' 
[Wed:17:46:38] <Svante> From the earlier manifest description the wording “root element” still exist in a subchapter of 1.1.1
[Wed:17:46:38] <Svante> “The metadata manifest describes the metadata files of the OpenDocument package in RDF/XML. Its root element <odf:Package> represents the OpenDocument package itself. “
[Wed:17:46:38] <Svante> This is wrong as the root element could be <rdf:RDF>. (Svante Schubert)
[Wed:17:46:38] <Svante> Suggestion: Remove the string “Root element”.
[Wed:17:46:38] <Svante> Resolution:
[Wed:17:47:41] <Svante> Proposal: Just removing the XML related substring "Root element"
[Wed:17:47:52] <EliasT> good
[Wed:17:48:34] <Svante> Resolution on 1.11 as propsed
[Wed:17:48:46] <Svante> EliasT: Patrick and I are going to send out a new draft today
[Wed:17:49:22] <Svante> We should sent the upcoming draft out for review, after the update today
[Wed:17:50:30] <EliasT> excellent.
[Wed:17:51:51] <Svante> byebye
[Wed:17:52:11] <Svante> EliasT one more question from my side..
[Wed:17:52:15] <EliasT> k.
[Wed:17:52:49] <Svante> Is there any way to use a literal from a ODF content without duplicating the string in RDF/XML by using the xml:id approach?
[Wed:17:53:09] <EliasT> don't understand...
[Wed:17:53:11] <Svante> Example:
[Wed:17:53:25] <EliasT> <text:span m:about="" m:property="">foo</text:span>
[Wed:17:53:25] <Svante> <text:p xml:id="id">Elias Torres</text:p>
[Wed:17:53:40] <Svante> With RDFa it is the common way to solve it
[Wed:17:54:04] <Svante> My question is, would there be any chance to do the same going for the xml:id approach?
[Wed:17:54:20] <EliasT> haven't thought about it.
[Wed:17:54:46] <Svante> As we have this odf:content property, that is used implicitly to bind the element content to the IRI (from the xml:id element)
[Wed:17:55:31] <Svante> The question came up to me, when I wanted to suggest different ways in solving a problem. The problem was that a string from the ODF content was equal to a metadata literal and should not be duplicated
[Wed:17:55:48] <EliasT> it shouldn't..
[Wed:17:55:55] <EliasT> it's in an in-memory model.
[Wed:17:56:20] <Svante> <text:p xml:id="id">Elias Torres</text:p>
[Wed:17:57:05] <Svante> Imagine that "uri:paraEliasIRI" is bound to xml:id using "id" by the metadata manifest
[Wed:17:57:34] <Svante> How can I say that the content of that paragraph is a vCard:FN?
[Wed:17:57:51] <Svante> It seems impossible
[Wed:17:58:09] <EliasT> ah.. I see..
[Wed:17:58:21] <EliasT> that's why we need m:about m:property
[Wed:17:58:24] <EliasT> that's EXACTLY why
[Wed:17:58:34] <Svante> I just wanted to be sure ;-)
[Wed:17:58:35] <EliasT> you trying to sovle it with xml:id is like going backwards in time.
[Wed:17:58:39] <EliasT> :-)
[Wed:17:58:56] <Svante> Have nice afternoon, Elias! That's all from me for today...
[Wed:17:59:01] <EliasT> you're welcome!
[Wed:17:59:03] <EliasT> later.
[Wed:17:59:07] <EliasT> next week then
[Wed:17:59:16] <Svante> yes. 
[Wed:17:59:24] <Svante> byebye
[Wed:17:59:27] * EliasT has left #odf-metadata