> DcarchTelecons/MeetingNotes20071026

The following 522 words could not be found in the dictionary of 550 words (including 550 LocalSpellingWords) and are highlighted below:

37bfd6   abbreviate   About   about   above   ac   action   add   After   Agree   agreed   agrees   Aim   all   alot   Also   also   always   ambiguities   an   analysis   and   another   answers   any   Apart   are   area   argument   as   As   asking   assume   at   available   avoid   aware   away   backwards   Backwards   basis   be   because   been   before   beginning   being   best   better   bit   body   both   Both   btw   build   But   but   by   cached   call   can   capture   case   certain   change   changed   changes   check   circulated   clean   cleaned   cleaning   clear   closer   collaboration   comment   Comment   comments   commonalities   compactness   compared   compatibility   compatible   complete   Conclusions   configured   confused   constant   Content   content   continue   core   could   create   creates   Currently   currently   Dan   data   deal   dealing   December   decide   Decided   decision   define   depend   dependencies   description   differences   different   discussion   Do   do   doable   document   documentation   documents   draft   Draft   drafts   drive   dropped   dublincore   during   early   easily   easy   editing   end   enough   etc   even   Even   every   examples   existing   expect   extra   Fa   fairly   feedback   file   filesystem   Finalize   finalized   finish   five   Five   flashmeeting   fm   focusing   follows   for   forced   formal   format   forms   Forum   forward   freeze   friendly   from   full   further   generated   generates   get   gets   getting   given   go   goes   good   Good   great   group   had   Hans   happening   hard   has   have   Have   having   here   his   historical   hold   holder   how   However   human   idea   if   If   image   images   important   in   In   Inconvenient   informal   input   installed   interpret   interpretation   interpretations   interpretn   into   is   Is   issue   issues   it   itself   Ivan   just   kept   labor   later   lead   leave   let   like   link   links   list   live   long   look   machine   main   maintained   make   making   Makx   Management   management   manual   many   maps   maybe   Maybe   meeting   meetings   Metadata   Mgt   mgt   might   Might   Mikael   model   modified   modify   more   Most   move   moved   Moving   much   multiple   My   necessarily   need   Need   Needs   new   Next   no   Not   not   note   Note   November   now   Number   of   off   old   on   One   one   only   open   Open   opening   opinion   option   optionality   options   or   others   Otherwise   out   output   pages   parse   part   Participants   Partly   people   Pete   place   plan   Plan   plug   point   pointed   poll   position   possible   possibly   post   postponing   posts   preceded   Prepare   prepare   pressing   pretty   print   Priority   probably   problem   process   processor   produce   producing   product   profile   Propose   Proposed   Ps   public   Public   publish   Publishing   purpose   put   putting   Question   question   questions   quickly   quite   raw   readability   readable   ready   reason   reasonable   Rec   Recommendation   recommendation   Recommended   Recording   redirect   redirects   refers   regular   relatively   remain   removed   represent   requires   resolve   Resource   review   revise   risk   Sam   same   schemas   scribe   seems   separate   server   service   set   should   similar   simple   Singapore   single   site   situation   snapshots   so   Software   software   solution   solving   Some   some   something   soon   spec   specific   specification   specifications   stable   stage   stands   static   status   stored   straightforward   strong   structure   stuff   style   stylesheet   such   suggested   suggests   supported   survive   syntax   system   table   Table   take   taken   takes   telecon   temporary   Terms   terms   text   than   that   The   the   them   theory   There   there   these   they   thing   things   third   this   This   those   though   thought   time   to   To   together   Tom   too   tools   Topic   traditionally   transform   transformation   transforms   triples   true   Try   turn   Turtle   two   Two   type   uk   unexpected   Unix   unresolvable   up   upcoming   updated   use   used   useful   using   Validator   validator   version   versions   versus   very   view   vocabularies   wait   waiting   want   wanted   wary   way   ways   We   we   Website   Wednesday   week   welcome   well   were   what   What   when   where   whether   which   who   will   With   with   within   work   Working   working   worry   would   Would   year   years   your  

Clear message

2007-10-26 DC-ARCH telecon

Participants: Pete, Mikael, Tom (scribe), Hans

Recording: http://flashmeeting.open.ac.uk/fm/37bfd6-10226

1. Finalize DC-HTML for Public Comment on 5 November

Aim to put out for Website build. About ready - will post on stage area soon. Maybe Ivan feedback before public comment. Try to get out for Public Comment on 5 November.

DCAM interpretations of the existing specifications. Prepare and publish note on backwards compatibility and publish at same time? Pete to prepare something on wiki by 5 November. Mikael: let's make that a more stable type of note by time DC-HTML is finalized - Pete agrees.

Two issues:

Both of these would need to be part of document. We need to do this quickly.

Good idea to note in examples, if new URIs are used, that this refers to the upcoming decision just in case people are confused about the new URIs. Pete can put this into email. Mikael suggests also putting it into body of text -- a temporary place-holder, would later be removed.

Mikael: Backwards compatibility note is important here. Otherwise, DC-HTML should be more straightforward than DC-XML.

2. DC-XML

Mikael: we do not have a draft ready to be taken forward to Public Comment - need to make changes to existing drafts.

Conclusions from Singapore: DC-XML would be better off focusing on very straightforward and very regular "full" format and dealing with compactness at later stage. Priority: machine-friendly, easy to parse.

Pete: in Singapore, we agreed to avoid situation of too many options on table. Even within a single format we should be wary of having multiple ways to represent the same thing. We should not worry too much about the human readability of the raw syntax but assume tools will deal with human-friendly issues. This is closer to what we now call DC-XML-FULL - maybe revise this to take away some of the optionality (ways to abbreviate URIs, etc). Agree we do not have something ready to go to Public Comment.

