W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2005

RDF for Textual Encoding (was: rdf for non SemWeb applications)

From: Giovanni Tummarello <giovanni@wup.it>
Date: Fri, 04 Feb 2005 10:43:58 +0100
Message-ID: <420343DE.7010609@wup.it>
To: www-rdf-interest@w3.org


this is a contribution to a thread from some time ago about "non SemWeb" 
applications of RDF.  By non SemWeb it was meant, i believe, 
applications to fields that naturally live without a network connection 
and , if that is the case, could probably make a closed world assumption 
(or have been doing it so far :-) ).
An example of such application is textual encoding, that is, writing in 
machine processable how a literary text is structured ( pages, rows, 
paragraphs, sentences,  verses.. all the way down to grammatical 
elements such as "verb" "subject" and so on.).

For those interested I'd like to point at embryonic stage paper 
(warnings: highly questionable grammar, incomplete and likely partially 
incorrect) which explores textual encoding using SW tools.


For decades people have been creating their specific data structure, for 
the problem they needed to solve. When XML came along, applications 
began making extensive use of it as a data structure format, but it is 
clear that just a small subset of problems can be naturally represented 
as a tree. So what happens is that most complex XML based data formats 
in practice make a large use, e.g,  of attributes to be able to 
construct  what they needed from the start: graphs.

Trying to apply the semantic web technologies to these sort of problems 
is very interesting since the payoff is big. If it works, if we can in 
fact address domain specific use cases and queries with the  tools and 
semantics from the SW then we can immediately:
* enjoy the use of a commonly understood set of high level semantic 
constructs rather than relaying on application specific idiosyncrasies 
in the data model.  This in short means that developers would use 
constructs they know therefore the  project is cheaper to build and less 
error prone
* be able to use a large and growing set of tools and applications
* be naturally to expand these applications to a distributed environment

The paper:


from a semantic web point of view, this simple use case i think 
highlights the shortcomings of the SW query languages  that have a fixed 
path length. The data model that we propose for the encoding makes 
SparQL (for example) rather useless to compute the example query in the 
paper (if not with a  preprocessing or the addition of a list aware 
operator as we suggest) . Prolog (or metalog would do)  on the other 
hand does it really sweet :-)

P.S. I used "non sem web" since these applications where previously 
referred to as such, but i also agree that they are , in fact, SemWeb 
applications in its wider, nicer scope

Giovanni Tummarello, also on behalf of Christian Morbidoni
Received on Friday, 4 February 2005 09:45:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:55 UTC