[oslc-core] "One last" change to OSLC Core representations

[Scott Bosworth]

I understand and agree with the sentiment expressed by Samit and echoed by
others here, but after having listened in on considerable debate on this
question, I don't see a real issue with what is specified in the Core -
actually, I think it is clear and astute.

The "truth" on what's required for OSLC implementations is learned by
looking at domain specs. The core has set the direction for RDF and has
made strong guidance for domain specs while recognizing that there are also
other useful representation formats. It's gone even further to recommend
RDF/XML, even though other RDF representation formats will ultimately
probably be fine, especially given the widespread adoption of open source
toolkits like Jena . The domain workgroups have recognized the point
offered by Samit and are readily adopting MUST statements re: RDF/XML. I'm
not aware of any coming domain specification that is not adopting this
stance. And I see no evidence of the problem Tack is suggesting. In
practice, this issue is not real even though I could see how it might be in
theory.

For the Core to unequivocally require a representation for every case, even
for those situations it can't predict or yet imagine seems pretty
unnecessary and heavy handed (and imho, maybe even a bit foolish). Our
attention should be on the domain specs when it comes to this question. We
should be especially interested when a domain specification does not follow
the core representation guidance (i.e. does not include a MUST for RDF
representations). That situation may indicate a scenario that we can learn
from or it may indicate arbitrary or unnecessary differences. The spec
process allows for and is in place for this kind of debate and decision
making.

Scott



oslc-core-bounces at open-services.net wrote on 07/26/2010 12:43:42 PM:

> From: Tack Tong <tacktong at ca.ibm.com>
> Core representations
>
> +1 for me on Andy's comment.
>
>
> I second Samit's concern that unless there is a representation used by
all
> providers, a client writing code would then have to write separate code
for
> each provider, which they could do without OSLC by using the native api
of
> the provider.
>
> Tack Tong


Scott Bosworth | IBM Rational CTO Team | bosworth at us.ibm.com | 919.486.2197
(w) | 919.244.3387(m) | 919.254.5271(f)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100726/5df0f498/attachment-0003.html>