Re: rdf-text telecon agenda

From: Sandro Hawke <sandro@w3.org>
Subject: rdf-text telecon agenda
Date: Tue, 26 May 2009 17:35:44 -0500

> 
> Alan, Eric, and I just talked through the status of this effort, and
> came up with an agenda based on trying to make sure we're all in
> agreement on the things we think we're in agreement on, and then going
> on to share ideas about the remaining issue(s).
> 
>    Changed IRC channel: #owl
>    Teleconference code: OWL1  (6951)
>    10am Eastern  Time
> 
> This agenda has lots of PROPOSED resolutions.  This group has no formal
> decision-making authority, so these resolutions should be understood as
> reflecting consensus among the people who attend.  Brief +1 / -1
> response via e-mail could be helpful, too.
> 
> 1.  set of language tags
> 
>     BCP-47 vs RFC-3066
>     Clarify that we're interpreting RDF Concepts as
>         linking to 3066 or it successor.
>     double-check with addison?
> 
>     PROPOSED: We understand that when RDF Concepts referred to RFC
>     3066 it really meanted "RFC 3066 or its successor" (which is
>     currently BCP-47).  We'll add a note to this effect to this spec.

+1, sure, why not, but isn't this quite a minor point?

> 2.  change of name of datatype
> 
>     PROPOSED: The datatype previously known as rdf:text should be
>     called rdf:PlainLiteral

+0, any name that makes people less unhappy is good

PS:  By rdf:PlainLiteral I assume you really mean rdf: O(+>

> 3.  change of title
> 
>     PROPOSED: The title will no longer mention i18n.  It will be
>     something more like: A Datatype for RDF Plain Literals

+1, anything to get the dreaded "i18n" out, if it was there

> 4.  how much of i18n stuff to remove?
> 
>     PROPOSED: Pending approval from Michael Sperberg-McQueen, we'll
>     remove the 3rd intro paragraph (from LC version).  It talks about
>     xml:lang, etc.
> 
>     (That paragraph was expanded in response to Michael
>     Sperberg-McQueen's comment.  Assuming Michael is okay, we'll just
>     drop that paragraph.)

0, does it harm anything to keep the paragraph in?

> 5.  action: we need a new Abstract

+1, this should be tied to the title change

> 6.  plain literals without language tags
> 
>     PROPOSED: rdf:PlainLiterals will map 1-1 to RDF Plain Literals, so
>     Plain Literals with and without language are both handled by
>     rdf:PlainLiteral.

Umm, isn't this already the case?  Why is there a proposal to change to
the current situation?  Further, if this isn't the case, then the
proposed name change doesn't make sense.

> 7.  backward-compatibility goal
> 
>     This spec is not asking anyone to change their RDF implementation.
>     We're not adding market pressure to add the d-entailment.  RDF
>     folks can freely ignore this spec, without harm.
> 
>     PROPOSED: The spec will be clear that while this spec formally
>     specifies an XML Schema datatype, we do not promote or suggest or
>     pressure RDF or SPARQL software or data to be modified to
>     support/use this datatype.

-1, this is not the kind of thing to say in a recommendation
-1, this document does *not* have anything to do with an XML Schema datatype
-1, it is not the case that all RDF folks cannot freely ignore this spec
    without harm, nor should it be

> 8.  interoperability goal
> 
>     PROPOSED: We'll say something about how rdf:PlainLiteral typed
>     literals are not supposed to to leak out and break the
>     backward-compatibility goal.

Huh?  There already is quite some wording to this effect, and it appears
to me that the deatils of this wording is where the action currently is.
It appears to me that just about everyone has agreed (some reluctantly)
that there should be something said aobut interoperability with software
that has not had a chance to take this datatype into account.

> 9.  How to meet the interoperability goal...?
> 
>   .. brainstorming, sharing ideas, etc ...
>      
>      * Pat's approach using RDF'
> 
>     Status of Table 3?
> 
>     What do we say specifically about SPARQL?  
> 
>       - it shouldn't be be in the queried graph (but this this
>         isn't about SPARQL)
>       - it shouldn't be in the BGP
>       - it shouldn't be in a filter
>                STR("foo@"^^rdf:PlainLiteral), LANG( ), DATATYPE( )
>       - it shouldn't be in CONSTRUCT

Now, finally we appear to be getting to the need for a teleconference,
possibly at the end of the teleconference time.  I'm going to put my
thoughts on this in a separate response.

Peter F. Patel-Schneider
Alcatel-Lucent

Received on Wednesday, 27 May 2009 12:21:50 UTC