Re: Final CFP: In-Use Track ISWC 2013

On 05/02/2013 10:41 PM, Norman Gray wrote:
> Sarven and all, hello.

Hi Norman :)

> On 2013 May 2, at 18:38, Sarven Capadisli <info@csarven.ca> wrote:
>
>>> _What_ sucks on the web?  Certainly not PDF.
>>
>> HTML/Web, PDF/Desktop?
>
> PDF/Web, HTML/Desktop?  I'm not sure what you're trying to say here.

I was just trying to point that HTML is essentially Web friendly and 
that PDF is desktop friendly. Surely, both formats work on the other 
application, but there is at least some "intention" of where they are to 
be viewed. I'm not saying that's an absolute but more like a most common 
scenario.

So, I think PDF rather sucks on the Web because I can't always access it 
from any random Web browser.

>>> Thus HTML can do some unimportant things better than PDF,
>>
>> Web pages. It will never take off.
>
> No no, the web is massively successful.  HTML is a really clever
> hypertext format which is successful because it lets a number of
> things go wrong (it doesn't guarantee link integrity, links are all
> one-way, there's minimal text metadata, and so on).  These
> deficiencies are seriously smart things to use to create a global
> hypertext.  Web pages have taken off in a big way.
>
> It does not follow that HTML-based hypertext solves all text
> problems.  In particular, there is nothing in the above set of clever
> properties which makes HTML obviously ideal for communicating
> long-form textual arguments.

Good points. I guess it is a philosophical discussion point whether HTML 
is suitable to communicate long-form of text. Frankly, if I really have 
to read something super long, I want it in paper in my hands.

It also does not follow that, such because the information is HTML-based 
somehow we are restricted from printing it.

> And what is this 'desktop' of which you speak?  PDF is for making
> posters, presentations, on-screen documents, and on-tablet documents
> -- lots of very distinct layout problems there.  In the last case,
> you can even transfer the things to paper and read them in the bath,
> if you want.

I agree. I think I tried to clarify that earlier with HTML/Web, 
PDF/Desktop point.

>> but what it
>>> can't do, which _is_ important, is make things readable.  The
>>> visual appearance -- that is, the typesetting -- of rendered HTML
>>> is almost universally bad, from the point of view of reading
>>> extended pieces. I haven't (I admit) yet experimented with
>>> reading extended text on a tablet, but I'd be surprised if that
>>> made a major difference.
>>
>> I think you are conflating the job of HTML with CSS. Also, I think
>> you are conflating readability with legibility as far as the
>> typesetting goes. Again, that's something CSS handles provided that
>> suitable fonts are in use.
>
> CSS can help make HTML pages more readable.  Myself, I usually put
> quite a lot of effort into the CSS which accompanies web pages I
> write.  But it takes a lot of effort to produce good CSS, and the
> case you're aiming to optimise is the case of a normal-length
> web-page (under 1000 words, say), with relatively small investments
> on the part of the reader.
>
> Distributing PDF, you have easy and precise control over fonts,
> layout, and overall design (or rather, you in principle have access
> to a style which is carefully designed).  This makes it easy to
> produce something which is easy to read for thousands of words.

Indeed it takes time to pixel-perfect CSS if one wishes to do so. How 
long did it take LNCS or ACM-SIG to get it right?

It follows that, we do our lncs.css or acmsig.css and people simply use 
that in the HTML template (which we could also provide). So, no one is 
starting from scratch. That would be absurd and an unfair comparison.

> But this is to some extent irrelevant, because I think we're now
> talking about a non-problem:
>
>>> Also, HTML is not the same as linked data; there's no 'dog food'
>>> here for us to eat.
>>
>> That's quite a generalization there? So, I would argue that "HTML"
>> is more about eating dogfood in the Linked Data mailing list than
>> parading on PDF. We are trying to build things one step at a time;
>> HTML today, a URI that it can sit on tomorrow. Additional
>> machine-friendly stuff the day after.
>
> What, seriously, is the connection between HTML and linked-data?  If
> there is a deep connection, then HTML articles represent the
> linked-data community's dog-food, and it should be eaten.
>
> But there is no such deep connection.

It is a gateway. RDFa, Microdata, or even microformats to a certain 
degree can get us there. One block at a time. That's the point. I'm 
repeating this point constantly in this mailing list, so here it is one 
more time:

I don't care whether workshops, conference, or journals want to use 
XHTML or HTML5, or RDFa, Microdata or XYZ. They can decide that for 
themselves for the reasons that makes them sleep better at night. The 
point is that, if we have at least something like HTML, that's an 
excellent starting point.

I favour (X)HTML+RDFa for the task at hand, but I'm not going to demand 
that because I'm just one little me. At the end of the day, what I want 
to really see is that we can read each other's research on a standard 
looking webpage. I want to link to its interesting parts. I want to 
print it right off my browser. I want to dereference it and get 
structured statements out of it e.g., claims, conclusions, references 
etc. I want to interact with the charts by clicking randomly to learn 
more about it. I want to be able to change the sample data right from 
the page to see how their algorithm works. All of that.

We have these possibilities. Yet, some of us are overlooking this 
future, or insisting to keep things as is, meanhile preventing the 
community from getting there because they have their own agendas. That's 
clear!

-Sarven