Re: Semantic Web Languages

BTW what is etiquet, to reply to all, or just to the list?
I have taken the more conservative option.
Comment about SPARQL is interesting. So it could be used, that is, is
powerful enough, to write RDF? Does that include OWL?
How would a SPARQL statement be translated into RDF/OWL?
Henry, I understand there was frustration about the 80s where progress was
bogged down in conflict over strategy.
But I wonder if those conflicts ever really go away?
Isn't it what Peirce pointed out, that there is generalisation and
specifics, neither one without the other and generalisations can be
established at arbitrary points with respect to other generalisations and
with arbitrary boundaries?
Related is that it is possible to draw an analogy to anything, as my last
post illustrated. Of course I think it was a good analogy. But others may
think it wildly off topic. Again the etiquet of list posting has a role
here, and what is percieved as relevant is deliniated in a far stricter way
than in ordinary conversation (and this is a habit of technologists as well,
I'm not sure it is such a good habit though).
When thinking about these things one has to accept there is something very
fluid going on.
Let me illustrate with one of my concerns. My question comes right at the
end of this lengthy preamble.
I have been working on a project that entailed starting with government
originated schema, creating XML, from the XML an object model that was
contained in a work flow engine and exposed at different points as services
using SOAP (WSDL).
We went about this using AXIS to auto create the Java OM, but this actually
failed (for some obscure reason) and we ended up crafting the marshaling and
unmarshaling code by hand.
Moreover the OM had object nodes that had useful, but completely domain
specific names. This has both advantages, during development one knew what
one was looking at or looking for, and disadvantages which include very
little reuse, a lot of repetition and a consequent lack of modularity and
flexibility. I think the disadvantages outweigh the advantages.
But let us look at the situation would be were there to be a ready solution
to hand, let us say using some form of transformation pipelining based on
model theory. Newly introduced such a solution would meet a lot of inertia
and with good reason. The whole exercise is complex enough that the risks
associated with traveling a different solution path to that which is now
well tried and tested are considerable. These risks include, of course,
skill availability which is just another way of saying in the generality
what is an accepted way of tackling these problems. As Howard Lewis Ship,
the creator of the framework, Tapestry, I mention further below, once rather
sagely commented, in this development work one is coping with the limit of
complexity that humans can manage.
Now, before I go on, something else for the stew. The solution I am looking
for should contain a way to alter the relationship between input fields in a
rules governed manner and, concomitantly, alter the display of fields
dependant on the results of evaluating those rules. This, of course, has
been done, but another customer who wanted this particular solution (and
other bits of the puzzle concerning work flow and scanned input management,
but I needn't go into those details), wouldn't have bought in such a very
expensive solution. Their priority was to evaluate solutions that covered
the other bit of the puzzle first while for us, high and ready reuse would
be our priority due to the expense of otherwise having to reinvent the wheel
for every solution we offer.
The solution to the customer's main priorities is sold off the shelf by
suppliers who have developed their software over many years to its current
state of maturity.
So the picture is proprietary partial solutions that cover the most
important requirments against putative open source, open standards solutions
that could be developed later in a flexible manner etc. by whom ever that
customer might chose.
Strangely enough, such a solution, to my knowledge, doesn't exist at the
moment.
What is, perhaps, closest are the efforts around WSMO, but there is still a
lot missing.
In our development work we have used a framework called Tapestry. What is
relevant here is that the framework has been described as "static-structure
dynamic-behaviour" in a recent discusion on their list with the subject
"dynamically specifying component type".
And a solution was suggested along these lines:-

> Mark Stang
> <mstang@pingidentity.com> to Tapestry,
>
Where we have a Finite State Machine ("the Tasklet") which has states.  The
> State Name is what we use to look up the component.  So, as we progress
> through the state machine the states change and so does the component
> rendered.
>
It is possible to configure each state to pull it's components from a
> particular page, but in practice we have only one page.  It is called
> "Holder" and we generate it via ant from the .application file.
> We store the FSM in the visit.

In other words there is an XML file - the .application file, that is used to
auto generate a single .page file (another XML file that represents the way
components are used in the final rendered html, by allowing object instances
to pick up their parameters and taking those objects return values).
But in this implementation this process is mediated through the FSM, the
tasklet, allowing another level of indirection and additional computation.
Irrespective of the merits of this framework, as there are others and other
languages too, my question is what might products of the semantic web have
to contribute at this point, if anything?
I envisage that this FSM should be engineered to be semantically aware, to
be able to read in an Ontology that would represent the rules I have
mentioned. Lower down the persistence layer should be implemented using e.g.
Sesame/Sail which should be more straight forward than using hibernate.
But am I at all correct?
An application like this should save a lot of developer work and achieve a
lot of the goals I have mentioned. I think this sort of thing, which has in
a way been sized and costed, e.g. the market and development time are
scopable, would be an application for sem web technologies and would involve
architecture, not just bottom up usage, in fact a paradign application.
Thoughts?
Adam



On 02/04/06, Dan Brickley <danbri@danbri.org> wrote:
>
>
> * Henry Story < henry.story@bblfish.net> [2006-04-02 08:49+0200]
> >
> >
> > On 31 Mar 2006, at 23:58, John F. Sowa wrote:
> > >Danny,
> > >
> > >I don't violently disagree with anything you said, but I
> > >do have some quibbles and a couple of extra points:
> > >
> > >> One of my dayjob contracts requires a kind of validation
> > >> outside of RDF/OWL, this I'm implementing using custom
> > >> (mostly hard-coded) logic on top of the RDF/OWL representation.
> > >> ... Throughout this work I'm mixing and matching numerous
> > >> RDFS vocabularies/OWL ontologies as demanded by the domain.
> > >
> > >I realize that many people have been doing useful work with RDF
> > >and OWL, and since nothing better is widely available, people
> > >have to live with what they've been given.  But I believe that
> > >anything that has been done with RDF could have been done sooner,
> > >better, and with much greater efficiency with an XML tag that
> > >says LANG=TupleList followed by an enclosed list of tuples in
> > >the form (and with the option of n-ary tuples as well):
> > >
> > >   (R1 a b) (R2 c d) (R3 e f) (R4 g h) ...
> >
> > There have been numerous xml proposals along this line. Tim Bray
> > proposed one.
> > TriX is another [1]. But you could also look at NTriples [3] for a
> > very simple non xml version.
>
> NTriples was based on TimBL's Notation 3,
> http://www.w3.org/DesignIssues/Notation3.html which was also an ancestor
> of Turtle (a simpler and more triple-centric subset),
> http://www.dajobe.org/2004/01/turtle/   which itself influenced the
> design of the SPARQL syntax for querying RDF.
>
> In fact, I wouldn't be suprised if folks started using SPARQL notation
> for writing RDF...
>
> Dan
>
>