From alanruttenberg at gmail.com  Tue May  9 01:45:20 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Tue, 9 May 2006 01:45:20 -0400
Subject: [OWL] Abstract syntax proposal
Message-ID: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>

Sometimes (I hope it will be more often),  a provider of lots of  
interesting instances of a certain class will name them with a  
standard URI. Think ncbi entrez gene database entries, which, if a  
proposal I have just made is adopted, will all look like this:   
http://www.ncbi.nlm.nih.gov/2006/entrez/gene/596

I would like to be able to concisely say that all URI's starting with  
"http://www.ncbi.nlm.nih.gov/2006/entrez/gene/"  are of type  
EntrezGeneDatabaseEntry

The proposed syntax is:

'Individual*(' [ individualIDPattern ] { annotation } { 'type(' type  
')' } { value } ')

IndividualIdPattern is a perl compatible regular expression.
Inside the individual* body the variables '$1', '$2'... can be used  
as the string values of the matched group in the regular expression  
in any place that a lexicalForm could be used, i.e as the value of an  
annotation or datatypeProperty.

Similarly

'Class*(' classIDPattern ['Deprecated'] modality { annotation }  
{ super } ')'

These abbreviations could be carried over to the xml schema version  
of OWL, ideally they would be also serialized to RDF/XML so that one  
can owl:import an ontology with such definitions, but if this causes  
trouble they  could simply be expanded before encoding into RDF/XML,  
as long as an abstract syntax parser which noticed such a definition  
applied it to any owl:imports it also processed.

Here's an example:

Class(DatabaseEntry partial)
Class(GeneDatabaseEntry partial DatabaseEntry)
Class(EntrezGeneDatabaseEntry partial GeneDatabaseEntry)
DatatypeProperty(hasDatabaseId functional inverseFunctional)
AnnotationProperty(hasURIYear)
Individual*(<http://www.ncbi.nlm.nih.gov/(\\d+)/entrez/gene/(.*)>
     annotation(hasURIYear $1)
     type(EntrezGeneDatabaseEntry)
     value(hasDatabaseId $2))

-Alan



From alanruttenberg at gmail.com  Tue May  9 02:27:27 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Tue, 9 May 2006 02:27:27 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
Message-ID: <7F99FDF5-2002-4945-85BC-956FEDC798CC@gmail.com>

oops. No inverseFunctional DatatypeProperties(yet). Ignore that part.

On May 9, 2006, at 1:45 AM, Alan Ruttenberg wrote:

> DatatypeProperty(hasDatabaseId functional inverseFunctional)


From pfps at research.bell-labs.com  Tue May  9 10:23:45 2006
From: pfps at research.bell-labs.com (Peter F. Patel-Schneider)
Date: Tue, 09 May 2006 10:23:45 -0400 (EDT)
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
Message-ID: <20060509.102345.35425848.pfps@research.bell-labs.com>

From: Alan Ruttenberg <alanruttenberg at gmail.com>
Subject: [OWL] Abstract syntax proposal
Date: Tue, 9 May 2006 01:45:20 -0400

> Sometimes (I hope it will be more often),  a provider of lots of  
> interesting instances of a certain class will name them with a  
> standard URI. Think ncbi entrez gene database entries, which, if a  
> proposal I have just made is adopted, will all look like this:   
> http://www.ncbi.nlm.nih.gov/2006/entrez/gene/596
> 
> I would like to be able to concisely say that all URI's starting with  
> "http://www.ncbi.nlm.nih.gov/2006/entrez/gene/"  are of type  
> EntrezGeneDatabaseEntry

Yes, I can see that this would sometimes be convenient.  

However I don't view it as something that I would like to see in OWL 1.1.
I have a number of issues:
1/ Just what is the meaning of this sort of construct? For example, when
   does it entail another?  Would it require reasoning about regular
   expression inclusion?
2/ I view this as similar to the Fortran idea of making variables that
   start with 'I' to 'N' be integer-valued.  I don't think that this part
   of Fortran is in much favour.

peter


> The proposed syntax is:
> 
> 'Individual*(' [ individualIDPattern ] { annotation } { 'type(' type  
> ')' } { value } ')
> 
> IndividualIdPattern is a perl compatible regular expression.
> Inside the individual* body the variables '$1', '$2'... can be used  
> as the string values of the matched group in the regular expression  
> in any place that a lexicalForm could be used, i.e as the value of an  
> annotation or datatypeProperty.
> 
> Similarly
> 
> 'Class*(' classIDPattern ['Deprecated'] modality { annotation }  
> { super } ')'
> 
> These abbreviations could be carried over to the xml schema version  
> of OWL, ideally they would be also serialized to RDF/XML so that one  
> can owl:import an ontology with such definitions, but if this causes  
> trouble they  could simply be expanded before encoding into RDF/XML,  
> as long as an abstract syntax parser which noticed such a definition  
> applied it to any owl:imports it also processed.
> 
> Here's an example:
> 
> Class(DatabaseEntry partial)
> Class(GeneDatabaseEntry partial DatabaseEntry)
> Class(EntrezGeneDatabaseEntry partial GeneDatabaseEntry)
> DatatypeProperty(hasDatabaseId functional)
> AnnotationProperty(hasURIYear)
> Individual*(<http://www.ncbi.nlm.nih.gov/(\\d+)/entrez/gene/(.*)>
>      annotation(hasURIYear $1)
>      type(EntrezGeneDatabaseEntry)
>      value(hasDatabaseId $2))
> 
> -Alan
> 
> 
> _______________________________________________
> OWL mailing list
> OWL at lists.mindswap.org
> http://lists.mindswap.org/mailman/listinfo/owl

From alanruttenberg at gmail.com  Tue May  9 12:52:18 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Tue, 9 May 2006 12:52:18 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <20060509.102345.35425848.pfps@research.bell-labs.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<20060509.102345.35425848.pfps@research.bell-labs.com>
Message-ID: <5DC98935-B470-430C-8598-9C7CE843A5D1@gmail.com>


On May 9, 2006, at 10:23 AM, Peter F. Patel-Schneider wrote:
>
> Yes, I can see that this would sometimes be convenient.
>
> However I don't view it as something that I would like to see in  
> OWL 1.1.
> I have a number of issues:
> 1/ Just what is the meaning of this sort of construct? For example,  
> when
>    does it entail another?  Would it require reasoning about regular
>    expression inclusion?

Wasn't the intention. Is there some reading of the proposal that  
would require this, or any other reasoning support?

> 2/ I view this as similar to the Fortran idea of making variables that
>    start with 'I' to 'N' be integer-valued.  I don't think that  
> this part
>    of Fortran is in much favour.

It may be considered by some to be a bad idea, but is still obviously  
considered in favor by lots of people. For example, all http urls  
start with "http://", which seems similar in spirit to including the  
type in the name, and the perl community seems to be quite  
comfortable with the likes of %, $, @, * to partially type their  
variables.

I'm more sympathetic to an argument against that boils down to  
imprecise semantics, such as if there is something I didn't intend  
lurking in the proposal that might lead your 1/, rather than  
appealing to style, particularly given the obvious utility. If we  
consider an aim of OWL to bring more semantics to the web, this would  
seem to be helping advance the cause by making that easier.

-Alan

>
> peter
>
>
>> The proposed syntax is:
>>
>> 'Individual*(' [ individualIDPattern ] { annotation } { 'type(' type
>> ')' } { value } ')
>>
>> IndividualIdPattern is a perl compatible regular expression.
>> Inside the individual* body the variables '$1', '$2'... can be used
>> as the string values of the matched group in the regular expression
>> in any place that a lexicalForm could be used, i.e as the value of an
>> annotation or datatypeProperty.
>>
>> Similarly
>>
>> 'Class*(' classIDPattern ['Deprecated'] modality { annotation }
>> { super } ')'
>>
>> These abbreviations could be carried over to the xml schema version
>> of OWL, ideally they would be also serialized to RDF/XML so that one
>> can owl:import an ontology with such definitions, but if this causes
>> trouble they  could simply be expanded before encoding into RDF/XML,
>> as long as an abstract syntax parser which noticed such a definition
>> applied it to any owl:imports it also processed.
>>
>> Here's an example:
>>
>> Class(DatabaseEntry partial)
>> Class(GeneDatabaseEntry partial DatabaseEntry)
>> Class(EntrezGeneDatabaseEntry partial GeneDatabaseEntry)
>> DatatypeProperty(hasDatabaseId functional)
>> AnnotationProperty(hasURIYear)
>> Individual*(<http://www.ncbi.nlm.nih.gov/(\\d+)/entrez/gene/(.*)>
>>      annotation(hasURIYear $1)
>>      type(EntrezGeneDatabaseEntry)
>>      value(hasDatabaseId $2))
>>
>> -Alan
>>
>>
>> _______________________________________________
>> OWL mailing list
>> OWL at lists.mindswap.org
>> http://lists.mindswap.org/mailman/listinfo/owl


From pfps at research.bell-labs.com  Tue May  9 13:32:31 2006
From: pfps at research.bell-labs.com (Peter F. Patel-Schneider)
Date: Tue, 09 May 2006 13:32:31 -0400 (EDT)
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <5DC98935-B470-430C-8598-9C7CE843A5D1@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<20060509.102345.35425848.pfps@research.bell-labs.com>
	<5DC98935-B470-430C-8598-9C7CE843A5D1@gmail.com>
Message-ID: <20060509.133231.18843417.pfps@research.bell-labs.com>

From: Alan Ruttenberg <alanruttenberg at gmail.com>
Subject: Re: [OWL] Abstract syntax proposal
Date: Tue, 9 May 2006 12:52:18 -0400

> 
> On May 9, 2006, at 10:23 AM, Peter F. Patel-Schneider wrote:
> >
> > Yes, I can see that this would sometimes be convenient.
> >
> > However I don't view it as something that I would like to see in  
> > OWL 1.1.
> > I have a number of issues:
> > 1/ Just what is the meaning of this sort of construct? For example,  
> > when
> >    does it entail another?  Would it require reasoning about regular
> >    expression inclusion?
> 
> Wasn't the intention. Is there some reading of the proposal that  
> would require this, or any other reasoning support?

Well, perhaps.  You could consider it as a "pre-processing" instruction,
which would be expanded by user interface tools like Protege.  This,
however, would take it out of OWL 1.1.

> > 2/ I view this as similar to the Fortran idea of making variables that
> >    start with 'I' to 'N' be integer-valued.  I don't think that  
> > this part
> >    of Fortran is in much favour.
> 
> It may be considered by some to be a bad idea, but is still obviously  
> considered in favor by lots of people. For example, all http urls  
> start with "http://", which seems similar in spirit to including the  
> type in the name, and the perl community seems to be quite  
> comfortable with the likes of %, $, @, * to partially type their  
> variables.

Yes, heresies (still) abound.  :-)

The http:// idea is somewhat different in that an IRI is a composite
syntactic item, with (fairly) clear syntactic divisions.

> I'm more sympathetic to an argument against that boils down to  
> imprecise semantics, such as if there is something I didn't intend  
> lurking in the proposal that might lead your 1/, rather than  
> appealing to style, particularly given the obvious utility. If we  
> consider an aim of OWL to bring more semantics to the web, this would  
> seem to be helping advance the cause by making that easier.

Well the main OWL semantic relationship is entailment between ontologies,
which requires one to be able to answer whether one axiom entails another.
Taking your idea out of OWL per se means not having to worry about this
thorny issue.

This does, of course, lead to the question of how to "standardize" such
ancillary constructs.

> -Alan

peter

From alanruttenberg at gmail.com  Tue May  9 14:16:44 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Tue, 9 May 2006 14:16:44 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <20060509.133231.18843417.pfps@research.bell-labs.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<20060509.102345.35425848.pfps@research.bell-labs.com>
	<5DC98935-B470-430C-8598-9C7CE843A5D1@gmail.com>
	<20060509.133231.18843417.pfps@research.bell-labs.com>
Message-ID: <F36E54B3-130B-471E-BD69-4B03C48E7730@gmail.com>

On May 9, 2006, at 1:32 PM, Peter F. Patel-Schneider wrote:

> Well, perhaps.  You could consider it as a "pre-processing"  
> instruction,
> which would be expanded by user interface tools like Protege.  This,
> however, would take it out of OWL 1.1.

Not sure why - http://www-db.research.bell-labs.com/user/pfps/owl/ 
overview.html says

The features added in OWL 1.1 fall into five main categories:

1. syntactic sugar to make some commonly-stated things easier to say;
....

-Alan


From pfps at research.bell-labs.com  Tue May  9 14:40:40 2006
From: pfps at research.bell-labs.com (Peter F. Patel-Schneider)
Date: Tue, 09 May 2006 14:40:40 -0400 (EDT)
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <F36E54B3-130B-471E-BD69-4B03C48E7730@gmail.com>
References: <5DC98935-B470-430C-8598-9C7CE843A5D1@gmail.com>
	<20060509.133231.18843417.pfps@research.bell-labs.com>
	<F36E54B3-130B-471E-BD69-4B03C48E7730@gmail.com>
Message-ID: <20060509.144040.132855245.pfps@research.bell-labs.com>

From: Alan Ruttenberg <alanruttenberg at gmail.com>
Subject: Re: [OWL] Abstract syntax proposal
Date: Tue, 9 May 2006 14:16:44 -0400

> On May 9, 2006, at 1:32 PM, Peter F. Patel-Schneider wrote:
> 
> > Well, perhaps.  You could consider it as a "pre-processing"  
> > instruction,
> > which would be expanded by user interface tools like Protege.  This,
> > however, would take it out of OWL 1.1.
> 
> Not sure why - http://www-db.research.bell-labs.com/user/pfps/owl/ 
> overview.html says
> 
> The features added in OWL 1.1 fall into five main categories:
> 
> 1. syntactic sugar to make some commonly-stated things easier to say;
> ....
> 
> -Alan

Yes, but what would this "expand" to?

peter

From alanruttenberg at gmail.com  Tue May  9 15:02:01 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Tue, 9 May 2006 15:02:01 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <20060509.144040.132855245.pfps@research.bell-labs.com>
References: <5DC98935-B470-430C-8598-9C7CE843A5D1@gmail.com>
	<20060509.133231.18843417.pfps@research.bell-labs.com>
	<F36E54B3-130B-471E-BD69-4B03C48E7730@gmail.com>
	<20060509.144040.132855245.pfps@research.bell-labs.com>
Message-ID: <86162F1F-24F6-452A-BD5E-88453890F7A2@gmail.com>

On May 9, 2006, at 2:40 PM, Peter F. Patel-Schneider wrote:

> Yes, but what would this "expand" to?
>
> peter

Given the previous definitions

Class(DatabaseEntry partial)
Class(GeneDatabaseEntry partial DatabaseEntry)
Class(EntrezGeneDatabaseEntry partial GeneDatabaseEntry)
DatatypeProperty(hasDatabaseId functional)
AnnotationProperty(hasURIYear)
Individual*(<http://www.ncbi.nlm.nih.gov/(\\d+)/entrez/gene/(.*)>
      annotation(hasURIYear $1)
      type(EntrezGeneDatabaseEntry)
      value(hasDatabaseId $2))

The following:

