Re: declaredAs

On Aug 7, 2007, at 9:38 PM, Michael Schneider wrote:

[snip]
> Holding myself straight to this concrete example: How would I  
> express this in terms of declarations? I see how I can say that  
> some name is allowed to stand for both, a class and an individual:
>
>     :ClassOrIndividual owl:declaredAs owl:Class, owl:Individual .
>
> But how can I say that another name can /only/ stand for a class  
> and not an individual?
>
>     :OnlyClass owl:declaredAs owl:Class .
>
> I would need something like
>
>     :OnlyClass owl:notAllowedAs owl:Individual .

Probably. I mis-remembered structural consistent up a little working  
from memory.

> Otherwise, what should my parser do when only having the first of  
> these two declarations? It can either always deny ontologies, which  
> contains some name, which is somewhere used in a way that is not  
> explictly declared. In this case, the parser would show me the red  
> card, if I say something like
>
>     :OnlyClass a :ClassOrIndividual .
>
> But this would be very restrictive, and would be very much against  
> the "declarations are pure optional" spirit.

You could require that every valid use resource kind for a term also  
be a declared kind. That's a bit verbose, but it does the job.

[I'm not thrilled with this "resource kind" term, but as you  
introduced it, I'll stick with it.]

I.e., "An ontology is intended resource kind consistent iff every use  
resource kind of an entity is a declared resource kind of that entity".

Tools could easily saturate the declaratoins so you wouldn't have to  
maintain them directly. My example of wanting to merge two ontologies  
and first generating declarations from all the use kind worked that way.

> But if only existing declarations were taken into account, what  
> then would the two declarations above affect?
>
> I then see no difference between having declarations and having none:
>
>     * An axiom ':ClassOrIndividual a :OnlyClass' will (intendendly)  
> pass, because this matches the explicit declarations for both names.
>
>     * A statement ':OnlyClass a :ClassOrIndividual' will (un- 
> intendendly) pass, because there is no declaration which speaks  
> against using ':OnlyClass' at an individual's position.

See above. I think I patched my hole (thanks for pointing it out!). A  
richer declaration language would be nicer, I agree, since saturation  
is rather obnoxious in a lot of cases. So an annotation based  
solution (which is more easily extensible) is probably better for  
this case.

[snip]
> > Declarations let us write it down. Hard to see any other way  
> (although you
> > could imagine a declaration language that used patterns the way  
> aboutEachPrefix could,
> > or other macro like things; but these are implementation details  
> almost))
>
> An alternative would perhaps be to follow the lines of XDoclets for  
> Java. Within a comment, one could put in some "@DeclaredAsClass(C)"  
> string or something similar what a parser can easily detect and  
> which is hard to produce by accident. In OWL-1.1 we will have axiom  
> comments (annotations), so this approach could be realized   
> independent of any serialization language. I would probably prefer  
> to put all those declaration statements into a toplevel comment:
>
>     Ontology(MyOnt comment(@DeclaredAsClass(C)  
> @DeclaredAsObjectProperty(P) ...))

Really? For some reason I feel like I'd prefer to put them into  
EntityAnnotation axioms.

Btw, no need to overload comment. Just make a new annotation type  
e.g., declarations.

So, EntityAnnotation(C, declaredOnlyAs(Class).

> The advantages and disadvantages are similar to those of XDoclet  
> comments:
>
>     - Not directly supported by the language, just a convention
[snip]

Mine isn't, or at least needn't be. We could define certain  
annotations in the spec. At this point, again, we're just arguing the  
boring syntax bits. More interesting things would be e.g., macros, or  
a pattern language for applying declarations (or other properties and  
annotations).

Re: your question about list of use cases, etc., I volunteer you :)

Oh, here's another, more minor one, or a variation: Analysis of the  
use resource kind structure of an ontology. So, it's easy enough to  
determine all the use resource kinds of an ontology. So I might want  
to *dump* that structure to use as a seed for a new version (from  
scratch) of the ontology (or other analyses). Does this rise to the  
level of recommendation worthiness? Dunno. Probably not by itself.  
But it might help support the other case.

(And of course and annotation based implementation wouldn't have the  
backward compat issues, so would lower the cost.)

Uli sez: Bijan stop writing email. So I hereby stop.

Cheers,
Bijan.

Received on Tuesday, 7 August 2007 23:06:38 UTC