Re: Flower Power and Datatyping ~:-)

On 2002-02-04 23:47, "ext Sergey Melnik" <melnik@db.stanford.edu> wrote:

> Patrick Stickler wrote:

>> Having to use parseType for *every* typed literal will be
>> far too cumbersome.
> 
> Right, but not in the case when parseType declaration applies to all
> subordinate XML structure (I think that's the way parseType works right
> now). If only untidy literals are desired, one could place
> parseType="untidy" in the root of the XML tree, e.g. at the <rdf:RDF
> ...> node.

OK. That's much easier. I thought it had to be in each
statement containing a literal.


>> The global idiom thus becomes simply an incomplete
>> form of the local idiom which is filled in by the
>> global range constraint.
> 
> Great, I like Jeremy's/your suggestion. The examples above work just as
> well in S-P under tidy literals.

Right, insofar as S-P is the TDL local idiom and the "new"
global idiom is a derivative of that local idiom, it's
all the same, and no problems with tidy literals.

> My understanding was that untidy
> literals were needed in TDL only to attach a literal as a property value
> directly, w/o rdf:value. If such use is not required, untidy literals
> aren't too. The style used in the above example works fine for me.

Well, the TDL concept itself is totally agnostic to the tidy
vs. untidy question, whether the literals are tidy or not
does not effect the interpretation,

except for the present TDL MT, where the literals denote mapping
pairs, and then tidy literals would mung up the interpretation.

So, the way to fix the TDL MT to allow for tidy literals is
either to (1) adopt an idiom such as proposed above, where
the "untidyness" is captured by the bNodes, which don't
merge or (2) revise the MT to have the literals denote something
other than mapping pairs or some such refinement.

>> That provides for tidy literals, completely consistent graph
>> structure, and doesn't require any change to the syntax, since
>> we can simply treat
>> 
>>     <rdf:Description rdf:ID="foo">
>>       <ex:prop>val</ex:prop>
>>     </rdf:Description>
>> 
>> as synonymous with (a contracted form for)
>> 
>>     <rdf:Description rdf:ID="foo">
>>       <ex:prop>
>>         <rdf:Description>
>>           <rdf:value>val</rdf:value>
>>         </rdf:Description>
>>       </ex:prop>
>>     </rdf:Description>
>> 
>> or
>> 
>>     foo ex:prop _:1 .
>>     _:1 rdf:value "val" .
> 
> Yep, that's exactly my intention. The only additional detail I borrowed
> from Frank is the parseType="untidy" (or something like that)
> declaration. If missing, the document can be parsed just as in RDF 1.0,
> and no changes to the existing software are required.

And of course, with this modified TDL/D/S-P pair of local/global
idioms, the tidy vs. untidy issue goes away and we can make
all literals tidy and do without the parseType machinery, right?

Of course, we may then get slapped a bit by the charter insofar
as the interpretation of the present TDL global or S-B idioms
as being contracted forms for the modified TDL/D/S-P idiom,
but....

>> In comparison to the above, which achieves I think the same
>> results, the manditory use of parseType seems overly cumbersome
>> to me.
>> 
>> Jeremy's approach doesn't require a change to the XML syntax,
>> though it would require a change in the XML to graph mapping.
> 
> Right, this change could be indicated using the kind of flag that Frank
> suggested...

But we wouldn't need any flag at all, right?

Literals would be tidy, end of story.

>>> Only one piece of
>>> vocabulary per datatype is needed
>> 
>> That's good to hear.
>> 
>>> (a URI like rdfdt:integer).
>> 
>> I am opposed to using separate namespaces for existing datatypes.
>> Per Frank's comments in rdf-interest, if we're talking about
>> XML Schema integer, we should use the correct URI.
> 
> To be frank (or Frank? ;), personally I'm agnostic about xsd: vs.
> rdfdt:. We'd just have to make the opponents of using xsd: namespace
> happy somehow...

My understanding of at least Jonathan's replies were that,
if we use the complete URIs defined by the XML Schema specs
to refer to the entire datatypes, then that's OK.

But we can't use those URIs to refer e.g. only to the lexical
space, or to the value space, etc. nor can we impose any
semantics or interpretation of those datatypes not provided
by the XML Schema specs.

But I think that we can meet those conditions.

>> Also, I don't like seeing datatypes with any 'rdf*' namespace
>> and/or prefix. RDF does not and IMO should not have native
>> datatypes. There is no such thing as an "RDF integer".
>> 
>> We should use one URI per datatype, and use the URI that the
>> datatype creator/author specifies.
>> 
>>> Have a nice weekend,
>> 
>> I did. Thanks. ;-)
> 
> Thanks for your feedback. In fact, I feel that we are damn close to some
> kind of consensus.

So do I.

I think the key questions that need to be answered are:

1. Can we capture the MT with only one URI per datatype?
2. Is everyone OK with tidy literals? (the MT needs to change)
3. Does the charter allow us to treat the bNode free
   global idiom as a contracted form of the new bNode idiom?

If the answer to all three questions is yes, then we may be
well on our way to convergence.

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Monday, 4 February 2002 16:51:32 UTC