Re: Reversing the debate.

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.

"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

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.

	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
>
>
>
>
>
>

Received on Monday, 26 September 2011 21:40:33 UTC