Re: the S-B problem and what to do about it.

On 2002-02-24 22:05, "ext Aaron Swartz" <me@aaronsw.com> wrote:

> On 2002-02-24 2:54 PM, "Pat Hayes" <phayes@ai.uwf.edu> wrote:
> 
>> ex:age rdfs:range _:x .
>> xsd:integer rdfs:range _:x .
>> 
>> If that is acceptable, then that solves the problem, since it frees
>> up the datatype name itself to have the value space as its extension
>> when used as a class name.
> 
> I have no problem with the basic concept behind this, but I think that this
> specific version of it isn't going to work since it's impossible to write in
> RDF/XML.

One way to express the above semantics, which I've proposed
before with no response whatsoever from anyone, is to use a
specific range property that asserts a lexical space specific
constraint on property values.

I.e. rdfs:lrange.

It can be easily expressed in RDF/XML.

It has clear, reasonably mnemonic meaning to users.

It leaves rdfs:range to denote constraint to value space.

It is close enough to rdfs:range that it will seem familiar
while having a mnemonic distinction (l for lexical).

>> Of course we cannot use rdfs:range in this case, so this would
>> require us to reconsider decision (1); but the required change is
>> minimal.

I'm not saying yet which of the three proposals, if any, I wan't
to vote for (have to sleep on it a bit) but I think rdfs:lrange
would sufficiently address the objections to the expression of
this particular approach.

> I think Brian made it very clear that the <range> in one wasn't necessarily
> rdfs:range. It could also be rdfd:range. I think this would be an adequate
> solution also.

That's true. Though from the perspective of the less-technical
users, a somewhat mnemonic property would I think be appreciated,
and the least amount of new vocabulary as possible.

Using rdfs:range and rdfs:lrange provides that and covers the
bases.

Of course, no matter what we call the ranges or how we express
them, having range constraints for both value and lexical space
in the same graph will raise a conflict. This is a problem with
cohabitation of the inline and bNode idioms that was pointed out
since the earliest considerations of S.

If we are to allow both idioms to co-exist in the same graph, and
I think we must, then we will need a third "flavor" of range
constraint -- one which allows members of either lexical or value
space, leaving it to the graph syntax (literal or bNode) to discern
the distinction. If it is a literal, it is a member of the lexcal
space. If it is a bNode, it denotes a member of the value space.

I think that perhaps Pat's finding of such a "union" range constraint
as unworkable hinges on the fact that it treats the internal structure
of the datatype as opaque, not concerning itself about whether there
actually are two different spaces and what their relationship is,
but just treats all members of all spaces as equal members of the
*RDF* datatype class.

It may very well be that this is too ambiguous for e.g. entailment
proofs (though I'm not sure we have fully explored the options there)
but it does meet the needs to express datatyping in both inline and
bNode idioms and constrain property ranges to either flavor of idiom.

I don't want to reduce the utility of RDF datatyping for WebOnt, but
at the same time, don't want to see it too cumbersome and confusing
for the metadata and content management communities also. And there
is always the option of providing a solution now that has minimal
definition in the MT and the remainder expressed in axiomatic rules
and by other explicit means (even if less formal that the MT) which
captures the idioms and expected meaning of them insofar as humans
are concerned, and then continue to work on a more comprehensive
MT treatment of datatyping in terms of the MT -- i.e. if we decide
at this very moment in time to only capture pairings in the MT, per
the "Dummies" proposal, that doesn't mean that we have given up on
an MT account of datatyping suitable for WebOnt, only that that must
come as a subsequent (possibly immediate) next step, either by us
(if we still have time/energy) or by WebOnt or some other WG.

Need to think on this still a little bit (as I'm sure we all do).

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, 25 February 2002 01:40:30 UTC