[oslc-core] Resource value-type name adjustments and examples

[Dave]

(apologies for the HTML mail, but I needed some quick formatting...)

Following up on our discussion of the resource value types, here is my
proposal for better value-type names and an example for each.

   Resource              -> Resource Reference (aka URI Reference)
   Inline Resource       -> Inline Resource Reference (what's the RDF
terminology for this?)
   Local Resource        -> Local Resource Reference (aka Blank Node
reference)
   Inline Local Resource -> Local Resource (aka Blank Node)

I believe these are more clear to those with an without RDF knowledge and do
not conflate value-type with representation. Here's a detailed description
of each and examples.

*Resource Reference (aka URI Reference)*

This value-type is a link from within a source resource to a target
resource. Use this when you need a simple link and you do not need to
annotate the link with property values. For example, here is a property
"oslc_blog:attachment" that you might find inside a blog entry, it links to
a resource that is "attached" to the blog entry:

  <oslc_blog:attachment rdf:resource="http://example.com/attachments/2" />

*Inlined Resource Reference (aka ???)*

This value-type  is a link from within a source resource to a target
resource, but also provides some property values of the target resource
inlined into the source resource. Use this value-type when you need a simple
link, but you would also like to offer some summary information in the
resource being linked to.

For example, here is a property "oslc_blog:attachment" that you might find
inside a blog entry, it links to a resource that is "attached" to the blog
entry and offers some summary information about the attachment which may
duplicate property-values found in the target resource.

  <!-- Inlined Resource Reference: a link with properties of target inlined
-->
  <oslc_blog:attachment>
     <oslc_blog:Attachment  rdf:about="http://example.com/attachments/2">
           <dcterms:title>Really big MS Word document</dcterms:title>
           <oslc_blog:attachmentMedia rdf:resource="
http://example.com/uploads/5/big.doc" />
     </oslc_blog:Attachment>
  </oslc_blog:attachment>

*Local Resource (aka Blank Node)*

This value-type is a "local resource" that  exists only inside the source
resource and is optionally identified by an anchor ID so that it may be
referred to via a Local Resource Reference. Use this when you need a link to
a target resource and you need to annotate that link with property values.

For example, here is a property-value that is a link to an attachment that
is annotated with property-values, i.e. property values that are about the
link itself.

  <!-- Local Resource: a link with property-values -->
  <oslc_blog:attached>
     <oslc_blog:Attached rdf:nodeID="attachment0">

 <oslc_blog:attachmentApprovedDate>2010-10-10T12:00:00-05:00</oslc_blog:attachmentApprovedDate>

 <oslc_blog:attachmentPublishedDate>2010-10-10T12:47:13-05:00</oslc_blog:attachmentPublishedDate
>
        <oslc_blog:attachment rdf:resource="http://example.com/attachments/2"
/>
     </oslc_blog:Attached>
  </oslc_blog:attached>

*Local Resource Reference (aka Blank Node Reference)*

This value-type is a link from a source resource to "local resource" that
exists only inside of the source resource. Use this when you want to link to
an Local Resource.

For example, here is a property-value that is a link to the Local Resource
value above:

  <!-- Local Resource References: links to Local Resource -->
  <oslc_blog:publishedAttachment rdf:nodeID="attachment0" />
  <oslc_blog:approvedAttachment rdf:nodeID="attachment0" />

*Does this stuff validate?*

Here's a link to an example that shows all of the above forms with RDF
triples, graph, etc. -> http://goo.gl/y4r1

I've probably got some things wrong so please review these and let me know
what you think.

Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100617/ca2a43d9/attachment-0003.html>