ObjectProperty(describedByDatabaseEntry functional inverseFunctional)
Class(Gene :partial restriction(describedByDatabaseEntry allValuesFrom 
(GeneDatabaseEntry))

Individual(BCL2 type(Gene) value(describedByDatabaseEntry <http:// 
www.ncbi.nlm.nih.gov/2006/entrez/gene/596>))

would be expanded to add:

Individual(<http://www.ncbi.nlm.nih.gov/2006/entrez/gene/596>
      annotation(hasURIYear "2006")
      type(EntrezGeneDatabaseEntry)
      value(hasDatabaseId "596"))

-Alan


On May 9, 2006, at 2:40 PM, Peter F. Patel-Schneider wrote:

> From: Alan Ruttenberg <alanruttenberg at gmail.com>
> Subject: Re: [OWL] Abstract syntax proposal
> Date: Tue, 9 May 2006 14:16:44 -0400
>
>> On May 9, 2006, at 1:32 PM, Peter F. Patel-Schneider wrote:
>>
>>> Well, perhaps.  You could consider it as a "pre-processing"
>>> instruction,
>>> which would be expanded by user interface tools like Protege.  This,
>>> however, would take it out of OWL 1.1.
>>
>> Not sure why - http://www-db.research.bell-labs.com/user/pfps/owl/
>> overview.html says
>>
>> The features added in OWL 1.1 fall into five main categories:
>>
>> 1. syntactic sugar to make some commonly-stated things easier to say;
>> ....
>>
>> -Alan
>


From pfps at research.bell-labs.com  Tue May  9 15:06:52 2006
From: pfps at research.bell-labs.com (Peter F. Patel-Schneider)
Date: Tue, 09 May 2006 15:06:52 -0400 (EDT)
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <86162F1F-24F6-452A-BD5E-88453890F7A2@gmail.com>
References: <F36E54B3-130B-471E-BD69-4B03C48E7730@gmail.com>
	<20060509.144040.132855245.pfps@research.bell-labs.com>
	<86162F1F-24F6-452A-BD5E-88453890F7A2@gmail.com>
Message-ID: <20060509.150652.65210201.pfps@research.bell-labs.com>

Yes, "given the previous definitions".  However, with a different set of
definitions it would expand differently.  This is in contrast to most
"syntactic sugar" constructs that have a simple, context free expansion.

What, for example, would happen if the axiom

Individual(BCL3 type(Gene) value(describedByDatabaseEntry 
	<http://www.ncbi.nlm.nih.gov/2006/entrez/gene/597>))

was (later) added?

peter


From: Alan Ruttenberg <alanruttenberg at gmail.com>
Subject: Re: [OWL] Abstract syntax proposal
Date: Tue, 9 May 2006 15:02:01 -0400

> On May 9, 2006, at 2:40 PM, Peter F. Patel-Schneider wrote:
> 
> > Yes, but what would this "expand" to?
> >
> > peter
> 
> Given the previous definitions
> 
> Class(DatabaseEntry partial)
> Class(GeneDatabaseEntry partial DatabaseEntry)
> Class(EntrezGeneDatabaseEntry partial GeneDatabaseEntry)
> DatatypeProperty(hasDatabaseId functional)
> AnnotationProperty(hasURIYear)
> Individual*(<http://www.ncbi.nlm.nih.gov/(\\d+)/entrez/gene/(.*)>
>       annotation(hasURIYear $1)
>       type(EntrezGeneDatabaseEntry)
>       value(hasDatabaseId $2))
> 
> The following:
> 
> ObjectProperty(describedByDatabaseEntry functional inverseFunctional)
> Class(Gene :partial restriction(describedByDatabaseEntry allValuesFrom 
> (GeneDatabaseEntry))
> 
> Individual(BCL2 type(Gene) value(describedByDatabaseEntry <http:// 
> www.ncbi.nlm.nih.gov/2006/entrez/gene/596>))
> 
> would be expanded to add:
> 
> Individual(<http://www.ncbi.nlm.nih.gov/2006/entrez/gene/596>
>       annotation(hasURIYear "2006")
>       type(EntrezGeneDatabaseEntry)
>       value(hasDatabaseId "596"))
> 
> -Alan
> 
> 
> On May 9, 2006, at 2:40 PM, Peter F. Patel-Schneider wrote:
> 
> > From: Alan Ruttenberg <alanruttenberg at gmail.com>
> > Subject: Re: [OWL] Abstract syntax proposal
> > Date: Tue, 9 May 2006 14:16:44 -0400
> >
> >> On May 9, 2006, at 1:32 PM, Peter F. Patel-Schneider wrote:
> >>
> >>> Well, perhaps.  You could consider it as a "pre-processing"
> >>> instruction,
> >>> which would be expanded by user interface tools like Protege.  This,
> >>> however, would take it out of OWL 1.1.
> >>
> >> Not sure why - http://www-db.research.bell-labs.com/user/pfps/owl/
> >> overview.html says
> >>
> >> The features added in OWL 1.1 fall into five main categories:
> >>
> >> 1. syntactic sugar to make some commonly-stated things easier to say;
> >> ....
> >>
> >> -Alan
> >

From alanruttenberg at gmail.com  Tue May  9 15:35:15 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Tue, 9 May 2006 15:35:15 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <20060509.150652.65210201.pfps@research.bell-labs.com>
References: <F36E54B3-130B-471E-BD69-4B03C48E7730@gmail.com>
	<20060509.144040.132855245.pfps@research.bell-labs.com>
	<86162F1F-24F6-452A-BD5E-88453890F7A2@gmail.com>
	<20060509.150652.65210201.pfps@research.bell-labs.com>
Message-ID: <20E28608-7AF4-44B2-9731-057ACEDC06D2@gmail.com>

On May 9, 2006, at 3:06 PM, Peter F. Patel-Schneider wrote:

> Yes, "given the previous definitions".  However, with a different  
> set of
> definitions it would expand differently.  This is in contrast to most
> "syntactic sugar" constructs that have a simple, context free  
> expansion.
>
> What, for example, would happen if the axiom
>
> Individual(BCL3 type(Gene) value(describedByDatabaseEntry
> 	<http://www.ncbi.nlm.nih.gov/2006/entrez/gene/597>))
>
> was (later) added?
>
> peter

"Previous" was meant in the context of the message stream, not the  
OWL file.

I'm pretty sure you don't want to discuss what happens "later" in the  
owl file. (http://tinyurl.com/n6eye)

If you mean "also", then I don't see the problem.

-Alan

>
> From: Alan Ruttenberg <alanruttenberg at gmail.com>
> Subject: Re: [OWL] Abstract syntax proposal
> Date: Tue, 9 May 2006 15:02:01 -0400
>
>> On May 9, 2006, at 2:40 PM, Peter F. Patel-Schneider wrote:
>>
>>> Yes, but what would this "expand" to?
>>>
>>> peter
>>
>> Given the previous definitions
>>
>> Class(DatabaseEntry partial)
>> Class(GeneDatabaseEntry partial DatabaseEntry)
>> Class(EntrezGeneDatabaseEntry partial GeneDatabaseEntry)
>> DatatypeProperty(hasDatabaseId functional)
>> AnnotationProperty(hasURIYear)
>> Individual*(<http://www.ncbi.nlm.nih.gov/(\\d+)/entrez/gene/(.*)>
>>       annotation(hasURIYear $1)
>>       type(EntrezGeneDatabaseEntry)
>>       value(hasDatabaseId $2))
>>
>> The following:
>>
>> ObjectProperty(describedByDatabaseEntry functional inverseFunctional)
>> Class(Gene :partial restriction(describedByDatabaseEntry  
>> allValuesFrom
>> (GeneDatabaseEntry))
>>
>> Individual(BCL2 type(Gene) value(describedByDatabaseEntry <http://
>> www.ncbi.nlm.nih.gov/2006/entrez/gene/596>))
>>
>> would be expanded to add:
>>
>> Individual(<http://www.ncbi.nlm.nih.gov/2006/entrez/gene/596>
>>       annotation(hasURIYear "2006")
>>       type(EntrezGeneDatabaseEntry)
>>       value(hasDatabaseId "596"))
>>
>> -Alan
>>
>>
>> On May 9, 2006, at 2:40 PM, Peter F. Patel-Schneider wrote:
>>
>>> From: Alan Ruttenberg <alanruttenberg at gmail.com>
>>> Subject: Re: [OWL] Abstract syntax proposal
>>> Date: Tue, 9 May 2006 14:16:44 -0400
>>>
>>>> On May 9, 2006, at 1:32 PM, Peter F. Patel-Schneider wrote:
>>>>
>>>>> Well, perhaps.  You could consider it as a "pre-processing"
>>>>> instruction,
>>>>> which would be expanded by user interface tools like Protege.   
>>>>> This,
>>>>> however, would take it out of OWL 1.1.
>>>>
>>>> Not sure why - http://www-db.research.bell-labs.com/user/pfps/owl/
>>>> overview.html says
>>>>
>>>> The features added in OWL 1.1 fall into five main categories:
>>>>
>>>> 1. syntactic sugar to make some commonly-stated things easier to  
>>>> say;
>>>> ....
>>>>
>>>> -Alan
>>>


From pfps at research.bell-labs.com  Tue May  9 15:43:18 2006
From: pfps at research.bell-labs.com (Peter F. Patel-Schneider)
Date: Tue, 09 May 2006 15:43:18 -0400 (EDT)
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <20E28608-7AF4-44B2-9731-057ACEDC06D2@gmail.com>
References: <86162F1F-24F6-452A-BD5E-88453890F7A2@gmail.com>
	<20060509.150652.65210201.pfps@research.bell-labs.com>
	<20E28608-7AF4-44B2-9731-057ACEDC06D2@gmail.com>
Message-ID: <20060509.154318.48884326.pfps@research.bell-labs.com>

From: Alan Ruttenberg <alanruttenberg at gmail.com>
Subject: Re: [OWL] Abstract syntax proposal
Date: Tue, 9 May 2006 15:35:15 -0400

> On May 9, 2006, at 3:06 PM, Peter F. Patel-Schneider wrote:
> 
> > Yes, "given the previous definitions".  However, with a different  
> > set of
> > definitions it would expand differently.  This is in contrast to most
> > "syntactic sugar" constructs that have a simple, context free  
> > expansion.
> >
> > What, for example, would happen if the axiom
> >
> > Individual(BCL3 type(Gene) value(describedByDatabaseEntry
> > 	<http://www.ncbi.nlm.nih.gov/2006/entrez/gene/597>))
> >
> > was (later) added?
> >
> > peter
> 
> "Previous" was meant in the context of the message stream, not the  
> OWL file.
> 
> I'm pretty sure you don't want to discuss what happens "later" in the  
> owl file. (http://tinyurl.com/n6eye)
> 
> If you mean "also", then I don't see the problem.
> 
> -Alan

If this is to work as syntactic sugar, then there should be a simple,
effective transform that translates the extended syntax into base syntax.
The problem that I am pointing out is that there does not appear to be such
a transform, for two reasons:

1/ the transform requires a complete view of the entire ontology, which is
counter to the "simple" requirement; and
2/ the transform does not eliminate the base syntax, instead it adds new
syntax whenever an appropriate name appears.

(Yes, "appears" and "later" are not in the OWL specs at all.  However, it
sure seems to me that what you want is that any IRI of a particular form
will trigger the transform, and that in an environment where facts are
added to a KB axioms that are not currently available to system will also
trigger the transform.)

peter

From horrocks at cs.man.ac.uk  Wed May 10 04:57:46 2006
From: horrocks at cs.man.ac.uk (Ian Horrocks)
Date: Wed, 10 May 2006 09:57:46 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
Message-ID: <d780db80e42dab8f13d03cef49f10857@cs.man.ac.uk>

There are lots of cases of this kind. I think that what would be 
appropriate would be to layer some kind of macro language on top of 
OWL/OWL1.1 rather than extending the underlying "assembly language", 
but this is beyond the scope of our work. I believe that Alan Rectors 
group are working on this kind of thing.

Ian




On 9 May 2006, at 06:45, Alan Ruttenberg wrote:

> Sometimes (I hope it will be more often),  a provider of lots of
> interesting instances of a certain class will name them with a
> standard URI. Think ncbi entrez gene database entries, which, if a
> proposal I have just made is adopted, will all look like this:
> http://www.ncbi.nlm.nih.gov/2006/entrez/gene/596
>
> I would like to be able to concisely say that all URI's starting with
> "http://www.ncbi.nlm.nih.gov/2006/entrez/gene/"  are of type
> EntrezGeneDatabaseEntry
>
> The proposed syntax is:
>
> 'Individual*(' [ individualIDPattern ] { annotation } { 'type(' type
> ')' } { value } ')
>
> IndividualIdPattern is a perl compatible regular expression.
> Inside the individual* body the variables '$1', '$2'... can be used
> as the string values of the matched group in the regular expression
> in any place that a lexicalForm could be used, i.e as the value of an
> annotation or datatypeProperty.
>
> Similarly
>
> 'Class*(' classIDPattern ['Deprecated'] modality { annotation }
> { super } ')'
>
> These abbreviations could be carried over to the xml schema version
> of OWL, ideally they would be also serialized to RDF/XML so that one
> can owl:import an ontology with such definitions, but if this causes
> trouble they  could simply be expanded before encoding into RDF/XML,
> as long as an abstract syntax parser which noticed such a definition
> applied it to any owl:imports it also processed.
>
> Here's an example:
>
> Class(DatabaseEntry partial)
> Class(GeneDatabaseEntry partial DatabaseEntry)
> Class(EntrezGeneDatabaseEntry partial GeneDatabaseEntry)
> DatatypeProperty(hasDatabaseId functional inverseFunctional)
> AnnotationProperty(hasURIYear)
> Individual*(<http://www.ncbi.nlm.nih.gov/(\\d+)/entrez/gene/(.*)>
>      annotation(hasURIYear $1)
>      type(EntrezGeneDatabaseEntry)
>      value(hasDatabaseId $2))
>
> -Alan
>
>
> _______________________________________________
> OWL mailing list
> OWL at lists.mindswap.org
> http://lists.mindswap.org/mailman/listinfo/owl


From pfps at research.bell-labs.com  Wed May 10 07:02:21 2006
From: pfps at research.bell-labs.com (Peter F. Patel-Schneider)
Date: Wed, 10 May 2006 07:02:21 -0400 (EDT)
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <d780db80e42dab8f13d03cef49f10857@cs.man.ac.uk>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<d780db80e42dab8f13d03cef49f10857@cs.man.ac.uk>
Message-ID: <20060510.070221.55312041.pfps@research.bell-labs.com>

Yes, this would be a very good placement for this sort of feature.

The "macro" layer specification could be written in a fairly informal
manner, leaving it open as to whether this gets done in a separate
macro-expansion tool or in a user-interface tool.  

I also agree that this is outside of the scope of the specification of OWL
1.1 (or OWL DL) as a representation language, partly for reasons that I
outlined in previous posting.  This does not mean, however, that it could
not be part of a larger "specification".

peter


From: Ian Horrocks <horrocks at cs.man.ac.uk>
Subject: Re: [OWL] Abstract syntax proposal
Date: Wed, 10 May 2006 09:57:46 +0100

> There are lots of cases of this kind. I think that what would be 
> appropriate would be to layer some kind of macro language on top of 
> OWL/OWL1.1 rather than extending the underlying "assembly language", 
> but this is beyond the scope of our work. I believe that Alan Rectors 
> group are working on this kind of thing.
> 
> Ian
> 
> On 9 May 2006, at 06:45, Alan Ruttenberg wrote:
> 
> > Sometimes (I hope it will be more often),  a provider of lots of
> > interesting instances of a certain class will name them with a
> > standard URI. Think ncbi entrez gene database entries, which, if a
> > proposal I have just made is adopted, will all look like this:
> > http://www.ncbi.nlm.nih.gov/2006/entrez/gene/596
> >
> > I would like to be able to concisely say that all URI's starting with
> > "http://www.ncbi.nlm.nih.gov/2006/entrez/gene/"  are of type
> > EntrezGeneDatabaseEntry
> >
> > The proposed syntax is:
> >
> > 'Individual*(' [ individualIDPattern ] { annotation } { 'type(' type
> > ')' } { value } ')
> >
> > IndividualIdPattern is a perl compatible regular expression.
> > Inside the individual* body the variables '$1', '$2'... can be used
> > as the string values of the matched group in the regular expression
> > in any place that a lexicalForm could be used, i.e as the value of an
> > annotation or datatypeProperty.
> >
> > Similarly
> >
> > 'Class*(' classIDPattern ['Deprecated'] modality { annotation }
> > { super } ')'
> >
> > These abbreviations could be carried over to the xml schema version
> > of OWL, ideally they would be also serialized to RDF/XML so that one
> > can owl:import an ontology with such definitions, but if this causes
> > trouble they  could simply be expanded before encoding into RDF/XML,
> > as long as an abstract syntax parser which noticed such a definition
> > applied it to any owl:imports it also processed.
> >
> > Here's an example:
> >
> > Class(DatabaseEntry partial)
> > Class(GeneDatabaseEntry partial DatabaseEntry)
> > Class(EntrezGeneDatabaseEntry partial GeneDatabaseEntry)
> > DatatypeProperty(hasDatabaseId functional inverseFunctional)
> > AnnotationProperty(hasURIYear)
> > Individual*(<http://www.ncbi.nlm.nih.gov/(\\d+)/entrez/gene/(.*)>
> >      annotation(hasURIYear $1)
> >      type(EntrezGeneDatabaseEntry)
> >      value(hasDatabaseId $2))
> >
> > -Alan
> >
> >
> > _______________________________________________
> > OWL mailing list
> > OWL at lists.mindswap.org
> > http://lists.mindswap.org/mailman/listinfo/owl
> 
> _______________________________________________
> OWL mailing list
> OWL at lists.mindswap.org
> http://lists.mindswap.org/mailman/listinfo/owl

From rector at cs.man.ac.uk  Thu May 11 03:31:46 2006
From: rector at cs.man.ac.uk (Alan Rector)
Date: Thu, 11 May 2006 08:31:46 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <d780db80e42dab8f13d03cef49f10857@cs.man.ac.uk>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<d780db80e42dab8f13d03cef49f10857@cs.man.ac.uk>
Message-ID: <5C39AA45-9F67-4397-A98E-6B8F309F05DF@cs.man.ac.uk>

Alan

But it is very much in our interest.  I agree with Ian.  This should  
be layered on top.

alan

On 10 May 2006, at 09:57, Ian Horrocks wrote:

> There are lots of cases of this kind. I think that what would be
> appropriate would be to layer some kind of macro language on top of
> OWL/OWL1.1 rather than extending the underlying "assembly language",
> but this is beyond the scope of our work. I believe that Alan Rectors
> group are working on this kind of thing.
>
> Ian
>
>
>
>
> On 9 May 2006, at 06:45, Alan Ruttenberg wrote:
>
>> Sometimes (I hope it will be more often),  a provider of lots of
>> interesting instances of a certain class will name them with a
>> standard URI. Think ncbi entrez gene database entries, which, if a
>> proposal I have just made is adopted, will all look like this:
>> http://www.ncbi.nlm.nih.gov/2006/entrez/gene/596
>>
>> I would like to be able to concisely say that all URI's starting with
>> "http://www.ncbi.nlm.nih.gov/2006/entrez/gene/"  are of type
>> EntrezGeneDatabaseEntry
>>
>> The proposed syntax is:
>>
>> 'Individual*(' [ individualIDPattern ] { annotation } { 'type(' type
>> ')' } { value } ')
>>
>> IndividualIdPattern is a perl compatible regular expression.
>> Inside the individual* body the variables '$1', '$2'... can be used
>> as the string values of the matched group in the regular expression
>> in any place that a lexicalForm could be used, i.e as the value of an
>> annotation or datatypeProperty.
>>
>> Similarly
>>
>> 'Class*(' classIDPattern ['Deprecated'] modality { annotation }
>> { super } ')'
>>
>> These abbreviations could be carried over to the xml schema version
>> of OWL, ideally they would be also serialized to RDF/XML so that one
>> can owl:import an ontology with such definitions, but if this causes
>> trouble they  could simply be expanded before encoding into RDF/XML,
>> as long as an abstract syntax parser which noticed such a definition
>> applied it to any owl:imports it also processed.
>>
>> Here's an example:
>>
>> Class(DatabaseEntry partial)
>> Class(GeneDatabaseEntry partial DatabaseEntry)
>> Class(EntrezGeneDatabaseEntry partial GeneDatabaseEntry)
>> DatatypeProperty(hasDatabaseId functional inverseFunctional)
>> AnnotationProperty(hasURIYear)
>> Individual*(<http://www.ncbi.nlm.nih.gov/(\\d+)/entrez/gene/(.*)>
>>      annotation(hasURIYear $1)
>>      type(EntrezGeneDatabaseEntry)
>>      value(hasDatabaseId $2))
>>
>> -Alan
>>
>>
>> _______________________________________________
>> OWL mailing list
>> OWL at lists.mindswap.org
>> http://lists.mindswap.org/mailman/listinfo/owl
>
> _______________________________________________
> OWL mailing list
> OWL at lists.mindswap.org
> http://lists.mindswap.org/mailman/listinfo/owl

-----------------------
Alan Rector
Professor of Medical Informatics
School of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL +44 (0) 161 275 6149/6188
FAX +44 (0) 161 275 6204
www.cs.man.ac.uk/mig
www.clinical-esciences.org
www.co-ode.org



From bparsia at isr.umd.edu  Thu May 11 08:23:09 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Thu, 11 May 2006 13:23:09 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
Message-ID: <1D0F6B44-FB99-4E01-8DA1-346A629CA25B@isr.umd.edu>

Sorry to go back to the first message, but I have a point that might  
be lost if I try to post downthread. I generally endorse the macro  
idea, though macro systems are often dangerous things.

On May 9, 2006, at 6:45 AM, Alan Ruttenberg wrote:

> Sometimes (I hope it will be more often),  a provider of lots of
> interesting instances of a certain class will name them with a
> standard URI. Think ncbi entrez gene database entries, which, if a
> proposal I have just made is adopted, will all look like this:
> http://www.ncbi.nlm.nih.gov/2006/entrez/gene/596
>
> I would like to be able to concisely say that all URI's starting with
> "http://www.ncbi.nlm.nih.gov/2006/entrez/gene/"  are of type
> EntrezGeneDatabaseEntry
[snip]

This was already in old RDF:
	http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#URIPrefix
at least in a restricted form.

One example of issues:
	http://bat710.univ-lyon1.fr/~champin/rdf-tutorial/node27.html

So, quite a lot of care must be taken with such extensions. RDF is  
pretty dang fragile overall.

Personally, I would think that a macro system should be layered over  
the XML syntax (so you can type and otherwise validate your  
extensions) and use a grddl like mechanism for translation (where the  
transformation can be specified in XSLT...maaaaaaybe xquery, but I  
think sticking to XSLT is better in general for at least structural  
things).

Thus, worst case, you can apply all the relevant xslt and get a  
vanilla OWL 1.1 document, or you can notice the syntax explicitly  
(there schema typing helps) and deal with it in a different way.

Cheers,
Bijan.

From alanruttenberg at gmail.com  Thu May 11 10:09:00 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Thu, 11 May 2006 10:09:00 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <1D0F6B44-FB99-4E01-8DA1-346A629CA25B@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<1D0F6B44-FB99-4E01-8DA1-346A629CA25B@isr.umd.edu>
Message-ID: <ffd7f4ece66ce4cae9bb7711f6d27639@gmail.com>

On May 11, 2006, at 8:23 AM, Bijan Parsia wrote:

> This was already in old RDF:
> 	http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#URIPrefix
> at least in a restricted form.

Thanks for pointing out the reference.

> One example of issues:
> 	http://bat710.univ-lyon1.fr/~champin/rdf-tutorial/node27.html
> So, quite a lot of care must be taken with such extensions. RDF is 
> pretty dang fragile overall.

Agreed. I was about to write that mine was safe because  the results 
aren't available for further expansion, but realize that I hadn't 
specified that the ids in the expansion shouldn't be available for 
expansion themselves. And indeed this adds complexity - the definitions 
that used them have might have be marked in order to be protected in a 
real system in which "later" exists.

> Personally, I would think that a macro system should be layered over 
> the XML syntax (so you can type and otherwise validate your 
> extensions) and use a grddl like mechanism for translation (where the 
> transformation can be specified in XSLT...maaaaaaybe xquery, but I 
> think sticking to XSLT is better in general for at least structural 
> things).
>
> Thus, worst case, you can apply all the relevant xslt and get a 
> vanilla OWL 1.1 document, or you can notice the syntax explicitly 
> (there schema typing helps) and deal with it in a different way.

I assume the you mean the forthcoming XML Schema, rather than the 
RDF/XML, since it is no fun to do XSLT on the latter.
The downsides of this are that it is more dangerous - it can easily 
generate nonsense, even non-xml. It is also opaque to the reasoner. On 
the other hand, making it available to the reasoner allows for future 
optimizations, such as the regex reasoning that Peter worried about. 
(Though I can't tell if you are suggesting that a reasoner might 
actually look at the xslt when you write "notice the syntax 
explicitly")

On May 11, 2006, at 3:31 AM, Alan Rector wrote:

> But it is very much in our interest.  I agree with Ian.  This should 
> be layered on top.

On May 10, 2006, at 7:02 AM, Peter F. Patel-Schneider wrote:

> This does not mean, however, that it could not be part of a larger 
> "specification".

OK. But I don't know where discussion of this larger specification 
should happen, or what it's name is. I had been assuming that OWL was 
the umbrella under which this would fall. Perhaps we can have a track 
at OWLED.

On May 9, 2006, at 1:32 PM, Peter F. Patel-Schneider wrote:

> The http:// idea is somewhat different in that an IRI is a composite
> syntactic item, with (fairly) clear syntactic divisions.

If it would help, I think it would be sufficient for the intended usage 
that we only used a subset of the predefined syntactic elements.

On May 9, 2006, at 3:43 PM, Peter F. Patel-Schneider wrote:

> 1/ the transform requires a complete view of the entire ontology, 
> which is
> counter to the "simple" requirement; and
> 2/ the transform does not eliminate the base syntax, instead it adds 
> new
> syntax whenever an appropriate name appears.

I agree with the implementation assessment. On the matter of "simple", 
I think the specification mentioned "syntactic sugar", which according 
to wikipedia, is:  "a term coined by Peter J. Landin for additions to 
the syntax of a computer language that do not affect its expressiveness 
but make it "sweeter" for humans to use". We might disagree about 
whether this is "sweeter" or not. I think we agree that it doesn't 
effect the expressiveness in the DL sense. Relative to the kind of work 
any implementation that understands OWL needs to do, I'd still classify 
this as simple, though.  (I'm smiling as I write this. Peter, you 
really make we want to debate :)


-Alan


From bparsia at isr.umd.edu  Thu May 11 10:19:12 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Thu, 11 May 2006 15:19:12 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <ffd7f4ece66ce4cae9bb7711f6d27639@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<1D0F6B44-FB99-4E01-8DA1-346A629CA25B@isr.umd.edu>
	<ffd7f4ece66ce4cae9bb7711f6d27639@gmail.com>
Message-ID: <7E36C745-DF43-4C8A-8671-D61B1C6FCB68@isr.umd.edu>

On May 11, 2006, at 3:09 PM, Alan Ruttenberg wrote:

> On May 11, 2006, at 8:23 AM, Bijan Parsia wrote:
>
>> This was already in old RDF:
>> 	http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#URIPrefix
>> at least in a restricted form.
>
> Thanks for pointing out the reference.

NP.


[snip]
>> Personally, I would think that a macro system should be layered  
>> over the XML syntax
                                                                         
                                                                      
^^^^^^^^^^

>> (so you can type and otherwise validate your extensions) and use a  
>> grddl like mechanism for translation (where the transformation can  
>> be specified in XSLT...maaaaaaybe xquery, but I think sticking to  
>> XSLT is better in general for at least structural things).
>>
>> Thus, worst case, you can apply all the relevant xslt and get a  
>> vanilla OWL 1.1 document, or you can notice the syntax explicitly  
>> (there schema typing helps) and deal with it in a different way.
>
> I assume the you mean the forthcoming XML Schema,

See above. In general, I think we're calling the DIG derived syntax  
the XML syntax and the RDF/XML one the RDF syntax.

> rather than the RDF/XML,

RDF/XML is not XML worthy of the name.

> since it is no fun to do XSLT on the latter.
> The downsides of this are that it is more dangerous -

Of course, but eh.

> it can easily generate nonsense, even non-xml. It is also opaque to  
> the reasoner.

Well sure, unless the reasoner attends to the syntax before macro  
expansion, or intervenes at some other stage. But, uh, the whole  
point of having *macros* is so that it *can* be opaque to the  
reasoner (i.e., the reasoner doesn't see it).

> On the other hand, making it available to the reasoner allows for  
> future optimizations, such as the regex reasoning that Peter  
> worried about. (Though I can't tell if you are suggesting that a  
> reasoner might actually look at the xslt when you write "notice the  
> syntax explicitly")

Not the XSLT, but the original macro. So I define a macro syntax plus  
a translation function. If the reasoner knows the macro syntax, it  
might do soemthing special with that knowledge. If it doesn't, it can  
always expand the macro and proceed.

[snip]

Cheers,
Bijan.


From alanr at mumble.net  Thu May 11 10:35:05 2006
From: alanr at mumble.net (Alan Ruttenberg)
Date: Thu, 11 May 2006 10:35:05 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <ffd7f4ece66ce4cae9bb7711f6d27639@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<1D0F6B44-FB99-4E01-8DA1-346A629CA25B@isr.umd.edu>
	<ffd7f4ece66ce4cae9bb7711f6d27639@gmail.com>
Message-ID: <7CBC01F0-4EE2-4DCB-9F6D-CCCD5D950F3C@mumble.net>

Never mind this. I do think they are safe, even without the  
protection. Someone correct me if they find an example otherwise.
-Alan

On May 11, 2006, at 10:09 AM, Alan Ruttenberg wrote:

> Agreed. I was about to write that mine was safe because  the results
> aren't available for further expansion, but realize that I hadn't
> specified that the ids in the expansion shouldn't be available for
> expansion themselves. And indeed this adds complexity - the  
> definitions
> that used them have might have be marked in order to be protected in a
> real system in which "later" exists.


From alanruttenberg at gmail.com  Thu May 11 10:37:17 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Thu, 11 May 2006 10:37:17 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <7E36C745-DF43-4C8A-8671-D61B1C6FCB68@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<1D0F6B44-FB99-4E01-8DA1-346A629CA25B@isr.umd.edu>
	<ffd7f4ece66ce4cae9bb7711f6d27639@gmail.com>
	<7E36C745-DF43-4C8A-8671-D61B1C6FCB68@isr.umd.edu>
Message-ID: <11DCCA3F-B08E-467A-993B-B230033B9062@gmail.com>

So if I understand you correctly you are suggesting a new macro  
syntax, whose semantics is defined in terms of a translation to an  
xslt that can transform the OWL XML syntax?

-Alan

On May 11, 2006, at 10:19 AM, Bijan Parsia wrote:

> Not the XSLT, but the original macro. So I define a macro syntax  
> plus a translation function. If the reasoner knows the macro  
> syntax, it might do something special with that knowledge. If it  
> doesn't, it can always expand the macro and proceed.


From alanruttenberg at gmail.com  Tue May 16 16:08:04 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Tue, 16 May 2006 16:08:04 -0400
Subject: [OWL] 1.1 punning, annotation properties
Message-ID: <7FF4EE6F-78C4-4665-AB3A-A36EB831E32E@gmail.com>

Is it possible to add subproperty for annotation properties? Since  
annotation properties don't figure in the reasoning, would it  hurt?  
Adding it would make explicit relationships that are sometimes useful  
for rdfs and some systems can understand this, at least for querying.

Or does punning mean that there is no longer any need for annotation  
properties at all?

Actually on reading the syntax spec I am a bit confused.

"As a simple syntactic sugar, non-annotation properties can be part  
of certain class and property axioms". However I don't see a  
specification of which axioms those are. Or does the following

annotation ::= value
	| 'type(' description ')'

mean that wherever I see "annotation" in one of the axioms I can also  
use value() or type(). If type, does that mean that the individual on  
which the property is asserted is given that type? If so it looks  
like an Individual statement can have two type() parts.


-Alan


From alanruttenberg at gmail.com  Tue May 16 16:08:04 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Tue, 16 May 2006 16:08:04 -0400
Subject: [OWL] 1.1 punning, annotation properties
Message-ID: <7FF4EE6F-78C4-4665-AB3A-A36EB831E32E@gmail.com>

Is it possible to add subproperty for annotation properties? Since  
annotation properties don't figure in the reasoning, would it  hurt?  
Adding it would make explicit relationships that are sometimes useful  
for rdfs and some systems can understand this, at least for querying.

Or does punning mean that there is no longer any need for annotation  
properties at all?

Actually on reading the syntax spec I am a bit confused.

"As a simple syntactic sugar, non-annotation properties can be part  
of certain class and property axioms". However I don't see a  
specification of which axioms those are. Or does the following

annotation ::= value
	| 'type(' description ')'

mean that wherever I see "annotation" in one of the axioms I can also  
use value() or type(). If type, does that mean that the individual on  
which the property is asserted is given that type? If so it looks  
like an Individual statement can have two type() parts.


-Alan


From bparsia at isr.umd.edu  Tue May 16 18:40:28 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Tue, 16 May 2006 23:40:28 +0100
Subject: [OWL] 1.1 punning, annotation properties
In-Reply-To: <7FF4EE6F-78C4-4665-AB3A-A36EB831E32E@gmail.com>
References: <7FF4EE6F-78C4-4665-AB3A-A36EB831E32E@gmail.com>
Message-ID: <3ABC605D-DC0D-440F-862A-B1382119927A@isr.umd.edu>

On May 16, 2006, at 9:08 PM, Alan Ruttenberg wrote:

> Is it possible to add subproperty for annotation properties? Since
> annotation properties don't figure in the reasoning, would it  hurt?
> Adding it would make explicit relationships that are sometimes useful
> for rdfs and some systems can understand this, at least for querying.
>
> Or does punning mean that there is no longer any need for annotation
> properties at all?

[snip]

The latter. Or, if you prefer, you can use arbitrary OWL wrt  
annotation properties. That's the main use.

Cheers,
Bijan.

From matthew.pocock at ncl.ac.uk  Wed May 17 06:50:22 2006
From: matthew.pocock at ncl.ac.uk (Matthew Pocock)
Date: Wed, 17 May 2006 11:50:22 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <1D0F6B44-FB99-4E01-8DA1-346A629CA25B@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<1D0F6B44-FB99-4E01-8DA1-346A629CA25B@isr.umd.edu>
Message-ID: <200605171150.22608.matthew.pocock@ncl.ac.uk>

On Thursday 11 May 2006 13:23, Bijan Parsia wrote:

> Personally, I would think that a macro system should be layered over
> the XML syntax (so you can type and otherwise validate your
> extensions) and use a grddl like mechanism for translation (where the
> transformation can be specified in XSLT...maaaaaaybe xquery, but I
> think sticking to XSLT is better in general for at least structural
> things).

Eugh! This makes me feel dirty (in a bad way), like when you have chicken skin 
stuck under your nails *shudders* or watching a toddler eat worms but being 
stuck the wrong side of the patio doors to do anything about it.

My experience is that end-users and XSLT don't mix. Also, XML seems the wrong 
layer to define this mechanism.

Perhaps we have not clearly defined what we want out of a macro system. I 
would want a language that allowed me to take OWL AST and add a macros AST, 
and then have a defined mechanism whereby these macros expand to macros and 
OWL. I would only mention XML at the last moment, as a serialization format 
for OWL+Macro AST. Lastly, I would like to be able to attach annotations to 
the macros in exactly the same manner that I would the OWL statements.

If defined this way, we can potentially use the standard terminating functions 
tricks to restrict the macros language to something that will expand to a 
finite amount of OWL AST.

I guess there are two ways to bind macros to their arguments to trigger 
expansion, and these will affect both how useable it is and how strongly we 
can check that it terminates, together with if we need a reasoner during 
macro expansion - which I'm assuming we want to a void???

1: Macro has arguments
all_exists(someProp someClass) =
  intersection(
    individualvalueRestriction(property=someProp allvaluesFrom(someClass))
    individualvalueRestriction(property=someProp existsvalue()) )

2: Macro pattern-matches over the abstract syntax
  select ?id
  where class(?id) 
  and ?id =~ [http://www.w3c.org/]
  do class(?id annotation(note "This is a w3c concept"))

Matthew

>
> Thus, worst case, you can apply all the relevant xslt and get a
> vanilla OWL 1.1 document, or you can notice the syntax explicitly
> (there schema typing helps) and deal with it in a different way.
>
> Cheers,
> Bijan.
> _______________________________________________
> OWL mailing list
> OWL at lists.mindswap.org
> http://lists.mindswap.org/mailman/listinfo/owl

From bparsia at isr.umd.edu  Wed May 17 07:06:00 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Wed, 17 May 2006 12:06:00 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <200605171150.22608.matthew.pocock@ncl.ac.uk>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<1D0F6B44-FB99-4E01-8DA1-346A629CA25B@isr.umd.edu>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
Message-ID: <F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>

On May 17, 2006, at 11:50 AM, Matthew Pocock wrote:

> On Thursday 11 May 2006 13:23, Bijan Parsia wrote:
>
>> Personally, I would think that a macro system should be layered over
>> the XML syntax (so you can type and otherwise validate your
>> extensions) and use a grddl like mechanism for translation (where the
>> transformation can be specified in XSLT...maaaaaaybe xquery, but I
>> think sticking to XSLT is better in general for at least structural
>> things).
>
> Eugh! This makes me feel dirty (in a bad way),

Take a shower :)

> like when you have chicken skin
> stuck under your nails *shudders* or watching a toddler eat worms  
> but being
> stuck the wrong side of the patio doors to do anything about it.

Eh. C'mon.

> My experience is that end-users and XSLT don't mix.

End users and macros don't mix. XSLT and power users work fine.

> Also, XML seems the wrong
> layer to define this mechanism.

Don't think so.

> Perhaps we have not clearly defined what we want out of a macro  
> system. I
> would want a language that allowed me to take OWL AST

But the XML syntax will be very close to the OWL AST. And, uh, how on  
earth can you appeal to end users and then talk about ASTs?

> and add a macros AST,

What? Surely a macro is a *transformation* of *an* AST into a OWL 1.1  
AST (or possibly an AST that will get further expanded). But this is  
just fine for XSLT.

> and then have a defined mechanism whereby these macros expand to  
> macros and
> OWL. I would only mention XML at the last moment, as a  
> serialization format

Piffle. Why would we invent such a thing with all the attendant woes  
that comes with inventing such a thing when we can just *reuse* a  
perfectly workable solution that is widely implemented, supported,  
etc. etc. I'd much rather ask a random person for an XSLT than almost  
anything else. Certain than an ad hoc custom macro language.

> for OWL+Macro AST. Lastly, I would like to be able to attach  
> annotations to
> the macros in exactly the same manner that I would the OWL statements.

You are jumbling up concerns. There's nothing about doing it "at the  
xml level" that would even vaguely preclude this. Much Au the Contraire.

> If defined this way, we can potentially use the standard  
> terminating functions
> tricks to restrict the macros language to something that will  
> expand to a
> finite amount of OWL AST.

I really really really really really really don't care about this,  
and I don't think we should. If someone writes a crap macro, foo upon  
them, and don't use it. Most of the macros will be trivial transforms  
that are easily verifiable and it's a waste of spirit and an expense  
of shame to get all worked up about it.

> I guess there are two ways to bind macros to their arguments to  
> trigger
> expansion, and these will affect both how useable it is and how  
> strongly we
> can check that it terminates, together with if we need a reasoner  
> during
> macro expansion

[snip]
Uh...and *this* is the chickenskin removing alternative for you?  
Dude, my proposal just needs a write up and every XSLT developer in  
the world can use it, and people can buy books on how to do OWL  
macros. Yes, of course there are potential termination issues, but it  
doesn't seem to have hurt XSLT overall. Invoking a reasoner during  
macro expansion?!?!? Brrr.

Speaking as an implementor and standards guy, I don't think any  
variant of your proposal will fly. One involves finding a suitable  
XSLT engine and some minor hookup, plus all that PR/documentation  
writing joy. The other...eh....kill me now.

Cheers,
Bijan.

From matthew.pocock at ncl.ac.uk  Wed May 17 09:13:44 2006
From: matthew.pocock at ncl.ac.uk (Matthew Pocock)
Date: Wed, 17 May 2006 14:13:44 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
Message-ID: <200605171413.44759.matthew.pocock@ncl.ac.uk>

> [snip]
> Uh...and *this* is the chickenskin removing alternative for you?
> Dude, my proposal just needs a write up and every XSLT developer in
> the world can use it, and people can buy books on how to do OWL
> macros. Yes, of course there are potential termination issues, but it
> doesn't seem to have hurt XSLT overall. Invoking a reasoner during
> macro expansion?!?!? Brrr.

But have you ever in the whole of your life seen two different OWL toolkits 
(or different releases of a single toolkit) serialize the OWL to the same 
RDF-XML? I know for a fact that protege, jena and the owl-api don't. And 
that's ignoring writing the "same thing" down using different syntactic 
forms.

> Cheers,
> Bijan.

From bparsia at isr.umd.edu  Wed May 17 09:20:24 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Wed, 17 May 2006 14:20:24 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <200605171413.44759.matthew.pocock@ncl.ac.uk>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
Message-ID: <AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>

On May 17, 2006, at 2:13 PM, Matthew Pocock wrote:

>> [snip]
>> Uh...and *this* is the chickenskin removing alternative for you?
>> Dude, my proposal just needs a write up and every XSLT developer in
>> the world can use it, and people can buy books on how to do OWL
>> macros. Yes, of course there are potential termination issues, but it
>> doesn't seem to have hurt XSLT overall. Invoking a reasoner during
>> macro expansion?!?!? Brrr.
>
> But have you ever in the whole of your life seen two different OWL  
> toolkits
> (or different releases of a single toolkit) serialize the OWL to  
> the same
> RDF-XML?

But the normative syntax for OWL 1.1 is *not* RDF/XML. If we were  
talking about RDF/XML then I agree with all your sentiments. But  
we're going to have a reasonable XML syntax (based on DIG 2).

> I know for a fact that protege, jena and the owl-api don't. And
> that's ignoring writing the "same thing" down using different  
> syntactic
> forms.

I think that semantically equivalent distinct syntactic forms (e.g.,  
A&B and ~(~A v ~B)) should properly not be noticed as equivalent by  
the macro system. First, it's brutally hard to understand. Second,  
it's hard to debug, third it requires some normal form or equivalence  
testing (brr), finally, isn't the core point of the macro system to  
introduce *new* syntax, so I don't see we need to intervene with core  
syntax. In fact, that's scary.

Cheers,
Bijan.

From matthew.pocock at ncl.ac.uk  Wed May 17 09:50:13 2006
From: matthew.pocock at ncl.ac.uk (Matthew Pocock)
Date: Wed, 17 May 2006 14:50:13 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
Message-ID: <200605171450.13273.matthew.pocock@ncl.ac.uk>

On Wednesday 17 May 2006 14:20, Bijan Parsia wrote:

> But the normative syntax for OWL 1.1 is *not* RDF/XML. If we were
> talking about RDF/XML then I agree with all your sentiments. But
> we're going to have a reasonable XML syntax (based on DIG 2).

In that case we are probably violently agreeing while grossly 
miss-understanding each other's positions.

> I think that semantically equivalent distinct syntactic forms (e.g.,
> A&B and ~(~A v ~B)) should properly not be noticed as equivalent by
> the macro system. 

Oh, I agree - just pointing out ways in which the same information can be 
represented in different ways.

> isn't the core point of the macro system to
> introduce *new* syntax

Yup - so going back a few steps - are we trying to define a way to do macros 
that act like template expansions (=function from some args to some OWL) or 
like pattern-matching re-write rules?

My worry with using an XSLT-style language is that it will be trivially easy 
to build stuff that is not OWL-XML and probably not even XML, where as a 
dedicated macro language can be constructed so that we always get OWL out the 
other end (or at the very least, a mix of OWL and un-expanded macros).

If macros are to be used by users, even if they are written by power-users, 
will there be a syntax for "importing" them into the OWL+Macros document?

> Cheers,
> Bijan.

Matthew

From rector at cs.man.ac.uk  Thu May 18 04:05:17 2006
From: rector at cs.man.ac.uk (Alan Rector)
Date: Thu, 18 May 2006 09:05:17 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
Message-ID: <3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>

All

Bijan, Matthew, All

I am strongly in favour of a set of transformations/macros.  I would  
very much worry about doing this through XSLT, at least as the  
primary language unless it were a very well defined constrained set  
of XSLT transforms that, in effect, simply used XSLT as the assembly  
language. Even then I worry.

To be useful a macro language has to be  sensitive to OWL semantics.
Amongst other things which macro use where, at least in our  
applications, depends on the it is in the subclass hierarchy.
  Furthermore I want to be able to
understand the combined results in terms of OWL semantics rather than  
XML semantics.

Using arbitrary XSLT transforms over OWL seriealisations ignoring OWL  
semanticsclearly dangerous.   And itt begs the qusetion.  The  
question is what sort of macros or macro language would be helpful to  
OWL and what effect they have on the resulting semantics.     
Therefore the primary definition of  macros etc. should be at the OWL  
level.  If somebody wants to implement them in XSLT in some tools  
fine - or even an XSLT library -  but let's have the definitions at  
the level of the OWL semantics not the serialisation XML syntax.



Regards

Alan



On 17 May 2006, at 14:20, Bijan Parsia wrote:

> On May 17, 2006, at 2:13 PM, Matthew Pocock wrote:
>
>>> [snip]
>>> Uh...and *this* is the chickenskin removing alternative for you?
>>> Dude, my proposal just needs a write up and every XSLT developer in
>>> the world can use it, and people can buy books on how to do OWL
>>> macros. Yes, of course there are potential termination issues,  
>>> but it
>>> doesn't seem to have hurt XSLT overall. Invoking a reasoner during
>>> macro expansion?!?!? Brrr.
>>
>> But have you ever in the whole of your life seen two different OWL
>> toolkits
>> (or different releases of a single toolkit) serialize the OWL to
>> the same
>> RDF-XML?
>
> But the normative syntax for OWL 1.1 is *not* RDF/XML. If we were
> talking about RDF/XML then I agree with all your sentiments. But
> we're going to have a reasonable XML syntax (based on DIG 2).
>
>> I know for a fact that protege, jena and the owl-api don't. And
>> that's ignoring writing the "same thing" down using different
>> syntactic
>> forms.
>
> I think that semantically equivalent distinct syntactic forms (e.g.,
> A&B and ~(~A v ~B)) should properly not be noticed as equivalent by
> the macro system. First, it's brutally hard to understand. Second,
> it's hard to debug, third it requires some normal form or equivalence
> testing (brr), finally, isn't the core point of the macro system to
> introduce *new* syntax, so I don't see we need to intervene with core
> syntax. In fact, that's scary.
>
> Cheers,
> Bijan.
> _______________________________________________
> OWL mailing list
> OWL at lists.mindswap.org
> http://lists.mindswap.org/mailman/listinfo/owl

-----------------------
Alan Rector
Professor of Medical Informatics
School of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL +44 (0) 161 275 6149/6188
FAX +44 (0) 161 275 6204
www.cs.man.ac.uk/mig
www.clinical-esciences.org
www.co-ode.org



From bparsia at isr.umd.edu  Thu May 18 18:53:54 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Thu, 18 May 2006 23:53:54 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
Message-ID: <8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>

On May 18, 2006, at 9:05 AM, Alan Rector wrote:

> All
>
> Bijan, Matthew, All
>
> I am strongly in favour of a set of transformations/macros.  I  
> would very much worry about doing this through XSLT,

Why?

> at least as the primary language unless it were a very well defined  
> constrained set of XSLT transforms that, in effect, simply used  
> XSLT as the assembly language.

Why? But see the Meaning Definition Language (MDL)

> Even then I worry.

Learn to love the bomb, baby.

> To be useful a macro language has to be  sensitive to OWL semantics.

No, it doesn't. It *really* doesn't. I don't know why you all think  
so. None of the useful sugar we've talked about remotely requires a  
language sensitive to OWL semantics.

> Amongst other things which macro use where, at least in our  
> applications, depends on the it is in the subclass hierarchy.

Er...Now *I'm* scared.

>  Furthermore I want to be able to
> understand the combined results in terms of OWL semantics rather  
> than XML semantics.

I don't understand this. Here's the work flow:

Document with macros ---> expand macros ---> plain OWL 1.1 document

Then you reason, in principle on the plain owl 1.1 document.

> Using arbitrary XSLT transforms over OWL seriealisations ignoring  
> OWL semanticsclearly dangerous.

No. Since the end result has to be an OWL document or the reasoner  
will reject it, I fail to see the danger.

> And itt begs the qusetion.

I don't think so.

>   The question is what sort of macros or macro language would be  
> helpful to OWL

This would be helpful to owl because it would allow people to add  
arbitrary syntatic sugar. Since that's pretty much all I've seen for  
the macro system, I think it meets the actual requirements and would  
be durn useful. A macro system that extended the semantics of the  
base language isn't a macro system in my book, but something more.

> and what effect they have on the resulting semantics.

None, sugar.

>     Therefore the primary definition of  macros etc. should be at  
> the OWL level.

This makes no sense. I don't even know what this means. What little I  
grasp of it puts it far beyond a macro language, IMHO.

>   If somebody wants to implement them in XSLT in some tools fine -  
> or even an XSLT library -  but let's have the definitions at the  
> level of the OWL semantics not the serialisation XML syntax.

allDifferent --> syntactic definition fine
exclusiveOr --> same
allDisjoint --> same
disjointUnion --> oh yeah

Now, I think you definitely don't want to let macros touch existing  
constructs. It should only expand *new* terms. Which is very close to  
how most people think of *macros* :)

So, I would argue that this is safe (or reasonably safe) useful, and  
easy to specify and implement. Whereas, this stuff that is  
"sensitive" to owl semantics sounds, well, really wacky. Procedural  
attachmenty. If I'm going to let you alter the fundamental  
expressivity of the language, then yeah, it requires a lot of a lot  
of thought. I just don't see this as a reasonable sense of "macro".

Cheers,
Bijan.

From alanruttenberg at gmail.com  Thu May 18 22:42:05 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Thu, 18 May 2006 22:42:05 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
Message-ID: <14576D39-6368-49E8-B17F-7CF494EB2D94@gmail.com>


Bijan and the other AlanR, have discussed:

> Why? But see the Meaning Definition Language (MDL)

I looked about 30 pages into http://www.charteris.com/capability/ 
technology/xmltoolkit/Downloads/MDL206.pdf
quickly, and I still don't know how I would do the macro below.  
That's probably a failing of my being unable to absorb this much  
information in such a short time. But it might help if you could show  
how something like this plays out.

Turn this:

(value-partition '(!things !bigThings (!littleThings !itsyThings ! 
smallThings)) :disjoint t :covering t)

or this, if you are going to say something about this not being XML,

<value-partition disjoint="true" covering="true">
     <things><bigThings/><littleThings><itsyThings/><smallThings/></ 
littleThings></things>
</value-partition>

into this (or xml equivalent)

Class(ex:things complete unionOf(ex:bigThings ex:littleThings ))
DisjointClasses(ex:bigThings ex:littleThings )
Class(ex:bigThings partial ex:things )
Class(ex:littleThings complete unionOf(ex:itsyThings ex:smallThings ))
DisjointClasses(ex:itsyThings ex:smallThings )
Class(ex:itsyThings partial ex:littleThings )
Class(ex:smallThings partial ex:littleThings )
Class(ex:littleThings partial ex:things )
)

Here's the lisp implementation. Lisp is good at macros. Have you  
thought about making the macro expansion be implemented in scheme or  
lisp? There's a fairly trivial embedding of the abstract syntax into  
sexp's that I use. Here's the implementation for the above macro.

(defun value-partition (spec &key (disjoint t) (covering t))
   (setq spec (eval-uri-reader-macro spec))
   (let ((parent (car spec))
	(children (rest spec)))
     (list* (if (and covering (> (length children) 1))
	       (class parent :complete (apply 'union-of (mapcar (lambda(el)  
(if (listp el) (car el) el)) children))))
	   (if (and disjoint (> (length children) 1))
	       (apply 'disjoint-classes (mapcar (lambda(el) (if (listp el)  
(car el) el)) children)))
	   (loop for child in children
	      when (listp child)
		append (value-partition child :disjoint disjoint :covering covering)
	      collect
		(class (if (listp child) (car child) child) :partial parent)))))

I have similar functions for taking a nested structure and turning it  
into an existential hierarchy, or a tree of individuals.

I used it to generate the tutorial at http://tinyurl.com/l2h6k
The code that generates the three demonstrated patterns is here:
http://svn.mumble.net:8080/svn/lsw/trunk/hcls/ontology-wg/hierarchy- 
examples.lisp
The code that implements the transforms is here:
http://svn.mumble.net:8080/svn/lsw/trunk/owl/patterns.lisp

Alan Rector said:

>> Amongst other things which macro use where, at least in our
>> applications, depends on the it is in the subclass hierarchy.
>
> Er...Now *I'm* scared.

The way it's phrased, I am too, since it would imply that macro  
expansion would depend on reasoner inferences.
But I suspect that's not what is meant. The worse I can imagine is  
that it depends on what's explicitly told, which is easier. Alan, do  
you have an example?

>> Using arbitrary XSLT transforms over OWL seriealisations ignoring
>> OWL semanticsclearly dangerous.
>
> No. Since the end result has to be an OWL document or the reasoner
> will reject it, I fail to see the danger.

Does having to debug the resultant mess qualify as danger? And, BTW,  
I've tried to use XSLT a couple of times and for anything other than  
really trivial things it is quite unpleasant.

>>   The question is what sort of macros or macro language would be
>> helpful to OWL
>
> This would be helpful to owl because it would allow people to add
> arbitrary syntatic sugar. Since that's pretty much all I've seen for
> the macro system, I think it meets the actual requirements and would
> be durn useful. A macro system that extended the semantics of the
> base language isn't a macro system in my book, but something more.

Which semantics? The model theoretic semantics? I don't think there's  
a proposal for that. What's an example of extending the semantics  
that you would consider out of bounds?

>>     Therefore the primary definition of  macros etc. should be at
>> the OWL level.
>
> This makes no sense. I don't even know what this means. What little I
> grasp of it puts it far beyond a macro language, IMHO.

Could you please give an example that is far beyond a macro language  
please?

One way that this makes sense is to make easily available to the  
macro writer classes of terms from which the abstract syntax is  
constructed, terms like Individualvaluedpropertyid, in order to  
*easily* write transformations like: if there is an ObjectProperty  
with a super which mentions UtilityClass, add an annotation on  
property TODO: "get rid of this superclass".

> Now, I think you definitely don't want to let macros touch existing
> constructs. It should only expand *new* terms. Which is very close to
> how most people think of *macros* :)

My turn to say that I don't know what that means. I've written, in my  
system, a translator that looks for strings anywhere in the first  
level of an abstract syntax form for individuals, classes, or  
properties, and packages them up into an rdfs:comment. No ambiguity  
is introduced. Are you saying I shouldn't be able to do that?

(define-ontology foo ()
	   (class !likeit
	     "These are the kinds of class comments I like to write"
	     :partial)
	   (class !dont :partial (annotation !rdfs:comment "I don't like  
writing comments like this. There's too much noise, and my editor  
doesn't understand how to syntax hilight it")))

BTW, Bijan, you can be very amusing when you are being vicious. Had  
me laughing :)

-Alan


From bparsia at isr.umd.edu  Fri May 19 03:59:42 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Fri, 19 May 2006 08:59:42 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <14576D39-6368-49E8-B17F-7CF494EB2D94@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<14576D39-6368-49E8-B17F-7CF494EB2D94@gmail.com>
Message-ID: <F0FF3BBE-A5FE-499B-BCA4-5D7DF7F07B62@isr.umd.edu>

On May 19, 2006, at 3:42 AM, Alan Ruttenberg wrote:

> Bijan and the other AlanR, have discussed:
>
>> Why? But see the Meaning Definition Language (MDL)
>
> I looked about 30 pages into http://www.charteris.com/capability/ 
> technology/xmltoolkit/Downloads/MDL206.pdf
> quickly, and I still don't know how I would do the macro below.

Sorry, I don't mean to offer MDL as an alternative, it's just an  
example of a higher level mapping/transformation language (from XML  
to RDF) that compiles to bidirectional XSLT transformations. But it  
only deals with a subset of RDF or OWL. It was intended as an example  
of using XSLT as an "assembler".

> That's probably a failing of my being unable to absorb this much  
> information in such a short time. But it might help if you could  
> show how something like this plays out.
>
> Turn this:
>
> (value-partition '(!things !bigThings (!littleThings !itsyThings ! 
> smallThings)) :disjoint t :covering t)
>
> or this, if you are going to say something about this not being XML,
>
> <value-partition disjoint="true" covering="true">
>     <things><bigThings/><littleThings><itsyThings/><smallThings/></ 
> littleThings></things>
> </value-partition>
>
> into this (or xml equivalent)
>
> Class(ex:things complete unionOf(ex:bigThings ex:littleThings ))
> DisjointClasses(ex:bigThings ex:littleThings )
> Class(ex:bigThings partial ex:things )
> Class(ex:littleThings complete unionOf(ex:itsyThings ex:smallThings ))
> DisjointClasses(ex:itsyThings ex:smallThings )
> Class(ex:itsyThings partial ex:littleThings )
> Class(ex:smallThings partial ex:littleThings )
> Class(ex:littleThings partial ex:things )
> )

This looks easy enough to do in XSLT.

> Here's the lisp implementation. Lisp is good at macros. Have you  
> thought about making the macro expansion be implemented in scheme  
> or lisp?

Well, only to reject it out of hand :) I'm quite familiar with scheme/ 
lisp macros but that's a pretty intolerable implementation burden  
(and use!). BTW, did you know that XSLT is a scheme dialect (sans  
macros)? yep, it's based on DSSSL-O

[snip examples I'll have to check out]

> Alan Rector said:
>
>>> Amongst other things which macro use where, at least in our
>>> applications, depends on the it is in the subclass hierarchy.
>>
>> Er...Now *I'm* scared.
>
> The way it's phrased, I am too, since it would imply that macro  
> expansion would depend on reasoner inferences.
> But I suspect that's not what is meant.

Well,he *did* talk about the reasoner around here :)

> The worse I can imagine is that it depends on what's explicitly  
> told, which is easier. Alan, do you have an example?
>
>>> Using arbitrary XSLT transforms over OWL seriealisations ignoring
>>> OWL semanticsclearly dangerous.
>>
>> No. Since the end result has to be an OWL document or the reasoner
>> will reject it, I fail to see the danger.
>
> Does having to debug the resultant mess qualify as danger?

No.

> And, BTW, I've tried to use XSLT a couple of times and for anything  
> other than really trivial things it is quite unpleasant.

I agree that it can be nasty. OTOH, there are substantial PR and  
reuse advantages. And it's not *that bad*. Plus, there are a ton of  
engines out there. You could even write your sheets in SXSLT and  
translate them out ;)

>>>   The question is what sort of macros or macro language would be
>>> helpful to OWL
>>
>> This would be helpful to owl because it would allow people to add
>> arbitrary syntatic sugar. Since that's pretty much all I've seen for
>> the macro system, I think it meets the actual requirements and would
>> be durn useful. A macro system that extended the semantics of the
>> base language isn't a macro system in my book, but something more.
>
> Which semantics? The model theoretic semantics? I don't think  
> there's a proposal for that. What's an example of extending the  
> semantics that you would consider out of bounds?


A "macro" that said, "If I see 'a rdf:type C' translate it to 'a  
rdf:type C. a rdf:type D'" was my thought. This *might*, and I  
emphaize *might*, not be so bad if it's a one pass thing. But one  
needs to be careful as it's getting closer to an implementation of  
epistemic rules.

Semantically, I think the simplest thing is to have new constructs  
that are defined by a translation to the base constructs (i.e., is  
strictly equivalent). This is perfectly well understood. I don't feel  
a strong need to *enforce* this in the language, though It might not  
be that hard. Buggy scripts are buggy scripts.

>>>     Therefore the primary definition of  macros etc. should be at
>>> the OWL level.
>>
>> This makes no sense. I don't even know what this means. What little I
>> grasp of it puts it far beyond a macro language, IMHO.
>
> Could you please give an example that is far beyond a macro  
> language please?

See above.

> One way that this makes sense is to make easily available to the  
> macro writer classes of terms from which the abstract syntax is  
> constructed, terms like Individualvaluedpropertyid, in order to  
> *easily* write transformations like: if there is an ObjectProperty  
> with a super which mentions UtilityClass, add an annotation on  
> property TODO: "get rid of this superclass".
>
>> Now, I think you definitely don't want to let macros touch existing
>> constructs. It should only expand *new* terms. Which is very close to
>> how most people think of *macros* :)
>
> My turn to say that I don't know what that means. I've written, in  
> my system, a translator that looks for strings anywhere in the  
> first level of an abstract syntax form for individuals, classes, or  
> properties, and packages them up into an rdfs:comment. No ambiguity  
> is introduced. Are you saying I shouldn't be able to do that?
>
> (define-ontology foo ()
> 	   (class !likeit
> 	     "These are the kinds of class comments I like to write"
> 	     :partial)
> 	   (class !dont :partial (annotation !rdfs:comment "I don't like  
> writing comments like this. There's too much noise, and my editor  
> doesn't understand how to syntax hilight it")))

That's fine because it doesn't actually modify or change the  
meaningful part of the axioms. So it's equivalence preserving.

> BTW, Bijan, you can be very amusing when you are being vicious. Had  
> me laughing :)

:)

Cheers,
Bijan.

From bparsia at isr.umd.edu  Fri May 19 04:08:09 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Fri, 19 May 2006 09:08:09 +0100
Subject: [OWL] Call for examples (Re:  Abstract syntax proposal)
In-Reply-To: <F0FF3BBE-A5FE-499B-BCA4-5D7DF7F07B62@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<14576D39-6368-49E8-B17F-7CF494EB2D94@gmail.com>
	<F0FF3BBE-A5FE-499B-BCA4-5D7DF7F07B62@isr.umd.edu>
Message-ID: <46439246-05F7-48D9-8784-28F831CEE52F@isr.umd.edu>

I think to move forward on a macro system, it would help to have a  
set of clear exemplifying examples. Then we can assess what's needed.

So, my current needs include:
	disjointUnion
	exclusiveOr
	allSameAs
	allDisjointFrom

I'm sure there's more in there but that's a start. I'll try to pick  
at the dig syntax to see what these would look like.

Cheers,
Bijan.

From rector at cs.man.ac.uk  Fri May 19 04:58:18 2006
From: rector at cs.man.ac.uk (Alan Rector)
Date: Fri, 19 May 2006 09:58:18 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
Message-ID: <BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>

Bijan

I was perhaps jumping in too quickly, so back to some use cases.  My  
concern is primarily with effect not means.  Some of these are more  
than macros - you are entirely right.  I am looking for an expansion/ 
transformation language to handle them however.   We have used macro- 
like languages that used the hierarchy heavily in the past in three  
situations, all of which are dependent on the language being able to  
reference to subclass hierarchy:

a)	To expand reified relations.  This can be done on a relation by  
relation basis but is unreliable as a new macro is required for each  
new property.  It is much cleaner to say that all the subproperties  
of a given property are to be expanded in a particular way.  This  
allows the user to add new subproperties in the particular place and  
have them behave correctly.

