W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2003

Re: JJC's take on I18N concerns

From: pat hayes <phayes@ihmc.us>
Date: Fri, 22 Aug 2003 07:26:05 -0700
Message-Id: <p06001a05bb64d49a31a4@[]>
To: Martin Duerst <duerst@w3.org>
Cc: w3c-rdfcore-wg@w3.org

>Hello Pat,
>Many thanks for your participation in this discussion.
>At 10:16 03/08/15 -0700, pat hayes wrote:
>>>Hello Jeremy,
>>>Just to make sure, here some responses:
>>>At 21:32 03/08/13 +0300, Jeremy Carroll wrote:
>>I agree with Jeremy; further comments below.
>>>>This is a reply to
>>>>which was (AFAICT) endorsed by I18N at their recent telecon.
>>>>I am also copying the recipients of
>>>>(other than those who I believe are already on the To lists)
>>>>2. I18N feels that the currently proposed implementation is overly
>>>>complicated for the user, and that this will introduce a strong risk
>>>>that users do not implement language information properly.
>>>>RDF Core had feedback against other implementions on grounds of their
>>>>complexity. This was a tradeoff decision.
>>>I think it is complexity for the user (somebody writing RDF (RDF/XML
>>>or otherwise) or scraping,...) vs. complexity for implementers of
>>>core software.
>>You seem to be operating under assumptions 
>>about RDF/XML which are inappropriate. We do 
>>not anticipate that the typical RDF user will 
>>ever write or even see RDF/XML. In the RDF 
>>design it plays the role of a machine-oriented 
>>data transmission notation; it will be as 
>>remote from user experience as Javascript code 
>>is from the typical user of a web browser. The 
>>readability of RDF/XML is relevant only to 
>>implementers who are concerned with debugging 
>>their software.
>I'm sorry that the definition of 'user' was not completely clear.
>We don't mean the total end user. We mean all the people scraping
>data from the Web,... The example of Javascript is probably about
>right, there are a lot of people writing Javascript, and it would
>be difficult to get most of these people to do the right thing.
>>>>3.  The current approach assumes the existence of constructs to describe
>>>>language and carry language information in the native markup associated
>>>>with a fragment.  Such constructs may not exist, in which case it seems
>>>>impossible to ascribe such information at a meta level.
>>It is certainly not impossible, though it may 
>>indeed be ad-hoc. For example, one could use a 
>>construction like this:
>>_:x  ex:textIs "somepieceofXMLscrapedfromsomewhere"^^rdf:XMLliteral .
>>_:x  ex:language "fr" .
>>where the lang tag is coded as a plain literal.
>The point referred to constructs in some markup language.
>Your argument is that there are mechanisms outside XML Literals that
>would be able to indicate the language of an XML Literal.
>We agree with this, but note that unless this is the solution
>adopted by the specification, this kind of proposal is ad-hoc
>(as you say) and therefore does not meet our requirement that
>language information be easy to pick up by generic tools.

But this 'requirement' seems unreasonable to me. 
Language information is one kind of information 
which is relevant to one (very special) kind of 
topic, viz. assertions about pieces of NL text. 
This is not a centrally important issue for RDF, 
and will be completely irrelevant to many RDF 
applications. RDF is a generic description 
language - basically a simple logic - which can 
be used in many ways. It is neither feasible nor 
desireable for the RDF spec to impose particular 
representational 'styles' on the user community; 
we we expect that the business of writing 
ontologies in RDF will be done by others, and 
that standards will emerge in techniques and 
styles for particular purposes. The Dublin Core 
ontology, for example, for all its many faults, 
is already emerging as a kind of standard 
vocabulary for many purposes, and OWL can be seen 
as a style of RDF. If you (or others) would like 
to propose a recommended technique for 
representing language information in RDF, you are 
free to do so. But that is your affair, not ours.

