Re: Dave Reynolds: rdf:text - clarification requested

The discussion goes longer and longer, so instead of a point-by-point
comment, I would summarize my belief on this matter

1. rdf:text MAY be supported by an RDF processor, but this is SHOULD
NOT be required (thus, the RDF spec is not amended by rdf:text)

2. rdf:text MAY be supported by a OWL 1 processor, but this is SHOULD
NOT be required

3. RIF and OWL 2 parsers MUST support rdf:text

4. Other languages MAY support rdf:text as a specially defined RDF datatype.

Jie

On Wed, Dec 10, 2008 at 11:22 AM, Dave Reynolds <der@hplb.hpl.hp.com> wrote:
>
> Axel Polleres wrote:
>>
>> Sandro Hawke wrote:
>>>
>>> Dave:
>>>>>>
>>>>>> Please could I get some clarification on the following line from the
>>>>>> rdf:text document:
>>>>>>
>>>>>> """In addition to the RIF and OWL specifications, this datatype is
>>>>>> expected to supersede RDF's plain literals with language tags, cf. [5],
>>>>>> which is why this datatype has been added into the rdf: namespace. """
>>>>>>
>>>>>> I don't recall any discussion on this notion of "supersede". What
>>>>>> exactly is being proposed here? I have been regarding rdf:text as a
>>>>>> formalization of RDF plain literals with language tags which simplifies
>>>>>> OWL2/RIF's job but is not a change to RDF.  Clearly any change to the RDF
>>>>>> specs would have implications for tools developers, especially if there are
>>>>>> any round-tripping requirements, and wouldn't be something to make likely. I
>>>>>> don't think it appropriate to hint at such a change in the rdf:text document
>>>>>> without more details.
>>>>>>
>>>>>> Apologies for not having noticed this line earlier.
>>>
>>> Axel:
>>>>>
>>>>> My personal opinion: I is not the intention to change/affect the
>>>>> existinfg RDF specs, but the datatype is indeed intended to fix the mismatch
>>>>> between plain literals and language tagged literals for impementations which
>>>>> adopt it.
>>>
>>> Dave:
>>>>
>>>> Is that something that needs "fixing"?
>>>>
>>>> In i18n terms then internationalized text and strings are quite
>>>> different things. The differences between the two in RDF have not been a
>>>> problem in implementations or practice that I'm aware of. Is there any
>>>> evidence to suggest otherwise?
>>>>
>>>> I thought rif:text, now rdf:text, was invented to simplify including
>>>> internationalized strings in RIF not to fix some problem with RDF.
>>>>
>>>>> Any suggestion for a rewording that would rather convey this message?
>>>>
>>>> We need clarity on what is being proposed before thinking of a wording.
>>>>
>>>> Are you intending or expecting that RDF implementations should
>>>> explicitly support rdf:text as a datatype?
>>>>
>>>> So that they would regard:
>>>>
>>>> (a)    eg:a eg:p  "foo"@en .
>>>>
>>>> and
>>>>
>>>> (b)    eg:a eg:p  "foo@en"^^rdf:text .
>>>>
>>>> as equivalent graphs?
>>
>> IMO yes, implementations that are rdf:text-aware should treat these
>> equivalently.
>
> So an rdf:text-aware RDF processor would be different from currently
> deployed RDF processors.
>
>>> I'm not totally sure which kind of equivelence is right here, but I'm
>>> inclined to make it as close to identity as possible.  That is, (a) and
>>> (b) are two different ways to serialize the same triple.
>>
>> +1
>>
>>> So it's a lot like these two Turtle documents
>>>
>>> (c)    @prefix foo: <http://example.org/abc#>
>>>       foo:a foo:p  "hello"
>>>
>>> and
>>>
>>> (d)    @prefix bar: <http://example.org/abc#>
>>>       bar:a bar:p  "hello"
>>>        which are different text but serialize the same RDF graph.
>>>
>>> For simplicity of implementation, I think RDF serializations should
>>> mandate use of one style of language tagging or the other.  In order to
>>> handle legacy syntaxes which were created before rdf:text and so could
>>> not pick, I think we should probably say rdf:text SHOULD NOT be used in
>>> any RDF syntax which has built-in support for language tagging (in order
>>> to avoid all the problems you name, below).
>>>
>>> That is, in RDF/XML, N-Triples, N3, and Turtle,
>>
>> note: the latter three are "only" member- or team submissions.
>
> Trivial correction but n-triple is part of the RDF Core specs; however,
> since it is not recommended for interchange then it is not so relevant.
>
>> a standard emerging from these could fix that, and likewise could the
>> upcoming re-launch of DAWG (in case that there is support to add datatype
>> support to SPARQL in that round).
>
> "Fix" what? N3/Turtle/SPARQ have a perfectly good syntax for
> internationalized text which map to RDF language-tagged literals.
>
>>> one SHOULD NOT use
>>> rdf:text.  (Happily, this aligns with rdf-syntax saying "Any other names
>>> are not defined and SHOULD generate a warning when encountered, but
>>> should otherwise behave normally.")  Meanwhile, the various RIF syntaxes
>>> and the newer OWL syntaxes do not directly support language tagging, so
>>> one has to use rdf:text.  Perhaps a Turtle 1.1 would remove type-a
>>> language tagging and mandate rdf:text instead. Similarly, APIs are free
>>> to pick one or the other (or some other, equivalent) approach, but
>>> should probably just provide one, and certainly not distinguish between
>>> the two.
>>>
>>>> Would there be any expectation on round tripping so that an RDF
>>>> processor receiving a graph in form (b) would be expected to return it in
>>>> the same form and not normalize it to form (a)?
>>>
>>> With the above formulation, this problem doesn't come up.
>>>>
>>>> When we originally proposed rif:text I was expecting to translate RDF
>>>> lang-tagged literals to rif:text as part of a translator and rif:text would
>>>> not appear as a datatype in the RDF.
>>>>
>>>> Implementing rif:text as a RDF datatype is clearly possible but the
>>>> discontinuity introduced by changing RDF would be a serious concern. We
>>>> could end up in a state where some RDF producers thought form (b) was a
>>>> legal way to exchange an internationalized text fragment in RDF while a
>>>> fraction of deployed RDF consumers would not consume it (at least not with
>>>> the required semantics).
>>>
>>> Agreed, this is a problem we should avoid.
>>>
>>>> If only RIF and RDF were involved then my preferred phrasing would be
>>>> something like:
>>>>
>>>> "Note that the rdf:text datatype is purely intended for use within RIF
>>>> and it is not intended that RDF processors should support this as an RDF
>>>> datatype. Consumers of RDF-RIF combinations are expected to map between RDF
>>>> language-tagged literals and rdf:text literals as part of the RIF
>>>> translation process."
>>>>
>>>> Indeed it might be better still to substitute "SHOULD NOT" (in the
>>>> RFC2119 sense) for "not intended".
>>>>
>>>> However, that doesn't cover OWL2. I don't understand enough of OWL2's
>>>> requirements here, and how interoperation with deployed RDF is envisaged, to
>>>> be able to suggest anything specific.
>>
>> I see the concerns, however, supporting it in OWL2 and not in RDF sounds
>> kind of weird, assuming that OWL2 will have an RDF serialization... no?
>
> Surely OWL2 serialization will map literals which it treats as of type
> rdf:text to language-tagged literals in the RDF serialization. No?
>
> Dave
> --
> Hewlett-Packard Limited
> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
>
>
>



-- 
Jie
http://www.cs.rpi.edu/~baojie

Received on Wednesday, 10 December 2008 16:47:09 UTC