b)	For axiom schemas. An example is to expand "Ulcer of SOME X" to  
Ulcer of SOME (Mucosa AND isLayerOf SOME X) for X subsumed by PartOf  
SOME DigestiveTract.

c)	To hide ontological comlexities.  We have a whole series of  
different subproperties for part_of.  They can all be distinguished  
by the combination of the types of the arguments, but users have a  
terrible time learning them.  It is much easier to expand X isPartOf  
SOME Y according to the subclass of X and Y to the correct variant.

d) 	To enforce constraints for work-arounds: For example, if you are  
using transitive orbits - i.e. a parent transitive property with  
exactly one non-transitive subproperty which is intended to be the  
direct connect, e.g.

	is_followed_by
		has_next

For most cases for most users to whom you wish to give this, you want  
to enforce that the only thing that can be used to define a specific  
class of lists is the subproperty has_next where as the parent  
property is used in definitions intended to be used to define  
abstract patterns or queries.  This is best enforced by  
distinguishing use in 'complete' defintiions/equivalentClass axioms  
from use in 'partial' defintions/subclass axioms.
(Yes there are cases where you want the power users to do other  
things, but that's for the power users.)

That should be enough to give a flavour of what we are trying to  
achieve.  In our previous experience this was all done in the context  
of incremental classification in a classifier/compiler that enforced  
define before before use, so that, for example, the classes would all  
be classified up to the addition of the new macro containing axiom  
before the macro was applied, then the macro applied and the  
resulting axiom added.  No further macro expansion was done, although  
in theory of course there could be a cascade.  We avoided it by not  
allowing it and accepting the incompleteness entailed.

Clearly they are all more than simple Macros, so you may just  
consider them out of scope for the current discussion.  However, they  
are real needs. Suggestions as to how best to address these needs and  
whether they relate to Alan Ruttenberg's use cases solicited.

My other concern about using XSLT on the XML serialisation is the  
empirical observation that there remains much controversy around the  
RDF/XML and other XML serialisations, so that I worry about the  
stability of things that depend on them.   However, if we are  
speaking of true macros completely independent of the language, then  
this is probably irrelevant.

Regards

Alan



From bparsia at isr.umd.edu  Fri May 19 08:23:00 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Fri, 19 May 2006 13:23:00 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>
Message-ID: <9AF7B290-79A2-4108-91FB-FC640E89CFF0@isr.umd.edu>

On May 19, 2006, at 9:58 AM, Alan Rector wrote:

> Bijan
>
> I was perhaps jumping in too quickly, so back to some use cases.   
> My concern is primarily with effect not means.  Some of these are  
> more than macros - you are entirely right.  I am looking for an  
> expansion/transformation language to handle them however.   We have  
> used macro-like languages that used the hierarchy heavily in the  
> past in three situations, all of which are dependent on the  
> language being able to reference to subclass hierarchy:
>
> a)	To expand reified relations.  This can be done on a relation by  
> relation basis but is unreliable as a new macro is required for  
> each new property.

