W3C home > Mailing lists > Public > public-owl-dev@w3.org > July to September 2007

RE: Property Value Ranges

From: Ibach, Brandon L <brandon.l.ibach@lmco.com>
Date: Fri, 24 Aug 2007 14:34:06 -0400
To: John McClure <jmcclure@hypergrove.com>
Cc: Owl Dev <public-owl-dev@w3.org>
Message-id: <0D237077B37CD943A64396032B656927035E7980@EMSS04M23.us.lmco.com>

John,
	I don't have the background knowledge to properly comment on the
ramifications of allowing DataRanges as the object in an RDF triple, but
I'd be awfully wary of thorny issues such as asserting a triple with an
object that is a DataRange which describes an infinite set of possible
values.  Would this create an infinitely large RDF model?
	Ok, so the case you described was essentially setting up a
shortcut for asserting 23 individual triples, using the DataRange to
describe the set of objects on which to assert the given subject and
predicate.  This use case looks a lot like the one Matt Williams was
just asking about, but with data values as the objects instead of
individuals.  Unfortunately, I don't believe there is any way to assert
a triple for each member of a DataRange, so I'm not sure what to
suggest, there.
	I think you need to more closely examine the semantics of
<owl:allValuesFrom> (section 3.2 of the OWL Semantics spec), which, in
this case, means that an assertion such as (#a #P "x") implies that "x"
is a member of the given DataRange.  A value of "x" would cause no
problem, but a value of "m" would cause a contradiction.  The only
assertion an allValuesFrom will ever cause is an <rdf:type> on the value
of another assertion.  Only someValuesFrom or hasValue can cause the
assertion of a property value (and, in the case of someValuesFrom, it's
not so clear, since there may not be a specific value to assert).
	Your discussion of separating predicate nouns and verbs
basically describes temporal logic, which neither RDF nor OWL provide
direct support for.  I believe there are some techniques, generally
involving reification of statements so that temporal assertions can be
made about the statement.  There are also a variety of proposals for
temporal extensions to OWL (Google "temporal OWL" for a selection of
examples).  Temporal modeling clearly has many use cases and
considerable value.  However, I just don't think temporal modeling
extensions are on the table for this round of OWL standardization
efforts, which have been pretty specifically scoped.

-Brandon :)

-----Original Message-----
From: John McClure [mailto:jmcclure@hypergrove.com] 
Sent: Friday, August 24, 2007 12:52 PM
To: Ibach, Brandon L
Cc: Owl Dev
Subject: RE: Property Value Ranges


>-----Original Message-----
>From: Ibach, Brandon L [mailto:brandon.l.ibach@lmco.com]
>Sent: Thursday, August 23, 2007 12:36 PM
>To: John McClure; Owl Dev
>Subject: RE: Property Value Ranges
>
>
>John,
>	Hmmm...  While I agree that this is more concise, and
>potentially more maintainable, I strongly disagree with the "clearer"
>part.  How am I to know what this means, when I see it?  The first
>problem I see is that the OWL semantics would infer an assertion that
>#blny is an rdfs:Literal, since that (or a subclass of it) is the range
>of all datatype properties.  Since you've also asserted that #blny is a
>DataRange, there is a conflict.  OWL DL will flag it as an error and
OWL
>1.1, with punning, will consider the two assertions to be talking about
>different entities, one a literal and the other a data range, with the
>two having nothing to do with each other.  Neither case will accomplish
>what you desire, here.

You're right. owl:DataRange is a subclass of rdf:Resource.  As it
represents a
set of literal values, seems to me that a DataRange should be able to
operate in
the same contexts as a Literal, i.e., just as a Collection.

Sounds like a potential issue to me... to you also?

>	Setting that aside, for the moment, it is not entirely clear
>what the relationship between the individual and the data range is,
>anyway.  To illustrate my point, I wasn't quite sure exactly what
>semantics you were trying to express with the original example, based
on
>your English-language description.  You may have meant that #a does,
>indeed, have a value for the #P property and that the value is some
>string matching the regexp "[b-ln-y]", but you aren't saying
>specifically what that string is.

No, I said #a has the set of values in the range (with exceptions),
i.e., 23
values.

