See also: IRC log
<fsasaki> no comments
<trackbot> ACTION-135 -- Pedro Luis Díez Orzas to pedro to have Giuseppe to flesh out specialRequirements -- due 2012-06-22 -- OPEN
<trackbot> ACTION-126 -- David Filip to david to come up with a proposal for mtConfidence -- due 2012-07-02 -- OPEN
<fsasaki> action-126 due to next thursday
<trackbot> ACTION-126 David to come up with a proposal for mtConfidence due date now to next thursday
<trackbot> ACTION-107 -- Shaun McCance to flesh out locale proposal -- due 2012-07-05 -- OPEN
<fsasaki> action-107 next thursday
<fsasaki> close action-141
<trackbot> ACTION-141 Table in a staging wiki page to notify current state of all data categories in terms of consensus and impl comitments. closed
<trackbot> ACTION-81 -- David Lewis to consider consolidation of author, revisionAgent and translationAgent -- due 2012-05-17 -- CLOSED
<fsasaki> close action-81
<trackbot> ACTION-81 consider consolidation of author, revisionAgent and translationAgent closed
fsasaki: By mid-July, we should decide on which data categories we need.
fsasaki: Implementation commitments to end of July
fsasaki: In september, we release an update draft version. Everyone should have a description of a prototype.
daveL: One level is a running prototype, and another level is passing the test suites. When do we need to do the latter?
fsasaki: The W3C process doesn't require that until next year. I would propose that people develop examples along with the prototypes.
daveL: Does it make sense to develop some common prototype test suites?
daveL: That might kick-start the process with developing tests. We might even start with ITS1.0 tests.
fsasaki: These are HTML5 examples
for ITS, we'll put our examples in these directories.
... These examples are simultaneously in the test files.
Maxime: Would the test output files have a repository?
fsasaki: We need to develop new
tests for new data category features
... Here's an example of a test output
... However, we don't want to force implementors to reproduce this artificial output literally.
... But it should be an illustrative example to help them.
Des: We're considering creating a
default set of 'test contents' to demonstrate the
implementation, in a complete round trip.
... it could serve as a standard set of contents that other people can work with (and is realistic)
fsasaki: We developed different
kinds of XLIFFs in various round-trips and use cases.
... We might not end up with a single 'gold standard' of data, but more a set of best practice example on what to do with metadata.
... We can start discussing this in September.
... And concentrate on the best practices
daveL: Would Adobe be a good example of what we're doing?
Des: Yes, interop of the metadata
is the main goal here.
... that would be a good way to demonstrate it, as long as it's on the agenda.
... We might not have exact applicable content, but I can participate in constructing some example content.
<fsasaki> ACTION: felix to think about a round tripping test suite data package [recorded in http://www.w3.org/2012/06/28-mlw-lt-minutes.html#action01]
<trackbot> Created ACTION-145 - Think about a round tripping test suite data package [on Felix Sasaki - due 2012-07-05].
<trackbot> ISSUE-23 -- Re-draft section 7.6. "Removal, Archiving and Re-integration of ITS mark-up" -- open
fsasaki: No comments around ISSUE-3, let's close it and keep it in mind when defining best practices
fsasaki: Any issues with closing ISSUE-23? .. No, closing it.
fsasaki: We can close these by September when we finalize these. Any comments against closing it now?
daveL: Getting data categories closed by September. It would be beneficial to be able to demonstrate a concrete pipeline (Des)
<trackbot> ISSUE-16 -- Parameter for rules -- open
<trackbot> ISSUE-24 -- Proposal to change ITS term -- open
fsasaki: I propose closing ISSUE-16 and ISSUE-24? Any comments?
shaunm: (ISSUE-16) Global parameter default may encourage bad practices, but we should discuss what would be a way to specify them.
fsasaki: Let's keep ISSUE-16 open until further discussion.
<fsasaki> scribe: fsasaki
maxime: there are two different
ways to do the mapping to RDF
... first approach would be to compute each element and attribute in XML world, then convert that into rdf
... option b) would be to transform ITS metadata in RDF, that is ITS global rules in RDF
... the google docs goes into option b
... the dom fragments refer to one fragment in the element / or attribute. Pretty similar to what is shown in the artifical output at http://www.w3.org/International/its/tests/test1/Translate1-result.xml
... question is: do we want to do that in RDF or do via option a?
... if there is no use case, we can have standard output in XML like http://www.w3.org/International/its/tests/test1/Translate1-result.xml
and transform that into a RDF/XML document
scribe: so mapping would be a simple xslt stylesheet
tadej: right now the data that we
expect in the rdf file will be for disambiguation, ne terms
... so things that don't appear in global rules
... we can defintetely work with option a) to do that
... so there is no use case in producing b)
... so we can keep the use case in mind - in dublin we discussed a lot whether it is possible
... it is possible but takes a lot of effort to implement
... so for practical purposes the option a) is easier to do
maxime: writing two options in the draft, asking for comments would be good
<DomJones> I have to leave unfortunately. Apologies. Dom
dave: going back to use cases
... obvious use case for option a is: extract connections between content and external entities
... and publish it in NIF ontology
... so that would be a way to collect the data from an ITS parser into RDF
... use case is to collect it as a language resource for other NLP components
tadej: that is one of the things
we proposed in Dublin
... I'm worried about having an end-to-end use case
... this is rather a bridge use case, not doing something with that
... if anybody can see a use to cause an implementation, it is a valid use case
... people in the localization industry won't jump into this soon, but maybe in language resources area
... sebastian wrote a long mail before the meeting describing that
... even NIF has to grow more to accomodate these use cases
... so this particular part might be delayed
maxime: for option a we would need a standard output
felix: that would be part of the recommendation
<tadej> felix: Can someone update the google doc on ITS-RDF integration to update it to standards-language?
<scribe> ACTION: maxime to write something for option b) of rdf conversion [recorded in http://www.w3.org/2012/06/28-mlw-lt-minutes.html#action02]
<trackbot> Created ACTION-146 - Write something for option b) of rdf conversion [on Maxime Lefrançois - due 2012-07-05].
<scribe> ACTION: felix to write something for option a) of rdf conversion, plus XSLT [recorded in http://www.w3.org/2012/06/28-mlw-lt-minutes.html#action03]
<trackbot> Created ACTION-147 - Write something for option a) of rdf conversion, plus XSLT [on Felix Sasaki - due 2012-07-05].
tadej: above is the list of
... I defined "entityRel" attribute to determine the relationship for the link
... a NE, term, WSD, or NE type
... only bigger mismatch is: instead of having entityRel for each type we would define individual attributes
... that's the only way to keep this part consistent
... other issue that in ITS 1.0, the attributes only mention "term"
<mlefranc> ACTION: maxime to use the standard output XML files and the already written RDF vocabulary to draft a XML->RDF/XML XSLT stylesheet [recorded in http://www.w3.org/2012/06/28-mlw-lt-minutes.html#action04]
<trackbot> Created ACTION-148 - Use the standard output XML files and the already written RDF vocabulary to draft a XML->RDF/XML XSLT stylesheet [on Maxime Lefrançois - due 2012-07-05].
tadej: i.e. term=yes, termInfo,
... so I'd propose different attributes
... at the end it is the question of markup - consistency vs. backwards compatibility
... keeping strict compatibility will lead to more markup
... more specifc, the term data category is the same
... except that we allow people to specify terminology lexcion
... and there is looser support for identifiers
<Pedro> sorry, but my micro does not work :-(
pedro, you are now not muted anymore
<tadej> Pedro: ...
<tadej> Pedro: We wanted to discuss the event in Madrid.
<tadej> fsasaki: Can we continue with this topic next week?