Re: Reversing the debate.

Hi Pat,

On 09/26/2011 07:34 PM, Pat Hayes wrote:
> Perhaps the best way to resolve this interminable debate would be to
> start from the other end. Rather than implementors pointing out the
> horribleness of various proposals, could we have a list of what
> implementors would consider to be the least objectionable behavior? I

I fear there is no single obvious consensus amoung implementors :-(

> myself have no idea why "xxx@lll" is so very much worse than "xxx"
> paired with the datatype langbase:tag, but I am quite willing to be

Nice challenge. It strikes me as odd, which might be more of an
intuition than science. We already have a two-dimensional space,
consisting of a value and a datatype on one hand and a very similar
two-dimensional space consisting of a value (string) and a language tag.
Fortunately, this is not a three dimensional space, but just a two
dimensional one because all language tagged strings are (implicitly) of
type xsd:string (or some rdf:langString subtype). I.e., there is no such
thing as "1.0"@en^^xsd:float vs. "1,0"@nl^^xsd:float (oops, forget that;
I see TONS of WORMS ...).

It is clear that we want to support operations mostly on the plain
string value, such as search and comparison. That is, I don't want a
search for @ to succeed on "foo"@en. Also, I don't want "foo"@en to be
lexically smaller than "foo"@nl. So, from an implementation point of
view, I probably want to maintain the two-dimensional space where the
value ("foo") is separated from the tag [1]. It would make me very happy
if the 2.67 dimensional space (value + datatype/language tag/nothing) is
reduced to a simple two-dimensional space: value+URL. Changing "foo"
into "foo"^^xsd:string is a good step here. Changing "foo"@en into
"foo"^^lang:en would be a nice and consistent second step, putting all
literals in a nice two-dimensional space without exceptions.

In addition, I believe that having a URL for a language opens some
nice opportunities to model relations between languages in RDF.

> told that there is a consensus among implementors that this is so (or
> whatever in fact is the consensus) and then I am sure I can design an
> RDF modification which will realize that desired behavior and have a
> reasonably coherent semantics.
>
> I would however observe that as tagged literals are exceptional, and

In what sense exceptional?  I think there are lots of use-cases where
language tags play a vital role.

> as we are proposing to make some kind of change to the existing spec,
> that *some* amount of change to existing code might have to be
> contemplated. If no changes are allowed at all to any existing
> deployed code, the WG should just pack up now, define RDF2 to be the
> same as RDF1 and declare its business done. We all have other things
> to do, I am sure.

That is far too sceptical to me :-) Just map @tag into ^^lang:tag and
define some more mappings for related SPARQL constructs and I think that
everything is much more orthogonal and simple.  Yes, we will have infinite
debates on the relations between @en, @en-US, @en-GB, etc., but we won't
be able to resolve these anyway.  Just declare these out of the scope of
this working group.  At least we provide whoever wants to model langages
with URLs about which they can make statements.

	Cheers --- Jan

[1] I'm part of the camp where operations on strings are considered
both slow and dangerous ...  Data processing systems should try to
avoid looking into strings as much as possible.

> Pat
>
> On Sep 26, 2011, at 4:51 AM, Jan Wielemaker wrote:
>
>> On 09/26/2011 11:28 AM, Richard Cyganiak wrote:
>>> You understate the issues.
>>>
>>> Every existing application that uses the Literal.getLexicalForm()
>>> call of some API to get at the xxx part of xxx@lll would have to
>>> be changed, because the lexical form of xxx@lll is now xxx@lll.
>>>
>>> That's a complete non-starter.
>>
>> I fully agree. Also note that APIs for (notably in-core) RDF stores
>> can now typically work on a single shared representation of the
>> literal. If we add a tag to the literal many of the operations will
>> have to create a copy without the tag. I'm not saying this cannot
>> be solved, but I fear it will be natural nor pretty, especially for
>> existing stores that did not anticipate this in their design
>> phase.
>>
>> I must admit that I'm only following this from the sideline. As an
>> implementor I'm starting to get worried about some wild ideas
>> though. The solution I still like best is that foo@tag is the same
>> as "foo"^^langbase:tag, where langbase is some to be decided prefix
>> for language identifiers.  Any implementation should be fairly
>> comfortable with that (typically it will just simplify things).
>>
>> I understand things get complicated if we want to attach semantics
>> to the these datatypes, so I'd propose not to do that. Most likely
>> others will make an attempt.
>>
>> Regards --- Jan
>>
>>
>>
>>
>
> ------------------------------------------------------------ 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
>
>
>
>
>
>

Received on Monday, 26 September 2011 20:10:31 UTC