Re: ISSUE-72: Provenance Data Category - same for locQualityIssue?

Very good point, Pablo, thanks for checking. So either we change the 
test suite or the spec. We already have three implementations passing 
the HTML global test, see provenance at
http://htmlpreview.github.com/?https://raw.github.com/finnle/ITS-2.0-Testsuite/master/its2.0/testSuiteDashboard.html#conformance-classes-overview

I'll file an issue about this in tracker. Thoughts from others?

Best,

Felix

Am 22.03.13 12:37, schrieb Pablo Nieto Caride:
>
> Hi Felix, all,
>
> Yes Felix you have a point perhaps global rules are not that useful, 
> but anyway Test Suite's example provenance5html.html for instance 
> seems very valid to me (said sentence would mean modifying the Test 
> Suite examples, I can do it if this goes forward).
>
> Any other thought on this?
>
> Cheers,
>
> Pablo.
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> 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>
>         ************************************************************
>