W3C home > Mailing lists > Public > public-rdf-wg@w3.org > May 2011

Re: Action-48 text: a New Plan for plain literals

From: Antoine Zimmermann <antoine.zimmermann@insa-lyon.fr>
Date: Mon, 23 May 2011 17:58:00 +0200
Message-ID: <4DDA8408.3070304@insa-lyon.fr>
CC: public-rdf-wg@w3.org
I see. Would it be an option to not introduce the changes in OWL 2? 
Should OWL 2 be updated every time RDF is extended with a new vocabulary?

Practically, I don't think it would create any important failure if OWL 
reasoners don't understand the datatype rdf:LanguageTaggedLiteral.
It would just be disregarded, just like my:datatype would be.

The reason to have this datatype is that there would be a way to refer 
to what is now called "plain literals with language tags". 
rdf:PlainLiteral does not offer this, unless it is combined with the OWL 
2 datatype definition vocabulary, which RDF tools don't have to 
implement. Something that has the same meaning as:

         :LanguageTaggedLiteral owl:equivalentClass [
                 rdf:type rdfs:Datatype;
                 owl:onDatatype rdf:PlainLiteral;
                 owl:withRestrictions ( [ rdf:langRange "*" ] )

but not dependent on OWL semantics.

Le 23/05/2011 17:05, Peter Frederick Patel-Schneider a écrit :
> From: Antoine Zimmermann<antoine.zimmermann@insa-lyon.fr>
> Subject: Re: Action-48 text: a New Plan for plain literals
> Date: Mon, 23 May 2011 09:41:08 -0500
>> Le 23/05/2011 16:24, Peter Frederick Patel-Schneider a écrit :
>>> There would be an effect on the OWL 2 specs.  At the very least,
>>> rdf:LanguageTaggedLiteral would have to be added to the reserved
>>> vocabulary.
>>    From the OWL 2 SS&FS:
>> """IRIs with prefixes rdf:, rdfs:, xsd:, and owl: constitute the
>> reserved vocabulary of OWL 2."""
>> so, no, we don't need to add rdf:LanguageTaggedLiteral to the reserved
>> vocabulary since it is already in.
> Sorry, I meant to say that it would have to be added to the reserved
> vocabulary with special treatment.  And, of course, that special
> treatment would have to be reflected throughout the OWL 2
> specification.
>> Sections 4.3 and 5.7 of the structural spec should be
>>> rewritten.  I expect that other parts of this document would have to be
>>> changed to reflect the new kind of lexical space.
>>> Other normative documents would probably have to be changed, including
>>> the mapping to RDF, the RDF-based semantics, and profiles.
>> If "foo"@en is declared as syntactic sugar in *all* concrete syntaxes,
>> then the mapping will certainly "look" the same, although abstractly
>> different, right?
> I fully expect that some changes will be required, particularly as there
> are many places in the documents that refer to RDF graphs.
>>> There would be an effect on OWL 2 implementations.  Each implementation
>>> would have to handle this new form for strings.
>> But that form of string will be forbidden to appear in concrete
>> syntaxes, so would it cause real problems?
> What about:
> 9. It's ok to use rdf:LanguageTaggedString and rdf:PlainLiteral in
> rdfs:range statements.
> This would require implementation.
> As well, OWL 2 implementations will have to handle
> rdf:LanguageTaggedString when interacting with things like triple
> stores, etc.
>>> Getting approval from the OWL WG for changes might be very difficult, as
>>> there was much debate on rdf:PlainLiteral.  I don't see any benefits of
>>> rdf:LanguagedTaggedString over rdf:PlainLiteral.
>> rdf:LanguagedTaggedString is not a replacement for rdf:PlainLiteral,
>> it's a complement.
> OK, then I don't see any benefits of rdf:LanguagedTaggedString plus
> rdf:PlainLiteral.  over rdf:PlainLiteral by itself.
>> AZ.
> peter

Antoine Zimmermann
Researcher at:
Laboratoire d'InfoRmatique en Image et Systèmes d'information
Database Group
7 Avenue Jean Capelle
69621 Villeurbanne Cedex
Tel: +33(0)4 72 43 61 74 - Fax: +33(0)4 72 43 87 13
Lecturer at:
Institut National des Sciences Appliquées de Lyon
20 Avenue Albert Einstein
69621 Villeurbanne Cedex
Received on Monday, 23 May 2011 15:58:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:06 UTC