>An alternative interpretation, and
>the one that I actually modeled, is that if #a has any value for #P
(and
>you aren't saying how many it has or even that it has any at all) that
>value is a string matching the regexp.

I'm not sure that's true.  As a member of a class that has that
restriction, you
modelled that 23 queries for each of 23 values would each return true.
But now
you're saying that a query engine could not or would not return 23
values for a
query on P of #a.

Sounds to me like a problem with query engines' handling of a DataRange.
To you
too?

>OWL has the ability to model
>either of these cases as well as numerous other variations.  However,
>your syntax doesn't make it at all clear which of these cases applies.
>The OWL specs could simply dictate the interpretation that a reasoner
>should use if it sees something like this, but then the flexibility to
>model other cases is lost and this new syntax is only of limited value.
>	Now, you've shown a syntax that can provide some disambiguation
>of this sort of thing, using the "verb" attribute.  However, given that
>OWL is committed to remaining compatible with RDF, including being
>expressible using triples, this approach is problematic.

I believe separating predicate nouns from predicate verbs is a useful
evolution
of the language.  Frankly I don't see how semantics that address *time*
and
*condition* of axiomatic statements can be avoided.  Without these, I
have
trouble modelling textual material, so I've added the concepts myself as
efficiently as I can, and am moving forward. I think it can be
implemented so as
not to upset the triples-applecart.

>As I
>mentioned, it may be feasible as a private syntax extension, *if you
can
>reliably map it to standard OWL syntax/semantics*, but I think it's
>quite doubtful that something like this would be able to gain much
>traction for inclusion in the standard.

I am exploring this. In the absence of a 'verb', a statement defaults to
'has'
and there is no impact on the conventional RDF.  Note that I have been
asking
about negation lately to deal with 'hasNot' so that I CAN do that
mapping into
OWL syntax.  So, yes, I am doing what you're suggesting.  I am presently
pessimistic that future, past & conditional tenses can be modelled,
since as I
say standard RDF semantics don't yet address the issue.

>	I don't want to discourage your participation in the discussion,
>here, but I urge you to consider the often complex relationships and
>interdependencies among the OWL model/semantics, the RDF/RDFS
>model/semantics, and the various syntaxes supported (or proposed) for
>each.

Hmm, if only this were my day job! :) More seriously, though, I want a
simpler
syntax that works better for RDF/A annotations, because that's where
most RDF
will be found (I think few people are going to create RDF/OWL files). So
I want
to annotate an XHTML element such as
     <span rdfa:property="Author.FullName.eng">John McClure</span>
which is expanded by a transform to
     <Document>
         <Author>
	<Person>
	     <FullName>
		<rdfs:Literal eng='John McClure'/>
	     </FullName>
	</Person>
         </Author>
     </Document>
This transform of course identifies from the ontology associated with
the
document that Author is a property of a Document and FullName is a
property of a
Person.  In other words, RDFA annotations are concatenations of
property-names.
Since the semantics of source text relies unquestionably on the
semantics of
tenses & conditions, then tenses and conditions are required to be
represented
in the annotation.  Obviously, I cringe at the thought of defining
'hasP' and
'willHaveP' and 'hadP' properties. Far easier to say
	<span rdfa:property='Author.had.FullName.eng'>abcd</span>
which is expanded by a transform to
     <Document>
         <Author>
	<Person>
	     <FullName verb='had'>
		<rdfs:Literal eng='abcd'/>
	     </FullName>
	</Person>
         </Author>
     </Document>

Sorry to get off the topic of property value ranges, but apparently you
needed
to understand better my context for asking these questions.

Thanks,
John McClure
>
>-Brandon :)
>
>-----Original Message-----
>From: John McClure [mailto:jmcclure@hypergrove.com]
>Sent: Thursday, August 23, 2007 2:39 PM
>To: Ibach, Brandon L; Owl Dev
>Subject: RE: Property Value Ranges
>
>Brandon,
>I agree about using patterns in this instance...
>But my point is that it seems clearer to say:
>
><owl:DataRange rdf:about='#blny'>
>    <owl11:onDataRange rdf:resource="&string;"/>
>    <owl11:pattern rdf:datatype="&string;">[b-ln-y]</owl11:pattern>
></owl:DataRange>
>
><owl:Thing rdf:about="#a">
>     <P rdf:resource='#blny'/>
></owl:Thing>
>
>No rdf:typing is necessary and I think query & maintenance is alot
>easier.
>
>Thanks,
>John
>
<snip/>
Received on Friday, 24 August 2007 18:34:30 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2013 09:32:55 GMT