Re: rdf-text telecon agenda

>> 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.
>
> So no overlap with xsd:string?

I'm not quite sure what that question means.

The use case in my head is that given this graph:

    <a> <b> "c".
    <d> <e> "f"^^xs:string.

one could convert it to an RDF-Graph-Like structure using
rdf:PlainLiteral, like these RIF Frames:

    <a>[<b> -> "c"^^rdf:PlainLiteral].
    <d>[<e> -> "f"^^xs:string].

and then one could convert it back, without loss.

But I also expect the value spaces to overlap.  I expect the RIF
condition:

    "hello"^^xs:string = "hello@"^^rdf:PlainLiteral

to be true in all interpretations.

So, I don't quite know the right language for this, but in my head
"hello@"^^rdf:PlainLiteral behaves just like "hello" -- it has the same
value as "hello"^xs:string, but is distinct syntactically.  I guess with
the right D-entailments (which RIF and OWL always have) they'd compare
as equal, but in SPARQL they would not.

>> 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.
>
>0
>(Specs are not places to do this).

Okay, my reading between the lines was that this was something that was
important to you.  I'm a fan of having specs be frank and forthright
about what people are supposed to do, but I can also live without it.

>> 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.
>
>+1
>
>> 
>> 9.  How to meet the interoperability goal...?
>
>I'm confused.
>Is this relative to the current wiki text?

I'd hope people will be familiar with the current wiki text, but there
seems to be enough confusion that I think we need to back up and talk
about it.  What I see is people drafting text that they think will make
other people happy, and then those people not being at all happy with
it.  (like you and Axel's text.)

>>   .. 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)
>
>Need to say must not be exposed by a system providing enhanced entailment.
>
>Covered by "MUST NOT occur ... in the results of SPARQL basic graph pattern matching [SPARQL] using extended SPARQL Basic Graph Matching;"
>
>>       - it shouldn't be in the BGP
>
>?? As a constant in a BGP ??
>
>If it is legal RDF, it should be allowed.  Other "illegal" things are (helps people find them in duff data and fix it).
>
>
>>       - it shouldn't be in a filter
>>                STR("foo@"^^rdf:PlainLiteral), LANG( ), DATATYPE( )
>
>Little value banning it.
>
>>       - it shouldn't be in CONSTRUCT
>
>+1 (and already covered by "MUST NOT occur in published RDF content")

It sounds like you're okay with the current wiki draft.   True?

I generall consider you representative of a large set of RDF
implementors, but I'm concerned that even if you're okay with this
current text, it's convoluted enough that RDF implementors wont get it
right.  I wouldn't object on those grounds; it's just a concern of mine.

      -- Sandro

Received on Wednesday, 27 May 2009 13:10:49 UTC