Re: Reversing the debate.

On Mon, Sep 26, 2011 at 5:39 PM, Andy Seaborne <
andy.seaborne@epimorphics.com> wrote:

>
> On 26/09/11 18:34, 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
>> 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
>> 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 believe it is "users" not "implementers" who should be the best guide and
> note that it's both code and data that might change but not at the same
> time.
>

+1


>
> "user" here is one or both of:
>
> 1/ data publishers
> 2/ application writers
>
> Consider:
>
>  <foo> skos:prefLabel "bar"@en .
> or
>  <foo> rdfs:label "bar"@en .
>
> Current systems would output "bar" when looking for the English label.
>
> See for example:
>
> http://environment.data.gov.**uk/doc/bathing-water/ukl2202-**36400<http://environment.data.gov.uk/doc/bathing-water/ukl2202-36400>
>
> the TTL data includes:
>
> bw:ukl2202-36400
>      skos:prefLabel "Southerndown"@en
>
>
> which fills in the item label in the HTML.
>
>  I would however observe that as tagged literals are exceptional, and
>> 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.
>>
>
> Yes - and ditto for simple literal/xsd:string.
>
> But option 2d only changes the datatype not the lexical form (various other
> option 2? have the same feature).  Lexical forms are widely used for display
> purposes.
>

Agreed. As the implementer of an API, I expect that there will necessarily
be code changes required on my part when all is said and done and I'm fine
with that. But I'd like to isolate my users from those changes as much as
possible. Any change that impacts the lexical form seen by a user will be
too disruptive, so that eliminates option 4 for me. Giving a language-tagged
literal a datatype where it didn't have one before, a la 2* or 3, is less
disruptive but might still require some change to user code. Obviously
option 1 would require no change to user code.

The key issue for me is that literals have 3 distinct attributes: lexical
form, datatype, and language tag. These should be 3 distinct attributes in
the abstract syntax. Keeping the language tag as a separate component in the
abstract syntax is an explicit recognition that language-tagged literals are
in fact exceptional.

An RDF API will provide accessors for each attribute of a literal, and it
makes my life (slightly) easier to have these attributes modeled directly in
the abstract syntax rather than do some string munging to get at the
language tag. Beyond that, it's been argued pretty compellingly that
language tags are orthogonal to both the lexical form and the datatype. I
don't think it's appropriate to smush the language tag into the lexical form
or the datatype just so we can eliminate a field from the abstract syntax,
which seems to be the motivation for options 3 and 4. I just don't see the
benefit there.

As the implementer of a RIF system, I shudder at a potentially infinite
universe of type IRIs for language-tagged literals, so that eliminates
option 3 for me.

I was traveling last week and didn't have time to cast my vote in the poll,
but I would have voted for 1 or 2d and against 3 and 4. I don't have a
strong preference between 1 or 2d -- if language-tagged literals can be
given a common type with minimal contortions in the abstract syntax and
semantics then great; if not I won't shed any tears.

-Alex


>
>        Andy
>
>  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.
>>
>> 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<http://www.ihmc.us/users/phayes>
>>
>>
>>
>>
>>
>>
>>
>