[oslc-core] Asset Management specification finalization
John Arwe
johnarwe at us.ibm.com
Mon Apr 9 14:19:04 EDT 2012
> Still, what's unclear to me is how much such Assets can be different
> from the rest of the resources that are modeled by other OSLC
> specifications.
FWIW, I treat "either/or" thinking in the XOR sense as an indicator
that the speaker is working under a "single inheritance" assumption.
It's a very common assumption for IT-centric folks to have.
Other assumptions, e.g. "multiple inheritance" are possible.
Often just explaining the difference opens (at least stretches) minds.
For the case of a spec like this, the trick is often trying to both
convey the widest possible scope of applicability (encourage wide re-use)
and also a specific example (for new readers primarily). The reason it's
tricky is because people read things differently: some read the specific
example to be limiting, rather than exemplary, which works counter to
the authors' "encourage wide re-use" goal.
> For instance, if a tool implementor, say a bug tracking system vendor,
> didn't read about OSLC-CM, and they discover OSLC Assets, then they may
> choose to implement it... which may be coherent with their business case
> (bug reports having value, whatever).
>
> But my own understanding is that being compliant with OSLC-CM would be a
> better priority for them.
OSLC-familiar folks might call it "usually a better fit".
But bottom line, if the vocabulary does the job for your purpose, and
your implementation uses the vocabulary within any constraints that the
vocabulary imposes (which are often quite weak, being conveyed in
natural language), who am I (who is anyone) to criticize its use?
> Now... maybe a tool can implement both OSLC-CM and OSLC Assets at the
> same time, whenever a particular bug report can both have a value and a
> priority, thanks to the inherent extensibility of RDF.
Right - multiple inheritance model. Allowing this should be at least
an informal goal of our specs, IMO; i.e., we should be Very Reluctant
to deliberately prevent an implementation from simultaneously implementing
all specs at once.
I often talk about the single/multiple inheritance question ala the
open/closed world question; the former being a specific example of
the latter (there are others, like reference targets). Not sure if
doing so gets anyone's hackles up.
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120409/4531f05c/attachment-0003.html>
More information about the Oslc-Core
mailing list