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

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