Dear all, These was a long email discussion about dereferenceable IRIs for the Reference Data Library. Below a summary.

Feel free to pick up the discussion and continue here.

Onno Paap wrote:

Dear Paul,

We have a challenge that we would like your help (as WG3 convener) for. It is about namespaces.

The requirement is that namespaces must be dereferenceable. This means, if you enter a namespace+ID in a web browser, something about that is returned. E.g. a label.

We have used many namespaces in our standards, but none of them are dereferenceable. We want to change that.In the same process we want to make them as short as possible.

Another requirement is that namespaces must never change. Note that if a namespace carries a company or association name, it is not trusted to never change. Because it is out of community control. Except if ISO of course.

From these two requirements I came up with two solutions:

1. Take a namespace that is not related to a company or association in its name, and put that into our standards. Put up a web server by that domain name for the dereferencing or redirecting.

2. Take a namespace that is related to ISO.ORG on the ISO server,.and make it dereferenceable by installing redirections to active online endpoints.

Solution 1:We tried this solution and failed. We created domain rdlfacade.org and proposed that for namespaces in ISO 15926-8.The WG3 convener in that time Gerry Radack and the SC4 secretary Brian Stanton refused it. They made us use a non-dereferenceable iso.org namespace.

..... Surely, Part 9 should not define the URIs for the resources.First, it would be wise if the URI plan were made by an SC4 resolution, since it affects many of the parts of ISO 15926, and possibly other SC4 standards.Second, it seems to me that Part 8 should standardize the URIs for the things Part 8 defines, and similarly Part 7.If nothing defines the URIs for the RDL, that is because no standard defines the RDL.I completely agree with Hans that the standard IRIs should begin http://standards.iso.org/iso/15926/. After the solidus, however, I would suggest the syntax ISOCS standardized for URNs, that is, the next level is spelled “tech”, because the alternatives at that level are defined by ISOCS as “part” and “edition” and other such stuff that is about URIs for the publications. The idea of “tech” is that everything after “tech/” is up to the managing SC. I would also point out that they did all of that formally upon request from TC184/SC4 and TC68 (Banking/Finance). The reference publication is IETF RFC 5141 (http://www.rfc-editor.org/info/rfc5141). We substitute http://standards.iso.orgfor urn:iso:std: and the rest is pretty much the same, with solidus instead of colon. I’m pretty sure this is what ISOCS recommends, but there is probably some current ISO directive for this. This was briefly a big issue for ISO 10303-28. The ISOCS author of the syntax was Holger Apel, and it was negotiated with several interested TCs.-Ed

Another small note:parts 1 through 7 are computer language agnostic.So actually all namespaces should belong in part 8 and higher..RDF/OWL is not mentioned in the 1-7 parts.Suppose we completely move to a new computer standard, only part 8 and higher are changed.

Robin Benjamins wrote:

I am going to add my two cents…

The URI subject is a real sore point with me.

First off, I fully support Onno's request. That request underlies the weakness of URIs when what is being identified can potentially "move". The need for reliable and immutable RDL identifiers is paramount. Resolvability is secondary and is also highly desired but should not weaken or put at risk the reliability of identification.

URIs are political and emotional and is the reason why I am so disappointed in them. URIs contain meaning, which is their weakness when it is pointing to items that can move in various ways such as ownership or status or physical location, etc. (And DNS is not an answer either.) URIs for RDL items are problematic. Unless we can agree on a non-polictical, tribal or emotional namespaces scheme, I do not think will come to any solution. And a central master registry that can redirect would break the peer to peer model of ISO 15926 and put a central point of failure into the mix.

Since getting really useful URIs will take incredible superhuman cooperation, I have instead opted to achieve resolvability via implementation alternatives. General idea is that every single RDL item may end up with several namespaces over its lifetime so we need to simply treat the URI of the moment as a variable and manage mapping between past URIs that may be encode in configurations across the industry landscape. Not sure how to do that, that is what I expect smart people to figure out.

Enough jaw flapping for now…

David Leal wrote:

Dear Onno,

The objection to rdlfacade.org was from several national standards bodies including the BSI, not just Gerry Radack and Brian Stanton. It was an issue of principal - the content of an international standard should be hosted by ISO or by a maintenance agency approved by ISO. It was not acceptable to have the content controlled by an organization without formal accountability.

