RE: heading toward datatyping telecon

> I presume from the above we are considering the P option.  
> What the query would 
> actually return would be better represented as:
> 
>    <#foo> <#intProperty>  _:lit:"0x12" .
> 
> You are right that there is not sufficient information here 
> to deduce what 
> "0x12" means, but one could then query for the rdf:type 
> property of _:lit:"0x12" 
> which would return:
> 
>    _:lit:"0x12" <rdf:type> <#hexProperty> .
> 
> And that is sufficient.  Eh? :)

Yes. I was actually not considering the P option, but
fearing that the response would have been:

    <#foo> <#intProperty>  "0x12" .

I.e., no way to get to 

    _:lit:"0x12" <rdf:type> <#hexProperty> .

As for the P option, just how does one then get the lexical
form from the label? Is the label is a new construct of the
RDF Graph itself? Or do I have to parse the nodeID to get it?

If I have to parse the nodeID to get it, and if the goal
of the label is to compress the graph with regards to
literals, then why not just use a URV. Very tight, and portable
beyond the RDF space.

I.e.

    <#foo> <#intProperty> <xxx:hexInteger:0x12> .

Done. No need for two separate queries. Got rid of even
one more arc. Data type tightly bound to lexical form.
Doesn't get in the way of inferred bindings, etc.

Eh?

> Now querying for representation properties of _:anon we get
> 
>    _:anon  <#hexInteger> "0x12" .
> 
> which would seem to be sufficient.

The problem I have with this approach is that it mixes
the datatype classes with property classes -- maybe that's
not such a big deal, but something in my gut doesn't like
it.

I think it is because I'm expecting to get

    _:anon  rdf:value "0x12" .
    _:anon  rdf:type  <#hexInteger> .

The fact that the type is "hidden" in the property seems
less clean to me. Of course, that's just a subjective
impression, but ...

I can see that both the P and S approaches are trying to
reduce the number of arcs/nodes in the graph and make the
relationship between literal and type tighter, but both
seem equally successful and unsuccessful. P makes the type
relation clear but "hides" the lexical form in a label
that I can't see how I get at in the graph apart from
extracting it from the nodeID. S makes the lexical form
clear but hides the type semantics behind property semantics,
which could be confusing. Both shrink the graph the same
amount.

The X approach shrinks the graph even more, and apart
from having to parse the URV, keeps the type and lexical
form explicit. So I guess I see it as being better, but
of course, I'm grossly biased ;-)

> Finally, thanks again for taking the trouble to provide a 
> concrete example.  It 
> communicated so much better to me, and possibly others in the 
> WG, what you meant.

You're welcome.

Cheers,

Patrick

Received on Wednesday, 7 November 2001 08:04:26 UTC