[Oslc-pm] Skeleton specification draft

[John Arwe]

I stood up a skeleton for PM 1.0 based on a copy & tweak of Automation 
(since they were the next youngest wg, they represent state of the 
evolving art so as good a copy source as any) and linked it off of the wg 
home page [1].  It is NOT ready for anyone else to read or comment on yet, 
but just doing a skeleton forced some questions into the open, so trying 
to work those on the email list to the degree we can (below).  I also 
created a handful of other skeleton pages (Examples, etc) and linked those 
in.

1: Version number - should we use 1.0 or 2.0.  The recommendation from 
Core is that specs should be numbered with the first (major) version 
component being equal to the first (major) version component of the Core 
spec on which they are based, which would be 2.0; we had that discussion 
with Automation back in December/January.  I left all existing references 
on the wiki at 1.0, until the wg decides which to use. 
As a concrete proposal, I'll propose that we go with Core's 
recommendation.  There is a bit of explanatory text in the skeleton to 
address the "2.0 is logically 1.0" confusion that anyone coming later 
might have, i.e. (in red at the very top) "NOTE: This version of the 
specification has version 2.0 to indicate that it is an OSLC Core 2.0 
compliant specification. This specification is the initial version of an 
OSLC Performance Monitoring specification".  There is also a "previous 
version" link whose value is N/A.


2: Relationship labels - many existing specs refer to [2], which in turn 
refers to a "technique" in RDF called (hold your nose, newcomers) 
"reification" [3,4].  Reification appears to be on the outs in the W3C RDF 
working group.  We may want to discourage the practices for which Core 2.0 
recommends reification, especially if it turns out that our scenarios do 
not require it.
I propose we say that representations SHOULD NOT use reification.  [5] 
shows the usual text in existing specs based on Core 2.0 (from 
Automation).


3: We'll need some concrete examples of performance monitoring metrics 
that our scenarios need to capture before I can do anything about resource 
definition(s).


4: The CRTV proposal is out there, but I don't think it has been discussed 
within the working group.  We should add that to a future agenda, probably 
after all the scenarios we have on the radar have been discussed.  My 
guess is that an instance example would be useful for such a discussion, 
maybe we can get a volunteer to create one on the (newly skeletized) 
Examples page.


5: Core has discussed in the past changing how resource definitions could 
be coupled more loosely to domain specs, to enable changes (especially, 
additions) to vocabularies to occur without requiring the associated 
domain specification to go through a full new-version cycle.  My sense is 
that they are getting ready to really attempt it soon, perhaps as part of 
the Core 3.0 work (fair disclosure: I'm involved and nudging them in this 
direction, so OSLC vocabularies work more like other Linked Data 
vocabularies on the Web... Dublin Core et al.).  We might consider whether 
we should get ahead of that movement; I think we could potentially provide 
feedback on what works/does not if we were to try the separation.  Given 
the scenarios to date and timeline we've discussed, I think we are on the 
right side of the "simple enough that we could try something and re-do it 
if we don't like the result" tipping point.  Other domains with more 
resources would have a harder time of that.



I'll just reinforce in closing that there is little if any value in 
reading the skeleton spec as it stands.  It's still got broken links, some 
content referring to Automation, a not-useful single resource definition, 
etc.  I'll be sanding those off over time while some of the preceding 
questions are resolved in the working group.  E.g. the version answer will 
cause a non-trivial set of changes once links are considered.



[1] http://open-services.net/bin/view/Main/PerformanceMonitoringHome
[2] http://open-services.net/bin/view/Main/OslcCoreSpecAppendixLinks
[3] 
http://en.wikipedia.org/wiki/Reification_%28knowledge_representation%29 
very short, but more accessible than [4] IMO
[4] 
http://en.wikipedia.org/wiki/Reification_%28computer_science%29#Reification_on_Semantic_Web
[5] 
http://open-services.net/bin/view/Main/AutoSpecificationV2?sortcol=table;up=#Labels_for_Relationships

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-pm_open-services.net/attachments/20120430/302061fc/attachment-0003.html>