For ISO 15926 reference data, the response to an HTTP GET on the URI of a reference data item been not been standardised. The next step will be to define the response that is required by industry. There may be many different requirements. This is new ground for the standardization community, and therefore I suggest that an industry standard be created first, which can then be harvested by ISO.

- DBpedia approach: Get a human readable page and an OWL fragment at the namespace location based on the requested subject. Example: OSLO resource http://dbpedia.org/resource/Oslo note that uri redirects to /page/Oslo

You really love extraordinarily long URIs. The MMT has decided to keep URIs as short as possible. Long URIs simply occupy too much disk space (and makes SPARQL queries next to unreadable).

http://standards.iso.org/15926/rdl/ tells us that iso.org has a subdomain 'standards', and in that subdomain the standard 15926. Inside that 15926 standard we find the RDL ontology.http://standards.iso.org/15926/dm/ tells us that iso.org has a subdomain 'standards', and in that subdomain the standard 15926. Inside that 15926 standard we find the data model ontology.

The version information is in the ontology header. We don't need more bureaucracy.

Regards,Hans

David Leal wrote:

Dear Hans,

Any organization is free to set up a SPARQL endpoint which provides triples that have been standardized by ISO. ISO should not choose one particular SPARQL endpoint.

For an ISO 15926 reference data items in general, a redirect to a SPARQL endpoint is not necessarily the required response. I am sure that ISO could create a server that produced an HTML page for each reference data item, but we would have to tell ISO what it would contain.

Best regards,David

Victor Agroskin wrote:

Dear David,

Probable PCA can make a demo in this style by tweaking their dereferencing service. But it will not demonstrate much except technical capabilities of some software.

The real problem is that we do not know now - _what_ to return for such requests.

> For an ISO 15926 reference data items in general, a redirect to a SPARQL endpoint is not> necessarily the required response. I am sure that ISO could create a server that produced> an HTML page for each reference data item, but we would have to tell ISO what it would contain.

I can not agree with that, for the reasons given below. The demo should really demonstrate an access to the endpoint servicing some triple-store. And the problem is that there is none.

> Any organization is free to set up a SPARQL endpoint which provides triples that have> been standardized by ISO. ISO should not choose one particular SPARQL endpoint.

Of course, but where are these? Only Part 8 and Part 3 reference data are now issued as triples in "official" attachments to the standard. Part 4 and Part 6 reference data are issued in a table form only, as well as I know. Table transformation to RDF is required, current transformation of P4 is "unofficial", incomplete and not compliant to P2.

And this is an important issue for namespace problem. As I've deduced from the questionnaire recently distributed to WG3 members, ISO still plans to issue reference data (Part 4 primarily) as tables. No plans to use RDF, am I right?

The best option will be if ISO changes this attitude, and start publishing RDF as primary form of RD standardisation. Of course ISO will never manage itself a complex RDL IT infrastructure, it can be put upon maintenance organization.

If not - it will be better in this situation for ISO to refrain from standardising URIs, and issue only some kinds of UUIDs for standardised entities. Then industry will be able to maintain federated façade infrastructure using these UUIDs and deciding on namespaces completely independently.

What we really need a demonstration of - is the demonstration of possibility for cooperation between ISO and maintenance organisation. We are really sure of technical capabilities!

David Leal wrote:

Dear Victor,

>As I've deduced from the questionnaire recently distributed to WG3 members, ISO still plans to issue reference data (Part 4 primarily) as tables. No plans to use RDF, am I right?

ISO is us, so we can decide. At present there are different approaches to the representation of ISO 15926 reference data as triples. I think that we should let industry implementation experience lead to either:1) consensus on the best approach; or2) consensus that different approaches each have benefits and should exist side by side.

Until we get there, I do not think we can rush to standardization. This discussion is independent of the discussion on URIs. These just need to be unique and make it clear that ISO is the owning organization. The current URI structure based on the ISO URN scheme seems to work.

Best regards,David

Onno Paap wrote:

To David: if the convener (or consensus) comes up with the conclusion that dereferenceable URIs are impossible, then I would like to check out your solution. I'm not there yet. I still believe.