Now, if what you had said was true, that it 
really was *impossible* to express language 
information in RDF, then you would have a 
legitimate complaint. But it is not true: there 
are many ways, of which the one I suggested is 
the most obvious, to express this information in 
RDF. In fact, it is *easy* to express it in RDF: 
compared to other expressive tasks, this one is 
relatively trivial.  So your complaint amounts to 
a request that RDF provide a special syntactic 
form just to express this kind of information. 
But the same case can be made for many other 
kinds of information: some people feel that 
temporal information is centrally important, for 
example, and regret that RDF does not have 
special syntax for encoding transaction times; 
other people  feel that provenance information is 
central, and regret that RDF provides no way for 
one ontology to indicate a relationship with 
another (the use of owl:imports is one step in 
that direction).  If we were to accede to all 
these desires and regrets, RDF would have a 
syntax with the complexity of a major programming 
language; this kind of feature-bloat is 
completely at odds with the design goals of RDF.

>It would be similar to say that in XML, there is no need for
>xml:lang because each markup language can define its own
>mechanism (e.g. attribute) to indicate language.

If XML is seen as a generic structure-describing 
language, I think this is actually a good 
argument. Of course if XML is seen instead as a 
generic text-markup notation, then language 
information may indeed be reasonably considered 
to be a  central issue.

>>>>4. It seems to I18N that it will be difficult to convert rdf created
>>>>using the old syntax to the new syntax. Where legacy documents simply
>>>>declared xml:lang at the top of the file, they will now have to declare
>>>>it for every XML literal.  Also, there is no provision for automatic
>>>>conversion from the old to the new syntax.
>>>>Old style was vague, no indication that xhtml namespace needed declaring
>>>>(predated xhtml?). Not really useable because 
>>>>of such problems, certainly not
>>>>in a portable fashion. The old spec is 
>>>>sufficiently bad to make this problem
>>>>a non-starter since it is not clear what old style xml literal are supposed
>>>>to mean, particularly the treatment of 
>>>>namespaces. Also old spec was somewhat
>>>>unclear how language was supposed to be treated.
>>>There definitely were some vaguenesses, but we agreed on what these
>>>were in the area of language tagging at the Technical Plenary in Cannes.
>>>The lastcall draft has clarified these.
>>But there seems to be a basic assumption lying 
>>behind your point, that the current spec must 
>>be backwards compatible with M&S. This is 
>>impossible: indeed, our WG charter is to 
>>clarify and rationalize the M&S spec, which was 
>>known to be confused when the WG was founded.
>I agree with clarify, this was explained to us at the joint meeting
>in Cannes. I don't remember rationalize. It doesn't sound like a bad
>thing to do, but I don't think this affects the argument.
>The basic assumption behind my argument is not backwards compatibility
>(although this is also an issue separately). It is that it is not
>productive in inter-WG discussions to have a joint meeting and agree
>(without a need for long discussion) on what exactly the real unclarities
>are (and how to address them), and to come back much later claiming
>that everything is unclear anyway.

As I was not at the Cannes meeting, I has better not comment further on this.

>>>>5. I18N considers that it should be possible to conclude that a plain
>>>>literal and an XML literal without markup are the same text.
>>They are clearly the same *text*; the literal 
>>strings will be identical. So, taken literally, 
>>your point here is already satisfied. If you 
>>meant to say that a plain literal, and an XML 
>>literal without markup, could denote the same 
>Yes, that's what we mean.

OK, although I fail to see what possible reason 
there could be for wanting this to be the case.

>>then this raises a more complex issue 
>>concerning datatyping.  I would suggest that 
>>you raise this matter with the XML Schema 
>>group, since they have devoted considerable 
>>time and effort to considerations of identity 
>>between items in the value spaces of datatypes. 
>>The consensus in XML Schema 1.0 was that all 
>>such value spaces should be considered to be 
>>disjoint. I gather that the story in 1.1 will 
>>be more complex, and involve a rather subtle 
>>distinction between equality and identity.
>To the extent that the basic equality/identity for plain literals and
>XML Literals without language information is concerned, we are satisfied
>with the solution and text that you and Jeremy have worked on recently.

?? But that solution makes it impossible for 
plain literals and XML literals to ever denote 
the same entities.

