Olivier, Thx for the comments. I agree to all except the comment on discovery. The Shape resource was introduced to enable reporting scenarios, e.g. driving a generic query builder. Then other uses were identifier, e.g. creation of resources.
Each domain spec could provide standard Shape resources. This just makes the natural language spec more machine-understandable. Implementations that support additional properties would have to extend those. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube From: Olivier Berger <[email protected]> To: [email protected] Date: 05/27/2010 09:39 AM Subject: Re: [oslc-core] Some Topics for Discussion Today Sent by: [email protected] Hi. Le mercredi 26 mai 2010 à 08:59 -0400, Arthur Ryman a écrit : > 1. I've been digging deeper into OWL and there does appear to be a way to > express the kind of information we are putting in our Shape resources, > e.g. cardinality. The OWL way is somewhat more complex - it involves class > restrictions. Our Shape approach is easier for clients to handle. I think > we should at least describe the semantics of Shape in terms of OWL so we > are compatible. We may be able to regard Shape as a simplified form for > the equivalent OWL. > +1 Even if OWL is more complex, it is a widely used standard (I guess) at least in the Semantic Web communities (maybe not in ALM implementors communities ?)... so we may be having some kind of disclaimers above Shapes specs like : "ok, fellows, if you know OWL already, skip this and come back only when you'll try to implement consumers : the real truth about OSLC is next chapter " ;-) Again, as Shapes look to me very much like reinventing some wheel standardized elsewhere, I think it is very much important to not so much tighten the rest of OSLC to it (at least in the presentation of the specs). OSLC is great as it tries and propose a reference standard for ALM interoperability. I think learning OSLC should be quite straightforward (at least for the mandatory domain-related aspects), for fear to see it somehow dismissed by the Shapes introduction (for OWL addicts) and it's added complexity (meta / reification discussions, etc. when one only want to know how to spell "bug status" in OSLC), while the important thing is the rest of the standard : how to standardize the common properties of resources exchanged by tools. Real standardization for common properties and wider adoption looks more important to me than discovery of resources, for the time being. Enough ranting ;) Best regards, -- Olivier BERGER <[email protected]> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