Not necessarily. You could add the new property to a list of  
properties that are so expanded...or...

> It is much cleaner to say that all the subproperties of a given  
> property are to be expanded in a particular way.  This allows the  
> user to add new subproperties in the particular place and have them  
> behave correctly.

You could use an annotation property to mark properties as being to  
be expanded this way. I'm suspicious abotu using the subproperty tree  
that way, as it seems to me to lead to "syntax superproperites",  
i.e., superproperties which are extraneous from a modeling point of  
view, but there for easy of writing things down. I don't *denigrate*  
the latter requirement. It's critical. But our solution shouldn't  
crap up the modeling (e.g.,  having such superproperties can muck up  
analysis and segmetnation algorithms).

> b)	For axiom schemas. An example is to expand "Ulcer of SOME X" to  
> Ulcer of SOME (Mucosa AND isLayerOf SOME X) for X subsumed by  
> PartOf SOME DigestiveTract.

This is clearly useful, but I'd want some marker for it. SOME* or  
soemthing. Maybe parameterizable. Just doing a postfacto transform  
seems to conceal what you are doing.

> c)	To hide ontological comlexities.  We have a whole series of  
> different subproperties for part_of.  They can all be distinguished  
> by the combination of the types of the arguments, but users have a  
> terrible time learning them.  It is much easier to expand X  
> isPartOf SOME Y according to the subclass of X and Y to the correct  
> variant.

