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

RE: [ACTION-256]: Compile and circulate itsTool examples togehter with proposal text

From: Yves Savourel <ysavourel@enlaso.com>
Date: Wed, 7 Nov 2012 06:10:11 -0700
To: "'Felix Sasaki'" <fsasaki@w3.org>, "'Dave Lewis'" <dave.lewis@cs.tcd.ie>
CC: "'Jirka Kosek'" <jirka@kosek.cz>, <public-multilingualweb-lt@w3.org>
Message-ID: <assp.06581b27a1.assp.0658773b39.00a401cdbce9$37ff1c00$a7fd5400$@com>
Sorry if I misled you Dave: I though the email I answered was an outcome of the F2F rather than an input. My bad.

 

It seems to me that tool and version could be easily encoded in a URI without end-point.

But can that be done for MT confidence as well? It seems there are 3 information for that data category: tool, version and some engine identifier. I suppose that could be encoded. But I haven’t seen examples.

 

-yves

 

 

From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: Wednesday, November 07, 2012 5:54 AM
To: Dave Lewis
Cc: Jirka Kosek; public-multilingualweb-lt@w3.org
Subject: Re: [ACTION-256]: Compile and circulate itsTool examples togehter with proposal text

 

 

2012/11/7 Dave Lewis <dave.lewis@cs.tcd.ie>

Hi Felix,
Yes, the URI pointer work in most cases, but this is to address the case where we want to embed the target of the pointer in the file (based on the case linguaserv brought up in Lyon, where they may be able to ammend file but can add new ones to a client's CMS, so it problematic to mandate an external file only) and it is HTML file, so a simple element fragment URI won't work.


Why?
 


We are also, I guess, trying to make the solution a similar as possible to the stand-off markup case to ease implementation.



That means that we require the "end" of the URI to be XML. I would oppose to that. Either we say "anything can be on the other end of the URI", or  we speciy what is here. About the Linguaserve case: as Jirka noted, we can leave that use case implementation defined - it would simplify a lot about the HTML processing.

Best,

Felix
 


cheers,
Dave






On 07/11/2012 11:26, Felix Sasaki wrote:

Hi Dave, all,

apologies, I'm behind things. I thought we'd agreed at the f2f meeting that there is just an URI pointing to tool information, nothing else. See
http://www.w3.org/2012/11/02-mlw-lt-minutes.html

[

Felix: You could have a seperate script element for each standoff item.

… pitty Yves cannot be on the phone. He has raised concerns: anything possible, tool with element it in, or define a schema. There is a drawback that you restrict people to xml processing, what about the case of RDF or audio. Does everyone who needs the element need XML?

...

<fsasaki> "Disambiguation|file:///tools.xml#T2" > "Disambiguation|http://enrycher.com/v1.2/language-en"

Felix: Paste proposal into chat, from Yves, this URI itself is just a URI, no further information, self-contained in the URL. This tool is X, in Lang Y, in the URL where each tool can create the tool itself. But in a large document this is the list of annotation with URI = tool1, URI = tool2. Dont restrict the URI being retrieved and XML removes this restriction.

Dave Lewis: Naoto has interest in this.

… any other comments else I'll take this on board, update text, get feedback from Tadej and Yves. Try to update and send off today (2nd Nov).

Tadej: I like felix's suggestion on URI encoding. All people will not be able to encode in a common format but good to provide best-practices.
]

So why do we discuss the toolinfo element and id resolution in "script" at all? 

Sorry for the additional loop,

Felix

2012/11/7 Dave Lewis <dave.lewis@cs.tcd.ie>

Hi Jirka,
Thanks for that.

So to check, does the solution suggested by Yves, i.e. reflecting the toolInfo id in the script id,
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Nov/0019.html
and only having one toolInfo element per script as discussed in.
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Nov/0038.html
solve this problem?

cheers,
Dave 



On 05/11/2012 15:59, Jirka Kosek wrote:

On 2.11.2012 14:29, Dave Lewis wrote:

For HTML this works when the tool info is external to the file. However,
it doesn't work when the tool information is held with the file. Here we
could use the XML in htm:script element solution that we use for mark-up
in some of the data categories (e.g. Quality Issue). In this case we
would need to specify in the spec the element type the IRI refers to.

So we would need the following wording:
"Where the IRI in not used in a its:toolRefs attribute in an XML
document or not for pointing to an external resource in a its-tool-refs
attributed in a HTML document, then it MUST refer to a its:toolInfo
element."

This is not technically possible. In HTML its:toolInfo inside <script>
element and is not exposed as a markup, it's just plain text inside
<script> which doesn't have ID and can't be directly addressed.

                        Jirka

 




-- 
Felix Sasaki 

DFKI / W3C Fellow

 

 




-- 
Felix Sasaki

DFKI / W3C Fellow

 
Received on Wednesday, 7 November 2012 13:10:44 UTC

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