[oslc-Metrics] Discussion: Use of rdf:ID to give URIs to parts of resources

[Arthur Ryman]

Workgroup members,

While reviewing the spec, I found a problem in the definition Fact Tables 
[1]. Fact Tables have columns and cells. Each cell explicitly refers to 
the column that it belongs to  using a local resource identifier aka a 
blank node defined using the rdf:nodeID attribute. This reference is 
needed because the order of elements is not significant in RDF/XML like it 
is in HTML or normal XML.

The problem is that a Fact Table could get long and that when the server 
returns it, the result may have to be split into several pages. However, 
the meaning of a blank node is scoped to a document. Therefore there is no 
way to refer to the column defined in page 1 from the cell defined in page 
2.

The fix is very simple. Instead of using blank nodes, we use 
resource-relative URIs which are defined by rdf:ID (instead of 
rdf:nodeID). This gives the Columns in a Fact Table stable URIs which can 
be referenced from any other resource. The URIs are hash URIs, i.e. they 
use fragment identifiers. For example, suppose a Fact Table was contained 
in a query response, 
http://braintwistors.example.com/taskphocus/Query/3365. [2] The column 
URIs in that example would become:

http://braintwistors.example.com/taskphocus/Query/3365#d1
http://braintwistors.example.com/taskphocus/Query/3365#m1

When refering to these URIs from another document, the full URI can be 
used, or you can use the xml:base attribute to identify the resource that 
the Columns are defined in, and use just the relative #m1 and #m2 URIs.

Since the above is a problem in the spec, I am going to correct. Please 
adjust your implementations.

This raises the question of whether we should allow rdf:ID on any element 
since this gives us a useless way to refer to parts of a larger resource. 
This is very useful for HTML documents and might also be useful for EMS. 
For example, it might be useful to refer to a specific assumption 
contained in a Scenario resource, a specific prediction in an Estmate, or 
a specific observation in a Measurement .

Does anyone see any problem in allowing these fragment URIs to be defined? 
I'll add this topic to a future telecon.

[1] http://open-services.net/bin/view/Main/MetricsEmsFactTable
[2] 
http://open-services.net/bin/view/Main/MetricsEMS10PrimerMonitoringAndControllingExecution#Listing_of_Defect_Arrival_Rate_M

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE

Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063