>[I will take note of the issue and try to get back to XML
>Schema in due time.]
>>>>language markup as proposed in the current solution makes this
>>>>impossible, since it is never clear whether the markup was in the
>>>>original text or not.
>>That seems to be a weak argument. For example, 
>>the use of a distinctive wrapper (as suggested 
>>by Jeremy at one point) would probably suffice 
>>to keep the distinction clear, in practice.
>If the RDF/XML spec requires such a wrapper, then that might satisfy
>us. If the RDF/XML parser adds such a wrapper when parsing, that will
>satisfy us. Just having applications maybe add a wrapper doesn't help.
>>But in any case, surely this would apply 
>>equally well to XML literals with language tags?
>If language information is handled in the same way for plain literals
>and XML literals, then this satisfies our concerns, because then it
>will be as easy to compare these two if they have language information
>as it will be to compare them if they don't have language information.
>>>>6. I18N has not been convinced that either of the alternative proposals
>>>>for including language information are problematic, and feels they are
>>>>more intuitive and workable than the current proposal because they do
>>>>not entail the problems cited above.
>>>>I think this is answered by Sandro
>>>>There's a serious concern that people who don't care about XML wont
>>>>bother to implement these bits if they are bolted onto to the side
>>>>like that.  As just another datatype, it fits in smoothly, with no
>>>>particular extra work required.  (except for that language tag...)
>>>>Would you rather many implementations not support XML at all?
>>>>(Perhaps not really a fair question....)
>>>Implementing XML Literals right is basically just a combination of
>>>plain literals and datatyped literals. So it's not that difficult
>>>to implement.
>>It is trickier than you might think when your 
>>implementation has to interoperate with other 
>>SW standards, such as OWL. For example, does 
>>the owl:Class containing
>>have one or two items in it?
>My understanding based on the very recently approved changes
>would be that in a standard interpretation, it does have two
>items, but in an interpretation that decides to treat text-only
>XML Literals equivalent with plain literals, it would have one

Er....that does not make sense. If the answer can 
vary between interpretations then the inference 
is unknown; and it should not be unknown. 
Identity of literals (using known datatypes, and 
rdf:XMLLiteral is always a known datatype) is 
determined by the forms of the literals 
themselves, so does not vary with interpretation. 
With the current version of the semantics, the 
answer will always be 2: that is, there are no 
interpretations in which an XML literal can 
denote the same as a plain literal.

>>How about the class containing
>>? You must provide an answer.
>As far as I understand OWL, this would depend on whether the
>ex:someDatatype is supported, and how it is defined.

OK, fair enough.

>>Does the answer change when you later discover that
>>ex:someDatatype owl:sameAs rdf:XMLliteral .
>>? It should not change.
>If ex:someDatatype is supported and defined as being the same as

It is not *defined* that way, but a reasoner 
might be able to infer this, eg by discovering 
that the cardinality of a class containing 
{ex:someDatatype, rdf:XMLLiteral} was 1.

>, then the implementation will do the right thing

Well, will it? That is precisely the question. 
The point is that being 'supported' means 
something like 'having some information about', 
but WHAT information is not known ahead of time 
and may vary as inferences are made.

>  (and
>ex:someDatatype owl:sameAs rdf:XMLliteral .
>will be information it already knows).
>If ex:someDatatype is supported and defined as being different from
>rdf:XMLLiteral, then the implementation will do the right thing

Again, that is not obvious. 

>  (and
>ex:someDatatype owl:sameAs rdf:XMLliteral .
>is a wrong statement that will produce a contradiction).
>If ex:someDatatype is not supported, then I have absolutely
>no idea how any OWL implementation could be able to predict
>ex:someDatatype owl:sameAs rdf:XMLliteral .
>(or ex:someDatatype owl:differentFrom rdf:XMLliteral .
>assuming owl:differentFrom exists).
>If OWL implementations are able to make such predictions,
>I guess OWL will be a real killer application for predictions
>in all kinds of fields.

It is quite possible for a datatype to be 
'partially supported' in the sense that an 
inference engine knows some information about it 
but not all the information about it. Under these 
circumstances, we expect that any inferences 
which are valid under this partial information 
will remain valid when further information is 
discovered, possibly as a result of other 
inference processes. The ways these processes can 
interact is complex and very hard to predict in 
detail; it is usually only possible to define a 
notion of semantic validity and require that 
implementations preserve it.

>>These are the kinds of question that are 
>>settled by a formal semantics; so in order to 
>>make sure that a feature is implementable it is 
>>not sufficient to implement one app; you have 
>>to provide a formal semantics for the feature.
>If the formal semantics require RDF or OWL to do anything serious
>with unknown datatypes, then it seems to me that they either
>posses very interesting predictive powers, or that something
>is somewhat wrong.

