Re: A summary of the proposal for resolving the issues with rdf:text --> Could you please check it one more time?

On Thu, May 21, 2009 at 09:05:43PM +0200, Harry Halpin wrote:
> I apologize for angering anyone with my previous e-mail (although,
> again, it is a bad idea to create incompabilities, period, with RDF I
> think at this point), especialy if we want RIF and OWL2 to get heavy
> adoption (which I want). I did not receive any warnings, but got this
> from SWIG. I have, upon Sandro's suggestion, removed SWIG for the
> list.
> 
> All I'm saying is why not add text like this, with some test cases:
> 
> "As applications that support rdf:text may deal with RDF data that
> supports only plain literals and pre-dates rdf:text,  when exchanging
> RDF graphs plain literals are replaced with rdf:text literals"
> 
> Which is just the natural inverse of what is *already* said in the spec:
> 
> " ..typed rdf:text literals are semantically equivalent to plain
> literals, which allows specifications built on top of RDF to consider
> only typed literals. Since the rdf:text datatype just provides
> additional forms for writing plain literals, its addition does not
> change the semantics of RDF. Furthermore, when exchanging RDF graphs
> between RDF tools, typed rdf:text literals must be replaced with plain
> literals, thus maximizing interoperability between RDF tools that
> support rdf:text and those that do not.
> 
> That's a quick and simple engineering hack that keeps the OWL2/RIF
> formal semantics straight I assume, while letting RIF/OWL2 operate
> over existing RDF data and getting whatever features result from
> rdf:text without forcing people to add rdf:text to existing data. That
> is a goal, right? If not, why?

if there are two classes of RDF graphs, those that are used for
exchange, and those that are used in applications, then later specs
which refer to plain literals need to specify which class of graphs
they apply to. perhaps more compelling is the issue that for many
systems, (and this is certainly a design goal of good specs) there are
no clear distinctions between the graphs used inferencing systems,
query systems or applications using graph APIs. examples include OWLIM
for Sesame and the Jena plugins for Oracle.

one could try to be exhaustively prescriptive about when which graphs
where allowed to exist and when they were at risk of being exposed to
e.g. non-rdf:text application, but then at that point, the non-
interchange class of graph becomes an implementation detail which
doesn't need specification at all. do what you want in the privacy of
your internal structures.


> I will not formally object to rdf:text without the sentence above, and
> hopefully a quick hack would prevent any formal objections However, I
> do sympathize with objections over features that - and remember, I'm
> saying *from the outside*, I'm sure there's good reasons on the
> *inside* - that create incompatibilities.
> 
> On Thu, May 21, 2009 at 8:38 PM, Harry Halpin <hhalpin@ibiblio.org> wrote:
> > Quick note -
> >
> >    I have not been tracking this issue, but it does seem a very bad
> > idea (well worthy of a formal objection) in general to create a
> > incompatibility with something as a basic as a text string, ala plan
> > literal. As this seems to be an issue almost entirely motivated by
> > formal semantics, I see *no* reason why formal semantic motivations
> > should cause pain for users and already existing data.
> >
> >  Why not just in RIF and OWL2 have plain literals default to be
> > treated as having a data-type of "rdf:text" (or whatever is needed in
> > the formal semantics), and never require the explicit edition of any
> > work by the users?
> >
> > In particular, ""Family Guy" would then default to ""Family Guy@". Why
> > is this option not tenable? Seems rather sensible to me, but I assume
> > there *must* be some reason for not doing it that way.
> >
> >
> > On Wed, May 20, 2009 at 7:20 PM, Pat Hayes <phayes@ihmc.us> wrote:
> >>
> >> On May 20, 2009, at 9:57 AM, Boris Motik wrote:
> >>
> >>> Hello,
> >>>
> >>> I have to agree that the text in the rdf:text specification might not
> >>> reflect
> >>> correctly the intentions I expressed. Quite frankly, we (i.e., the authors
> >>> of
> >>> the rdf:text specification) haven't been really aware of all the
> >>> repercussions
> >>> and possible interpretations of our spec. The text you refer to at the end
> >>> of
> >>> this e-mail has been introduced as a reaction to one of the earlier
> >>> comments by
> >>> the SPARQL WG.
> >>>
> >>> Nevertheless, here is what the goals of rdf:text are:
> >>
> >> Thanks for this summary.
> >>
> >>>
> >>> 1. Both RIF and OWL 2 find the distinction between plain and typed
> >>> literals
> >>> painful. This is because, whenever one refers to literals, one needs two
> >>> subcases: for a plain and for a typed literal.
> >>
> >> So?
> >>
> >>> Both RIF and OWL 2 have
> >>> independently come up with exactly the same idea: they opted to represent
> >>> the
> >>> "semantic content" of plain literals through typed literals whose value is
> >>> the
> >>> same as the corresponding plain literals.
> >>
> >> Thanks for making this clear in a public forum. OWL 2 and RIF are
> >> deliberately, by design, creating a central incompatibility with a basic
> >> feature of RDF. This  seems to me to be a quite extraordinary and amazing
> >> observation, one that deserves to be publicized as widely as possible (which
> >> is why I am CCing this to semantic-web@w3.org). Why would two W3C WGs set
> >> out to deliberately *create* interoperability problems with other W3C
> >> standards, just when those standards are beginning to achieve widespread
> >> acceptance?
> >>
> >>> This makes the definitions and the
> >>> semantic treatment of literals in both RIF and OWL 2 much simpler.
> >>
> >> It makes it more elegant, yes, but is there really a PROBLEM here that needs
> >> to be solved? That is, what actual issues for users or implementations are
> >> posed by the presence of two literal forms? Or is this discomfort simply a
> >> matter of theoretician's feelings of inelegance or clumsiness? Because if
> >> the latter (as I strongly suspect), this is not a sufficient reason to
> >> attempt to retroactively undermine the existing RDF standard, and to
> >> deliberately create what I believe will be troublesome and awkward problems
> >> for an entire generation of implementations, and certainly for a majority of
> >> existing ones. Creating problems like this is exactly what W3C WGs should
> >> NOT be doing, especially at a critical point in the deployment of SWeb
> >> technology. Google just quietly announced their cautious support for RDFA.
> >> It is not exactly a great idea for two W3C WGs to be at that very moment
> >> deliberately attempting to undermine one of the basic aspects of the RDF
> >> design. Elegance, is, frankly, not of central importance right now.
> >>
> >>>
> >>>
> >>> 2. Both RIF and OWL 2 need a mechanism to refer to the set of all plain
> >>> literals. For example, in OWL 2 you might want to say "the range is a
> >>> piece of
> >>> text".
> >>
> >> That problem can be trivially solved by introducing a class of such values,
> >> and giving it a reserved name. RDF plain literals denote themselves, so that
> >> the class of plain literal values is also the class of plain literals which
> >> is also the class of pieces of text.
> >>
> >>> In OWL 2 this is very important because of facets. Using a datatype for
> >>> this purpose is natural.
> >>
> >> Natural. maybe, but not REQUIRED. And given the problems that it causes,
> >> maybe it isn't so natural after all. Think of OWL 2 as part of an existing
> >> world-wide deployment of SWeb systems, and then ask if it is 'natural'.
> >>
> >>> Both RIF and OWL 2 have chosen to follow the
> >>> definitions of datatypes from XML Schema. Thus, each datatype consists of
> >>> a set
> >>> of lexical values, a value space, and a L2V mapping. Plain literals do not
> >>> follow these principles
> >>
> >> Of course they do. Abstractly, the plain literal 'datatype' is as follows:
> >> the lexical space is all character strings; the value space is all character
> >> strings; and the L2V mapping is the identity map. Obvious extension to the
> >> case of tagged literals. Where is the conceptual problem here?
> >>
> >>> ; therefore, rdf:text defines lexical values that encode
> >>> the content of plain literals.
> >>
> >> Giving rise immediately, and predictably, to the interoperability nightmare
> >> of there being two ways to represent one ubiquitous kind of thing - a piece
> >> of unmarked text, with an optional language tag -  which require exotic
> >> means to establish their equivalence, and different specs requiring
> >> different ways to be used. This is an elementary systems-engineering
> >> mistake, a decision which could have been designed to create global systemic
> >> problems. (Even the "managerial" situation of narrowly focussed WGs working
> >> on parts of the problem in isolation is classic. Future systems engineering
> >> 101 course textbooks will be able to cite this as an example.)
> >>
> >>> Now as I have already said, we have not had the complete store as clear in
> >>> our
> >>> minds right from the beginning. Given all the LC comments (which have by
> >>> the way
> >>> have been quite useful and have significantly improved the spec), however,
> >>> both
> >>> RIF and OWL 2 have agreed that the view I proposed in my e-mail is the
> >>> appropriate one (at least from the RIF and OWL 2 points of view).
> >>
> >> All SWeb WG's points of view should be primarily to further the deployment
> >> of the SWeb.
> >>
> >>> As I've stated
> >>> in my summary e-mail, to achieve this we simply need to remove from the
> >>> specification any special treatment of rdf:text: this should be a datatype
> >>> like
> >>> any other. This is precisely the part of the document that you are
> >>> referring to.
> >>>
> >>> Thus, the final version of the document would not mention any
> >>> interoperability
> >>> problems.
> >>
> >> How wonderful. We will not mention them, so they will have gone away. Or,
> >> more precisely, they have not gone away, but they aren't OUR problem.  We
> >> are just doing our job, and making the Semantic Web work isn't in our WG
> >> charter: we are just concerned with RIF/OWL.
> >>
> >> Sorry about the sarcastic tone, but this really does deserve it.
> >>
> >>> Furthermore, we may also rework the introduction to make the intention
> >>> behind rdf:text clearer.
> >>
> >> Certainly, the rdf:text document is very misleading as written. It purports
> >> to be about representing internationalized text, which is clearly not even
> >> close to the truth, and it does not even mention the apparently real
> >> motivation, which is (see above) to create incompatibilities with the RDF
> >> plain literal design.
> >>
> >> Pat
> >>
> >>>
> >>> Regards,
> >>>
> >>>        Boris
> >>>
> >>>> -----Original Message-----
> >>>> From: Eric Prud'hommeaux [mailto:eric@w3.org]
> >>>> Sent: 20 May 2009 16:36
> >>>> To: Boris Motik
> >>>> Cc: 'Seaborne, Andy'; 'Alan Ruttenberg'; public-rdf-text@w3.org; 'Sandro
> >>>> Hawke'; 'Axel Polleres'
> >>>> Subject: Re: A summary of the proposal for resolving the issues with
> >>>> rdf:text
> >>>> --> Could you please check it one more time?
> >>>>
> >>>> On Wed, May 20, 2009 at 01:38:29PM +0200, Boris Motik wrote:
> >>>>>
> >>>>> Hello,
> >>>>>
> >>>>> I fully appreciate use case and I agree with your observation: this is
> >>>>
> >>>> something
> >>>>>
> >>>>> that has to be addressed. I don't think, however, that solving this
> >>>>> problem
> >>>>
> >>>> is
> >>>>>
> >>>>> in the domain of rdf:text. The rdf:text specification merely defines yet
> >>>>
> >>>> another
> >>>>>
> >>>>> datatype by specifying it in exactly the same way as this is done in XML
> >>>>
> >>>> Schema.
> >>>>>
> >>>>> This datatype is just like any other XML Schema datatype; hence, the job
> >>>>
> >>>> from
> >>>>>
> >>>>> rdf:text's point of view is done.
> >>>>
> >>>> Ahh, perhaps we have different goals for rdf:text. rdf:text was, if I
> >>>> understand, created to address the issue that one could not infer the
> >>>> presenece of or the consequences of plain literals. One could fill
> >>>> that hole by creating a datatype that consumes and infers plain
> >>>> literals, or one could create a datatype which bijects to plain
> >>>> literals. Special machinery associated with that datatype is required
> >>>> in either case.
> >>>>
> >>>> (I, who was not involved in rdf:text except as an afterthought,
> >>>> argue that it is intended to take the former approach. You, an
> >>>> author, argue something closer to the latter.
> >>>> )
> >>>>
> >>>>> Furthermore, the addition of rdf:text to the mix of the supported
> >>>>> datatypes
> >>>>
> >>>> adds
> >>>>>
> >>>>> no new conceptual problems to SPARQL: the situation with rdf:text is no
> >>>>> different than with, say, xsd:integer (there are other examples as
> >>>>> well).
> >>>>
> >>>> For
> >>>>>
> >>>>> example, assume that you have an RDF graph
> >>>>>
> >>>>> G = { <a, b, "1"^xsd:integer> }
> >>>>>
> >>>>> but you ask the query
> >>>>>
> >>>>> Q = { <a, b, "1.0"^^xsd:decimal> }.
> >>>>>
> >>>>> Clearly, G D-entails Q, so Q should be answered as TRUE in G. It is not
> >>>>> the
> >>>>> business of XML Schema to specify how this is to be achieved: XML Schema
> >>>>
> >>>> merely
> >>>>>
> >>>>> specifies what the correct answer to the above question is. It is a
> >>>>> SPARQL
> >>>>> implementation such as OWLIM that should think of how to support such a
> >>>>> definition.
> >>>>
> >>>> SPARQL is defined in terms of the graph, so Q will fail to match G. As
> >>>> entailments supplement the graph, a D-entailing system confronted with
> >>>>  <a, b, "1"^xsd:integer>
> >>>>
> >>>> will have a (notional) graph
> >>>>  G = { <a, b, "1"^xsd:integer> .
> >>>>       <a, b, "1.0"^^xsd:decimal> . }.
> >>>>
> >>>> I'd say that we're aguing whether <a, b, "bob@en"^^rdf:text> shows up
> >>>> in the graph. You propose something like:
> >>>>  <a, b, "bob@en"^^rdf:text> D-entails to
> >>>>  G = { <a, b, "bob@en"^^rdf:text> .
> >>>>       <a, b, "bob"@en> . }.
> >>>> while I propose it that you never utter <a, b, "bob@en"^^rdf:text> and
> >>>> have the tools that implement the specification produce only <a, b,
> >>>> "bob"@en>
> >>>> .
> >>>>
> >>>>
> >>>>> I don't know whether a solution to the above problem (with xsd:integer
> >>>>> and
> >>>>> xsd:decimal) exists. If not, I agree that one should be developed;
> >>>>> however,
> >>>>
> >>>> we
> >>>>>
> >>>>> would not go to the XML Schema WG and ask them to specify how should
> >>>>> SPARQL
> >>>>> handle this case, would we?
> >>>>>
> >>>>> The problem with rdf:text is *precisely* the same as the one that I
> >>>>> outlined
> >>>>> above. At an abstract level, it can be stated as "Several syntactic
> >>>>> forms of
> >>>>> literals get mapped to the semantically identical data values". AS
> >>>>
> >>>> demonstrated
> >>>>>
> >>>>> above, this problem exists without rdf:text, so I don't see how rdf:text
> >>>>
> >>>> brings
> >>>>>
> >>>>> anything new into the whole picture. Thus, you can apply to the rdf:text
> >>>>
> >>>> case
> >>>>>
> >>>>> exactly the same solution that you would apply to xsd:integer and
> >>>>
> >>>> xsd:decimal.
> >>>>
> >>>> Your proposal is analogous to the D-entailment of numeric types, while
> >>>> I interpret the rdf:text last call wording as attempting to reduce the
> >>>> interrop challenges that would stem from spotty coverage with respect
> >>>> to that D-entailment.
> >>>>
> >>>>
> >>>>> If such a solution doesn't exist yet, then the SPARQL WG should address
> >>>>
> >>>> these
> >>>>>
> >>>>> issues, and it should do so in general for all datatypes (xsd:integer,
> >>>>> xsd:decimal, and so on), not just for rdf:text.
> >>>>
> >>>> I'd argue that it's more of an RDF Core issue (admitting that they
> >>>> don't exist). To solve an entailment especially for SPARQL sidesteps
> >>>> the other folks who want to know what's in the graph, for instance, an
> >>>> RDF graph API (such as exist in Jena, Sesame, ...), other entailment
> >>>> regimes that may or may not stack on top of OWL (imagine an
> >>>> app-directed regime like FOAF smushing), as well as secondary
> >>>> consumers of RDF graphs, for instance, an XSLT wich runs on the XML
> >>>> results returned from a SPARQL query service.
> >>>>
> >>>>
> >>>>> To summarize, I think that the work from the point of view of the
> >>>>> rdf:text
> >>>>
> >>>> WG is
> >>>>>
> >>>>> *done* and that we should not do anything else in this forum.
> >>>>
> >>>> Andy has argued that approach 1 is the only of the 3 that is
> >>>> compatible with this text from the last call document:
> >>>> [[
> >>>> Despite the semantic equivalence between typed rdf:text literals and
> >>>> plain literals, the presence of typed rdf:text literals in an RDF
> >>>> graph might cause interoperability problems between RDF tools, as not
> >>>> all RDF tools will support rdf:text. Therefore, before exchanging an
> >>>> RDF graph with other RDF tools, an RDF tool that suports rdf:text MUST
> >>>> replace in the graph each typed rdf:text literal with the
> >>>> corresponding plain literal. The notion of graph exchange includes,
> >>>> but is not limited to, the process of serializing an RDF graph using
> >>>> any (normative or nonnormative) RDF syntax.
> >>>> ]]. \1 is clarifying the boundries of the above graph exchange.
> >>>>
> >>>>> Regards,
> >>>>>
> >>>>>        Boris
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Eric Prud'hommeaux [mailto:eric@w3.org]
> >>>>>> Sent: 20 May 2009 13:18
> >>>>>> To: Boris Motik
> >>>>>> Cc: 'Seaborne, Andy'; 'Alan Ruttenberg'; public-rdf-text@w3.org;
> >>>>>> 'Sandro
> >>>>>> Hawke'; 'Axel Polleres'
> >>>>>> Subject: Re: A summary of the proposal for resolving the issues with
> >>>>
> >>>> rdf:text
> >>>>>>
> >>>>>> --> Could you please check it one more time?
> >>>>>>
> >>>>>> On Wed, May 20, 2009 at 09:29:00AM +0200, Boris Motik wrote:
> >>>>>>>
> >>>>>>> Hello,
> >>>>>>>
> >>>>>>> I don't see the benefit of option 1, as it makes things unnecessarily
> >>>>>>
> >>>>>> complex.
> >>>>>>>
> >>>>>>> The fewer exceptions we have, the easier it will be to actually
> >>>>
> >>>> implement a
> >>>>>>>
> >>>>>>> conformant system. The dichotomy between plain und typed literals is
> >>>>
> >>>> just an
> >>>>>>>
> >>>>>>> example of an exception that just makes implementation difficult.
> >>>>
> >>>> Instead of
> >>>>>>>
> >>>>>>> introducing more special cases, I think we should unify these whenever
> >>>>>>
> >>>>>> possible.
> >>>>>>>
> >>>>>>> Furthermore, I'm not sure whether sorting out things such as the ones
> >>>>>>
> >>>>>> pointed
> >>>>>>>
> >>>>>>> out below is necessary to finalize the rdf:text specification. Please
> >>>>
> >>>> note
> >>>>>>
> >>>>>> that
> >>>>>>>
> >>>>>>> rdf:text already has a well-defined lexical and value space, and this
> >>>>>>> is
> >>>>>>
> >>>>>> *the
> >>>>>>>
> >>>>>>> only* thing that we need to be able to plug rdf:text into the model
> >>>>
> >>>> theory
> >>>>>>
> >>>>>> of
> >>>>>>>
> >>>>>>> RDF. That is, given RDF graphs G1 and G2 possibly containing rdf:text
> >>>>>>
> >>>>>> literals
> >>>>>>>
> >>>>>>> and/or plain literals, using the definitions from the present rdf:text
> >>>>>>> specification one can unambiguously answer the question whether G1 D-
> >>>>
> >>>> entails
> >>>>>>
> >>>>>> G2.
> >>>>>>>
> >>>>>>> For example, if G1 is
> >>>>>>>
> >>>>>>> <a, b, "abc@en"^^rdf:text>
> >>>>>>>
> >>>>>>> and G2 is
> >>>>>>>
> >>>>>>> <a, b, "abc"@en>
> >>>>>>>
> >>>>>>> then, according to the existing RDF model theory document, G1
> >>>>>>> D-entails
> >>>>
> >>>> G2
> >>>>>>
> >>>>>> and
> >>>>>>>
> >>>>>>> vice versa. I don't see what else is there for the rdf:text
> >>>>
> >>>> specification to
> >>>>>>
> >>>>>> do:
> >>>>>>>
> >>>>>>> I really think that the specification is complete. If SPARQL or other
> >>>>>>> specifications want to apply rdf:text in a different way and create
> >>>>
> >>>> special
> >>>>>>>
> >>>>>>> cases, they are free to do so; however, I don't think it is in scope
> >>>>>>> of
> >>>>
> >>>> the
> >>>>>>>
> >>>>>>> rdf:text specification to solve all such problems.
> >>>>>>
> >>>>>> (Hesitantly re-stating use case), consider the use case of the OWLIM
> >>>>>> plugin for Sesame. If OWLIM forward chains some triples into the
> >>>>>> Sesame repository with objects like "bob"@en, existing SPARQL queries
> >>>>>> on the existing Sesame engine will match them as expected. RIF rules
> >>>>>> can consume those triples and know that any rules applying to a domain
> >>>>>> of rdf:text apply.
> >>>>>>
> >>>>>> Constrast that with an OWLIM which emits triples with objects like
> >>>>>> "bob@en"^^rdf:text . These triples will not match conventional queries
> >>>>>> intended to discover e.g. all the folks named "Bob". The Sesame SPARQL
> >>>>>> implementation can be extended, but then we are in Pat's scenario of
> >>>>>> fixing RDF by visiting all the deployed code.
> >>>>>>
> >>>>>> I expect that any design of rdf:text would have it reacting to plain
> >>>>>> literals as if they had a datatype of rdf:text and the appropriate
> >>>>>> lexical transformation. I propose that the simplest complete design is
> >>>>>> one where the inference of rdf:text objects results in their
> >>>>>> expression as plain literals, avoiding a dualism between
> >>>>>> "bob@en"^^rdf:text and "bob"@en which would lose interroperability
> >>>>>> with existing queries, graph APIs, XPaths operating on SPARQL Results,
> >>>>>> non-OWL inferencing systems, ...
> >>>>>>
> >>>>>>
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>>        Boris
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: public-rdf-text-request@w3.org [mailto:public-rdf-text-
> >>>>>>
> >>>>>> request@w3.org]
> >>>>>>>>
> >>>>>>>> On Behalf Of Eric Prud'hommeaux
> >>>>>>>> Sent: 20 May 2009 03:18
> >>>>>>>> To: Seaborne, Andy
> >>>>>>>> Cc: Alan Ruttenberg; public-rdf-text@w3.org; Boris Motik; Sandro
> >>>>
> >>>> Hawke;
> >>>>>>
> >>>>>> Axel
> >>>>>>>>
> >>>>>>>> Polleres
> >>>>>>>> Subject: Re: A summary of the proposal for resolving the issues with
> >>>>>>
> >>>>>> rdf:text
> >>>>>>>>
> >>>>>>>> --> Could you please check it one more time?
> >>>>>>>>
> >>>>>>>> On Tue, May 19, 2009 at 03:57:11PM +0000, Seaborne, Andy wrote:
> >>>>>>>>>
> >>>>>>>>> Apologies:
> >>>>>>>>>
> >>>>>>>>>> On Fri, May 15, 2009 at 11:50 AM, Seaborne, Andy
> >>>>>>
> >>>>>> <andy.seaborne@hp.com>
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Monday PM end before 18:00 (GMT+1)
> >>>>>>>>>>> Thursday PM.
> >>>>>>>>>>> Tuesday @17:00 (GMT+1) for a short call; end before 17:30.
> >>>>>>>>>
> >>>>>>>>> I can't make the slot.
> >>>>>>>>>
> >>>>>>>>> Input: please consider interoperability of data between OWL and RDF.
> >>>>>>
> >>>>>> Option
> >>>>>>>>
> >>>>>>>> 1 is better for that than option 2 as Eric points out.
> >>>>>>>>>
> >>>>>>>>> This is also the least change to LC and IMHO is not a substantive
> >>>>
> >>>> change
> >>>>>>
> >>>>>> (it
> >>>>>>>>
> >>>>>>>> follows on from the current graph exchange intent) to add the text
> >>>>
> >>>> needed
> >>>>>>
> >>>>>> for
> >>>>>>>>
> >>>>>>>> SPARQL.  Roughly: the scoping graph of an rdf-text aware D-entailment
> >>>>
> >>>> for
> >>>>>>
> >>>>>> BGP
> >>>>>>>>
> >>>>>>>> matching includes the RDF forms and does not include ^^rdf:text.
> >>>>
> >>>> (Non-
> >>>>>>
> >>>>>> aware
> >>>>>>>>
> >>>>>>>> entailment regimes would merely treat as a datatype form.)
> >>>>>>>>
> >>>>>>>> does anyone oppose option 1 (plain literals are considered to satisfy
> >>>>>>>> entailments constrained to type rdf:text and entailments of type
> >>>>
> >>>> rdf:text
> >>>>>>
> >>>>>> are
> >>>>>>>>
> >>>>>>>> expressed as plain literals in the RDF graph)? (i'm wondering if we
> >>>>
> >>>> can
> >>>>>>
> >>>>>> work
> >>>>>>>>
> >>>>>>>> this out before we work out scheduling this phone call.)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>        Andy
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
> >>>>>>>>>> Sent: 19 May 2009 16:01
> >>>>>>>>>> To: Axel Polleres
> >>>>>>>>>> Cc: Seaborne, Andy; public-rdf-text@w3.org; Boris Motik; Sandro
> >>>>
> >>>> Hawke;
> >>>>>>>>>>
> >>>>>>>>>> eric@w3.orf
> >>>>>>>>>> Subject: Re: A summary of the proposal for resolving the issues
> >>>>
> >>>> with
> >>>>>>>>>>
> >>>>>>>>>> rdf:text --> Could you please check it one more time?
> >>>>>>>>>>
> >>>>>>>>>> On Mon, May 18, 2009 at 10:03 AM, Axel Polleres
> >>>>>>
> >>>>>> <axel.polleres@deri.org>
> >>>>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Alan, since you were calling for the TC, is that fixed now?
> >>>>>>>>>>> Otherwise, I am afraid it is not possible before Friday.
> >>>>>>>>>>
> >>>>>>>>>> Yes, let's have whoever can make it meet at 5:30 BST = 12:30
> >>>>
> >>>> Boston
> >>>>>>>>>>
> >>>>>>>>>> time.
> >>>>>>>>>> Zakim, meet on irc #rdftext for the code. I will send a code
> >>>>
> >>>> earlier
> >>>>>>
> >>>>>> if
> >>>>>>>>>>
> >>>>>>>>>> I can.
> >>>>>>>>>>
> >>>>>>>>>> -Alan
> >>>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
> >>>> mobile: +1.617.599.3509
> >>>>
> >>>> (eric@w3.org)
> >>>> Feel free to forward this message to any list for any purpose other than
> >>>> email address distribution.
> >>>
> >>>
> >>>
> >>>
> >>
> >> ------------------------------------------------------------
> >> IHMC                                     (850)434 8903 or (650)494 3973
> >> 40 South Alcaniz St.           (850)202 4416   office
> >> Pensacola                            (850)202 4440   fax
> >> FL 32502                              (850)291 0667   mobile
> >> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >

-- 
-eric

office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.