To Håvard: We have discussed the hash URI (#) and came to the conclusion it should be changed in part 8 to slash (/) URIs. The best explanation why is in this document http://www.w3.org/TR/cooluris/ which I suggest everybody should read first, before we start re-discussing it over.Change in part 8 is ok <we came to that conclusion yesterday> if the POSC Caesar TAB puts a change procedure in place.

Here are examples how dereferencing could work for us, if we decide to use the ISO server (we never use enough examples).

The page on the ISO server http://standards.iso.org/iso/15926/rdl redirects all to the POSC Caesar endpoint, preserving the ID of the object. In the POSC Caesar database there is an intelligent mapping to either RDL-resident classes or externally located online dereferenceable linked data. A serious example of externally trusted online linked data may be a Russian RDL.

Ed barkmeyer wrote:

All,

The fact of life since about 2005 is that a URI that is not a link on a Web page is probably NOT a locator, and you do need some server that knows about URIs with the given “URL” prefix. That is why XML Schema distinguishes the schema identifier from the schemaLocation. All that the current Internet doctrine requires is that there is some such server, somewhere on the Internet.

We need to sort out three ideas here. One is the form of URIs for ISO standard RDL elements. One is the form of URIs for extended RDLs developed by consortia and not standardized in ISO. And the last is URIs for company data elements maintained by Façades. In sorting out these ideas, it is important to distinguish URIs that are locators from URIs that are only identifiers. The ISO URIs should be locators, the URIs for extended RDLs may or may not be locators, the Façade URIs are not locators.

What David Leal suggests is certainly consistent with the views of other SC4 projects, and other such projects in other ISO TCs. For an extensible repository that has the force of an international standard (or TS), the TC or SC creates a formal URI pattern based on iso.org, according to ISOCS directives (or recommended practice), and appoints a “registration authority” (RA) whose job is to maintain the repository and the supporting servers. The content of the authoritative repository serves as the current text of that part of the international standard. That is what SC4/WG2 is doing with PLIB and eOTD (but they don’t use URIs, they rolled their own). And I agree that that is what should be done for the ISO standard RDL.

David and Håvard used what I understand to be the recommend ISOCS and TC184/SC4 prefix for constructing identifiers. Further, it is my understanding that ISOCS will maintain links at standard.iso.org to established registration authorities for ISO standards. So, Håvard’s statement:

I have two problems with Håvard’s proposed form:(1) I would strongly discourage a reference to the “edition” of the standard, which refers to a publication. The whole point of a registration authority is to make new “editions” as needed, according to a specified process for adding and modifying entries, without the ISO adoption and publication process.(2) I see no reason to spell RDL “reference-data/data-model” in the standard prefix. “rdl” or “rdl/dm” is a lot more likely to be error-free when typed, and not to grow gratis line breaks when it is cut and pasted. There will be no ignorant users of .../15926/-8/tech/<anything>. The terms can be cryptic. (In the ITU, the form would be itu.org/oid/1.0.15926.8.6...)

The conventions Håvard cites for how the sharp/hash is handled were intended for browsers and web-page links. By that convention, the URI is pure locator, and the browser uses the local part (after the hash) to display the proper part of the returned resource. Returning the database as the HTTP dereference of an RDF URI may be just what is expected from the registration authority for the RDL. But it is desirable that such a repository also exhibits a query interface for accessing individual items, and in that case some part of the identifier, e.g., the part beyond the hash, is used for the query. If SC4 (WG3) creates an ISO registration authority for the standard RDL, we will need to specify the intended behaviors. (Whether the RA server for ISO 639 at the U.S. Library of Congress – loc.gov – is the pattern we want for RDLs is questionable. Their database is a few hundred records.)

What the URIs for extended or specialized RDLs, e.g., as further developed by JORD or PCA or API or ..., might look like is out of our scope. They will not begin “standards.iso.org”, and the rest of their syntax will be defined by the developing body. If, however, such a server is able to “dereference” the ISO RDL URIs as well as the consortium URIs, the interface will necessarily involve a query approach or a Linked Open Data approach, instead of interpreting the URI as a URL for the whole resource.

Returning the database is NOT the desired behavior of a Façade, where most of the content is a company-owned data collection and the URIs are invented by the thousands to refer to individual elements of that collection. These URIs are mostly prefixed by a company-specific domain name, except those that are references to RDL terms. These URIs are not locators at all; they are ONLY identifiers. In the course of the plant construction process: engineer-build-operate, the data will change hands, and the façade that maintains it may be different from the façade that supported its creation. What is wanted for a Façade is support of a query for a URI, not the ability to dereference it by browser conventions. One can think of a SPARQL server, or a Linked Open Data protocol, for accessing such a URI.

In the land of Façades, nothing prevents the existence of multiple supporting servers, as long as they are somehow synchronized. Nothing prevents the existence of repositories that extend the standard in non-standard ways and provide both standard RDL and extended RDL. Nothing prevents the implementers of supporting servers from communicating with each other to find the current live resource for an RDL URI. This is distinct from using an Internet Domain Name Server for the purpose. A Façade that maintains one RDL may know how to find other Façades that maintain other RDLs or further extensions of the one it maintains. Such façades would be “RDL URI Name Servers” that communicate with each other using (adapted) DNS protocols. Indeed, something very like this is envisaged in the scope of Part 9.

So we need to sort out three concerns:- whether we will have a registration authority for the ISO RDL, thus enabling HTTP de-reference for the ISO URIs- what the form of the ISO URIs will be (SC4 can still agree to use the ISO prefix, whether there is an RA or not)- the use of the URIs as identifiers that will be mixed with many other URIs that are locally “dereferenced” by other servers, using non-HTTP protocols (query, LOD)

I strongly agree that we should use an ISO prefix for the standard RDL elements, and in the form David and Håvard suggested (more or less). I do NOT think we should make HTTP dereference a primary concern, UNLESS we are serious about creating a registration authority. (And, OBTW, who will tie the bell around that cat’s neck, and what specification will govern his behaviour?)

-Ed

Hans Teijgeler wrote:

Ed,

For the most I agree with your dissertation. But I would like to make some things very clear.

It has always be my understanding that the RDL data will, once, be stored in a standard façade with standard declarations and standard templates. In the end ALL data are reference data, the RDL data happen to be universal enough to be "the" reference data.

Right now this is not the case for a very simple reason: Part 4 was, with Part 2, "the first in the valley" and something had to be pioneered. There were no Parts 7, 8, 9, 10.Now we are close to get our ducks in a row we should reconsider the data structure of the RDL. These data must seamlessly fit in the fine granularity of the lifeyle data. HTTP blobs are useless for that.This RDL restructuring can also be used to remove its flaws, such as a better definition of instances of ClassOfIndirectProperty (as we found missing in the HEED Projet).

For the day-to-day work the data are in RDF format, but for definitional purposes templates are also represented in OWL format with restricted Properties. I have prepared a document in an attempt to describe the overall architecture. See http://www.15926.org/publications/gener ... /index.htm. It may be flabbergasting to some, but it is what is required.

Dereferencing to me is, ultimately, using SPARQL to translate an IRI to find the applicable triples and from those the applicable datatype properties (strings, numbers, Booleans), for use in applications. This also holds for the reference data, as I wrote today to David Leal:

>We need to sort out three ideas here. One is the form of URIs for ISO standard RDL elements.> One is the form of URIs for extended RDLs developed by consortia and not standardized in ISO.> And the last is URIs for company data elements maintained by Façades. In sorting out these ideas,> it is important to distinguish URIs that are locators from URIs that are only identifiers.> The ISO URIs should be locators, the URIs for extended RDLs may or may not be locators,> the Façade URIs are not locators.>> If we're indeed relying on Semantic Web architecture as envisioned by W3C and popularised in> http://www.w3.org/TR/cooluris/, answers to all these questions are rather straightforward.> All URIs should be identifiers and none of them should be locators (if we get rid of the> #-URIs, which are in between - they are identifiers and at the same time indicate location> in the page, but not the page itself).>> Dereferencing of identifier URI brings you to some location with a distinct URL. It is already> working for URI http://posccaesar.org/rdl/RDS327239 - brings you to URL> http://posccaesar.org/rdl/page/RDS327239 . It should work exactly in the same way for RD> items introduced by all parts of the standard.

There is only one problem - total absence of any ISO-approved data-model.owl file. What was produced by PCA is heavily criticized now by David (and many others) and whole project of "Part 12" was started to overcome this problem. The only representation we have to refer to data model is PCA - http://rds.posccaesar.org/2009/08/OWL/ISO-15926-4_2007 with all #-URIs in this namespace dereferenceable to this page.

> I have two problems with Håvard’s proposed form:>> (1) I would strongly discourage a reference to the “edition” of the standard,> which refers to a publication. The whole point of a registration authority is to make new> “editions” as needed, according to a specified process for adding and modifying entries,> without the ISO adoption and publication process.>> (2) I see no reason to spell RDL “reference-data/data-model” in the standard prefix.> “rdl” or “rdl/dm” is a lot more likely to be error-free when typed, and not to grow gratis> line breaks when it is cut and pasted. There will be no ignorant users of .../15926/-8/tech/<anything>.> The terms can be cryptic. (In the ITU, the form would be itu.org/oid/1.0.15926.8.6...)

Colleagues, this discussion is departing from the technical question Onno had asked. We've some parts of the standard approved with known revision schedules. There some URIs already standardised, and we'll be unable to get rid of them - once published, they are there for eternity, as W3C puts it.

Other parts are in certain stages of development. Some of them introduce their own URIs, so overall URI policy and the way to URI unification are obvious candidates for Roadmap document we are going to work on.

But whatever solution will be agreed - its realization will depend in the possibility to entrust administration control over one single sub-domain of iso.org to external entity capable to manage complex IT infrastructure for RDL. The moment it is resolved - this external entity will have plenty of work with existing P4 and P8 URIs.

Regards,Victor Agroskin

Ed Barkmeyer wrote:

Onno,

Read Section 3 of http://www.w3.org/TR/cooluris/. HTTP de-referencing of HTML bookmarks is not the most important use of RDL URIs. If I use the PCA link now, what I get back is an HTML page. As the cited cooluris document specifically says (in section 3 – URIs for things), there is a difference between the identifier for the web page about the class identified by the URI and the identifier for the class itself. The most important thing for RDF usage is having identifiers for the classes, not URIs for the descriptive web pages. The appliance that forces liquid thru the pipeline is an instance of RDL Class Pump, not an instance of “web page that describes the pump class”. For humans, assisted by browsers, you want a server like the Sparqler that accepts the URI for the class and locates the corresponding web page. Nothing does an HTTP de-reference of the class identifier: it does not refer to a web resource.

Further, your position assumes that the server at standards.iso.org is willing to redirect http://standards.iso.org/iso/15926/rdl/RDS327239 to posccaesar.org. The formal process for making that happen is not in place. I believe that it would be necessary to adopt a registration authority for http://standards.iso.org/iso/15926/tech/rdl by some formal action of SC4. Further, the rules by which that authority can add to or modify the RDL would have to be formally adopted as well. (One would have to ask Howard Mason, or someone who knows the ISO administrative rules for these things.) If WG3 wants to do this, there is a new work item in the offing (ask WG2).

We have to sort out what things we want to do, what we need to identify and what the syntax for URIs that identify those things should be. AND, we need to talk about what servers would support what kinds of URIs and how.

So, are we talking about how WG3 will identify RDL classes? Or what the web pages that describe RDL classes will be called and how those webpages will be accessed? I strongly believe those are two different ideas, and it seems to me that David and Håvard and others have also tried to say that.

> So, are we talking about how WG3 will identify RDL classes? Or what the web pages> that describe RDL classes will be called and how those webpages will be accessed?> I strongly believe those are two different ideas, and it seems to me that David and> Håvard and others have also tried to say that.

In my humble opinion, both answers are "NO".

We have to find an answer to a quite different question: what top-level administrative and legal options are available to facilitate transformation of RDL class identifiers to URLs of web pages that describe these classes.

Only based on this answer we can work out answers to your two questions, probable in different documents and by different groups of stakeholders.

For example, if there is no way to facilitate sub-domain forwarding, URIs will remain undereferenceable for foreseeable future and RDL maintainers can look for technical solutions (like the one David had suggested) completely independently of iso.org URI-URN discussions of people working on standard parts.

Ed Barkmeyer wrote:

All,

First, I should apologize for my first “dissertation”. My second email was probably more to the point. Viktor got it right. The issue here is how to get a consistent set of URIs for 15926 and its non-ISO extensions. But there is a difference between the ISO standardized URIs, which WG3 can legislate, and URIs for extensions, which we can’t. We don’t have to be concerned with the latter.

For once, I completely agree with Hans:

Dereferencing to me is, ultimately, using SPARQL to translate an IRI to find the applicable triples and from those the applicable datatype properties (strings, numbers, Booleans), for use in applications. This also holds for the reference data,

“My sentiments exactly.” Well, maybe not exactly, because I don’t care whether the server uses SPARQL or some other LOD protocol. The point is that one uses a purpose-built server to find the necessary properties and information associated with an IRI and return it in a useful form (read: RDF). And that applies to both the schema/ontology/”reference data”, as Hans says, and to the live industry data as well.

If Onno wants to associate a set of HTTP accessible HTML webpages with the class IRIs as well, it is a good thing, but not important. It is just something else that the RDL URI server will be able to find.

The point has also been raised that we have URIs in some adopted specifications that are a consequence of early pioneers in the valley (per Hans). It is easy to change those with Technical Corrigenda, if SC4 and WG3 come up with a standard naming policy with the next few months. There is NO commercial implementation of these specifications that depends on maintaining consistency with their URIs. But if we are lucky, what we are specifying NOW – Parts 7, 8 and 9 – will have industry usage, and at that point we will no longer be talking about changes to experimental software, but rather about changes to deployed industry information bases. Those URIs are forever. “The past is but prologue.”

-Ed

David Leal wrote:

First, Ed … please don't stop the dissertations, I learn a lot from them

Seems to me the big question is : Is real HTTP URI dereferencing a critical requirement, or not? I'm not talking about Hans definition of dereference, but the normal definition of the word (i.e. HTTP protocol).

My view is that it's probably best to forget the idea that ISO is going to support proper dereferencing of HTTP URIs. Perhaps I'm a pessimist, but after 5-10 years of banging my head against a wall - I do stop at some point.

If most people agree with that view, then the community has a decision to make … Is the formality of ISO standards, and their URIs, for RD items worth the trade-off of losing real HTTP URI dereference? If everyone agrees that SPARQL is sufficient for online access, then perhaps it is.

Perhaps we're an anomaly, but as long as there's a downloadable RDF/OWL representation of the RDL it does not matter that much if it's dereference-able via HTTP or not. I would not normally build a production application that depends on a server over which I have no control. Keeping a local cache or loose coupling to the RDL as annotation are safe ways to address that concern, and so that's what we'd likely do (and have done) for any critical application.

Cheers,David

Onno Paap wrote:

All,

Please don't think I'm asking for a grandiose plan, where ISO or SC4 has to staff-up a large group of reference data or model supporters.

If we decide to use a subdomain of iso.org the granular redirecting is done at the side of the industry, not ISO.Merely redirect a folder to a server. So, in effectThe address http://standards.iso.org/iso/15926/rdl redirects all traffic to http://posccaesar.org/rdl preserving the trailing ID. No more, no less. Technically, this is very simple to implement, e.g. a web server rewrite rule.The POSC Caesar server will take care of granular redirects, from dereferencing onto web page to redirecting to other LOD servers of trusted ontologies.

The grandiose plan exists, of course. Currently the load is with POSC Caesar. And they are already on the ball, luckily (thank you).

Ed's "DNS for RDLs" needs to be set up, that is true. But this is beside the point, of namespaces in ISO 15926 parts, of this discussion. We intend to test "DNS" solutions in our ISO 15926-9 team, and conclude with minimal standardization that seems required to be written in part 9, leaving technical solutions available for software companies.

David Price's question: are dereferenceable URIs (IRIs) required? I say yes, because people capable of writing Sparql queries are low in supply. We are talking about engineers (my company has 30,000 of them). They point and click. I agree, the click can invoke a query, but we have to decide where the query goes to find the data. A URL click on a spreadsheet, or one in augmented reality, should find the engineering data. And still work, after 10 years, when the RDL is supported by the son of POSC Caesar, but the ISO still exists.

Ed Barkmeyer wrote:

Onno,

I don’t understand this logic. If in the specification we say this is a dereferenceable URI, then people and tools will try to access this URI and get Error 404.If we say, this URI can be made dereferenceable by telling your local DNS to redirect the ISO URL to another URL, then we have to specify what that other URL is. And if that redirect is to be specified in a TS, why in tarnation are we not just specifying the real dereferenceable URI in the first place?

The reason why we want to specify an ISO URI is that we mean the URI to be the international standard term for the thing. How one finds a server that can interpret that URI into a resource containing information about the named thing, is an Implementors Forum kind of thing, and Part 9 will specify how to speak to that server. The function of the URI is not “locator for web page”; it is “identifier for class (or property)”. As Hans said, the IMPORTANT “de-referencing the URI” concept for WG3 is that I can - feed it to a server as part of a query that says what I want returned, which might be a web page locator, or some useful set of RDF triples; and- refer to it in a formal statement I make about a thing in my plant.In so many words, “de-referencing an RDL URI”, in the sense of going to some web page, is UNIMPORTANT to the tools conforming to 15926. Finding such a web page, in addition to, or in lieu of, the text of the ISO TS, is important to the standards developers and the toolsmiths, but that is not the purpose of the URI itself.

The recommendation in the cooluris Note that You cited explicitly says one should have DIFFERENT URIs for the thing and the web page that describes the thing, so as not to produce confusion about the semantics of the identifier. I strongly suggest that WG3 should take that advice. The IDENTIFIER for the thing – the RDL element – begins standards.iso.org; the LOCATOR for a web page that describes the thing may begin poscceasar.org or jord.org or whatever other organization will actually provide a server that can “dereference” the URI to human-readable text. The identifier is standardized for posterity; the supporting resources will come and go over time.

To be honest. Having a standard for where the endpoint is would be nice, but it is not directly connected to dereferencable URIs. A sparql endpoint is a separate service for doing complex queries on the data. If there is no such service for part 8, then it is easy to set up for anyone. Also you do not need to change any namespaces for a new endpoint to work, just simply put the endpoint uri in your program or add it as a service in a federated query.

Hindrik Koning wrote:

Dear all

A nice thing of an endpoint is it points to an end and that’s it.I have to admit, I do not understand all of the discussion.It appears we have more end points but no end.The requirements needed to come to the endpoint lack a uniform agreed specification (some people say a standards would be nice)So maybe we should set the agreed requirements in a specification first, before jumping to different conclusion and endpoints

Kind Regards,

Hindrik

Hans Teijgeler wrote:

Hi Håvard,

Thanks!

For 15926 I already used the RDL endpoint successfully:

Attachment:

dereferencing.png [ 198.18 KiB | Viewed 3320 times ]

Strange enough you used RDL:hasDesignation rather than rdl:hasDesignation , but when I look up the RDF/XML code of INCH I see <pca:hasDesignation>INCH</pca:hasDesignation>How does this fit together?

Regards,Hans

Håvard Ottestad wrote:

Hans, that is good.

RDL, rdl & pca is just the prefix.

We know about the issue, but it's not a very big issue. If you render the fully qualified URI then they are the same.

It has most likely come when different people built different parts of our system.

For the non technical:

Prefix is something used to make the text shorter and more readable.

A prefix is a short word, eg "rdfs" which is used instead of a long URL eg. "http://www.w3.org/2001/XMLSchema#"

Making a change to Part 8 will further increase the reputation that ISO 15926 is a science project with never ending and constant fiddling and with no consideration, responsibility or accountability to the consequence impacted upon business usage. The "#" character has been in use since 2006 and is in the published standard. I am strongly opposed to changing Part 8 for something that falls in to the "fiddling" category. Its time for the MMT and other deep-think groups to get on with completing the work and stop changing stuff.

Or am I wrong and ISO 15926 is actually a science project and business should abandon it and wait until it is finished or find something else? I am going to be bone-headed about this and fight this change until I am ejected from TAB.

Hans Teijgeler wrote:

Hi Robin,

You undoubtedly know how long it took for IBM, Oracle and others to define the ER technologies, including SQL, and yet we have used them from the beginning and accepted (had to accept) that developments took place that affected our software. Rome wasn't built in a day either.

If true standardized lifecycle information integration, with globally distributed data, had been easy, it would have been there for a long time. If I understand it well you haven't yet touched the subject of lifecycle information integration.

In the Foreword of both ISO/TS 15926-7 and -8 the following (standard) statement appears:QUOTE An ISO/PAS or ISO/TS is reviewed every three years with a view to deciding whether it can be transformed into an International Standard. UNQUOTE

The date of Part 8 is April 15th 2011, so in a few months' time we have to start the reviewing process, and subsequently the set of ISO ballots. I have a load of comments to both Part 7 and Part 8, but nevertheless they have proved to be useful.

A change like the proposed one must be possible in case it is necessary, because once these Parts have the status of International Standard it will be darned difficult to convince the member states of ISO to make such a change unless it is a true erratum.

Having said that, I think the ISO 15926 community owes you because of your relentless promotional activities. And by all means stay in the TAB !

Regards,Hans

Onno Paap wrote:

Dereferenceable URIs are required.It is a big deal if users that aren't using ISO 15926 compatible software can still click and call up (RDL) data. Just to be able to put a link in a spreadsheet cell that can be clicked to call up information is a big deal.

Compare this to Domain Name Service (DNS) that everybody uses. A domain name is translated to an IP address of a web server. If the domain is sold and changes ownership, or if the server is replaced, the DNS is pointed to a new IP address and propagated to the other DNS servers. The user can still use the same domain name. Nothing changes on his end.

Our system isn't about domains but about address paths to endpoints which cannot be solved by DNS. But still it is easily done with redirect rules. The technique to do this is simple, tested, and done in just a few minutes, on existing servers.

What we don't want is temporary URIs. Just like we don't want to let users type in IP addresses but use DNS instead. For the ISO 15926 RDL classes, templates, etc, all namespaces should be iso.org based, and still dereferenceable.

As Ed pointed out, for federations of facades (a ISO 15926-9 term) we need this technique for sure. Here, data is created in a facade, and moved to another by contractual transfers (data handover). We will use dereferenceable namespaces of the plant owners. The data is on the servers of the suppliers and Engineering Contractors at the start, later moved to those of the plant owners. Just like we now use the unit name, tag name and document schemes and number blocks given out by plant owners.

Many of the suppliers do not use facades nor databases. They use email and spreadsheets.80% of the existing 10,000 suppliers is our estimate, won't use SPARQL.

So the question isn't if it is required. It is required.Matthew West used to say: "you cannot deny a requirement".

Ed said: I do NOT think we should make HTTP dereference a primary concern, UNLESS we are serious about creating a registration authority.

Onno: The registration authority of this point in time is POSC Caesar. We only need to point all traffic of the iso.org based URI to the POSC Caesar server. We do not need an ISO-organization for registration of RDL endpoints.

Hans said: Dereferencing to me is, ultimately, using SPARQL to translate an IRI to find the applicable triples and from those the applicable datatype properties (strings, numbers, Booleans), for use in applications.

Onno: this is correct. See below a diagram how a software program Pubby for Semantic Web is solving this. This is not for the big brands, who have dereferencing in their package already. The POSC Caesar endpoint solves it is bit different, but we ought to think about making a specification for the ideal dereferencing behavior.

Attachment:

pubby-architecture.png [ 28.31 KiB | Viewed 3320 times ]

Robin said: The "#" character has been in use since 2006 and is in the published standard. I am strongly opposed to changing Part 8 for something that falls in to the "fiddling" category

Onno: We haven't discussed this properly yet. The # will call up an entire RDF file if there is a file at that address. Of course there isn't/ shouldn't. There is an endpoint with a web service, which will take the fraction identifier and present the data in SPARQL response or HTML (if dereferencing).So no, we won't change part 8 for that and I retract my earlier remark about the slash (/).

Hans said: Having said that, I think the ISO 15926 community owes you (ed: Robin) because of your relentless promotional activities. And by all means stay in the TAB !

Onno: I agree to that. As for all people involved in the ISO 15926, pushing it. Thank you!

Robin Benjamins wrote:

Hans,

Thanks for your feedback.

I understand that things will always evolve and improve. My reaction to Onno's request was that it appeared that a decisions was made without discussing with the wider user and implementer community on how this change will impact business usage of ISO 15926. The specific change is small and can be absorbed without too much fuss. But the issue is that there needs to be some connection between improvements to the standard in an ideal situation tied to the consequences in the dirty real world. Maybe some ideal changes are just not worth pursuing?

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum