15926.org

The poll on namespaces was a success. The MMT SIG definitely works and it was a job well-done by the group and especially Kari-Anne as chair person.

The conclusion is:
Does a namespace need to be short? -- Yes
Does a namespace need to carry ISO part information -- No
Do we need to split up Entity Data Types in dm and rdl? -- dm: only one namespace for entities, a separate dm:
Does a namespace need to contain version information? -- No
Do namespaces need to be divided up in many groups? -- Yes

The namepsaces used in ISO 15926-8 I propose to make these:

Please refer to the MoM from the MMT meeting on the 29th of November 2012 (https://www.posccaesar.org/wiki/SigMmtMomNovember291112)

How will iso.org facilitate for Linked Data? Or is LD no longer relevant?

mstrand wrote:How will iso.org facilitate for Linked Data? Or is LD no longer relevant?

Hi Morten,

Linked data is very relevant. But also other means of interoperability.

ISO has no business model in place to support a server that needs to run under industrial requirements (24/7 support, mirrored, 99.x % uptime, etc etc).

The JORD project has been started to cover online facilities for the industry. See this thread for more information http://15926.org/viewtopic.php?f=10&t=71

ISO is involved, in that they will support new class proposals from organizations like the support group JORD will produce. In the form of spreadsheets and reviews by multiple national bodies.

If Linked Data is relevant and desired for the namespaces mentioned above, the standards.iso.org based namespaces will not work. Simply because we don't own that domain name, and cannot use it as we wish. This includes installing a LD server on it. The only way we can have LD and standards.iso.org at the same time, is if ISO decides to provide such services.

If we can rent or otherwise use standards.iso.org, the whole thing changes ofcourse.

We have permission to use that domain name because we made an ISO standard.

For services, correct me if I'm wrong: I think you are saying we need to control the service because an URI address must be resolvable?
If this assumption is correct, the answer is that the namespace + fraction identifier don't have to be resolvable.
Most data isn't classes but individuals expressed in RDF. Those are information about parts of construction projects or running facilities. There is a change-over of ownership in several phases of such a project. So data is moved from one server to another to the next. If data is moved but not changed the namespace should also not change. Therefore most URI addresses are not resolvable.
Of course we DO HAVE to resolve the URIs somehow, to reach its data. The mapping of namespace-based URIs to online URLs is solved by the called server by a redirect. A method for that is for example pURL (http:purl.org) but it may be better if each software solution takes care of this on its own, and not have a dependency.

Your assumption was correct. And this means that LD support is not in scope. Which answers my question

The pURL method you describe has the same limitations as LD software: you need to have control over the called server, which is given by the domain of the URI.

I have an objection specifically to the namespace

dm="http://standards.iso.org/iso/15926/dm#"

As JORD RDL is the most used RDL now, I'd propose to keep its namespace

dm="http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003#"

as de-facto standard or "best practice" for implementations.

We can't use Posc Caesar in a namespace. That was the reason we had rdlfacade.org

We are not allowed to use the name of a specific standardization body in a namespace of an international standard.

Personally I also think it is a good practice to never use a namespace that is in fact a resolvable URL. Because that situation is usually temporary, dependent of the existence or death of the domain name.

That's why it will be probable better to make distinction between standard and "JORD best practice".

Practical consequences of a decision should be taken into account. If namespace is changed - time frame and methodology for endpoint migration should be decided, PURL server start time, if required, etc.