Re: just strings, please [was: reagle-01, reagle-02 issues]

Dan, I believe I will completely follow
you in your reasoning.
As you might know, we have been struggling
with [...] as functional terms and then
using ...^^... as functional terms
and one of the reasons was that in order
to do backward chaining we thought we
needed to rewrite the existentials in the
conclusion as skolem functional terms
when we wanted to have horn style logic
(single triple conclusions).
While playing with substitutions I now
think that there is no more need for
such functional terms; for instance
in case of
  {?x :b ?y} => {?x :k _:u . _u :m ?y}.
we could simply rewrite that as
  {?x :b ?y. ?u = (:sf ?x ?y)} => {?x :k ?u}.
  {?x :b ?y. ?u = (:sf ?x ?y)} => {?u :m ?y}.
That seems to do the job; just make sure...
Also as you and TimBL have been evidencing
interpretation properties are perfect, so all
we need are just triples, plain conjunctions,
implications and all using just uris, bnodes
(which turn into univars in premises/queries)
and strings and that's it. I think I could
drastically simplify euler in that respect...


> Date: Fri, 28 Feb 2003 15:28:36 -0600
> From: Dan Connolly <connolly@w3.org>
> To: Pat Hayes <phayes@ai.uwf.edu>
> Cc: Jeremy Carroll <jjc@hplb.hpl.hp.com>, www-archive@w3.org, Dan
Brickley <danbri@w3.org>, Eric Miller <em@w3.org>, Brian McBride
<bwm@hplb.hpl.hp.com>
> Message-id: <1046467715.7451.121.camel@dirk.dm93.org>
> Subject: just strings, please [was: reagle-01, reagle-02 issues]
>
>
> (not to the WG, yet)
>
> On Fri, 2003-02-28 at 09:00, pat hayes wrote:
> [...]
> > Then the entire rdf:XMLliteral datatype machinery is just an
> > elaborate way of encoding the old 'XML bit', which I thought was the
> > original intent in any case. Introducing XML canonicalization seems
> > to have been one those neat ideas that got slipped in without too
> > much discussion and has turned out to be a tar-pit. I am particularly
> > concerned that this ugly mess is now centrally included in the very
> > core of RDF. I would hope that many 'cheap and cheerful' RDF engines
> > wouldn't even want to know about XML, still less about XML
> > canonicalization.
>
> Amen.
>
> I'm starting to think it's worth unravelling all these
> barnacles around literals and going back to just to just
> strings, URIs, and bnodes as terms in RDF triples/graphs.
>
> no lang
>
> no c14n
>
> no datatypes
>
>
> rationale:
>
> no lang: the RDF query guys have been collecting
> use cases for a while; this one was suggested
> last June, and unlike all the others,
> nobody has reported a solution/implementation:
>
> [[
> Find the language specific value of a property  [image]
>         Retrieve the value of a property for a particular language (as
>         specified by xml:lang). Specifically, retrieve the english
>         description of each class specified in
>         http://www.w3.org/2000/01/rdf-schema#
>
>         Published by Geoff Chappell on 2002-06-25
> ]]
>  --
> http://rdfstore.sourceforge.net/2002/06/24/rdf-query/query-use-cases.html
>
> the folks that really need lang functionality are
> using real triples: see
>   4.2 Poor mans language qualification
>   in
>   http://www.dublincore.org/documents/dcq-rdf-xml/#sec4
>
> When the WG made the xml literal decision, I yielded
> because my alternative (representing XML infosets
> ala lisp s-expressions) was more complex than
> I could justify.
>
> But if we use simple
>   str xmlrep:parsesAs _:infosetDataStructure
> interpretation properties, life gets much
> simpler.
>
> I haven't worked out all the details, but
> I think it works better for stuff like XML
> query integration in the long run;
> Implementation experience:
>   http://www.w3.org/2001/03swell/xml.n3
> (EricM, cf your "XML infoset modelling"
> action in the SemWeb CG)
>
>
> I know interpretation properties work in my
> apps for datatypes too; while I suspect
> putting datatypes into the abstract syntax
> doesn't minimize cost in the long term,
> I don't have direct evidence yet,
> the way I do for lang.
>
> I wanna see our design integrated
> with SQL engines. I pushed on that in after-hours
> chat a bit today, and Dave B and Jeremy said
> our design does fit with contemporary
> SQL implementation work.
>
> rationale against c14n is provided by reagle's issue,
> plus webont's issues...
>
>
>
>
> I'm not moving to reopen the WG decisions yet,
> but I'm collecting evidence and designing
> alternatives.
>
>
> --
> Dan Connolly, W3C http://www.w3.org/People/Connolly/

-- ,
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

Received on Saturday, 1 March 2003 09:14:02 UTC