Namespace for RD entities used in JORD export file http://rds.posccaesar.org/downloads/PCA-RDL.owl.zip is:
http://rds.posccaesar.org/2008/06/OWL/RDL#
JORD endpoint uses another namespace:
http://posccaesar.org/rdl/
The reason for that is unknown for me, and it adds difficulty to understanding of RD. Also this inconsistency clearly violates requirements of draft Part 9.
I'm going to file a ticket in RDS support system to change a namespace in export file.
Is anyone using URIs in export file namespace? Are there any other reasons to keep separate namespace for exported data?
Namespace in JORD output file - need to change
Re: Namespace in JORD output file - need to change
Victor, did you send that ticket?
Re: Namespace in JORD output file - need to change
Yes, the ticket sits there for some time. As no one replied to this topic with any objections, I was planning to ask Lillian to implement this.
Re: Namespace in JORD output file - need to change
Actually,
There is data with different owners in the RDL.
We already found that "part 2 classes" should go under the dm namespace.
Classes typed-over from other standards (ASTM, DIN) should have their own namespaces.
In part 8 the # fragment identifier is preferred. So the output should be something like
http://posccaesar.org/rdl# not http://posccaesar.org/rdl/
I guess I could make a complete study and let there only one all-encompassing change of the IDs.
And a mapping table for those who want to update it on their end.
*edit*
Not to forget all the classes that are already standardized. They have the namespace(with RDL in from of the unique number) See http://standards.iso.org/iso/15926/-4
There is data with different owners in the RDL.
We already found that "part 2 classes" should go under the dm namespace.
Classes typed-over from other standards (ASTM, DIN) should have their own namespaces.
In part 8 the # fragment identifier is preferred. So the output should be something like
http://posccaesar.org/rdl# not http://posccaesar.org/rdl/
I guess I could make a complete study and let there only one all-encompassing change of the IDs.
And a mapping table for those who want to update it on their end.
*edit*
Not to forget all the classes that are already standardized. They have the namespace
Code: Select all
p4: http://standards.tc184-sc4.org/iso/15926/tech/reference-data#
Re: Namespace in JORD output file - need to change
Here I see a problem. People often refer to http://www.w3.org/TR/cooluris/ as a definitive resource on URIs. Description of 303 and Hash approaches is quite clear there. And choice is very well described:In part 8 the # fragment identifier is preferred. So the output should be something like
http://posccaesar.org/rdl# not http://posccaesar.org/rdl/
If implementation follows the rules described in this document, requirement in Part 8 is rather a mistake.The hash URIs have the advantage of reducing the number of necessary HTTP round-trips, which in turn reduces access latency. A family of URIs can share the same non-hash part. The descriptions of http://www.example.com/about#exampleinc, http://www.example.com/about#alice, and http://www.example.com/about#bob are retrieved with a single request to http://www.example.com/about. However this approach has a downside. A client interested only in #product123 will inadvertently load the data for all other resources as well, because they are in the same file. 303 URIs, on the other hand, are very flexible because the redirection target can be configured separately for each resource. There could be one describing document for each resource, or one large document for all of them, or any combination in between. It is also possible to change the policy later on.
Part 4 (and part 6) standardized reference data items are a big problem, I agree. As I see the situation, if ISO is unable to offer soon even the basic solution we are discussing in other topic - JORD will be obliged to mirror all entities in its own namespace, and wait till ISO is ready.
Re: Namespace in JORD output file - need to change
This is an example of a domain, there are no URIs.
All sources agree that hash URI should return a page with only part of it referencing one resource.
Look at http://www.w3.org/wiki/HashVsSlash
As described in the document referenced in my previous comment, hash and fragment after hash is really stripped from http query by a browser compliant with HTTP standard.
Therefore attempts to reach
http://rds.posccaesar.org/2008/02/OWL/I ... ractObject
or
http://rds.posccaesar.org/2008/02/OWL/I ... 3#Activity
should return whole page http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003 !
Using hash URIs in RDL is impossible, I believe.
All sources agree that hash URI should return a page with only part of it referencing one resource.
Look at http://www.w3.org/wiki/HashVsSlash
As described in the document referenced in my previous comment, hash and fragment after hash is really stripped from http query by a browser compliant with HTTP standard.
and read further.When a client wants to retrieve a hash URI, then the HTTP protocol requires the fragment part to be stripped off before requesting the URI from the server. This means a URI that includes a hash cannot be retrieved directly
Therefore attempts to reach
http://rds.posccaesar.org/2008/02/OWL/I ... ractObject
or
http://rds.posccaesar.org/2008/02/OWL/I ... 3#Activity
should return whole page http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003 !
Using hash URIs in RDL is impossible, I believe.