They are required to at least not break, and not 
to make assumptions which might be falsified by 
further information. Taken together this are a 
reasonably serious requirement.

>>BTW, there is a real problem in having 
>>entailments depend on the detailed syntactic 
>>form of literal strings (which they would if 
>>you want XML literals without markup to be 
>>identical to plain literals). The whole point 
>>of datatyping is that each datatype provides 
>>criteria for identity between lexical forms 
>>which can be checked efficiently and locally.
>This can be done. The function checking for the identity between
>plain literals and XML Literals without markup is slightly more
>complicated than strcmp(), but still extremely easy. There are only
>two things to add, both on the XML side

They have to be done for all strings, since in one case the inference

aaa ppp "sss" .
aaa ppp "sss"^^rdf:XMLLiteral .

is valid, but in the other it is not. So it is 
not sufficient to use strcmp() even on simple 
literals, or even on xsd:strings, if we were to 
adopt this convention.

>- If a '<' is seen, return not equal (to be equivalent to strcmp,
>   one would need to decide whether markup is smaller than any
>   character, or larger, but this is irrelevant here)
>- If a '&' is seen, parse for &amp;, &lt;, &gt; and friends.
>If you need the actual function, I can send it to you.

I am aware of the function, but I am also aware 
of the disastrous effect it would have on
inferential search processes. As the advantages 
of this change seem to me to be largely 
aesthetic, I do not feel that it is a good choice.

>>If the criteria vary depending on the form of 
>>the string, then one has effectively created 
>>multiple datatypes. If we were to say that XML 
>>strings without markup were identical to simple 
>>character strings, but those with markup were a 
>>distinct category, then this amounts to having 
>>two datatypes, rdf:XMLiteralWithMarkup and 
>>rdf:XMLLiteralWithoutMarkup, the latter being a 
>>subclass of xsd:string and the former being 
>>disjoint from it. We could have done this, but 
>>(apart from the obvious artificiality) it seems 
>>to be of little utility, since one could use 
>>simple literals or xsd:string to type the 
>>lexical forms which have no markup and gotten 
>>the very same entailments, in this case.
>You are right that there is now a subset relationship between the two
>types. And you are right that it would be possible to define a separate
>name for the part of the superset that is not in the subset (i.e.
>rdf:XMLLiteralWithMarkup). But it's not clear why this would be necessary.
>As for just using xsd:string (or plain literals), yes, that's an option,
>but discussions with Jeremy Caroll and Jim Hendler, who both use
>XML Literals for documentation purposes, have revealed that implementers
>often prefer to just write out everything as XML Literals.
>>I confess to finding this entire issue of XML 
>>compliance rather boring, but I have always 
>>understood, from the WG discussions on this 
>>issue, that the whole point of XML literal 
>>typing was to distinguish text which came from 
>>an XML 'source' from text which simply happened 
>>to be like XML in some way, but was not itself 
>>genuine XML. Your insistence, that genuine XML 
>>should be indistinguishable from faux XML in 
>>the case that neither contains MXL markup, 
>>seems to be fundamentally at odds with this 
>>basic idea of distinguishing 'real XML' from 
>>mere text.
>This may seem so at first sight. But seeing pieces of XML as sequences
>of characters with potentially interspersed markup easily explains things.
>(This is similar to having boxes of apples and boxes of apples and oranges.
>A box with apples and oranges that happens by chance to contain only apples
>doesn't seem to be different from a box with apples.)

I can see that this way of thinking is coherent 
and has a rationale. So does the other way of 
thinking, however. And the other way of thinking 
has several other technical merits: it conforms 
to the basic rationale of 
datatyping-as-classification as embodied in the 
XSD structure, and it allows for a natural 
round-tripping between RDF and other XML 

BTW, I don't agree that the complexities of XML 
are 'easily explained' by thinking of it as text 
with markup. That view fails, for example, to 
account for the centrally important fact that 
text with markup is in fact text, and can be 
processed by text-handling tools and described 
using text-describing vocabulary with perfect 


IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Saturday, 23 August 2003 05:38:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:54:07 UTC