W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > November 2012

Re: [All] changes to provenance

From: Felix Sasaki <fsasaki@w3.org>
Date: Mon, 19 Nov 2012 09:46:38 +0100
Message-ID: <50A9F1EE.6020505@w3.org>
To: Dave Lewis <dave.lewis@cs.tcd.ie>
CC: public-multilingualweb-lt@w3.org
Hi Dave, all,

sorry for the late reply. Below sounds good to me, let's just discuss 
this briefly during today's call. I only have comments to the XLIFF file:

- We say at http://www.w3.org/TR/its20/#its-version-attribute that the 
version attribute needs to be present at the "rules" element, I added 
one in the updated version of the XLIFF file.
- The XPath expressions at "its:provRule" don't have namespace prefixes. 
I added a prefix for "urn:oasis:names:tc:xliff:document:1.2".

Updated example is attached.

Best,

Felix

Am 14.11.12 19:03, schrieb Dave Lewis:
> felix,
> OK, I appreciate the changes are complex to take on board at this 
> stage, making the logical nesting is getting very hard to read and 
> they probably don't buy us much.
>
> So we can stick to the trans/transRev version rather than using the 
> explicit activity attribute.
>
> Referring to the other changes made in:
> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Nov/0089.html 
>
>
> - made some wording updates on the description
>
>>> just wording imrpovement - should keep these
>
> - renamed the data category, actually just to provenance (the provRef
> aspect amkes it slightly broader than just agents)
>
>>> As you suggest
>
> - removed the trans/transRev subdivision and introduced a
> differnetiating flag 'activity'. Currently this just has values
> translation and translationRevision, but we can quickly add to this as
> suggested by marcis
>
>>> As you suggest, we drop this
>
> - made the use of pointer and non pointer rules mutually exclusive
> (hopefullly examples will now tell us which we really need)
>
>>> So shall we just avoid mixing them in the examples, rather than 
>>> forcably prevent mixing pointer/nonpointer in the logical structure? 
>>> I attach an XLIFF 1.2 pointer based mapping example we can use. I 
>>> think this is in fact the only real use case for global pointers for 
>>> this data category - the ones in the current examples are fairly 
>>> artificial.
>
> - allow stand off provenance records to be used in global _and_ local
>
>>> the (probably only) use case for this is to allow provenance 
>>> standoff to be used with attribute text. Actually, i think that if 
>>> we change the inheritance rule from 'include element but exclude 
>>> attributes' to 'include elements and attributes', the we can 
>>> annotate attributes well enough with local markup - it will rarely 
>>> be different from the surrounding element mark-up (unlike 
>>> mtconfidence where every string will have a different score). So we 
>>> could then drop non-pointer global rules altogether.
>
> - I broadened the language for the provRef attribute, so it can still
> point to a PROV record (specifically an entity one), but could also
> point to other records. Seeing the work starting on XML change records
> at TPAC and also seeing some convergence on a specific PEMT activity
> logging format in XML between CNGL and the CASMECAT project - it seemed
> prudent not to exclude these others (note this isn't bound to the
> activity value like the other attributes)
>
> >> as stated, this is just being prudent, not a big issue.
>
> Does this sound OK?
>
> Dave
>
> p.s. I'm checking through the other examples now also.
>
>
>
> On 14/11/2012 13:11, Felix Sasaki wrote:
>> Dave, all,
>>
>> since we only have two weeks time, I would propose to do only one 
>> change to the definition of proveance: rename "translation 
>> provenacne" to "provenace". All other changes (e.g. a different role 
>> for standoff, see the other thread) would need more time, which we 
>> don't have. It also will raise concerns from other implementors like 
>> Linguaserve, as we have just seen.
>>
>> Thouhgts?
>>
>> Best,
>>
>> Felix
>>
>>
>> -- 
>> Felix Sasaki
>> DFKI / W3C Fellow
>>
>



Received on Monday, 19 November 2012 08:47:08 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 June 2013 00:25:03 UTC