Re: Formats and icing (Was Re: [ESWC 2015] First Call for Paper)
Hi all,
Thanks John for the references to my project.
It seems that here you need a solution that both pleases those who want
a PDF to comply with existing processes, and those who want a
machine-readable format for better Web-accessibility.
The DITA
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita
standard is an OASIS standard, like Open Document. It's an XML framework
dedicated to the creation of documents via the assembling of content
components, the topics. See it as a Docbook evolved. The Wikipedia page
https://en.wikipedia.org/wiki/Darwin_Information_Typing_Architecture
is a good introduction.
In the DITA ecosystem, a processing engine has been developed by the
community, the DITA Open Toolkit http://dita-ot.github.io/. Through
its plugin system, it enables the publication of DITA content to a
myriad of output formats:
* PDF
* Simple HTML
* HTML WebHelp (fancy example http://purl.org/dita/ditardf-project)
* ePub and Kindle (through the dita4publisher plugin
http://dita4publishers.sourceforge.net/)
* ...and RDF/XML through the plugin part of the DITA RDF project
http://purl.org/dita/ditardf-project. The plugin extracts the
metadata of the documentation (author, title, creation date, links,
variables), not the meaning of the content (output example
https://github.com/ColinMaudry/dita-rdf/blob/ditaot-plugin/dita2rdf/demo/out/ditaot-userguide.rdf).
It could be extended to extract certain facts from the content.
DITA has a nice feature: its core vocabulary can be extended via
specialization, so that it can support specific purposes: learning
content, troubleshooting documents, etc.
Those who want a PDF would make a PDF rendition and those who want
machine-readable formats would use a flavour of HTML or give me a hand
with the RDF output.
What do you think?
Colin
On 02/10/2014 11:08, John Walker wrote:
Hi All,
I know Latex is the norm in academic circles, but the DITA XML
standard is widely used in industry and gaining traction in publishing.
Colin Maudry ( @CMaudry) has a project for extracting RDF metadata
from DITA content [1].
Seems to be attracting interest from Marklogic and HarperCollins [2]
and others [3].
Cheers,
John
[1] http://purl.org/dita/ditardf-project
[2] http://files.meetup.com/1645603/meetup-2014-08-12.pptx
[3]
http://de.slideshare.net/TheresaGrotendorst/towards-dynamic-and-smart-content-semantic-technologies-for-adaptive-technical-documentation
On October 2, 2014 at 12:03 AM Norman Gray nor...@astro.gla.ac.uk
wrote:
Greetings.
On 2014 Oct 1, at 22:36, Luca Matteis lmatt...@gmail.com wrote:
So forget PDF. Perhaps we can add markup to Latex documents and make
them linked data friendly? That would be cool. A Latex RDF
serialization :)
There exists
http://www.siegfried-handschuh.net/pub/2007/salt_eswc2007.pdf:
SALT: Semantically Annotated LATEX Tudor Groza Siegfried Handschuh
Hak Lae Kim
Digital Enterprise Research Institute
IDA Business Park, Lower Dangan
Galway, Ireland
{tudor.groza, siegfried.handschuh, haklae.kim}@deri.org
ABSTRACT
Machine-understandable data constitutes the basis for the Seman-
tic Desktop. We provide in this paper means to author and annotate
Semantic Documents on the Desktop. In our approach, the PDF file
format is the basis for semantic documents, which store both a
document and the related metadata in a single file. To achieve this we
provide a framework, SALT that extends the Latex writ- ing environment
and supports the creation of metadata for scien- tific publications.
SALT lets the scientific author create metadata while putting together
the content of a research paper. We discuss some of the requirements
one has to meet when developing such an ontology-based writing
environment and we describe a usage scenario.
That describes a very thorough approach to embedding some semantics
within LaTeX documents.
Yes, 'thorough'; very thorough; verging on the intimidating.
I dimly recall that there was a rather more lightweight approach
which was used for proceedings in ISWC or ESWC -- I remember marking
up a LaTeX document in something less comprehensive than SALT -- but I
can't remember enough to be able to re-find it.
All the best,
Norman
--
Norman Gray : http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK
attachment: colin.vcf
Re: Formats and icing (Was Re: [ESWC 2015] First Call for Paper)
Dear Sarven et al,
I'd like to say that I'm an HTML/CSS/JavaScript aficionado so I'd be
the first to embrace Web standards to produce publications. I'm simply
playing a bit of the devil's advocate here because I think that Latex
is still more mature than HTML for writing papers. However, I must
admit I'd like to see a future where that is different.
But before we ask conferences to embrace this still immature HTML
world (at least for producing papers) we must write the frameworks,
the libraries, the CSS templates that enable the same level of
publication that Latex enables. JavaScript for example can help with
the kerning issue (http://kerningjs.com/) and this should be part of
the HTML publisher toolkit. For solving the browser inconsistencies,
standalone tools (based on a Webkit engine for example) must be built
that produce a consistent printable layout no matter the operating
system (browser fonts render differently on Mac/Windows/Linux).
So yes, we can get there, but there's some work to be done to prove
that HTML is up for task. And once we get there, then we can start
going crazy and adding interactions which is really the power of the
Web platform.
Phillip Lord, by interactions I don't mean simple animations, I mean
this: http://worrydream.com/LadderOfAbstraction/ - use the right side
scrolling to instantly see the output given different inputs. That's
powerful stuff.
Best,
Luca
On Thu, Oct 2, 2014 at 4:02 PM, Colin Maudry co...@maudry.com wrote:
Hi all,
Thanks John for the references to my project.
It seems that here you need a solution that both pleases those who want a
PDF to comply with existing processes, and those who want a machine-readable
format for better Web-accessibility.
The DITA standard is an OASIS standard, like Open Document. It's an XML
framework dedicated to the creation of documents via the assembling of
content components, the topics. See it as a Docbook evolved. The Wikipedia
page is a good introduction.
In the DITA ecosystem, a processing engine has been developed by the
community, the DITA Open Toolkit. Through its plugin system, it enables the
publication of DITA content to a myriad of output formats:
PDF
Simple HTML
HTML WebHelp (fancy example)
ePub and Kindle (through the dita4publisher plugin)
...and RDF/XML through the plugin part of the DITA RDF project. The plugin
extracts the metadata of the documentation (author, title, creation date,
links, variables), not the meaning of the content (output example). It could
be extended to extract certain facts from the content.
DITA has a nice feature: its core vocabulary can be extended via
specialization, so that it can support specific purposes: learning
content, troubleshooting documents, etc.
Those who want a PDF would make a PDF rendition and those who want
machine-readable formats would use a flavour of HTML or give me a hand with
the RDF output.
What do you think?
Colin
On 02/10/2014 11:08, John Walker wrote:
Hi All,
I know Latex is the norm in academic circles, but the DITA XML standard is
widely used in industry and gaining traction in publishing.
Colin Maudry ( @CMaudry) has a project for extracting RDF metadata from DITA
content [1].
Seems to be attracting interest from Marklogic and HarperCollins [2] and
others [3].
Cheers,
John
[1] http://purl.org/dita/ditardf-project
[2] http://files.meetup.com/1645603/meetup-2014-08-12.pptx
[3]
http://de.slideshare.net/TheresaGrotendorst/towards-dynamic-and-smart-content-semantic-technologies-for-adaptive-technical-documentation
On October 2, 2014 at 12:03 AM Norman Gray nor...@astro.gla.ac.uk wrote:
Greetings.
On 2014 Oct 1, at 22:36, Luca Matteis lmatt...@gmail.com wrote:
So forget PDF. Perhaps we can add markup to Latex documents and make
them linked data friendly? That would be cool. A Latex RDF
serialization :)
There exists
http://www.siegfried-handschuh.net/pub/2007/salt_eswc2007.pdf:
SALT: Semantically Annotated LATEX Tudor Groza Siegfried Handschuh Hak
Lae Kim
Digital Enterprise Research Institute
IDA Business Park, Lower Dangan
Galway, Ireland
{tudor.groza, siegfried.handschuh, haklae.kim}@deri.org
ABSTRACT
Machine-understandable data constitutes the basis for the Seman- tic
Desktop. We provide in this paper means to author and annotate Semantic
Documents on the Desktop. In our approach, the PDF file format is the basis
for semantic documents, which store both a document and the related
metadata
in a single file. To achieve this we provide a framework, SALT that extends
the Latex writ- ing environment and supports the creation of metadata for
scien- tific publications. SALT lets the scientific author create metadata
while putting together the content of a research paper. We discuss some of
the requirements one has to meet when developing such an ontology-based
writing environment and we describe a usage scenario.
That describes a very thorough
Re: Formats and icing (Was Re: [ESWC 2015] First Call for Paper)
Hi Luca, I'll admit my opinion is probably skewed by nearly 15 years working in and around technical documentation environment using structured authoring tools like FrameMaker and Oxygen based on XML/SGML technologies. I'm a firm convert from WYSIWIG environments like MS Word to more structured 'semantic' markup made possible with XML... sometimes referred to as WYSIWYM or What You See Is What You Mean. There are some great tools out there that make editing a doddle and allow use of vector images (SVG) and mathematical formulas (MathML) directly in your XML document. As it is XML, then weaving in some RDFa is also possible if you are so inclined Going to the rendered publication format whether that be page-based (PDF) or web-based (HTML) or whatever else is possible via a myriad of approach whether you prefer Latex, HTML+CSS+JS or XSL-FO (for the masochists out there :) Certainly most technical authors I know would run a mile were you to suggest the edit directly as Latex or XSL-FO, or even raw XML/HTML for that matter, but perhaps developers would be more comfortable with it. DITA on top of this offers the specialization as Colin mentioned, but also a myriad of different (direct and indirect) referencing possibilities to pull and push content between different documents. HTML imports [1] and custom elements [2] might offer some of these options in HTML at some point in the future. Cheers, John [1] http://www.w3.org/TR/html-imports/ [2] http://w3c.github.io/webcomponents/spec/custom/ On October 3, 2014 at 10:59 AM Luca Matteis lmatt...@gmail.com wrote: Dear Sarven et al, I'd like to say that I'm an HTML/CSS/JavaScript aficionado so I'd be the first to embrace Web standards to produce publications. I'm simply playing a bit of the devil's advocate here because I think that Latex is still more mature than HTML for writing papers. However, I must admit I'd like to see a future where that is different. But before we ask conferences to embrace this still immature HTML world (at least for producing papers) we must write the frameworks, the libraries, the CSS templates that enable the same level of publication that Latex enables. JavaScript for example can help with the kerning issue (http://kerningjs.com/) and this should be part of the HTML publisher toolkit. For solving the browser inconsistencies, standalone tools (based on a Webkit engine for example) must be built that produce a consistent printable layout no matter the operating system (browser fonts render differently on Mac/Windows/Linux). So yes, we can get there, but there's some work to be done to prove that HTML is up for task. And once we get there, then we can start going crazy and adding interactions which is really the power of the Web platform. Phillip Lord, by interactions I don't mean simple animations, I mean this: http://worrydream.com/LadderOfAbstraction/ - use the right side scrolling to instantly see the output given different inputs. That's powerful stuff. Best, Luca On Thu, Oct 2, 2014 at 4:02 PM, Colin Maudry co...@maudry.com wrote: Hi all, Thanks John for the references to my project. It seems that here you need a solution that both pleases those who want a PDF to comply with existing processes, and those who want a machine-readable format for better Web-accessibility. The DITA standard is an OASIS standard, like Open Document. It's an XML framework dedicated to the creation of documents via the assembling of content components, the topics. See it as a Docbook evolved. The Wikipedia page is a good introduction. In the DITA ecosystem, a processing engine has been developed by the community, the DITA Open Toolkit. Through its plugin system, it enables the publication of DITA content to a myriad of output formats: PDF Simple HTML HTML WebHelp (fancy example) ePub and Kindle (through the dita4publisher plugin) ...and RDF/XML through the plugin part of the DITA RDF project. The plugin extracts the metadata of the documentation (author, title, creation date, links, variables), not the meaning of the content (output example). It could be extended to extract certain facts from the content. DITA has a nice feature: its core vocabulary can be extended via specialization, so that it can support specific purposes: learning content, troubleshooting documents, etc. Those who want a PDF would make a PDF rendition and those who want machine-readable formats would use a flavour of HTML or give me a hand with the RDF output. What do you think? Colin On 02/10/2014 11:08, John Walker wrote: Hi All, I know Latex is the norm in academic circles, but the DITA XML standard is widely used in industry and gaining traction in publishing. Colin Maudry ( @CMaudry) has a project for extracting RDF metadata from DITA content [1]. Seems to be attracting interest from Marklogic and HarperCollins [2] and others [3]. Cheers,
Cost and access (Was Re: [ESWC 2015] First Call for Paper)
On 2014-10-02 13:50, John Domingue wrote: As well as being irritating, UK academics submitting to ESWC run the risk that their papers will not be open to REF submission; even if they are, we have to go to additional efforts to ensure they are green OA published. This is also true of ISWC which makes the semantic web a pretty unattractive area to do research in. for both ISWC and ESWC the PDFs are freely available e.g. see [1] John [1] http://2014.eswc-conferences.org/program/accepted-papers It is great that some agreements between the conferences and the publishers allow open access e.g., [1]. However, lets not forget that: 1) a good chunk of publicly funded research is produced and reviewed for free, meanwhile: 2) the public still ends up paying for the research submissions i.e., institutions pay their fees to subscribe to the periodicals from the publisher. So, not only are we working for free, we are paying again for the research that we've produced. And all meanwhile, insisting on making it easier and preferable by the publisher. Having said that, there is no need to pile on the publisher. After all, they have a business and the intuitions are willing to pay for their services and products. That's okay. Many in the SW field are interested in discovering the research output at great precision, without having to go through the publisher, or having to use a common search engine to look for keywords endlessly for something mildly relevant. We are all in fact working towards that universal access of information - I think TimBL said a few things on that silly little topic. IMO, this is where it comes apparent that the level of openness that's offered by the publisher is superficial and archaic. The SW community can do much better by removing the unnecessary controls that are in place to control the flow of information. This is whereabouts we should wake up. :) -Sarven http://csarven.ca/#i smime.p7s Description: S/MIME Cryptographic Signature
Re: Cost and access (Was Re: [ESWC 2015] First Call for Paper)
Dear Sarven, I guess that all people belonging the semantic web community have been enriched from this discussion. I'm sure that there are a lot of aspect about how ideas, material, research outcomes, etc. can been shared and disseminate through all the world. However, my personal (very personal) feeling is that the next edition of ESWC will not be able to solve everything... and with this, I don't want to discredit the huge amount of work that all the organization committee is doing. So, I would invite you to collect all the things that you don't consider fair, and to apply them when you will sit on your desk for organizing your conference. Anyway, if you don't want to do this, please at least remove my address from the discussion, because I'm not interested in continuing reading it. Thanks and have a nice day. Mauro. On Fri, Oct 3, 2014 at 12:07 PM, Sarven Capadisli i...@csarven.ca wrote: On 2014-10-02 13:50, John Domingue wrote: As well as being irritating, UK academics submitting to ESWC run the risk that their papers will not be open to REF submission; even if they are, we have to go to additional efforts to ensure they are green OA published. This is also true of ISWC which makes the semantic web a pretty unattractive area to do research in. for both ISWC and ESWC the PDFs are freely available e.g. see [1] John [1] http://2014.eswc-conferences.org/program/accepted-papers It is great that some agreements between the conferences and the publishers allow open access e.g., [1]. However, lets not forget that: 1) a good chunk of publicly funded research is produced and reviewed for free, meanwhile: 2) the public still ends up paying for the research submissions i.e., institutions pay their fees to subscribe to the periodicals from the publisher. So, not only are we working for free, we are paying again for the research that we've produced. And all meanwhile, insisting on making it easier and preferable by the publisher. Having said that, there is no need to pile on the publisher. After all, they have a business and the intuitions are willing to pay for their services and products. That's okay. Many in the SW field are interested in discovering the research output at great precision, without having to go through the publisher, or having to use a common search engine to look for keywords endlessly for something mildly relevant. We are all in fact working towards that universal access of information - I think TimBL said a few things on that silly little topic. IMO, this is where it comes apparent that the level of openness that's offered by the publisher is superficial and archaic. The SW community can do much better by removing the unnecessary controls that are in place to control the flow of information. This is whereabouts we should wake up. :) -Sarven http://csarven.ca/#i
Re: Cost and access (Was Re: [ESWC 2015] First Call for Paper)
Let's work through the requirements and a plausible migration plan. We need: 1 persistent storage: it's hard to beat books for a feeling of persistence. Contracts with trusted archival institutions can help but we might also want some assurances that the protocols and formats will persist as well. It would be possible to have a fallback contract with a conventional publisher but it's hard to see what's in it for them if they have to paper print everything or migrate to a new format when the Web loses way to something else. Maybe it's more pragmatic to forgoe these assurances of persistence and just hope that economic interests protect the valuable stuff. 2 impact factor: i have the impression that conventional publishers have a bit of a monopoly and and sudden disruption would be hard to engineer. How do to get leading researchers to devote their work in some new crackpot e-journal to the exclusion of other articles which will earn them more points towards tenure and grants? Perhaps the answer is slowly build the impact factor; perhaps it's some sort of revolution in the minds of administrators and funders. I work towards a network of actionable data just like the rest of you so I don't want to discourage this conversation; I just want to focus it. On Oct 3, 2014 12:12 PM, Sarven Capadisli i...@csarven.ca wrote: On 2014-10-02 13:50, John Domingue wrote: As well as being irritating, UK academics submitting to ESWC run the risk that their papers will not be open to REF submission; even if they are, we have to go to additional efforts to ensure they are green OA published. This is also true of ISWC which makes the semantic web a pretty unattractive area to do research in. for both ISWC and ESWC the PDFs are freely available e.g. see [1] John [1] http://2014.eswc-conferences.org/program/accepted-papers It is great that some agreements between the conferences and the publishers allow open access e.g., [1]. However, lets not forget that: 1) a good chunk of publicly funded research is produced and reviewed for free, meanwhile: 2) the public still ends up paying for the research submissions i.e., institutions pay their fees to subscribe to the periodicals from the publisher. So, not only are we working for free, we are paying again for the research that we've produced. And all meanwhile, insisting on making it easier and preferable by the publisher. Having said that, there is no need to pile on the publisher. After all, they have a business and the intuitions are willing to pay for their services and products. That's okay. Many in the SW field are interested in discovering the research output at great precision, without having to go through the publisher, or having to use a common search engine to look for keywords endlessly for something mildly relevant. We are all in fact working towards that universal access of information - I think TimBL said a few things on that silly little topic. IMO, this is where it comes apparent that the level of openness that's offered by the publisher is superficial and archaic. The SW community can do much better by removing the unnecessary controls that are in place to control the flow of information. This is whereabouts we should wake up. :) -Sarven http://csarven.ca/#i
Debates of the European Parliament as LOD
- Dataset announcement - We are happy to announce the release of a new linked dataset: the proceedings of the plenary debates of the European Parliament as Linked Open Data. The dataset covers all plenary debates held in the European Parliament (EP) between July 1999 and January 2014, and biographical information about the members of parliament. It includes: the monthly sessions of the EP, the agenda of debates, the spoken words and translations thereof in 21 languages; the speakers, their role and the country they represent; membership of national parties, European parties and commissions. The data is available though a SPARQL endpoint, see http://linkedpolitics.ops.few.vu.nl/ for more details. Please note that this is a first version; we hope you will try it out and send us your feedback! - Context - The data was created within the Talk of Europe project [1]. To obtain data on the plenary debates, we generated RDF from the HTML pages published on the official website of the EP [2]. We collaborated with the Political Mashup project [3], who provided scripts to scrape the HTML pages. The bibliographical data about members of parliament comes from the Automated Database of the European Parliament by Bjørn Høyland of the University of Oslo [4]. We translated this database to RDF, linked it to the debate data, and made it available as Linked Data as part of the Talk of Europe dataset. - Access to the data - We provide access in three ways: • Through a SPARQL endpoint at http://linkedpolitics.ops.few.vu.nl/sparql/ • Using the ClioPatria web interface at http://linkedpolitics.ops.few.vu..nl/ • By downloading data dumps. See http://linkedpolitics.ops.few.vu.nl/. We use a CC BY 4.0 license. To acknowledge us, please provide a link to the Talk of Europe project website http://talkofeurope.eu/. Kind regards, Laura Hollink [1] http://talkofeurope.eu/ [2] http://europarl.europa.eu/ [3] http://politicalmashup.nl/ [4] http://folk.uio.no/bjornkho/MEP/ --- --- --- --- --- Laura Hollink Assistant Professor Web and Media group VU University Amsterdam http://www.cs.vu.nl/~laurah/
Re: Formats and icing (Was Re: [ESWC 2015] First Call for Paper)
Luca Matteis lmatt...@gmail.com writes: I'd like to say that I'm an HTML/CSS/JavaScript aficionado so I'd be the first to embrace Web standards to produce publications. I'm simply playing a bit of the devil's advocate here because I think that Latex is still more mature than HTML for writing papers. However, I must admit I'd like to see a future where that is different. The conference does not want latex, it wants PDF. So write your documents in latex, publish in HTML. The only thing that needs to change are the tools in the middle. But before we ask conferences to embrace this still immature HTML world (at least for producing papers) we must write the frameworks, the libraries, the CSS templates that enable the same level of publication that Latex enables. Well, that's already been done. As for the same level of publication I profoundly disagree. LNCS format is very poor for anything other than printing. I want a form of publication that allows me, the reader, to switch layout. For solving the browser inconsistencies, standalone tools (based on a Webkit engine for example) must be built that produce a consistent printable layout no matter the operating system (browser fonts render differently on Mac/Windows/Linux). Seriously? You want to build another browser. My experience is that the web is more consistent than PDF. Font problems with PDFs used to be the norm. Tend not to use them now, so perhaps that's changed. And, again, printable? At least some of us want to move away from that. Stlying in reader issue, not an authorial one. So yes, we can get there, but there's some work to be done to prove that HTML is up for task. No. There is work to be done to prove that we can break the habit of a lifetime. HTML is far from immature. We move, and then we fix any problems that we may have. Why would we bother before? Phillip Lord, by interactions I don't mean simple animations, I mean this: http://worrydream.com/LadderOfAbstraction/ - use the right side scrolling to instantly see the output given different inputs. That's powerful stuff. Colour figures and animations would be a nice start though. Phil
Re: Cost and access (Was Re: [ESWC 2015] First Call for Paper)
On 2014-10-03 13:36, Eric Prud'hommeaux wrote: Let's work through the requirements and a plausible migration plan. We need: Agreed. In favour of taking action. Just to separate and emphasize on the issues. The original request was merely: Will you consider encouraging the use of Semantic Web / Linked Data technologies for Extended Semantic Web Conference paper submissions? or Will you compromise on the submission such that the submissions can be in PDF and/or in HTML(+RDFa)? This, in my view, attempts to retain the existing workflow. There is nothing here that tries to solve everything (as some misinterpret or paint it as such). Incremental actions are preferable than throwing our hands into the air and running away frantically from the problem that the community brought it onto itself. This is about creating awareness and embracing Web-native technologies for SW research submissions, provided that the final presentation (i.e., in PDF) complies with the requested template, which is passed to the publisher in the end. Just to elaborate on that, while the submissions in the end may only be in PDF (although, it would be great to work it out without that, but one step at a time right?), the fact that the submission line acknowledges the importance and flexibility in creating, sharing, and preserving research knowledge using the technologies in what the conference is all about, should not be underestimated. As a plus, authors that are on their way to going from, say HTML+CSS to PDF, have the opportunity and willingness to make their research contributions publicly accessible under a Web space that they control. The source method to represent this information sets the tone for the rest of the phases. That is, if LaTeX/Word is source, then it is extra work to get HTML out of that, and many would not and do not (in fact) bother. However, if HTML is source (for instance), then we retain that possibility. All meanwhile that the publisher gets their PDF (e.g., via HTML+CSS to print file), as well as authors fulfilling their academic/research requirements. Moving on: 1 persistent storage: it's hard to beat books for a feeling of persistence. Contracts with trusted archival institutions can help but we might also want some assurances that the protocols and formats will persist as well. It would be possible to have a fallback contract with a conventional publisher but it's hard to see what's in it for them if they have to paper print everything or migrate to a new format when the Web loses way to something else. Maybe it's more pragmatic to forgoe these assurances of persistence and just hope that economic interests protect the valuable stuff. This is out of my area, but as I understand it, going from digital source to print is just a view or materializing of said knowledge. History has shown that, both, PDF and HTML are sufficient for storage. Those that wish to archive via PDF can do so. It is just a view after all. However, that one particular view to store knowledge need not set the tone for everything else. I think the tool-chain around HTML/XML tries to lift those restrictions. For instance, with HTML we are free to create any suitable presentation for any device with CSS. 2 impact factor: i have the impression that conventional publishers have a bit of a monopoly and and sudden disruption would be hard to engineer. How do to get leading researchers to devote their work in some new crackpot e-journal to the exclusion of other articles which will earn them more points towards tenure and grants? Perhaps the answer is slowly build the impact factor; perhaps it's some sort of revolution in the minds of administrators and funders. I'd like to be optimistic about this and entertain the idea that, either the current journals evolve or a new line of journals will seek, embrace and truly employ the scientific method with the aid of available technologies. At this time, it is difficult to solely rely on human-only peer reviews, because it is time consuming and error-prone. If reviewers have the opportunity to better investigate, by raising the support that's available from machines, the truthfulness and reproducibility of given research can be better verified. We are certainly heading in that direction with all the work that goes on in SW and other fields. The bottleneck is that, right now, it is not seriously given the light of day, or even tested out. When SW/LD conferences resist to come to terms with supporting their own fundamentals or visions towards research submissions, how is what we currently have any desirable? Just to be clear, the original proposal is not for all of sciences to adopt. It is for international semantic web conferences. That's the minimal step we can take. So, I agree, some revolution, or maybe just evolution on the idea of putting our own technologies to test will contribute towards increasing the impact factor
SPARQL Monitor Service?
All, The SPARQL monitor service identified by the URI http://sparqles.okfn.org is down. It's been so for sometime now, does anyone know what's going on. -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this smime.p7s Description: S/MIME Cryptographic Signature
Re: Cost and access (Was Re: [ESWC 2015] First Call for Paper)
Eric Prud'hommeaux e...@w3.org writes: Let's work through the requirements and a plausible migration plan. We need: 1 persistent storage: it's hard to beat books for a feeling of persistence. Contracts with trusted archival institutions can help but we might also want some assurances that the protocols and formats will persist as well. In my area, the majority of journals aren't printed; I've thrown away conference proceedings the last decade anyway. Protocols and formats, yes, true a problem. I think in an argument between HTML and PDF, then it's hard to see one has the advantage over another. My experience is that HTML is easier to extract text from, which is always going to be base line. For what it is worth, there are achiving solutions, including archive.org and arxiv.org both of which leap to mind. 2 impact factor: i have the impression that conventional publishers have a bit of a monopoly and and sudden disruption would be hard to engineer. How do to get leading researchers to devote their work in some new crackpot e-journal to the exclusion of other articles which will earn them more points towards tenure and grants? Perhaps the answer is slowly build the impact factor; perhaps it's some sort of revolution in the minds of administrators and funders. This is true. So, if the reason that ESWC and ISWC only accept papers in PDF is because we need LNCS for tenure and that they will only take PDF, it would be good to have a public statement about this. As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. I work towards a network of actionable data just like the rest of you so I don't want to discourage this conversation; I just want to focus it. Okay. I would like to know who made the decision that HTML is not acceptable and why. Phil
Re: Cost and access (Was Re: [ESWC 2015] First Call for Paper)
I think that this is at the core of the problem: 2 impact factor: i have the impression that conventional publishers have a bit of a monopoly and and sudden disruption would be hard to engineer. How do to get leading researchers to devote their work in some new crackpot e-journal to the exclusion of other articles which will earn them more points towards tenure and grants? Perhaps the answer is slowly build the impact factor; perhaps it's some sort of revolution in the minds of administrators and funders. publishers also own impact factors. in addition, impact factors are thought for printed material not for the web, not to talk about the web of data. there are the alt metrics but those are yet to prove their validity. I keep wondering if html and pdfs are the only options. why not having a real web-of-data native format? On Fri, Oct 3, 2014 at 8:02 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: Eric Prud'hommeaux e...@w3.org writes: Let's work through the requirements and a plausible migration plan. We need: 1 persistent storage: it's hard to beat books for a feeling of persistence. Contracts with trusted archival institutions can help but we might also want some assurances that the protocols and formats will persist as well. In my area, the majority of journals aren't printed; I've thrown away conference proceedings the last decade anyway. Protocols and formats, yes, true a problem. I think in an argument between HTML and PDF, then it's hard to see one has the advantage over another. My experience is that HTML is easier to extract text from, which is always going to be base line. For what it is worth, there are achiving solutions, including archive.org and arxiv.org both of which leap to mind. 2 impact factor: i have the impression that conventional publishers have a bit of a monopoly and and sudden disruption would be hard to engineer. How do to get leading researchers to devote their work in some new crackpot e-journal to the exclusion of other articles which will earn them more points towards tenure and grants? Perhaps the answer is slowly build the impact factor; perhaps it's some sort of revolution in the minds of administrators and funders. This is true. So, if the reason that ESWC and ISWC only accept papers in PDF is because we need LNCS for tenure and that they will only take PDF, it would be good to have a public statement about this. As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. I work towards a network of actionable data just like the rest of you so I don't want to discourage this conversation; I just want to focus it. Okay. I would like to know who made the decision that HTML is not acceptable and why. Phil -- Alexander Garcia http://www.alexandergarcia.name/ http://www.usefilm.com/photographer/75943.html http://www.linkedin.com/in/alexgarciac
Re: SPARQL Monitor Service?
Hi Kingsley, We're working to resolve some issues (both technical and man-power related) so please consider this as a brief break in the SPARQLES service. We understand that the service is useful for the community and we are working to get it up and running again as soon as possible! Sorry for any inconvenience in the meantime! Best, Aidan On 03/10/2014 11:43, Kingsley Idehen wrote: All, The SPARQL monitor service identified by the URI http://sparqles.okfn.org is down. P.S., I'm not sure that the service *itself* is identified by the URI. *ducks*
scientific publishing process (was Re: Cost and access)
In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. In the past I have tried various means to produce good-looking HTML and I've always gone back to a setup that produces PDF. If a document is available in both HTML and PDF I almost always choose to view it in PDF. This is the case even though I have particular preferences in how I view documents. If someone wants to change the format of conference submissions, then they are going to have to cater to the preferences of authors, like me, and reviewers, like me. If someone wants to change the format of conference papers, then they are going to have to cater to the preferences of authors, like me, attendees, like me, and readers, like me. I'm all for *better* methods for preparing, submitting, reviewing, and publishing conference (and journal) papers. So go ahead, create one. But just saying that HTML is better than PDF in some dimension, even if it were true, doesn't mean that HTML is better than PDF for this purpose. So I would say that the semantic web community is saying that there are better formats and tools for creating, reviewing, and publishing scientific papers than HTML and tools that create and view HTML. If there weren't these better ways then an HTML-based solution might be tenable, but why use a worse solution when a better one is available? peter On 10/03/2014 08:02 AM, Phillip Lord wrote: [...] As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. [...] Phil
Re: scientific publishing process (was Re: Cost and access)
In my opinion, the opposite is true. PDF I almost always end up printing out. This isn't the point though. Necessity is the mother of invention. In the ideal world, a web conference would allow only HTML submission. Failing that, at least HTML submission. But, currently, we cannot submit HTML at all. What is the point of creating a better method, if we can't use it? The only argument that seems at all plausible to me is, well, we've always done it like this, and it's too much effort to change. I could appreciate that. Anyway, the argument is going round in circles. Peter F. Patel-Schneider pfpschnei...@gmail.com writes: In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. In the past I have tried various means to produce good-looking HTML and I've always gone back to a setup that produces PDF. If a document is available in both HTML and PDF I almost always choose to view it in PDF. This is the case even though I have particular preferences in how I view documents. If someone wants to change the format of conference submissions, then they are going to have to cater to the preferences of authors, like me, and reviewers, like me. If someone wants to change the format of conference papers, then they are going to have to cater to the preferences of authors, like me, attendees, like me, and readers, like me. I'm all for *better* methods for preparing, submitting, reviewing, and publishing conference (and journal) papers. So go ahead, create one. But just saying that HTML is better than PDF in some dimension, even if it were true, doesn't mean that HTML is better than PDF for this purpose. So I would say that the semantic web community is saying that there are better formats and tools for creating, reviewing, and publishing scientific papers than HTML and tools that create and view HTML. If there weren't these better ways then an HTML-based solution might be tenable, but why use a worse solution when a better one is available? peter On 10/03/2014 08:02 AM, Phillip Lord wrote: [...] As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. [...] Phil -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU
Re: scientific publishing process (was Re: Cost and access)
the PDF has its value. yes, it ends up being printed and perhaps that is its main limitation. it is not a document for the web. it is a document engineered to preserve the layout. the format is closed, proprietary and with little real methods that support interoperability or data reusability -I am including in interoperability facilities for NLP and direct processing of the content. I keep wondering about alternatives. I am not against the PDF, it is just one more format with a very limited and precise use, that of providing a uniform layout. it is oversold and there are no viable alternatives. by viable I mean embedded within a publishing workflow -that provided by word processors as well as that in use by publishers. I dont see myself as an editor receiving HTML and having to deal with the complexity in HTML. as an author, I dont want more work than that implicit in putting together my paper and submitting it, so every little burden on the author is just a no go IMHO. However, as a scientist who is aware of the limitations of closed formats, I would really like to have an alternative, one we can all live with. On Fri, Oct 3, 2014 at 9:11 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: In my opinion, the opposite is true. PDF I almost always end up printing out. This isn't the point though. Necessity is the mother of invention. In the ideal world, a web conference would allow only HTML submission. Failing that, at least HTML submission. But, currently, we cannot submit HTML at all. What is the point of creating a better method, if we can't use it? The only argument that seems at all plausible to me is, well, we've always done it like this, and it's too much effort to change. I could appreciate that. Anyway, the argument is going round in circles. Peter F. Patel-Schneider pfpschnei...@gmail.com writes: In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. In the past I have tried various means to produce good-looking HTML and I've always gone back to a setup that produces PDF. If a document is available in both HTML and PDF I almost always choose to view it in PDF. This is the case even though I have particular preferences in how I view documents. If someone wants to change the format of conference submissions, then they are going to have to cater to the preferences of authors, like me, and reviewers, like me. If someone wants to change the format of conference papers, then they are going to have to cater to the preferences of authors, like me, attendees, like me, and readers, like me. I'm all for *better* methods for preparing, submitting, reviewing, and publishing conference (and journal) papers. So go ahead, create one. But just saying that HTML is better than PDF in some dimension, even if it were true, doesn't mean that HTML is better than PDF for this purpose. So I would say that the semantic web community is saying that there are better formats and tools for creating, reviewing, and publishing scientific papers than HTML and tools that create and view HTML. If there weren't these better ways then an HTML-based solution might be tenable, but why use a worse solution when a better one is available? peter On 10/03/2014 08:02 AM, Phillip Lord wrote: [...] As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. [...] Phil -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- Alexander Garcia http://www.alexandergarcia.name/ http://www.usefilm.com/photographer/75943.html http://www.linkedin.com/in/alexgarciac
Re: scientific publishing process (was Re: Cost and access)
my humble two cents. Rather than the format (submitting, read etc), its the effective linking that is missing imo. The Semantic Web/Linked Data community has been preaching this concept of linking, and to some extent the dogfood site provides for such linking. However, this is limited to established meta-data tags, author/s, title, conference etc. What if improvement is focused on increasing the effective linking (concepts, relations) through some automated (semi) tools which both ESWC and ISWC communities provide, and which make the text of each submission linkable? C On 3 October 2014 18:11, Phillip Lord phillip.l...@newcastle.ac.uk wrote: In my opinion, the opposite is true. PDF I almost always end up printing out. This isn't the point though. Necessity is the mother of invention. In the ideal world, a web conference would allow only HTML submission. Failing that, at least HTML submission. But, currently, we cannot submit HTML at all. What is the point of creating a better method, if we can't use it? The only argument that seems at all plausible to me is, well, we've always done it like this, and it's too much effort to change. I could appreciate that. Anyway, the argument is going round in circles. Peter F. Patel-Schneider pfpschnei...@gmail.com writes: In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. In the past I have tried various means to produce good-looking HTML and I've always gone back to a setup that produces PDF. If a document is available in both HTML and PDF I almost always choose to view it in PDF. This is the case even though I have particular preferences in how I view documents. If someone wants to change the format of conference submissions, then they are going to have to cater to the preferences of authors, like me, and reviewers, like me. If someone wants to change the format of conference papers, then they are going to have to cater to the preferences of authors, like me, attendees, like me, and readers, like me. I'm all for *better* methods for preparing, submitting, reviewing, and publishing conference (and journal) papers. So go ahead, create one. But just saying that HTML is better than PDF in some dimension, even if it were true, doesn't mean that HTML is better than PDF for this purpose. So I would say that the semantic web community is saying that there are better formats and tools for creating, reviewing, and publishing scientific papers than HTML and tools that create and view HTML. If there weren't these better ways then an HTML-based solution might be tenable, but why use a worse solution when a better one is available? peter On 10/03/2014 08:02 AM, Phillip Lord wrote: [...] As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. [...] Phil -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU
Re: scientific publishing process (was Re: Cost and access)
One problem with allowing HTML submission is ensuring that reviewers can correctly view the submission as the authors intended it to be viewed. How would you feel if your paper was rejected because one of the reviewers could not view portions of it? At least with PDF there is a reasonably good chance that every paper can be correctly viewed by all its reviewers, even if they have to print it out. I don't think that the same claim can be made for HTML-based systems. Further, why should there be any technical preference for HTML at all? (Yes, HTML is an open standard and PDF is a closed one, but is there anything else besides that?) Web conference vitally use the web in their reviewing and publishing processes. Doesn't that show their allegiance to the web? Would the use of HTML make a conference more webby? peter On 10/03/2014 09:11 AM, Phillip Lord wrote: In my opinion, the opposite is true. PDF I almost always end up printing out. This isn't the point though. Necessity is the mother of invention. In the ideal world, a web conference would allow only HTML submission. Failing that, at least HTML submission. But, currently, we cannot submit HTML at all. What is the point of creating a better method, if we can't use it? The only argument that seems at all plausible to me is, well, we've always done it like this, and it's too much effort to change. I could appreciate that. Anyway, the argument is going round in circles. Peter F. Patel-Schneider pfpschnei...@gmail.com writes: In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. In the past I have tried various means to produce good-looking HTML and I've always gone back to a setup that produces PDF. If a document is available in both HTML and PDF I almost always choose to view it in PDF. This is the case even though I have particular preferences in how I view documents. If someone wants to change the format of conference submissions, then they are going to have to cater to the preferences of authors, like me, and reviewers, like me. If someone wants to change the format of conference papers, then they are going to have to cater to the preferences of authors, like me, attendees, like me, and readers, like me. I'm all for *better* methods for preparing, submitting, reviewing, and publishing conference (and journal) papers. So go ahead, create one. But just saying that HTML is better than PDF in some dimension, even if it were true, doesn't mean that HTML is better than PDF for this purpose. So I would say that the semantic web community is saying that there are better formats and tools for creating, reviewing, and publishing scientific papers than HTML and tools that create and view HTML. If there weren't these better ways then an HTML-based solution might be tenable, but why use a worse solution when a better one is available? peter On 10/03/2014 08:02 AM, Phillip Lord wrote: [...] As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. [...] Phil
Re: SPARQL Monitor Service?
On 10/3/14 11:28 AM, aho...@dcc.uchile.cl wrote: Hi Kingsley, We're working to resolve some issues (both technical and man-power related) so please consider this as a brief break in the SPARQLES service. We understand that the service is useful for the community and we are working to get it up and running again as soon as possible! Sorry for any inconvenience in the meantime! Best, Aidan Aidan, Thanks for responding, promptly! I now have a point of reference :) Naturally, if you need any assistance just ping me (on or offline). This service is very important to the LOD ecosystem. Kingsley On 03/10/2014 11:43, Kingsley Idehen wrote: All, The SPARQL monitor service identified by the URI http://sparqles.okfn.org is down. P.S., I'm not sure that the service *itself* is identified by the URI. *ducks* -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this smime.p7s Description: S/MIME Cryptographic Signature
Re: scientific publishing process (was Re: Cost and access)
My 2cents -- PDF is absolutely atrocious for e-readers. Kindles, Kobos and all the others *cannot* render a pdf appropriately (they're either too small, don't have dynamic zoom and are just a huge PITA to read on e-readers). I would be so happy to see papers available in form that I could actually read on an e-reader. It seems that one solution that would cater to some people's current practices would be to deploy a LaTeX -- HTML/RDFa script. On Fri, Oct 3, 2014 at 12:38 PM, Peter F. Patel-Schneider pfpschnei...@gmail.com wrote: One problem with allowing HTML submission is ensuring that reviewers can correctly view the submission as the authors intended it to be viewed. How would you feel if your paper was rejected because one of the reviewers could not view portions of it? At least with PDF there is a reasonably good chance that every paper can be correctly viewed by all its reviewers, even if they have to print it out. I don't think that the same claim can be made for HTML-based systems. Further, why should there be any technical preference for HTML at all? (Yes, HTML is an open standard and PDF is a closed one, but is there anything else besides that?) Web conference vitally use the web in their reviewing and publishing processes. Doesn't that show their allegiance to the web? Would the use of HTML make a conference more webby? peter On 10/03/2014 09:11 AM, Phillip Lord wrote: In my opinion, the opposite is true. PDF I almost always end up printing out. This isn't the point though. Necessity is the mother of invention. In the ideal world, a web conference would allow only HTML submission. Failing that, at least HTML submission. But, currently, we cannot submit HTML at all. What is the point of creating a better method, if we can't use it? The only argument that seems at all plausible to me is, well, we've always done it like this, and it's too much effort to change. I could appreciate that. Anyway, the argument is going round in circles. Peter F. Patel-Schneider pfpschnei...@gmail.com writes: In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. In the past I have tried various means to produce good-looking HTML and I've always gone back to a setup that produces PDF. If a document is available in both HTML and PDF I almost always choose to view it in PDF. This is the case even though I have particular preferences in how I view documents. If someone wants to change the format of conference submissions, then they are going to have to cater to the preferences of authors, like me, and reviewers, like me. If someone wants to change the format of conference papers, then they are going to have to cater to the preferences of authors, like me, attendees, like me, and readers, like me. I'm all for *better* methods for preparing, submitting, reviewing, and publishing conference (and journal) papers. So go ahead, create one. But just saying that HTML is better than PDF in some dimension, even if it were true, doesn't mean that HTML is better than PDF for this purpose. So I would say that the semantic web community is saying that there are better formats and tools for creating, reviewing, and publishing scientific papers than HTML and tools that create and view HTML. If there weren't these better ways then an HTML-based solution might be tenable, but why use a worse solution when a better one is available? peter On 10/03/2014 08:02 AM, Phillip Lord wrote: [...] As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. [...] Phil -- (•`'·.¸(`'·.¸(•)¸.·'´)¸.·'´•) .,.,
Re: scientific publishing process (was Re: Cost and access)
On Fri, Oct 3, 2014 at 6:38 PM, Peter F. Patel-Schneider pfpschnei...@gmail.com wrote: Further, why should there be any technical preference for HTML at all? Well one thing that HTML has over PDF is the ability to create typed links (RDFa) to other resources. To me that's a technical preference. Also the fact that it renders on all devices natively (all devices come with a Web-browser) is a technical preference. The fact that you can run JavaScript and provide interactions such as http://worrydream.com/LadderOfAbstraction/ is a technical preference. Probably many more...
Re: Cost and access (Was Re: [ESWC 2015] First Call for Paper)
Hi Phillip, Eric, et. al. On Fri, 10/3/14, Phillip Lord phillip.l...@newcastle.ac.uk wrote: Eric Prud'hommeaux e...@w3.org writes: Let's work through the requirements and a plausible migration plan. We need: 1 persistent storage: it's hard to beat books for a feeling of persistence. Contracts with trusted archival institutions can help but we might also want some assurances that the protocols and formats will persist as well. [snip] Protocols and formats, yes, true a problem. I think in an argument between HTML and PDF, then it's hard to see one has the advantage over another. My experience is that HTML is easier to extract text from, which is always going to be base line. --- Easier still is (X)HTML or XML written in plain text with Character Entities Hex Escaped. Clipboards are owned by the OS and for ordinary users, syntax errors are fatal; BreadButter (full employment) for Help Desks. Personally, I am un-fond of that ideology. XSLT 2.0 has a (flawless) translation mechanism which eases user pain. I've used it several times for StratML projects. If you want a copy of the transform, contact me off line. --- For what it is worth, there are achiving solutions, including archive.org and arxiv.org both of which leap to mind. --- The archiving solutions work well for the persistance of protocols and formats. Persistance of Linked Data depends upon the ability of an archive to reduce owl:sameAs and rdfs:* to their *export* standards. Professional credibility in all disciplines relies on how well one hefts the lingo - applies the schema labels to shared concepts. Publishers are very sensitive to this concern and it may be Linked Data with the deaf ear. [snip] Okay. I would like to know who made the decision that HTML is not acceptable and why. This is a related issue. The decision to ignore the seperation of concerns issue mentioned above is a user acceptance impediment when protocols and formats are the only parameters considered. In a few decades perhaps we will have real AI, Turing Machines, and academic disciplines will have their own Ontologies which speak to them. As a container, I think HTML is fine. I am not comfortable with RDFa decorations or /html/head meta data as absentee ownership of documents. In the meantime, Archives will have to develop methods to recycle and reduce rdfs:Labels, and they will have to be (uncharactaristically) ruthless. The statistics of RDF rely on a well known paradox (http://en.wikipedia.org/wiki/Birthday_problem). Close matches between name spaces and Ontologies have an extreme bias toward high probability identification. In the end, the probability is just a number, but it intimidates ordinary partial fractions who believe it is the smartest guy in the room. That is rather a bad thing. Cheers, Gannon Phil
Re: scientific publishing process (was Re: Cost and access)
On Fri, Oct 3, 2014 at 1:38 PM, Peter F. Patel-Schneider pfpschnei...@gmail.com wrote: One problem with allowing HTML submission is ensuring that reviewers can correctly view the submission as the authors intended it to be viewed. How would you feel if your paper was rejected because one of the reviewers could not view portions of it? At least with PDF there is a reasonably good chance that every paper can be correctly viewed by all its reviewers, even if they have to print it out. I don't think that the same claim can be made for HTML-based systems. The majority of journals I'm familiar with mandates a certain format for submission: font size, figure format, etc. So, in a HTML format submission, there should be rules as well, a standard CSS and the right elements and classes. Not different from getting a word(c) or latex template. Web conference vitally use the web in their reviewing and publishing processes. Doesn't that show their allegiance to the web? Would the use of HTML make a conference more webby? As someone said, this is leading by example. dfcp peter On 10/03/2014 09:11 AM, Phillip Lord wrote: In my opinion, the opposite is true. PDF I almost always end up printing out. This isn't the point though. Necessity is the mother of invention. In the ideal world, a web conference would allow only HTML submission. Failing that, at least HTML submission. But, currently, we cannot submit HTML at all. What is the point of creating a better method, if we can't use it? The only argument that seems at all plausible to me is, well, we've always done it like this, and it's too much effort to change. I could appreciate that. Anyway, the argument is going round in circles. Peter F. Patel-Schneider pfpschnei...@gmail.com writes: In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. In the past I have tried various means to produce good-looking HTML and I've always gone back to a setup that produces PDF. If a document is available in both HTML and PDF I almost always choose to view it in PDF. This is the case even though I have particular preferences in how I view documents. If someone wants to change the format of conference submissions, then they are going to have to cater to the preferences of authors, like me, and reviewers, like me. If someone wants to change the format of conference papers, then they are going to have to cater to the preferences of authors, like me, attendees, like me, and readers, like me. I'm all for *better* methods for preparing, submitting, reviewing, and publishing conference (and journal) papers. So go ahead, create one. But just saying that HTML is better than PDF in some dimension, even if it were true, doesn't mean that HTML is better than PDF for this purpose. So I would say that the semantic web community is saying that there are better formats and tools for creating, reviewing, and publishing scientific papers than HTML and tools that create and view HTML. If there weren't these better ways then an HTML-based solution might be tenable, but why use a worse solution when a better one is available? peter On 10/03/2014 08:02 AM, Phillip Lord wrote: [...] As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. [...] Phil
Re: scientific publishing process (was Re: Cost and access)
from reading all these emails it seems to me that we are somehow thinking just in terms of the same document just that more friendly for a web browser. I would argue that having a layout friendly document has been solved long ago, the problem is having an interoperable document beyond just having the usual metadata (author, tittle, etc). On Fri, Oct 3, 2014 at 10:25 AM, Diogo FC Patrao djogopat...@gmail.com wrote: On Fri, Oct 3, 2014 at 1:38 PM, Peter F. Patel-Schneider pfpschnei...@gmail.com wrote: One problem with allowing HTML submission is ensuring that reviewers can correctly view the submission as the authors intended it to be viewed. How would you feel if your paper was rejected because one of the reviewers could not view portions of it? At least with PDF there is a reasonably good chance that every paper can be correctly viewed by all its reviewers, even if they have to print it out. I don't think that the same claim can be made for HTML-based systems. The majority of journals I'm familiar with mandates a certain format for submission: font size, figure format, etc. So, in a HTML format submission, there should be rules as well, a standard CSS and the right elements and classes. Not different from getting a word(c) or latex template. Web conference vitally use the web in their reviewing and publishing processes. Doesn't that show their allegiance to the web? Would the use of HTML make a conference more webby? As someone said, this is leading by example. dfcp peter On 10/03/2014 09:11 AM, Phillip Lord wrote: In my opinion, the opposite is true. PDF I almost always end up printing out. This isn't the point though. Necessity is the mother of invention. In the ideal world, a web conference would allow only HTML submission. Failing that, at least HTML submission. But, currently, we cannot submit HTML at all. What is the point of creating a better method, if we can't use it? The only argument that seems at all plausible to me is, well, we've always done it like this, and it's too much effort to change. I could appreciate that. Anyway, the argument is going round in circles. Peter F. Patel-Schneider pfpschnei...@gmail.com writes: In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. In the past I have tried various means to produce good-looking HTML and I've always gone back to a setup that produces PDF. If a document is available in both HTML and PDF I almost always choose to view it in PDF. This is the case even though I have particular preferences in how I view documents. If someone wants to change the format of conference submissions, then they are going to have to cater to the preferences of authors, like me, and reviewers, like me. If someone wants to change the format of conference papers, then they are going to have to cater to the preferences of authors, like me, attendees, like me, and readers, like me. I'm all for *better* methods for preparing, submitting, reviewing, and publishing conference (and journal) papers. So go ahead, create one. But just saying that HTML is better than PDF in some dimension, even if it were true, doesn't mean that HTML is better than PDF for this purpose. So I would say that the semantic web community is saying that there are better formats and tools for creating, reviewing, and publishing scientific papers than HTML and tools that create and view HTML. If there weren't these better ways then an HTML-based solution might be tenable, but why use a worse solution when a better one is available? peter On 10/03/2014 08:02 AM, Phillip Lord wrote: [...] As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. [...] Phil -- Alexander Garcia http://www.alexandergarcia.name/ http://www.usefilm.com/photographer/75943.html http://www.linkedin.com/in/alexgarciac
Re: Cost and access (Was Re: [ESWC 2015] First Call for Paper)
On Oct 3, 2014 11:07 AM, Phillip Lord phillip.l...@newcastle.ac.uk wrote: Eric Prud'hommeaux e...@w3.org writes: Let's work through the requirements and a plausible migration plan. We need: 1 persistent storage: it's hard to beat books for a feeling of persistence. Contracts with trusted archival institutions can help but we might also want some assurances that the protocols and formats will persist as well. 1. An item printed on NISO Z39.48 conformant paper, using appropriate ink, is intended to have a life expectancy of several hundred years. Issues of testing using accelerated aging complicate matters - see e.g. http://www.loc.gov/preservation/resources/rt/AcceleratedAging.pdf Lossless compression of paper is difficult, which leads to a much higher attrition rate as items are weeded. Retrieval costs become higher as the number of replicas decreases. On the other hand, because a copy of the material is owned, a decision not to continue subscription to a journal does not cause loss of access to previous issues. 2. Document format obsolescence does not seem to be as big a problem as was once feared due to pre-emptive awareness of the issue, and the use of approaches like emulation. See e.g. http://www.dpworkshop.org/dpm-eng/oldmedia/index.html 3. Physical format obsolescence is a bigger issue; however moving forward it is less of a concern since storage media needs to be periodically replaced. 4. Archival data can (and should) be replicated, in multiple locations. Systems like David Rosenthal's LOCKSS (Lots Of Copies Keep Stuff Safe) use a k-strategy, using a relatively small number of high reliability and high cost replicas, at highly trusted institutions. http://www.lockss.org I proposed an r-strategy approach, using a much larger ad-hoc mesh containing much less reliable storage services with far more copies (requiring much more reasoning and automated planning to conform to preservation and performance policies). The working title was SCHMEER (Several Copies Help Make Everything Eventually Reachable) - alas my advisor, a noted expert in Digital Preservation, was not comfortable with computer thingies... I've thrown away **Weeded** conference proceedings the last decade anyway. 2 impact factor: i have the impression that conventional publishers have a bit of a monopoly and and sudden disruption would be hard to engineer. How do to get leading researchers to devote their work in some new crackpot e-journal to the exclusion of other articles which will earn them more points towards tenure and grants? Perhaps the answer is slowly build the impact factor; perhaps it's some sort of revolution in the minds of administrators and funders. The value of publication in formal journals derives solely from scarcity. Because there are only a limited number of slots, they allow for simple metrics. The same value could be achieved by skipping the whole publication part, and just issuing digitally signed badges to go in the disciplinary archives. Sophisticated scientometrics can provide more useful measures of the value of scientific research, but any metric that is known ahead of time can be gamed. Cassidy Sugimoto and I joked about starting a company called pimp my h that would provide bespoke strategic advice on publishing strategies to get the most h for a given amount of new work- intentional obliteration, Google Scholar SEO etc). We never thought of making up imaginary people to cite stuff though. There is a lot of effort going in to making data citable in ways meaningful to funding agencies. Simon
Re: Cost and access (Was Re: [ESWC 2015] First Call for Paper)
On 10/3/14 11:12 AM, Alexander Garcia Castro wrote: I think that this is at the core of the problem: 2 impact factor: i have the impression that conventional publishers have a bit of a monopoly and and sudden disruption would be hard to engineer. How do to get leading researchers to devote their work in some new crackpot e-journal to the exclusion of other articles which will earn them more points towards tenure and grants? Perhaps the answer is slowly build the impact factor; perhaps it's some sort of revolution in the minds of administrators and funders. publishers also own impact factors. in addition, impact factors are thought for printed material not for the web, not to talk about the web of data. there are the alt metrics but those are yet to prove their validity. I keep wondering if html and pdfs are the only options. why not having a real web-of-data native format? Or have everything in RDF (specific notation irrelevant) which can be transformed and published using HTML, PDF, Latex, or any other document types. You raised the question that SHOULD have been asked eons ago, in regards to Linked Open Data and all the conferences that swirl around it :) -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this smime.p7s Description: S/MIME Cryptographic Signature
Re: scientific publishing process (was Re: Cost and access)
On 10/3/14 11:50 AM, Peter F. Patel-Schneider wrote: In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. Why can can't we start with RDF documents, and then generate HTML, PDF, Latex etc.. documents from base RDF documents? I can't believe we don't do this, circa., 2014. Why do we work unproductively with HTML, PDF, Latex etc.. when they can all be generated from RDF documents? The steps should be: 1. Create an RDF Document 2. Generate HTML, PDF, Latex etc.. from the RDF document 3. Deliver a bundle comprised of RDF, HTML, PDF, Latex, or whatever the conference seeks -- if conferences in question are associated with Linked Open Data and the Semantic Web they should look themselves in the mirror when rejecting this kind of loosely-coupled bundle. -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this smime.p7s Description: S/MIME Cryptographic Signature
Re: scientific publishing process (was Re: Cost and access)
On 10/03/2014 10:25 AM, Diogo FC Patrao wrote: On Fri, Oct 3, 2014 at 1:38 PM, Peter F. Patel-Schneider pfpschnei...@gmail.com mailto:pfpschnei...@gmail.com wrote: One problem with allowing HTML submission is ensuring that reviewers can correctly view the submission as the authors intended it to be viewed. How would you feel if your paper was rejected because one of the reviewers could not view portions of it? At least with PDF there is a reasonably good chance that every paper can be correctly viewed by all its reviewers, even if they have to print it out. I don't think that the same claim can be made for HTML-based systems. The majority of journals I'm familiar with mandates a certain format for submission: font size, figure format, etc. So, in a HTML format submission, there should be rules as well, a standard CSS and the right elements and classes. Not different from getting a word(c) or latex template. This might help. However, someone has to do this, and ensure that the result is generally viewable. Web conference vitally use the web in their reviewing and publishing processes. Doesn't that show their allegiance to the web? Would the use of HTML make a conference more webby? As someone said, this is leading by example. Yes, but what makes HTML better for being webby than PDF? dfcp peter
Re: Cost and access (Was Re: [ESWC 2015] First Call for Paper)
On Fri, 10/3/14, Simon Spero sesunc...@gmail.com wrote: We never thought of making up imaginary people to cite stuff though. Never mind that, imagine the automation possibilities Huge numbers of imaginary people talking to themselves ... (thanks for the laugh) There is a lot of effort going in to making data citable in ways meaningful to funding agencies. A few years ago, I wrote a page which enables Agencies of the US Government to discover like-interested peers within so they could compare stratigies and plans. Simply talking to each other would be a possible solution, but given that the Agencies compete for funds with the same funding agency - Congress - there is a reluctance to be too open with each other. The output is Library of Congress MODS XML. It is dated, but here it is: http://www.rustprivacy.org/faca/samples/displayStratMLcorrespondants.html --Gannon
RE: scientific publishing process (was Re: Cost and access)
Yes, but what makes HTML better for being webby than PDF? Because it is a mark-up language (albeit largely syntactic) which makes it much more amenable to machine processing? -Original Message- From: Peter F. Patel-Schneider [mailto:pfpschnei...@gmail.com] Sent: 03 October 2014 21:15 To: Diogo FC Patrao Cc: Phillip Lord; semantic-...@w3.org; public-lod@w3.org Subject: Re: scientific publishing process (was Re: Cost and access) On 10/03/2014 10:25 AM, Diogo FC Patrao wrote: On Fri, Oct 3, 2014 at 1:38 PM, Peter F. Patel-Schneider pfpschnei...@gmail.com mailto:pfpschnei...@gmail.com wrote: One problem with allowing HTML submission is ensuring that reviewers can correctly view the submission as the authors intended it to be viewed. How would you feel if your paper was rejected because one of the reviewers could not view portions of it? At least with PDF there is a reasonably good chance that every paper can be correctly viewed by all its reviewers, even if they have to print it out. I don't think that the same claim can be made for HTML-based systems. The majority of journals I'm familiar with mandates a certain format for submission: font size, figure format, etc. So, in a HTML format submission, there should be rules as well, a standard CSS and the right elements and classes. Not different from getting a word(c) or latex template. This might help. However, someone has to do this, and ensure that the result is generally viewable. Web conference vitally use the web in their reviewing and publishing processes. Doesn't that show their allegiance to the web? Would the use of HTML make a conference more webby? As someone said, this is leading by example. Yes, but what makes HTML better for being webby than PDF? dfcp peter
Re: scientific publishing process (was Re: Cost and access)
On Fri, 2014-10-03 at 10:32 -0700, Alexander Garcia Castro wrote: from reading all these emails it seems to me that we are somehow thinking just in terms of the same document just that more friendly for a web browser. I would argue that having a layout friendly document has been solved long ago, the problem is having an interoperable document beyond just having the usual metadata (author, tittle, etc). Yes. We are setting the bar too low. The field of knowledge computing will only reach maturity when authors can publish their theses in such a manner that one can programmatically extract the concepts, propositions, and arguments; merge and reconcile them with one's own collection of concepts, propositions, and arguments; and manipulate (test, compare, confirm, etc.) them to alter or enlarge one's knowledge. This is nothing but computer assistance for the age-old way of knowledge dissemination and acquisition heretofore mediated by printed material and executed by thoughtful readers. (See Mortimer Adler, How to read a book and Sister Miriam Joseph, The Trivium.) I suspect some system for doing this could be cobbled together with existing RDF and XML standards and technology, but there is much room for improvement. Regards, --Paul snip
Re: scientific publishing process (was Re: Cost and access)
html5 has so-called semantic tags, like header, section. -- diogo patrão On Fri, Oct 3, 2014 at 6:01 PM, john.nj.dav...@bt.com wrote: Yes, but what makes HTML better for being webby than PDF? Because it is a mark-up language (albeit largely syntactic) which makes it much more amenable to machine processing? -Original Message- From: Peter F. Patel-Schneider [mailto:pfpschnei...@gmail.com] Sent: 03 October 2014 21:15 To: Diogo FC Patrao Cc: Phillip Lord; semantic-...@w3.org; public-lod@w3.org Subject: Re: scientific publishing process (was Re: Cost and access) On 10/03/2014 10:25 AM, Diogo FC Patrao wrote: On Fri, Oct 3, 2014 at 1:38 PM, Peter F. Patel-Schneider pfpschnei...@gmail.com mailto:pfpschnei...@gmail.com wrote: One problem with allowing HTML submission is ensuring that reviewers can correctly view the submission as the authors intended it to be viewed. How would you feel if your paper was rejected because one of the reviewers could not view portions of it? At least with PDF there is a reasonably good chance that every paper can be correctly viewed by all its reviewers, even if they have to print it out. I don't think that the same claim can be made for HTML-based systems. The majority of journals I'm familiar with mandates a certain format for submission: font size, figure format, etc. So, in a HTML format submission, there should be rules as well, a standard CSS and the right elements and classes. Not different from getting a word(c) or latex template. This might help. However, someone has to do this, and ensure that the result is generally viewable. Web conference vitally use the web in their reviewing and publishing processes. Doesn't that show their allegiance to the web? Would the use of HTML make a conference more webby? As someone said, this is leading by example. Yes, but what makes HTML better for being webby than PDF? dfcp peter
Re: scientific publishing process (was Re: Cost and access)
On 10/3/14 5:05 PM, Paul Tyson wrote: On Fri, 2014-10-03 at 10:32 -0700, Alexander Garcia Castro wrote: from reading all these emails it seems to me that we are somehow thinking just in terms of the same document just that more friendly for a web browser. I would argue that having a layout friendly document has been solved long ago, the problem is having an interoperable document beyond just having the usual metadata (author, tittle, etc). Yes. We are setting the bar too low. The field of knowledge computing will only reach maturity when authors can publish their theses in such a manner that one can programmatically extract the concepts, propositions, and arguments; merge and reconcile them with one's own collection of concepts, propositions, and arguments; and manipulate (test, compare, confirm, etc.) them to alter or enlarge one's knowledge. Yes, and we have a name for an abstract language (loosely bound to a variety of notations) that enables the above, in a manner that's comprehensible by both humans and machines, its called RDF. When you construct RDF statements (claims or propositions) using HTTP URIs to denote the subject, predicate, and objects of said propositions, you end up with RDF based Linked Data i.e., webby (or web-like) propositions that are still comprehensible to both humans and machines :-) Links: [1] http://kidehen.blogspot.com/2014/07/nanotation.html -- About Nanotation -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this smime.p7s Description: S/MIME Cryptographic Signature
Re: scientific publishing process (was Re: Cost and access)
Does ease of processing make something more webby? If so, LaTeX should be preferred to HTML. peter On 10/03/2014 02:01 PM, john.nj.dav...@bt.com wrote: Yes, but what makes HTML better for being webby than PDF? Because it is a mark-up language (albeit largely syntactic) which makes it much more amenable to machine processing? -Original Message- From: Peter F. Patel-Schneider [mailto:pfpschnei...@gmail.com] Sent: 03 October 2014 21:15 To: Diogo FC Patrao Cc: Phillip Lord; semantic-...@w3.org; public-lod@w3.org Subject: Re: scientific publishing process (was Re: Cost and access) On 10/03/2014 10:25 AM, Diogo FC Patrao wrote: On Fri, Oct 3, 2014 at 1:38 PM, Peter F. Patel-Schneider pfpschnei...@gmail.com mailto:pfpschnei...@gmail.com wrote: One problem with allowing HTML submission is ensuring that reviewers can correctly view the submission as the authors intended it to be viewed. How would you feel if your paper was rejected because one of the reviewers could not view portions of it? At least with PDF there is a reasonably good chance that every paper can be correctly viewed by all its reviewers, even if they have to print it out. I don't think that the same claim can be made for HTML-based systems. The majority of journals I'm familiar with mandates a certain format for submission: font size, figure format, etc. So, in a HTML format submission, there should be rules as well, a standard CSS and the right elements and classes. Not different from getting a word(c) or latex template. This might help. However, someone has to do this, and ensure that the result is generally viewable. Web conference vitally use the web in their reviewing and publishing processes. Doesn't that show their allegiance to the web? Would the use of HTML make a conference more webby? As someone said, this is leading by example. Yes, but what makes HTML better for being webby than PDF? dfcp peter
Re: scientific publishing process (was Re: Cost and access)
Hmm. Are these semantic? All these seem to do is to signal parts of a document. What I would consider to be semantic would be a way of extracting the mathematical content of a document. peter On 10/03/2014 02:32 PM, Diogo FC Patrao wrote: html5 has so-called semantic tags, like header, section. -- diogo patrão On Fri, Oct 3, 2014 at 6:01 PM, john.nj.dav...@bt.com mailto:john.nj.dav...@bt.com wrote: Yes, but what makes HTML better for being webby than PDF? Because it is a mark-up language (albeit largely syntactic) which makes it much more amenable to machine processing? -Original Message- From: Peter F. Patel-Schneider [mailto:pfpschnei...@gmail.com mailto:pfpschnei...@gmail.com] Sent: 03 October 2014 21:15 To: Diogo FC Patrao Cc: Phillip Lord; semantic-...@w3.org mailto:semantic-...@w3.org; public-lod@w3.org mailto:public-lod@w3.org Subject: Re: scientific publishing process (was Re: Cost and access) On 10/03/2014 10:25 AM, Diogo FC Patrao wrote: On Fri, Oct 3, 2014 at 1:38 PM, Peter F. Patel-Schneider pfpschnei...@gmail.com mailto:pfpschnei...@gmail.com mailto:pfpschnei...@gmail.com mailto:pfpschnei...@gmail.com wrote: One problem with allowing HTML submission is ensuring that reviewers can correctly view the submission as the authors intended it to be viewed. How would you feel if your paper was rejected because one of the reviewers could not view portions of it? At least with PDF there is a reasonably good chance that every paper can be correctly viewed by all its reviewers, even if they have to print it out. I don't think that the same claim can be made for HTML-based systems. The majority of journals I'm familiar with mandates a certain format for submission: font size, figure format, etc. So, in a HTML format submission, there should be rules as well, a standard CSS and the right elements and classes. Not different from getting a word(c) or latex template. This might help. However, someone has to do this, and ensure that the result is generally viewable. Web conference vitally use the web in their reviewing and publishing processes. Doesn't that show their allegiance to the web? Would the use of HTML make a conference more webby? As someone said, this is leading by example. Yes, but what makes HTML better for being webby than PDF? dfcp peter
Re: scientific publishing process (was Re: Cost and access)
As is often the case on the Internet, this discussion gives me a terrible sense of dejá vu. We've had this discussion many times before. Some years back the IW3C2 (the steering committee for the WWW conference series, of which I am part) first tried to require HTML for the WWW conference paper submissions, then was forced to make it optional because authors simply refused to write in HTML, and eventually dropped it because NO ONE (ok, very very few hardy souls) actually sent in HTML submissions. Our conclusion at the time was that the tools simply were not there, and it was too much of a PITA for people to produce HTML instead of using the text editors they are used to. Things don't seem to have changed much since. And this is simply looking at formatting the pages, never mind the whole issue of actually producing hypertext (ie., turning the article's text into linked hypertext), beyond the easily automated ones (e.g., links to authors, references to papers, etc..). Producing good hypertext, and consuming it, is much harder than writing plain text. And most authors are not trained in producing this kind of content. Making this actually semantic in some sense is still, in my view, a research topic, not a routine reality. Until we have robust tools that make it as easy for authors to write papers with the advantages afforded by PDF, without its shortcomings, I do not see this changing. I would love to see experiments (e.g., certain workshops) to try it out before making this a requirement for whole conferences. Bernadette's suggestions are a good step in this direction, although I suspect it is going to be harder than it looks (again, I'd love to be proven wrong ;-)). Just my personal 2c Daniel On Oct 3, 2014, at 12:50 - 03/10/14, Peter F. Patel-Schneider pfpschnei...@gmail.com wrote: In my opinion PDF is currently the clear winner over HTML in both the ability to produce readable documents and the ability to display readable documents in the way that the author wants them to display. In the past I have tried various means to produce good-looking HTML and I've always gone back to a setup that produces PDF. If a document is available in both HTML and PDF I almost always choose to view it in PDF. This is the case even though I have particular preferences in how I view documents. If someone wants to change the format of conference submissions, then they are going to have to cater to the preferences of authors, like me, and reviewers, like me. If someone wants to change the format of conference papers, then they are going to have to cater to the preferences of authors, like me, attendees, like me, and readers, like me. I'm all for *better* methods for preparing, submitting, reviewing, and publishing conference (and journal) papers. So go ahead, create one. But just saying that HTML is better than PDF in some dimension, even if it were true, doesn't mean that HTML is better than PDF for this purpose. So I would say that the semantic web community is saying that there are better formats and tools for creating, reviewing, and publishing scientific papers than HTML and tools that create and view HTML. If there weren't these better ways then an HTML-based solution might be tenable, but why use a worse solution when a better one is available? peter On 10/03/2014 08:02 AM, Phillip Lord wrote: [...] As it stands, the only statement that the semantic web community are making is that web formats are too poor for scientific usage. [...] Phil Daniel Schwabe Dept. de Informatica, PUC-Rio Tel:+55-21-3527 1500 r. 4356R. M. de S. Vicente, 225 Fax: +55-21-3527 1530 Rio de Janeiro, RJ 22453-900, Brasil http://www.inf.puc-rio.br/~dschwabe