Mikael: If DC-HTML takes November to finish, assume DC-XML version ready for Public Comment by end of year? This would probably be preceded by an updated draft circulated to the list before that. We would also need a backwards-compatibility note for this too.

There is an issue with interpretation of existing DC-XML format. Might be a good idea to have an interpretation of the old (2003) specification that follows the argument of the DC-HTML compatibility note (though not necessarily the same document). Need to have answers ready for people who will be asking questions about backwards compatibility.

Pete: DC-XML issues are different than with DC-HTML. In the XML case, format will look quite different than existing. In HTML case, similar. However, commonalities. I had thought of them as two separate documents (though they might have similar forms).

3. DC-TEXT

Mikael: Pete is using this in the DC-XML spec. Also used in DC-RDF which is Proposed Recommendation. Would be good to publish as a Note - Recommended Resource - relatively soon. Would be good to publish before DC-HTML spec gets Recommendation status. This spec is relatively stable - should just be a case of producing HTML version and putting on dublincore.org. Would be great to do this during November.

Pete: Agree with your analysis of dependencies. In terms of content, only question I have is whether to leave content pretty much as stands, where description of format is fairly informal - complete but informal - or add something like BNF description of the format.

Mikael: As long as it doesn't lead to ambiguities, can leave informal for now. Would not be hard to add the formal stuff later.

Pete: will work on getting cleaned-up up version out soon.

Tom: full set of DCTERMS documentation (decision documents, RDF schemas, HTML "DCMI Metadata Terms") may not be ready in time for 5 November, given need to check.

4. Finalize DC-RDF

DC-RDF is on hold waiting for updated DCTERMS vocabularies.

Mikael: Finalize new version during November (during Public Comment of DC-HTML) and if all goes to plan, publish DC-RDF as Rec beginning of December, maybe together with HTML document.

Pete: Question about Turtle versus RDF/XML...?

Mikael: Have thought alot about this. Decided on RDF/XML not because it is easily human-readable but because it is supported by tools - more than Turtle. One argument: wanted to use RDF validator service - take the XML examples and just plug them into the validator and get triples. Validator generates N-triples. Open to modify that but have had comments both ways - some people want both Turtle and RDF/XML. Do not have a strong opinion - will make a poll on list relatively soon opening this for comments. Apart from this DC-RDF is relatively straightforward.

5. Publishing the DSP model

Mikael: Needs to be modified a bit (work on examples). Propose to publish working draft document.

Tom: We have traditionally used wiki only for drafts and used the main SVN server for stable documents, but it has been suggested that URIs to specific versions on the wiki would be good enough to use for this purpose.

Mikael: Not reasonable to expect wiki software to survive more than five years - with risk of making URIs unresolvable. MoinMoin is not the best option from a Content Management point of view compared to others. But Content Mgt is one thing and stable URI management is another. One way of solving would be to freeze certain versions - define the URIs on the main server, but turn into redirect to wiki document. If wiki software were to change, redirects could be changed. One would need to live with differences in style. Partly a question of image: can DCMI live with links to cached images, etc?

Tom: how about we just capture the HTML file?

Mikael: requires manual labor, so not a clean solution.

Pete: in theory, should be simple but cleaning up those documents is not as simple as it should be. Table structure in wiki pages is always a problem.

Mikael: With things of Working Draft status, it is an issue of being forced to create HTML version. Inconvenient to continue editing in HTML. Some things like APs might be kept in wikis and maintained there.

[posts link to "print" version of a historical version]

What is at this URI is constant. This is a possible way of solving the redirect issue - could point to this with a redirect from the main site. This is doable, even if we decide later to put up an HTML version. This is a way of postponing the decision of making an HTML version to a later stage. I could live with this for DSP - put up a stable URI at the main server as a redirect something like the above. Five years from now, if MoinMoin were dropped, would need to change those redirects to point to URIs of the same snapshots in the new system (or to URIs of stored HTML versions if for any reason the wiki documents could not be moved forward as wiki versions). The same issue is true of HTML versions as well - depend on server as currently configured. If one were to move to a content mgt system different from Unix file system (SVN). Currently, URIs assume a static filesystem.

As for DSP... Moving to HTML too early creates extra work.

ACTION Tom: To check with Makx whether DSP draft could remain on wiki and redirect from a stable URI on the main server.

Mikael: Software will be installed when Website moved to Singapore. Need to wait for DC-XML and DC-HTML to be stable before putting DSP out for public comment. After a recommendation for DC-XML beginning of 2008 would be a good time to work on PR for DSP model.

Number of issues to resolve: documentation of terms in the format itself? Need to have a plan for dealing with those issues. Not ready to go to PC at this point.

6. GRDDL

Pete: In Singapore, we agreed to put GRDDL transforms into place for new DC-HTML - would need to take action. DanC stylesheet: need to check the RDF output of that.

Mikael: Two issues: GRDDL transform for new one (as part of the specification) and transform for the old one (as part of the compatibility note).

Pete: profile transformation for the old one is a core part of the backwards compatibility - basis for DCAM interpretation of old.

Mikael: would be useful to have a set of examples.

Pete: for new specification, would be useful to have these available so GRDDL-aware processor could be pointed to them.

7. Topic maps

Mikael: waiting for more input from Sam and his group. My view: welcome to produce something in collaboration with DCARCH, but they would need to drive discussion. Most of the discussion seems to be happening within ISO. Would be good if product is compatible with DCAM - would be good to have review from DCARCH Forum.

8. RDFa

Pete: we should have a look at RDFa syntax and possibly comment on issues such as unexpected triples being generated.

Mikael: DCMI position is pretty clear - no pressing need to produce further input to the process.

9. Next meeting

Plan to hold meetings every third week. Next meeting Wednesday 14 November.