Re: First crack at profiles in primer

On Apr 12, 2008, at 11:07 AM, Ivan Herman wrote:

> Hi Bijan,
>
> I was trying to find a good reason to shoot you, but I did not find  
> any:-( Sigh...:-)

I must be losing my touch...

> Seriously, I find the text really good as a start. Deep bow towards  
> Manchester...

Thanks!

> I was not sure how you wanted this text to evolve. I first tried to  
> use the {{Review}} macro but it seems that the style did not work  
> for this (why?)

I think the style isn't site wide. Sandro, I think having both EdNote  
and Review being site wide would be a good idea.

> so I was not sure how to do it. I ended up writing all my comments  
> in this mail.... I hope that is fine with you.

Yep.

> ---- Introduction ----
>
> (I am not sure how to handle that, actually): with this numbering  
> scheme we have now, when I use the word 'OWL', do I mean 'OWL in  
> general, both OWL 1 or OWL 2', or do I mean OWL 1?

I generally mean OWL 2 DL. This is just what happens, not policy. In  
the primer, we've not determined any policy yet.

> I tend to think now in terms of the former, but it is not 100%  
> clear what you mean in the text (you specifically talk about OWL 1  
> in the last section). It may be worth emphasizing that what you say  
> about Full/DL is valid both for OWL 1 and OWL 2, ie that OWL 1 has  
> adopted this fundamental "cut", and OWL 2 has adopted it, too.

My belief, in general, is that OWL 2 will replace OWL 1, at least  
conceptually. So, in the primer, I try to localize all the backward  
looking discussion. In the OWL 1 section, OWL DL and Full are  
discussed as well.

> You say (about OWL Full): "One can still define classes using  
> restrictions or constraint properties with property chains, and so  
> on.".

That wasn't about OWL Full.

> Why 'still'? As OWL Full is unrestricted, there is no 'still', so  
> to say...

That sentence is rewritten.

> (b.t.w., I do not think that remarks like "(subject to resource  
> constraints)" or "(modulo bugs in the implementation)." are  
> necessary, mainly if this text end up (as I think it should) as  
> part of an official document..., but that is a stylistic issue  
> only...)

When writing text that may possibly strike some advocates as making a  
case for a dialect that they do not like, I think it's probably a  
good idea to act prophylactically against some obvious talking/ 
complaint points. Plus, the former is, I think, a useful point for  
end users (the latter is merely prophylactic...a response to a point  
raised loudly in earlier discussions).

> ----- EL++ -----
>
> I know the role of SNOMED and NCI played for EL++, but I am not  
> sure that should be part of such a profile description. First of  
> all, most of the people will have no idea what these ontologies  
> are, and, secondly, it gives the wrong impression that we define a  
> profile for a particular branch of industry.

The point was to give an idea of the sorts of ontology EL++ is good  
for. I provided some additional characterization. We may want to  
replace the reference to the particular ontologies with the  
characterizations.

> My reading of EL++ is that some of the property characterization  
> ([inverse]functional, symmetric) are also missing.

I already mention that inverse is missing.

> I think they are also part of the 'key missing features' that you  
> began to write. (Well, your easy key may change the importance of  
> inverse functional properties in future, although I have no idea  
> whether those would fit into EL++).
>
> ----- OWL-R -----
>
> It is *really* not the way of shooting you:-),

You *know* you want to!

> but I do not understand what you mean by "all the OWL Fullish  
> features of RDFS"; but you say that yourself that it is not  
> helpful... If you mean reflection, well, at the moment, OWL-R does  
> not have that a.f.a.i.k. (that was the essence of the issue I had  
> on the axiomatic triples)... The only thing I see that may be  
> possible in OWL-R (well, OWL-R-Full, actually!) is the usage of the  
> same symbol for a data and object property. I may miss something...

I was riffing off some stuff Jeremy has said and probably botching it.

> Personally, I consider OWL-R (and at DL Lite, too, actually) as a  
> kind of a minimal set of extra ontology features that I can build  
> on top of RDFS, while keeping it still easy both to comprehend and  
> to implement.

Well, on top of RDFS DL or RDFS Full :)

> Ie, when you say "OWL-R is ideal for enriching RDF data", I think  
> it is not only a true statement but may be _the_ essential feature.

Good! Now if I only knew what I meant by that...

(Something like OWL-R isn't really intended for class expression  
inference.)

> Although I would add something like "..  with a set of minimal  
> ontological statements going beyond RDFS."
>
> Also, I also do not understand why the following is true:
>
> "Compared with DL Lite, OWL-R works better when you have already  
> massaged your data into RDF and are working with it as RDF."
>
> (I would not use the word 'massaged' here, b.t.w.) I could very  
> well imagine to (1) have my data in RDF (2) add a minimal set of  
> OWL statements to further characterize my data and... end up in DL  
> Lite.

That's certainly true.

> Ie, I do not see that as a differentiating feature from DL Lite.  
> Both are a simple extension that works very well on top of RDF data.

I was thinking that OWL-R works more naturally in ETL scenarios  
whereas DL Lite was designed to support federated query. But this may  
just be historical emphasis.

> I guess this still reflect a difficulty that I still have in making  
> a clear high level (ie, user level) distinction between the usage  
> of OWL-R and DL Lite. Maybe your remark in OWL-R saying "when the  
> data must be massaged by additional rules" is the strongest  
> distinction here... I am curious to hear Zhe's opinion.

Adding extra rules (e.g., DL Safe rules) to OWL-R doesn't change the  
complexity of inference; adding DL Safe rules (recursive ones for  
sure, at least) to DL-Lite does.

> I think both in the case of DL Lite and OWL-R it is worth  
> emphasizing somewhere that they scale very well with the amount of  
> data. (RDF or otherwise:-)

This is true of EL++ as well.

> B.t.w., you said for DL-Lite: "DL Lite restricts class axioms  
> asymmetrically, that is, you can use constructs as the subclass  
> that you cannot use as the superclass.". Isn't that statement  
> correct for OWL-R, too?

Yep, even moreso. But the steam, it ran out :)

> As for when you ran out of steam: I wonder whether this document  
> should talk about the OWL-R-DL and OWL-R-Full differentiation at  
> all. According to section 4.4 of the profile document in almost all  
> the cases these two coincide in practical use, so the difference  
> between the two is really only mathematical, so to say. We could  
> actually say that on the OWL-R level the distinction between OWL  
> Full and OWL DL is mostly gone, and that is it... But I may have a  
> technical misunderstanding here.

I don't have a good sense here.

> Finally, as for your comments below on what to do with the text: I  
> agree that it should not be part of the profile document. However,  
> I am not concerned to have this text (plus some examples) being  
> part of the primer; actually, on the contrary. The current primer  
> (that I really like, do not take me wrong!) may not be easy to read  
> for the constituency of possible OWL-R and DL-Lite users. Ie, it  
> would be fairly difficult for them to understand what they can and  
> cannot do if the only thing we offer is the current primer and the  
> profile spec.

Well, we can always scatter (hideable) comments throughout the  
primer. I.e., "This construct is unavailable in EL++".

> Although your idea to put it as a separate document: that is worth  
> considering... A separate primer for EL++, yet another for OWL-R?

Or make the current primer configurable a bit.

> If we had infinite manpower, that might be the best option... But  
> even if we do that, I would definitely prefer to keep this at the WG.

I'm not sure.

Cheers,
Bijan.

Received on Sunday, 13 April 2008 10:27:18 UTC