I'll need to think about this one, but it seems like the proper  
property constructors could handle this. I.e., why not *infer* which  
specialized relation they fall into? Isn't that better and less fragile?

> d) 	To enforce constraints for work-arounds: For example, if you  
> are using transitive orbits - i.e. a parent transitive property  
> with exactly one non-transitive subproperty which is intended to be  
> the direct connect, e.g.
>
> 	is_followed_by
> 		has_next
>
> For most cases for most users to whom you wish to give this, you  
> want to enforce that the only thing that can be used to define a  
> specific class of lists is the subproperty has_next where as the  
> parent property is used in definitions intended to be used to  
> define abstract patterns or queries.  This is best enforced by  
> distinguishing use in 'complete' defintiions/equivalentClass axioms  
> from use in 'partial' defintions/subclass axioms.
> (Yes there are cases where you want the power users to do other  
> things, but that's for the power users.)

Didn't quite get this one, but I'm groggy.

> That should be enough to give a flavour of what we are trying to  
> achieve.  In our previous experience this was all done in the  
> context of incremental classification in a classifier/compiler that  
> enforced define before before use, so that, for example, the  
> classes would all be classified up to the addition of the new macro  
> containing axiom before the macro was applied, then the macro  
> applied and the resulting axiom added.

I don't think of this as a macro. It's a bit expressive (though of  
course powerful macro systems like those of Lisp or Scheme let you do  
analogous things). The word "macro" as we've been using it suggest no  
great change to the semantics of the language. This *is* such a  
change. I'm not saying it wouldn't be useful, but it needs to be  
properly defined. It's analogous to adding DL Safe rules.

>   No further macro expansion was done, although in theory of course  
> there could be a cascade.  We avoided it by not allowing it and  
> accepting the incompleteness entailed.

Uhhhhhhh....this seems to be a warning sign, to me. Why stop? Is it  
just incompleteness?

> Clearly they are all more than simple Macros, so you may just  
> consider them out of scope for the current discussion.

I think they need to be clearly distinguished from the rather easy to  
hand situation of wanting to add arbitrary syntactic sugar. As you've  
presented it, you are adding somewhat random procedural rules with a  
not very clearly specified evaluation mechanism (are the expansions  
independent of the order of classification?) I'm sure that's useful,  
but I think we can do things in quite a bit nicer way. However,  
that's not a short term project.

>   However, they are real needs. Suggestions as to how best to  
> address these needs and whether they relate to Alan Ruttenberg's  
> use cases solicited.

Yes, if it turns out that sugar isn't all *that* interesting, then  
there's no need for a specified mechanism.

> My other concern about using XSLT on the XML serialisation is the  
> empirical observation that there remains much controversy around  
> the RDF/XML and other XML serialisations,

Well, this proposal ignores RDF/XML. To get RDF/XML you'd apply the  
macro transformations, then covert the result to RDF/XML. That works  
fine, but it doesn't let you author with macros in RDF/XML. Which, I  
think, is a good thing :)

