[oslc-core] Comment on ResourceShape resources

Dave Steinberg davidms at ca.ibm.com
Wed May 26 10:35:24 EDT 2010


Hi all,

First off, apologies for barging into the conversation.  I haven't been
involved in this group at all, but I've just been digging into Core spec
draft over the past few days and I was most puzzled by this particular
issue (and, really, resource shapes in general).  So, I thought I'd add my
two cents in the hopes that someone might find it helpful.

I definitely agree with Ian's comments about rdf:type being inappropriate
there, but I'm not sure about the suggestion to use rdf:predicate instead.
rdf:predicate is part of RDF's reification vocabulary, and its meaning in
that context is very different from what you're attempting to convey here.
For those who don't know, reification provides the ability to use RDF
statements to describe other statements.  The vocabulary includes the type
rdf:Statement and the properties rdf:subject, rdf:predicate, and
rdf:object.  For example, consider the following statement:

  a:service-provider dc:title "Blogging Service" .

It can be fully described by the following four statements:

  b:stmt rdf:type      rdf:Statement .
  b:stmt rdf:subject   a:service-provider .
  b:stmt rdf:predicate dc:title .
  b:stmt rdf:object    "Blogging Service" .

The effect of this is to introduce another node into the RDF graph
representing the statement and identifiable, itself, by a URI.  Note that
the four reification statements are not actually equivalent to the
statement they describe.

One important thing to notice about the reification statements is that the
subjects of them are all a statement.  Indeed, RDF Schema declares that
rdf:Statement is the domain of rdf:subject, rdf:predicate, and rdf:object.
This allows an RDFS-aware system to infer that the subject of any
rdf:predicate statement (such as the oslc:Property blank node in the
proposal below) is an rdf:Statement.  So in this proposal, we would be
saying that the blank node is both an oslc:Property and an rdf:Statement.
That's not strictly speaking wrong (pretty much nothing is in RDF), but
it's confusing and probably not what was intended, since an oslc:Property
appears to be some kind of "meta" concept, while an rdf:Statement is
actually a statement itself (an instance).

The RDFS equivalent of oslc:Property is (unsurprisingly) rdf:Property, but
there is no equivalent relationship to what you're trying to establish
here, since it is the URI of the rdf:Property itself that one uses in
writing the predicate of the statement.  So, if you wanted to follow that
lead, you would assign the URI http://purl.org/dc/terms#modified to the
oslc:Property, not leave it as a blank node, and make your shape statements
about the property itself.

But I'm not at all sure if that's really what you want to do.  It seems to
me that oslc:Property is intended to be something more like a
particle/attribute use in XML Schema (where the rdf:Property is analogous
to an element/attribute).  That is, it restricts how the property can be
used in a particular context.  If that's the case, I'm not sure what to
advise.  It does seem rather counter to the non-restrictive nature of RDF
as I understand it, but I'm definitely not an RDF expert and I can
certainly see the appeal of knowing what to expect.  At the very least, I
would encourage you to be clear about the concepts that resource shapes
introduce and not to reuse any vocabulary that would obscure those
concepts.

Cheers,
Dave

--
Dave Steinberg
Rational Software - IBM Toronto Lab
mailto:davidms at ca.ibm.com



                                                                                                            
  From:       Dave <snoopdave at gmail.com>                                                                    
                                                                                                            
  To:         oslc-core <oslc-core at open-services.net>                                                       
                                                                                                            
  Date:       05/26/2010 08:39 AM                                                                           
                                                                                                            
  Subject:    Re: [oslc-core] Comment on ResourceShape resources                                            
                                                                                                            
  Sent by:    oslc-core-bounces at open-services.net                                                           
                                                                                                            





Thanks for the excellent feedback Ian and I agree pdf:predicate seems
a much better fit here. I captured this issue on the issues page and
applied your suggested change to the Resource Shape resource
definition in appendix A.

So far we are using two notions from RDFS: the notion of a resource
definition, known as a class in the RDFS terminology, and
rdf:predicate. Perhaps I should add RDFS to the list of references at
the end of the spec.

- Dave


On Wed, May 19, 2010 at 8:02 AM, Ian Green1 <ian.green at uk.ibm.com> wrote:
> Hi all,
>
> the resource shape spec states that a Shape resource has zero-or-more
> oslc:Property's
>
>
> an oslc:Property has a (Resource, exactly-one) "rdf:type".
>
> This is a category error in the RDF model.  The rdf:type is the type of
> the instance, not the type of the RDF predicate which is modelling the
> oslc:Property.
>
> To be concrete - here is an example from the draft:
>
>
>
> <oslc:property>
>         <oslc:Property>
>             <oslc:name>modified</oslc:name>
>             <oslc:occurs>exactly-one</oslc:occurs>
>             <oslc:namespace rdf:resource="http://purl.org/dc/terms#" />
>             <rdf:type rdf:resource="http://purl.org/dc/terms#modified" />
>             <oslc:valueType rdf:resource="
> http://www.w3.org/2001/XMLSchema#dateTime" />
>         </oslc:Property>
>     </oslc:property>
>
> This asserts that there is a resource, of rdf:type oslc:Property AND also
> of rdf:type http://purl.org/dc/terms#modified
>
> We don't mean this.   We mean that the oslc:Property is indicated by an
> RDF predicate http://purl.org/dc/terms#modified.
>
> I suggest we change this part of the spec. to use rdf:predicate rather
> than rdf:type.  So the example becomes:
>
> <oslc:property>
>         <oslc:Property>
>             <oslc:name>modified</oslc:name>
>             <oslc:occurs>exactly-one</oslc:occurs>
>             <oslc:namespace rdf:resource="http://purl.org/dc/terms#" />
>             <rdf:predicate rdf:resource="
> http://purl.org/dc/terms#modified" />
>             <oslc:valueType rdf:resource="
> http://www.w3.org/2001/XMLSchema#dateTime" />
>         </oslc:Property>
>     </oslc:property>
>
>    -ian
>
> ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
> Chief Software Architect, Requirements Definition and Management
> IBM Rational
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
>
>
>
>
>
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net>
>

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100526/5cf67fc9/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100526/5cf67fc9/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100526/5cf67fc9/attachment-0001.gif>


More information about the Oslc-Core mailing list