See also: IRC log
<pchampin> this is pchampin on the phone
<tmichel> sound is really bad
it's like you speak though a filter
<tmichel> Any volunteer to scribe?
wonsuk pls mute
<tmichel> http://www.w3.org/2011/01/25-mediaann-minutes.html
<tmichel> Minutes from 25/01 are approved
<scribe> Scribe: Joakim
Actions:
<tmichel> Joakim's voice is ok
close action-368
<trackbot> ACTION-368 Improve description text for ma:compression and ma:format closed
<pchampin> +1
Werner; we have examples of subtitles
close action-399
<trackbot> ACTION-399 Change from string to string and/or URI in the ontology document closed
close action-398
<trackbot> ACTION-398 Send reminder email to group to review ontology document closed
close action-401
<trackbot> ACTION-401 Implement Felix's comment in the spec closed
close action-391
<trackbot> ACTION-391 Add subtitles example - lc comment 2403 closed
Thierry: We are done with the comments for both specs
we have received comments from Marie-Carmen which has been included
comments from Werner will be included this afternoon
Werner: should we include the DFXP mappings, we have the information?
OK, Werner will provide the mapping table, and Thierry will include it
Thierry: Once we have the edits,shall we push the
ont doc to LC?
... suggest to give extra 24h hours for people who did not join the group to
vote for publication
PA: how about the discussion on definiton of compression/format attributes
<pchampin> joakim: I'm not an expert regarding format/compression
<pchampin> ... first part of the track was about the possible merging of format and compression.
<pchampin> ... As we voted previously on having both, we keep them.
<pchampin> ... The second part is about allowing strings as values or enforce URIs.
<pchampin> werner: enforcing URIs has the advantage of being more precise,
<pchampin> ... but practically, this raises problems with underlying formats that don't provide a URI.
<pchampin> ... e.g. dublin-core
<pchampin> ... David agrees to that point for descriptive metadata,
<pchampin> ... but thinks we can be more stricy for technical metadata.
<pchampin> ... He is assuming that the API would access the actual media resource,
<pchampin> ... and could therefore extract the correct URI for compression.
<pchampin> ... But we have a use case where only an external source for metadata is available.
<pchampin> ... We could add in the spec that if the media resource is available, a URI must be returned.
PA: if we stick to URI, we must say which URI's to use
Werner: we could come up with schemes to use, but, there will be many
PA: we dont' want to commit to one particualr scheme. We should be flexible enough, to map any metadata
but, if that precies information exists, it should be returned
<tmichel> compression (attName="compression", attValue="URI" | "String")
(attName="compression", attValue="URI#Name")
<tmichel> The Dublin Core uses a String
PA: If we make URI mandatory, there will be some implementations that doesn't return anything
<pchampin> ... if they lack the information to make the URI
<pchampin> ... so enforcing URIs will only reduce the amount of info available.
<pchampin> ... We should rather *encourage* implementers to return a URI whenever they can
<pchampin> ... but *allow* them to return only a string.
<tmichel> The resolution is:
<tmichel> compression (attName="compression", attValue="URI" | "String")
Thierry: Do we agree to what is in the spec?
<tmichel> +1
<wbailer_> +1
<pchampin> ... anyway, users wanting precise information will ignore strings and consider only URIs
+1
<wonsuk> +1
<tmichel> Resolution is to leave the spec as is with:
<tmichel> compression (attName="compression", attValue="URI" | "String")
<pchampin> RESOLUTION: keep the spec as it is, regarding compression: implenters can return either URI or String
<tmichel> Thierry to send email to the Group if people want to object before tomorrow before moving to 2nd LC
<pchampin> multiple values are still possible, and implementers are *encouraged* to return a URI whenever they can.
Thierry: add a note to implementers in the API spec ?
Werner: It's an API issue, it knows if it can retrieve the information
<pchampin> +1
Thierry: We will have something in the API spec to encourage implementers to return a URI
Wonsuk!
<scribe> ACTION: wonsuk for compression, implementers are encouraged to return a URI [recorded in http://www.w3.org/2011/02/08-mediaann-minutes.html#action01]
<trackbot> Created ACTION-403 - For compression, implementers are encouraged to return a URI [on WonSuk Lee - due 2011-02-15].
<tmichel> After incorporation of Werner updates and the Timed text mapping table ...
<tmichel> Does the Group votes to move to 2nd last call
<tmichel> OK to publish 2nd LC ?
<tmichel> +1
+
<wonsuk> +1
<wbailer_> +1
<pchampin> +1
Resolution: The group agrees to publish the Ontology for Media Resources specification as a 2nd LC.
Thierry will finish the editing work today ! Publication should happen on thrursday. Thierry will announce it to the group and leave 14 hours for objections.
Next meeting in California ! Have a nice trip.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: jsderber Found Scribe: Joakim Default Present: +39.538.5.aaaa, wbailer, +2105800aabb, pchampin, +39.538.5.aacc Present: Thierry Florian Pierre-Antione Courtney Werner Wonsuk Joakim WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 08 Feb 2011 Guessing minutes URL: http://www.w3.org/2011/02/08-mediaann-minutes.html People with action items: are compression encouraged for implementers wonsuk WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]