> so that I worry about the stability of things that depend on  
> them.   However, if we are speaking of true macros completely  
> independent of the language, then this is probably irrelevant.

Yep. I think we need to do a better job, overall, of reaching out to  
the XML community. One way to do that is to make better and  
appropriate use of their technology.

One issue, of course, is that while this is trivial for XML editors,  
custom editors like Swoop will have to deal with new sugar on a case  
by case basis, which sucks. Oh well. For commonly used macros, this  
won't be a problem. I guess we could add some sort of extension  
feature to make it easy to add this extra stuff. Bleah.

Cheers,
Bijan.

From alanruttenberg at gmail.com  Fri May 19 11:25:55 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Fri, 19 May 2006 11:25:55 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <F0FF3BBE-A5FE-499B-BCA4-5D7DF7F07B62@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<14576D39-6368-49E8-B17F-7CF494EB2D94@gmail.com>
	<F0FF3BBE-A5FE-499B-BCA4-5D7DF7F07B62@isr.umd.edu>
Message-ID: <6c599cdcfca7e22a5052983d4fe0dfd7@gmail.com>


On May 19, 2006, at 3:59 AM, Bijan Parsia wrote:
>> Here's the lisp implementation. Lisp is good at macros. Have you 
>> thought about making the macro expansion be implemented in scheme or 
>> lisp?
>
> Well, only to reject it out of hand :) I'm quite familiar with 
> scheme/lisp macros but that's a pretty intolerable implementation 
> burden (and use!).

I'm willing to bet there are more implementations of scheme across more 
platforms than xslt. So implementation burden doesn't cut it. 
Intolerable use burden? I thought these were power users. Frankly, if 
we're thinking it's a  feature that there is a barrier to entry into 
the macro writing game, I'd be much more likely to expect that a random 
piece of scheme code does something useful and correct than a random 
piece of xslt. And a lot more confident that one could discern, from 
reading the code, what that was.

> BTW, did you know that XSLT is a scheme dialect (sans macros)? yep, 
> it's based on DSSSL-O

I'll ask JAR about this. Is there a xlst-in-one-template implementation?

>> Does having to debug the resultant mess qualify as danger?
>
> No.

We very much disagree here. I'm surprised to see you say that Mr. 
http://www.mindswap.org/2005/debugging/

>> And, BTW, I've tried to use XSLT a couple of times and for anything 
>> other than really trivial things it is quite unpleasant.
>
> I agree that it can be nasty. OTOH, there are substantial PR and reuse 
> advantages. And it's not *that bad*. Plus, there are a ton of engines 
> out there. You could even write your sheets in SXSLT and translate 
> them out ;)

Now we're talking :)

>
>>>>   The question is what sort of macros or macro language would be
>>>> helpful to OWL
>>>
>>> This would be helpful to owl because it would allow people to add
>>> arbitrary syntatic sugar. Since that's pretty much all I've seen for
>>> the macro system, I think it meets the actual requirements and would
>>> be durn useful. A macro system that extended the semantics of the
>>> base language isn't a macro system in my book, but something more.
>>
>> Which semantics? The model theoretic semantics? I don't think there's 
>> a proposal for that. What's an example of extending the semantics 
>> that you would consider out of bounds?
>
>
> A "macro" that said, "If I see 'a rdf:type C' translate it to 'a 
> rdf:type C. a rdf:type D'" was my thought. This *might*, and I 
> emphaize *might*, not be so bad if it's a one pass thing. But one 
> needs to be careful as it's getting closer to an implementation of 
> epistemic rules.

Could you elaborate on what the issue is here  - I just need more to 
understand it. Are you worried about the potential loop? 
(C->CD->CDD->CDDD)? Or are you worried about the meaning of "If I see"? 
As far as macros are concerned, "seeing", means literally seeing, not 
inferring (though I have to review Alan's examples to make sure he 
agrees).

> Semantically, I think the simplest thing is to have new constructs 
> that are defined by a translation to the base constructs (i.e., is 
> strictly equivalent). This is perfectly well understood. I don't feel 
> a strong need to *enforce* this in the language, though It might not 
> be that hard. Buggy scripts are buggy scripts.

Probably being dense, but I don't know what it would mean to not 
translate to base constructs. You mention equivalence as a criteria 
later. A couple of more words defining this would be helpful for me.

Thanks,
Alan




From bparsia at isr.umd.edu  Fri May 19 11:45:16 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Fri, 19 May 2006 16:45:16 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <6c599cdcfca7e22a5052983d4fe0dfd7@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<14576D39-6368-49E8-B17F-7CF494EB2D94@gmail.com>
	<F0FF3BBE-A5FE-499B-BCA4-5D7DF7F07B62@isr.umd.edu>
	<6c599cdcfca7e22a5052983d4fe0dfd7@gmail.com>
Message-ID: <A858A564-4B34-4A3A-9AFE-5FE475E7B6DA@isr.umd.edu>

On May 19, 2006, at 4:25 PM, Alan Ruttenberg wrote:

> On May 19, 2006, at 3:59 AM, Bijan Parsia wrote:
>>> Here's the lisp implementation. Lisp is good at macros. Have you  
>>> thought about making the macro expansion be implemented in scheme  
>>> or lisp?
>>
>> Well, only to reject it out of hand :) I'm quite familiar with  
>> scheme/lisp macros but that's a pretty intolerable implementation  
>> burden (and use!).
>
> I'm willing to bet there are more implementations of scheme across  
> more platforms than xslt.

So?

> So implementation burden doesn't cut it.

Sure it does. All the current implementations have to deal with XML  
already. Everyone except the racer guys have access to in their  
language high quality, modular XSLT engines. And we all can do it as  
a preprocessing step.

> Intolerable use burden?

Yep. Far fewer scheme/lispers than XSLTers. Far fewer. Plus there's a  
PR burden.

> I thought these were power users. Frankly, if we're thinking it's  
> a  feature that there is a barrier to entry into the macro writing  
> game, I'd be much more likely to expect that a random piece of  
> scheme code does something useful and correct than a random piece  
> of xslt. And a lot more confident that one could discern, from  
> reading the code, what that was.

I'm not so sure. For something sure. But there's a lot of XSLT out  
there that seems to work just fine. I'm not scared.

