[oslc-core] Comments on Core Draft

[Dave]

Hi Ian,

Thanks for the additional comments. I've responded inline below and
added a couple of issues to the issue tracking page as a result.


On Mon, Mar 8, 2010 at 11:48 AM, Ian Green1 <ian.green at uk.ibm.com> wrote:
> In the glossary, the definition of resource is the http definition of
> resource, whereas the use of that word elsewhere in the draft also
> includes use of the word in the RDF sense - an abstract thing identified
> by a URI. I wonder if there would be some value in making a distinction here.

I guess I don't understand the value of that distinction in the spec.


> In several places the draft refers to a String property containing  the
> QName of the property.  This should be rdf:resource="uri of the property".
> reflecting the fact that QName is an XML concept not an RDF concept.

This is captured, along with other problem with the way the spec uses
QName, in the issues page.


> On resource shape:
>        - I don't understand oslc:RdfTypeTest.  where can i find some
> explanation.  Is this duck typing?  By that I mean that a resource can be
> inferred to have some rdf:type, provided that it contains all of the OSLC
> Properties declared in a given RdfTypeTest resource.

Yes. As I understand the Resource Shape model (based on Tack's work),
it is duck typing.


>        - "QName of type defined by this type-test " should read
> rdf:resource of the type-test (a URI Reference).

That is acknowledged and on the issues page.


>        - what is the role of rdf:type on a ResourceShape resource?  is
> this always http://open-services.net/xmlns/oslc#ResourceShape?

Resource Shape is itself an OSLC Defined Resource and so has a rdf:type.


>        - why is there no rdf:about for a ResourceShape?

Because of my shortcomings as an RDF/XML generator. I'll fix that.


> On json reporesentations:
>
>        - why isn't OSLC adopting existing JSON representation of RDF?  we
> seem to be inventing?
>        - qname doesn't mean anything unless there is a mechanism to
> resolve the prefix.  the json representation doesn't seem to address this.
>  The talis representation uses the full URI which at least avoids the
> needs to deal with prefix mechanism, although the resulting json may be
> harder for humans to read.

I think the JSON representation we used in some of the v1 specs is
good enough, nice and concise, and don't see the need to switch to
something else.

The QName problem you mention is on the issues page now.

Thanks,
- Dave