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 16:51:54 UTC