>> BTW, did you know that XSLT is a scheme dialect (sans macros)?  
>> yep, it's based on DSSSL-O
>
> I'll ask JAR about this. Is there a xlst-in-one-template  
> implementation?

I doubt there's a metacircular interpreter, but, that doesn't bother me.

>>> Does having to debug the resultant mess qualify as danger?
>>
>> No.
>
> We very much disagree here. I'm surprised to see you say that Mr.  
> http://www.mindswap.org/2005/debugging/

Well, given the kinds of uses I'm thinking of (syntactic sugar,  
probably without recursion) I don't think it's any hard to debug XSLT  
than Scheme, Lisp. It all comes down to macroexpand anyway. Plus I  
hear there are some pretty good XSLT debuggers.

>>> And, BTW, I've tried to use XSLT a couple of times and for  
>>> anything other than really trivial things it is quite unpleasant.
>>
>> I agree that it can be nasty. OTOH, there are substantial PR and  
>> reuse advantages. And it's not *that bad*. Plus, there are a ton  
>> of engines out there. You could even write your sheets in SXSLT  
>> and translate them out ;)
>
> Now we're talking :)

Heh. I don't see why *that* made you happy. It's still XSLT. If this  
trivial syntactic difference makes you happy, then think of the  
XSLTers who *like* it.

[snip]
>> A "macro" that said, "If I see 'a rdf:type C' translate it to 'a  
>> rdf:type C. a rdf:type D'" was my thought. This *might*, and I  
>> emphaize *might*, not be so bad if it's a one pass thing. But one  
>> needs to be careful as it's getting closer to an implementation of  
>> epistemic rules.
>
> Could you elaborate on what the issue is here  - I just need more  
> to understand it. Are you worried about the potential loop? (C->CD- 
> >CDD->CDDD)?

No, I'm worried that it's adding a certain kind of information. This  
is very close to epistemic or procedural rules, esp. if you mix it  
with classification and reclassification. And if you *don't* it's  
somewhat counterintuitive ("What? If I *say* it's type C then it's  
type D it works but if I *infer* that it's type C it doesn't?!?!").

> Or are you worried about the meaning of "If I see"? As far as  
> macros are concerned, "seeing", means literally seeing, not  
> inferring (though I have to review Alan's examples to make sure he  
> agrees).

But that's not happy *either*; see the above case. If macros only  
work on *new* syntax and compile to old syntax, then it's all clear.  
But if macros work on *old* syntax and then...er...what, stop  
randomly? Then that's not so happy. Plus it makes it harder to add an  
entailment as an explicit statement because you get weird effects. Or  
it makes people *add* stuff explicitly in order to trigger those  
effects. All very very unhappy.

>> Semantically, I think the simplest thing is to have new constructs  
>> that are defined by a translation to the base constructs (i.e., is  
>> strictly equivalent). This is perfectly well understood. I don't  
>> feel a strong need to *enforce* this in the language, though It  
>> might not be that hard. Buggy scripts are buggy scripts.
>
> Probably being dense, but I don't know what it would mean to not  
> translate to base constructs. You mention equivalence as a criteria  
> later. A couple of more words defining this would be helpful for me.

yeah, I was sloppy. So, consider syntactic sugar. Generally, it's a  
*new* piece of syntax that compiles to an expanded piece of old  
syntax such that the new syntax and the expansion are considered to  
be strictly equivalent. For example, if your language only has not  
and or (~, v) you can define and and ifthen as macros (P -> Q <-> ~P  
v Q; P & Q <-> ~(~P v ~Q)).  I think that macros, properly speaking,  
should be more or less like this. So your comment shuffling macro is  
fine. Most of alan's are not.

That's not to say that meeting Alan's use cases isn't important, but  
I think it's a different activity, one that involves a change to the  
basic language and needs to be done careful so as to not screw things  
up. Uli and I had a discussion about this and we both have ideas. But  
I really wouldn't want to standardize it without a bit better handle  
on the formal properties.

BTW, Swoop already kind has the macro feature, except it works on  
somewhat arbitrary XML files, and you have to recompile, I think, to  
add new categories ;) But this way, right now, we can load a WS- 
Policy file and see it as owl.

I think the sugar macro system is going to be *hard enough* to  
accommodate sensibly with existing tools, so, given it's formal  
simplicity, it seems to be a good starting point.

Cheers,
Bijan.

From mcdougall at grammatech.com  Fri May 19 11:59:25 2006
From: mcdougall at grammatech.com (Michael McDougall)
Date: Fri, 19 May 2006 11:59:25 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <A858A564-4B34-4A3A-9AFE-5FE475E7B6DA@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>	<200605171150.22608.matthew.pocock@ncl.ac.uk>	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>	<200605171413.44759.matthew.pocock@ncl.ac.uk>	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>	<14576D39-6368-49E8-B17F-7CF494EB2D94@gmail.com>	<F0FF3BBE-A5FE-499B-BCA4-5D7DF7F07B62@isr.umd.edu>	<6c599cdcfca7e22a5052983d4fe0dfd7@gmail.com>
	<A858A564-4B34-4A3A-9AFE-5FE475E7B6DA@isr.umd.edu>
Message-ID: <446DEB5D.3010906@grammatech.com>

Bijan Parsia wrote:
> On May 19, 2006, at 4:25 PM, Alan Ruttenberg wrote:
>
>   
>> I thought these were power users. Frankly, if we're thinking it's  
>> a  feature that there is a barrier to entry into the macro writing  
>> game, I'd be much more likely to expect that a random piece of  
>> scheme code does something useful and correct than a random piece  
>> of xslt. And a lot more confident that one could discern, from  
>> reading the code, what that was.
>>     
>
> I'm not so sure. For something sure. But there's a lot of XSLT out  
> there that seems to work just fine. I'm not scared.
>   


I'm no XQuery expert, but I think it has fairly strong static typing 
rules that would help debug and validate macros (it wouldn't be the 
free-for-all that you get with macros in C). Since XQuery and XSLT2 are 
tightly linked, XSLT2 might offer the similar benefits. Though again, 
I'm no expert--I've used XSLT2 a fair bit but have heretofore I haven't 
been validating my scripts with typing. So maybe someone else in this 
forum can be more precise.

FWIW, the scheme interpreters I'm familiar with (my company makes heavy 
use of scheme) offer no static typing. But maybe I need to get out more.


Michael





From alanruttenberg at gmail.com  Fri May 19 13:38:35 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Fri, 19 May 2006 13:38:35 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>
Message-ID: <CB7EE20B-0D7B-4758-B272-F953578EA624@gmail.com>

Hi Alan,

I'm starting to look at your use cases. Looking at b) I have some  
questions about what you would expect to happen in a variety of cases.

On May 19, 2006, at 4:58 AM, Alan Rector wrote:
>
> b)	For axiom schemas. An example is to expand "Ulcer of SOME X" to
> Ulcer of SOME (Mucosa AND isLayerOf SOME X) for X subsumed by PartOf
> SOME DigestiveTract.

Would you expect to expand each of the following:

painfulUlcerOf SOME X where PainfulUlcerOf is a subproperty of ulcerOf.
ulcerOf MIN 2 X
ulcerOf EXACTLY 1 X
ulcerOf SOME (X and Muscle)
ulcerOf SOME (X or Muscle)
ulcerOf SOME (not X)
ulcerOf HAS stomach21
Individual(illness1 type(ulcerOf SOME X))
Individual(illness2 value(ulcerOf x)) where x a partOf SOME  
DigestiveTract.

-Alan


From alanruttenberg at gmail.com  Sat May 20 03:02:18 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Sat, 20 May 2006 03:02:18 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <A858A564-4B34-4A3A-9AFE-5FE475E7B6DA@isr.umd.edu>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<14576D39-6368-49E8-B17F-7CF494EB2D94@gmail.com>
	<F0FF3BBE-A5FE-499B-BCA4-5D7DF7F07B62@isr.umd.edu>
	<6c599cdcfca7e22a5052983d4fe0dfd7@gmail.com>
	<A858A564-4B34-4A3A-9AFE-5FE475E7B6DA@isr.umd.edu>
Message-ID: <DD6D476E-52E3-4C77-81AA-487029CCC985@gmail.com>


On May 19, 2006, at 11:45 AM, Bijan Parsia wrote:

>> So implementation burden doesn't cut it.
>
> Sure it does. All the current implementations have to deal with XML  
> already. Everyone except the racer guys have access to in their  
> language high quality, modular XSLT engines. And we all can do it  
> as a preprocessing step.

Everyone, *including* the racer guys, have access to in their  
language high quality, modular scheme implementations.

>> Intolerable use burden?
> Yep. Far fewer scheme/lispers than XSLTers. Far fewer. Plus there's  
> a PR burden.

The PR burden is the only one that I can see as being legitimate.  
Emacs doesn't seem to suffer from it, though. Anyways the point is to  
embed the macros rewriting in some real programming language. Choose  
Jython, or javascript if you are afraid of what people will think of  
scheme.

> Heh. I don't see why *that* made you happy. It's still XSLT. If  
> this trivial syntactic difference makes you happy, then think of  
> the XSLTers who *like* it.

Well the folks who wrote sxslt didn't seem to think it was a trivial  
syntactic difference. A couple of tidbits they quote from http:// 
www.kuro5hin.org/story/2002/1/15/1562/95011 as justification for  
embedding the transformation language in scheme:
> The signal-to-noise ratio of XSLT transformations is shameful,  
> easily among the worst of all computer languages in widespread use.  
> Non-trivial XSLT transformations almost appear obfuscated. [...]  
> The really bad thing is that the designers of XSLT made the  
> language free of side effects but then failed to include  
> fundamental support for basic functional programming idioms.  
> Without such support, many trivial tasks become hell.
Notwithstanding your poor taste in programming languages, I thank you  
for the rest of your comments regarding macros, they are helpful. I  
will think about them some more, as well as Alan's examples.

For your "call for examples", please include Individual* and value  
partition examples from my earlier message.

-Alan



From bparsia at isr.umd.edu  Sat May 20 06:13:32 2006
From: bparsia at isr.umd.edu (Bijan Parsia)
Date: Sat, 20 May 2006 11:13:32 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <DD6D476E-52E3-4C77-81AA-487029CCC985@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<14576D39-6368-49E8-B17F-7CF494EB2D94@gmail.com>
	<F0FF3BBE-A5FE-499B-BCA4-5D7DF7F07B62@isr.umd.edu>
	<6c599cdcfca7e22a5052983d4fe0dfd7@gmail.com>
	<A858A564-4B34-4A3A-9AFE-5FE475E7B6DA@isr.umd.edu>
	<DD6D476E-52E3-4C77-81AA-487029CCC985@gmail.com>
Message-ID: <6E37842A-4B4A-47AF-BD35-A0B5F4A30B42@isr.umd.edu>

On May 20, 2006, at 8:02 AM, Alan Ruttenberg wrote:

> On May 19, 2006, at 11:45 AM, Bijan Parsia wrote:
>
>>> So implementation burden doesn't cut it.
>>
>> Sure it does. All the current implementations have to deal with  
>> XML already. Everyone except the racer guys have access to in  
>> their language high quality, modular XSLT engines. And we all can  
>> do it as a preprocessing step.
>
> Everyone, *including* the racer guys, have access to in their  
> language high quality, modular scheme implementations.

True. I oversold this bit.

>>> Intolerable use burden?
>> Yep. Far fewer scheme/lispers than XSLTers. Far fewer. Plus  
>> there's a PR burden.
>
> The PR burden is the only one that I can see as being legitimate.  
> Emacs doesn't seem to suffer from it, though.

It sure does. Plus it's historical.

> Anyways the point is to embed the macros rewriting in some real  
> programming language.

Sigh. Though it sucks, XSLT is a real programming language. Plus, for  
sugar, I prefer something optimized for transform.

> Choose Jython, or javascript if you are afraid of what people will  
> think of scheme.

Now, really ick. Javascript? And you disparage *MY* taste in  
programming languages?!?!??! ;)

>> Heh. I don't see why *that* made you happy. It's still XSLT. If  
>> this trivial syntactic difference makes you happy, then think of  
>> the XSLTers who *like* it.
>
> Well the folks who wrote sxslt didn't seem to think it was a  
> trivial syntactic difference.

By "trivial" I meant that it's *primarily* a notational variation. I  
mean, there's a sense that RDF/XML and Abstract Syntax are trivial  
syntactic variants.

> A couple of tidbits they quote from http://www.kuro5hin.org/story/ 
> 2002/1/15/1562/95011 as justification for embedding the  
> transformation language in scheme:
>> The signal-to-noise ratio of XSLT transformations is shameful,  
>> easily among the worst of all computer languages in widespread  
>> use. Non-trivial XSLT transformations almost appear obfuscated.  
>> [...] The really bad thing is that the designers of XSLT made the  
>> language free of side effects but then failed to include  
>> fundamental support for basic functional programming idioms.  
>> Without such support, many trivial tasks become hell.
> Notwithstanding your poor taste in programming languages,

/me goes to the bookmark www.hitmanforhire.com! Ah, I see they have a  
special on kneecapping this week.

> I thank you for the rest of your comments regarding macros, they  
> are helpful. I will think about them some more, as well as Alan's  
> examples.

Cool

> For your "call for examples", please include Individual* and value  
> partition examples from my earlier message.

Sure.

Cheers,
Bijan.

From alanruttenberg at gmail.com  Sun May 21 01:10:18 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Sun, 21 May 2006 01:10:18 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>
Message-ID: <6738E9BB-09B2-431C-BA03-A15ED8B45684@gmail.com>


On May 19, 2006, at 4:58 AM, Alan Rector wrote:

> a)	To expand reified relations.  This can be done on a relation by
> relation basis but is unreliable as a new macro is required for each
> new property.  It is much cleaner to say that all the subproperties
> of a given property are to be expanded in a particular way.  This
> allows the user to add new subproperties in the particular place and
> have them behave correctly.

Alan, what's the expected interaction between the properties of the  
reified property and the superproperties?

So if I have a property, like in biopax, participant with  
subproperty:  left and I reify left so I can add stoichiometry.  
Suppose  I have individual reaction1 with left stoichiometry = 2 for  
value h, would you expect that querying for the stoichiometry of   
participant with value h would also return 2? Do you tend to want to  
say things like stoichiometry is functional and so if you have two  
properties in the same superproperty chain have different values  
asserted for it an inconsistency should be noted. Do you tend to have  
a class hierarchy for the reified properties that matches the initial  
property hierarchy?

Alan and others, a question related to the use of the property  
hierarchy in macro expansion. Do the property axioms  completely  
determine the property hierarchy? Or can some other statement in the  
ontology - facts  or axioms, cause an inference that changes the  
property hierarchy (by which I mean only the sub/superproperty  
relations)

-Alan

From evren at cs.umd.edu  Sun May 21 02:01:29 2006
From: evren at cs.umd.edu (Evren Sirin)
Date: Sun, 21 May 2006 02:01:29 -0400
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <6738E9BB-09B2-431C-BA03-A15ED8B45684@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>	<200605171150.22608.matthew.pocock@ncl.ac.uk>	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>	<200605171413.44759.matthew.pocock@ncl.ac.uk>	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>	<BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>
	<6738E9BB-09B2-431C-BA03-A15ED8B45684@gmail.com>
Message-ID: <44700239.70406@cs.umd.edu>

