- From: Felix Sasaki <fsasaki@w3.org>
- Date: Fri, 22 Mar 2013 12:19:09 +0100
- To: Pablo Nieto Caride <pablo.nieto@linguaserve.com>
- CC: 'Dave Lewis' <dave.lewis@cs.tcd.ie>, 'Phil Ritchie' <philr@vistatec.ie>, 'Chase Tingley' <chase@spartansoftwareinc.com>, kevin@spartanconsultinginc.com, public-multilingualweb-lt@w3.org, public-multilingualweb-lt-comments@w3.org
- Message-ID: <514C3E2D.3000505@w3.org>
Hi Pablo, Am 22.03.13 12:10, schrieb Pablo Nieto Caride: > > Hi Felix, > > It's perfect thank you! I think that Dave will agree too. > > And just one question related to Provenance. > > The sentence: > > The attribute |provenanceRecordsRefPointer|does not apply to HTML as > local markup is provided for direct annotation in HTML. Because that > information is the only one in the |provRule|element, the global rule > does not apply to HTML. > > Seems a little confusing to me, like you cannot use global rules with > HTML, but it's just a thought, what do you (everybody) think? > In HTML you have the local "its-provenance-records-ref" attribute to refer to standoff, see e.g. http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#EX-provenance-html5-local-2 The use case for provenance global rules is then there is no local markup for standoff available, like in http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#EX-provenance-global-1 since HTML has the local "its-provenance-records-ref" markup, there is no use case for HTML provenance global rules. Does this make sense? Best, Felix > Cheers, > > Pablo. > > *__________________________________* > > Hi Pablo, all, > > finally I made the edit for this. See the changelog > http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#changelog-since-20121206 > entry 23 and > http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#locQualityIssue-order > http://www.w3.org/International/multilingualweb/lt/drafts/its20/its20.html#provenanceRecord-order > > This should be it for issue-72, let me know if something is missing. > > Best, > > Felix > > Am 28.01.13 11:24, schrieb Pablo Nieto Caride: > > Hi, > > I agree with you guys, we should be consistent so the same > approach seems valid to me. Dave, I assume that we should add a > note or something about this in the spec, shouldn't we? > > Cheers, > > Pablo. > > *>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * > > Absolutely. I think we'd been assuming tis when we discussed it > for provenance records at the face to face last week, but I > realised we hadn't sought explicit consensus on this. > > cheers, > Dave > > On 27/01/2013 19:25, Phil Ritchie wrote: > > Yes, that's fine with me. We should keep characteristics like > these consistent across categories. > > Phil. > > > > > > From: Dave Lewis <dave.lewis@cs.tcd.ie> > <mailto:dave.lewis@cs.tcd.ie> > To: Chase Tingley <chase@spartansoftwareinc.com> > <mailto:chase@spartansoftwareinc.com>, > Cc: public-multilingualweb-lt-comments@w3.org > <mailto:public-multilingualweb-lt-comments@w3.org>, > public-multilingualweb-lt@w3.org > <mailto:public-multilingualweb-lt@w3.org>, > kevin@spartanconsultinginc.com > <mailto:kevin@spartanconsultinginc.com> > Date: 26/01/2013 12:51 > Subject: Re: ISSUE-72: Provenance Data Category - same for > locQualityIssue? > > ------------------------------------------------------------------------ > > > > > Thanks Chase. > > A logical follow-on question for LocQualityIssue implementors > (as the other data category with stand off markup with > multiple elements): Should we make the order of > locQualityIssue element within a locQualityIssues stand off > element reflect the order they were added in the same way? > > i.e. after the definition of locQualityIssues we add text: > "The order of its:locQualityIssue elements within a > its:locQualityIssues element should reflect the order with > which they were added to the document, with the most recently > added one listed first." > > Phil, guys? > > Regards, > Dave > > On 25/01/2013 19:37, Chase Tingley wrote: > Hi Dave, > > That sounds good. > > Thanks > > On Thu, Jan 24, 2013 at 12:41 AM, Dave Lewis > <dave.lewis@cs.tcd.ie <mailto:dave.lewis@cs.tcd.ie>> wrote: > Hi Chase, > Thanks for getting back to us on this. > > In relation to ordering of its:provenanceRecord I propose > therefore to add the following sentence to the provenance > section, after we introduce this element: > > "The order of its:provenanceRecord elements within a > its:provenanceRecords element should reflect the order with > which they were added to the document, with the most recently > added one listed first." > > Can signal whether you are happy with this? > > Then given, your comments also on the time annotation issue > below, I think I will be able to close this issue. > > thanks again for this comment, > Regards, > Dave > > > On 23/01/2013 18:17, Chase Tingley wrote: > Hi Dave & Pablo, > > Thanks for the responses. Comments inline > > On Tue, Jan 22, 2013 at 5:39 PM, Dave Lewis > <dave.lewis@cs.tcd.ie <mailto:dave.lewis@cs.tcd.ie>> wrote: > Hi Chase, Kevin, all, > First thanks to Pablo for his response. Some further responses > inline below related to timing: > > On 15/01/2013 17:33, Pablo Nieto Caride wrote: > > Hi Felix, all, > > >ii) Similarly, does the ordering of provenance records within a > <provenanceRecords> element make a statement about the > (temporal) order in which the records were created? If an > ordering is implied, it raises questions about the implied > ordering in a document where provenance records are declared > both globally and via local markup. > > Certainly the spec does not talk about temporal order, but > given that records cannot be declared both globally and via > local markup for a single element, the way I see it, and to > simplify things, each provenance record should be older than > the previous one. > > I think the best we can do is offer best practice advice that > the order with which more than one its:provenanceRecord are > listed in its:provenanceRecords element should reflect the > order they were added to the document rather than the order in > which the translation(revision) actually happened. > > Pablo, could you confirm that you intend the oldest one to be > listed last? > > I don't think we can mandate that the order indicated the > order in which the activity indicated in the record > (translation or translation revision) were preformed. This > information may not be available to the processor adding the > annotation. For example a TMS may add this annotation after > receiving translation revisions from two different translators > both for multiple elements but without per element timing > information, so it wouldn't know the order in which the actual > revisions were performed. Alternatively their timings may be > known for different elements, but they overlap in time, so > there wouldn't be an obvious order for the records. > > I think this makes sense. It's more important to me that the > overall semantics be clear than that the ordering work one way > or another. Just the knowledge that, for example, provenance > records are more like a list than a bag is an important detail. > > >iii) More generally, we observe that provenance records lack a > date/time attribute, which makes their semantics as a form of > history somewhat muddy. In practice, a single tool/agent may > edit a single document multiple times in succession over an > arbitrary period of time. Should these multiple "sessions" be > represented by a single logical provenance record? Or is it > the intention of the spec that the agent add a provenance > record for each of these sessions in which a modification is > made to the document? > > As I said in the previous point any modification of the > content should add a new provenance record, at least is what I > had in mind. > The original requirements for the proveance data category > primarily were intended to identifiy and differentiate the > _agents_ involved in translation or revising translations > different parts of a document. Its not clear what would be the > best form of timing information. Should it be the period over > which the agents conducted the translation(revison) or the > instance in time at which they completed it. As indicated > above, even just determining the ordering, let alone the > absolute timing of the activity, can be complicated, and would > require collection of this information to be pushed downstream > to CAT tools that aren't otherwise ITS aware. This might > present an implementation barrier if correct timing was mandated. > > Yes, you're right that this gets very messy when you consider > aggregating provenance data from multiple agents that may have > been processing in parallel. The main point I wanted to > clarify was that the purpose of the data category was to > identify agents as opposed to "processing events". I think > this is enough for now. > > Thanks! > > > > > > > ************************************************************ > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to > whom they > are addressed. If you have received this email in error please > notify > the sender immediately by e-mail. > > www.vistatec.com <http://www.vistatec.com> > ************************************************************ >
Received on Friday, 22 March 2013 11:19:39 UTC