On 5/21/2006 1:10 AM, Alan Ruttenberg wrote:
> Alan and others, a question related to the use of the property  
> hierarchy in macro expansion. Do the property axioms  completely  
> determine the property hierarchy? Or can some other statement in the  
> ontology - facts  or axioms, cause an inference that changes the  
> property hierarchy (by which I mean only the sub/superproperty  
> relations)
>   
There are at least two ways I can think of. First, you can define an 
unsatisfiable property:

SubClassOf(owl:Thing restriction(p maxCardinality(0))

No individual can have a p value so p would be subproperty of every 
other property (similar to unsatisfiable classes).

The second way is using nominals. For example, assert some relations 
about the properties. Then using domain and range restrictions (and 
cardinality restrictions if necessary) close this relation so no other 
value is possible. Then one property can end up as the subproperty of 
other. From the below ontology, it will be entailed that q is 
subproperty of p:

ObjectProperty(ex:p domain(oneOf(ex:a)))
ObjectProperty(ex:q domain(oneOf(ex:a)))

Class(owl:Thing partial
  restriction(ex:p allValuesFrom(oneOf(ex:b ex:c)))
  restriction(ex:q allValuesFrom(oneOf(ex:b))))

Individual(ex:a type(owl:Thing)
  value(ex:q ex:b)
  value(ex:p ex:b)
  value(ex:p ex:c))
Individual(ex:b type(owl:Thing))
Individual(ex:c type(owl:Thing))

Regards,
Evren
> -Alan
> _______________________________________________
> OWL mailing list
> OWL at lists.mindswap.org
> http://lists.mindswap.org/mailman/listinfo/owl
>   

-- 
Evren Sirin evren at cs.umd.edu
Graduate Research Assistant
Computer Science Department
Univ of Maryland, College Park, MD 20742
Phone: (301) 405-7027, Fax: (301) 405-6707



From alanruttenberg at gmail.com  Sun May 21 22:34:23 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Sun, 21 May 2006 22:34:23 -0400
Subject: [OWL] Punning, cocodat
Message-ID: <7839D479-1442-4B2B-AFBE-1FD96C31DFEA@gmail.com>

Hi, some more questions on punning

1) On reading the overview, I see

"...Class(Person partial super(Animal) type(MyClass) value(dc:creator  
peter)) which is syntactic sugar for Class(Person partial) plus
Individual(Person super(Animal) type(MyClass) value(dc:creator peter))"

"super" is a term used on properties, so I don't understand it's use  
in the fact.

2) The punning explanation in the language overview focuses on  
putting properties (via value) on properties and classes, explaining  
that they are asserted on individuals with the same name which bear  
no relation to the class/property. So classes can be on the lhs of a  
property. Can they also be on the rhs? In other words, can I have this:

Class(Person partial)
ObjectProperty(thinksHeIsA)
Individual(Alan value(thinksHeIsA Person))

Would Individual(Person) automatically be asserted?

3) I've recently seen the following pattern, in some early work of  
the HCLSIG, at http://128.36.123.50/NeuroWeb/ - see the CoCoDat  
Ontology in OWL format http://128.36.123.50/NeuroWeb/owl/cocodat.owl

In this, a class hierarchy is given, and an instance of each of the  
leaf classes is created and used as property values on instances  
corresponding to rows in a database. I am presuming that this is to  
replicate the usual case of hierarchical vocabulary, with terms from  
the vocabulary used as field values. However, since these folks want  
to work with OWL, they can't use the terms directly, and so they  
create the corresponding instances.
(picture: http://mumble.net/~alanr/piece-of-cocodat.png)

Now if the answer to 2) is yes, then I might expect that they would  
change their modeling to use the class terms directly. Of course they  
will then find that their non-leaf class queries don't work any more,  
since the individual isn't related to the class. Seeing that they  
might then go and declare that each punned individual is an instance  
of the class of the same name. And I wonder if they did that how well  
that would play with future metamodeling extensions.

Anyways, I'm trying to understand the implications for punning, and  
trying at the same time to figure out whether what neuroweb did was a  
good idea (and if not, what they should have done). And they seemed  
related.

Hope this isn't too confusing (and that I'm not too confused :)

-Alan

From rector at cs.man.ac.uk  Mon May 22 06:24:40 2006
From: rector at cs.man.ac.uk (Alan Rector)
Date: Mon, 22 May 2006 11:24:40 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <6738E9BB-09B2-431C-BA03-A15ED8B45684@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>
	<6738E9BB-09B2-431C-BA03-A15ED8B45684@gmail.com>
Message-ID: <093EA4A7-1E77-4328-B6CC-48DA2F1C0157@cs.man.ac.uk>

Alan, all

On 21 May 2006, at 06:10, Alan Ruttenberg wrote:

>
> On May 19, 2006, at 4:58 AM, Alan Rector wrote:
>
>> a)	To expand reified relations.  This can be done on a relation by
>> relation basis but is unreliable as a new macro is required for each
>> new property.  It is much cleaner to say that all the subproperties
>> of a given property are to be expanded in a particular way.  This
>> allows the user to add new subproperties in the particular place and
>> have them behave correctly.
>
> Alan, what's the expected interaction between the properties of the  
> reified property and the superproperties?

The whole point of this case is something that can be invoked for the  
simple cases that don't involve additional restrictions on the class  
that reifies the property.  It arose as part of the notion of a  
"close to user form" or "intermediate representation" so as to allow  
people to say, most of the time, "hasSeverity SOME Severe" rather  
than "hasFeature SOME (Severity AND (hasValue SOME Severe))".

In those cases where you really do need the reification - as in your  
example - the macro is irrelevant - e.g. in this example

	hasFeature SOME (Severity AND (hasValue SOME Severe) AND (hasTrend  
SOME GettingWorse))

>
> So if I have a property, like in biopax, participant with  
> subproperty:  left and I reify left so I can add stoichiometry.  
> Suppose  I have individual reaction1 with left stoichiometry = 2  
> for value h, would you expect that querying for the stoichiometry  
> of  participant with value h would also return 2? Do you tend to  
> want to say things like stoichiometry is functional and so if you  
> have two properties in the same superproperty chain have different  
> values asserted for it an inconsistency should be noted. Do you  
> tend to have a class hierarchy for the reified properties that  
> matches the initial property hierarchy?
>
> Alan and others, a question related to the use of the property  
> hierarchy in macro expansion. Do the property axioms  completely  
> determine the property hierarchy? Or can some other statement in  
> the ontology - facts  or axioms, cause an inference that changes  
> the property hierarchy (by which I mean only the sub/superproperty  
> relations)

Not with the usual constructs - see Evren's answer.

Alan (Rector)
>
> -Alan

-----------------------
Alan Rector
Professor of Medical Informatics
School of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL +44 (0) 161 275 6149/6188
FAX +44 (0) 161 275 6204
www.cs.man.ac.uk/mig
www.clinical-esciences.org
www.co-ode.org



From rector at cs.man.ac.uk  Mon May 22 06:24:53 2006
From: rector at cs.man.ac.uk (Alan Rector)
Date: Mon, 22 May 2006 11:24:53 +0100
Subject: [OWL] Abstract syntax proposal
In-Reply-To: <CB7EE20B-0D7B-4758-B272-F953578EA624@gmail.com>
References: <891F43AB-7809-4317-9D01-447CABC98101@gmail.com>
	<200605171150.22608.matthew.pocock@ncl.ac.uk>
	<F0437298-67C5-4EC3-B4D6-4F251837CB70@isr.umd.edu>
	<200605171413.44759.matthew.pocock@ncl.ac.uk>
	<AD537D0F-678B-46AE-9C5E-35C7D3400758@isr.umd.edu>
	<3374C152-74CB-42E0-8379-9B9A65EBC9E8@cs.man.ac.uk>
	<8207135F-BA1F-40AF-AD6A-0B377959A8D1@isr.umd.edu>
	<BD7EB461-3F43-49F3-86F4-DA97FE5F1836@cs.man.ac.uk>
	<CB7EE20B-0D7B-4758-B272-F953578EA624@gmail.com>
Message-ID: <C1412C58-B65E-42FE-9E4A-EC95D162C6C4@cs.man.ac.uk>

Alan
Quick replies.

On 19 May 2006, at 18:38, Alan Ruttenberg wrote:

> Hi Alan,
>
> I'm starting to look at your use cases. Looking at b) I have some  
> questions about what you would expect to happen in a variety of cases.
>
> On May 19, 2006, at 4:58 AM, Alan Rector wrote:
>>
>> b)	For axiom schemas. An example is to expand "Ulcer of SOME X" to
>> Ulcer of SOME (Mucosa AND isLayerOf SOME X) for X subsumed by PartOf
>> SOME DigestiveTract.
>
> Would you expect to expand each of the following:

BTW I would never use a property such as isUlcerOf and would always  
use a more generic property plus a class.  e.g.
X hasSite Stomach where X is a subclass of Ulcer.

However, with that caveat.
>
> painfulUlcerOf SOME X where PainfulUlcerOf is a subproperty of  
> ulcerOf.
	Expanded
> ulcerOf MIN 2 X
	In this case doesn't make sense, but it general I would expect to  
expand it.
> ulcerOf EXACTLY 1 X
	The issues we raised with "exactly" and max cardinality come in  
here, so it might require thought.  But the issue is about "EXACTLY"  
rather than the exansion
> ulcerOf SOME (X and Muscle)

Almost certainly an error in our normal usage.  However, I'd expand  
the X.  Almost certainly then in the example Mucosa and Muscle would  
be disjoint so the expression would be unsatisfiable.

> ulcerOf SOME (X or Muscle)

Also almost certainly an error - probably the sort of thing to be  
flagged up as a query.  But formally the same answer.

> ulcerOf SOME (not X)

Good question.  `Not thought through because our previous formalisms  
lacked true negation.  The reasonable expansion would be
Mucosa AND NOT (is_part_of SOME X) - i.e. an ulcer of someplace else,  
but still of the same general sort.  I'd think this would flag an  
error unless there was something else in the expression so that it  
was a relative negation:

ulcerOf

> ulcerOf HAS stomach21
??? don't understand.

> Individual(illness1 type(ulcerOf SOME X))

Expanded assuming X is part of the digetstive tract.

> Individual(illness2 value(ulcerOf x)) where x a partOf SOME  
> DigestiveTract.

Ditto.
>
> -Alan
>

-----------------------
Alan Rector
Professor of Medical Informatics
School of Computer Science
University of Manchester
Manchester M13 9PL, UK
TEL +44 (0) 161 275 6149/6188
FAX +44 (0) 161 275 6204
www.cs.man.ac.uk/mig
www.clinical-esciences.org
www.co-ode.org




From alanruttenberg at gmail.com  Mon May 22 13:09:54 2006
From: alanruttenberg at gmail.com (Alan Ruttenberg)
Date: Mon, 22 May 2006 13:09:54 -0400
Subject: [OWL] Punning, cocodat
In-Reply-To: <7839D479-1442-4B2B-AFBE-1FD96C31DFEA@gmail.com>
References: <7839D479-1442-4B2B-AFBE-1FD96C31DFEA@gmail.com>
Message-ID: <876a0fec169c3fb0ffa3c15e6c3ec315@gmail.com>

On May 21, 2006, at 10:34 PM, Alan Ruttenberg wrote:

>  I am presuming that this is to
> replicate the usual case of hierarchical vocabulary, with terms from
> the vocabulary used as field values. However, since these folks want
> to work with OWL, they can't use the terms directly, and so they
> create the corresponding instances.

Strike presume. This is "approach 2" in 
http://www.w3.org/TR/swbp-classes-as-values/. Thanks to John Barkley 
for pointing this out.

-Alan


From matthew.pocock at ncl.ac.uk  Tue May 23 04:32:20 2006
From: matthew.pocock at ncl.ac.uk (Matthew Pocock)
Date: Tue, 23 May 2006 09:32:20 +0100
Subject: [OWL] Punning, cocodat
In-Reply-To: <7839D479-1442-4B2B-AFBE-1FD96C31DFEA@gmail.com>
References: <7839D479-1442-4B2B-AFBE-1FD96C31DFEA@gmail.com>
Message-ID: <200605230932.21099.matthew.pocock@ncl.ac.uk>

On Monday 22 May 2006 03:34, Alan Ruttenberg wrote:
>
> In this, a class hierarchy is given, and an instance of each of the
> leaf classes is created and used as property values on instances
> corresponding to rows in a database. I am presuming that this is to
> replicate the usual case of hierarchical vocabulary, with terms from
> the vocabulary used as field values. However, since these folks want
> to work with OWL, they can't use the terms directly, and so they
> create the corresponding instances.
> (picture: http://mumble.net/~alanr/piece-of-cocodat.png)

Does this model more cleanly as a load of nested agregates? The hierachy of 
sets kind of model does drop out fairly naturally if you allow agregates and 
also allow the aggregate part-of relation to be transitive. Certainly, for 
biological species taxonomies, it feels more natural than a class hierachy 
with "enum-like" individuals.

Matthew

(can't spell for toffie)

From bcg at cs.man.ac.uk  Tue May 30 07:01:40 2006
From: bcg at cs.man.ac.uk (Bernardo Cuenca Grau)
Date: Tue, 30 May 2006 12:01:40 +0100 (BST)
Subject: [OWL] Additions the OWL 1.1 website
Message-ID: <Pine.GSO.4.42.0605301158020.1590-100000@kiss>


 Hi all,

 I have recently updated the OWL 1.1 website. In particular, I have added
a draft for an RDF syntax for OWL 1.1 and also a pointer to a potential
XML exchange syntax (not based on RDF) based on the DIG interface. Both
documents are subject to change (and will be changed). Feel free to take a
look and make any comments or suggestions

 Cheers,

 Bernardo


***********************************
Dr. Bernardo Cuenca Grau
Research Fellow
Information Management Group
School Of Computer Science
University of Manchester, UK
http://www.cs.man.ac.uk/~bcg
************************************


From pfps at research.bell-labs.com  Wed May 31 12:54:55 2006
From: pfps at research.bell-labs.com (Peter F. Patel-Schneider)
Date: Wed, 31 May 2006 12:54:55 -0400 (EDT)
Subject: [OWL] Additions the OWL 1.1 website
In-Reply-To: <Pine.GSO.4.42.0605301158020.1590-100000@kiss>
References: <Pine.GSO.4.42.0605301158020.1590-100000@kiss>
Message-ID: <20060531.125455.112411941.pfps@research.bell-labs.com>

Somehow the website 

http://owl1_1.cs.manchester.ac.uk/

which I assume is the OWL 1.1 website, has picked up quite a few artifacts.
I don't know where they come form.

peter


From: Bernardo Cuenca Grau <bcg at cs.man.ac.uk>
Subject: [OWL] Additions the OWL 1.1 website
Date: Tue, 30 May 2006 12:01:40 +0100 (BST)

> 
>  Hi all,
> 
>  I have recently updated the OWL 1.1 website. In particular, I have added
> a draft for an RDF syntax for OWL 1.1 and also a pointer to a potential
> XML exchange syntax (not based on RDF) based on the DIG interface. Both
> documents are subject to change (and will be changed). Feel free to take a
> look and make any comments or suggestions
> 
>  Cheers,
> 
>  Bernardo
> 
> 
> ***********************************
> Dr. Bernardo Cuenca Grau
> Research Fellow
> Information Management Group
> School Of Computer Science
> University of Manchester, UK
> http://www.cs.man.ac.uk/~bcg
> ************************************
> 
> _______________________________________________
> OWL mailing list
> OWL at lists.mindswap.org
> http://lists.mindswap.org/mailman/listinfo/owl