Namespaces -- the final decision

Message
Author
OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Namespaces -- the final decision

#1 Post by OnnoPaap »

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

Code: Select all

     xmlns:p7tm="http://standards.iso.org/iso/ts/15926/-8/ed-1/tech/reference-data/template-model#"
     xmlns:p7tpl="http://standards.iso.org/iso/ts/15926/-8/ed-1/tech/reference-data/templates#"
     xmlns:dm="http://standards.iso.org/iso/ts/15926/-8/ed-1/tech/reference-data/data-model#"
     xmlns:meta="http://standards.iso.org/iso/ts/15926/-8/ed-1/tech/reference-data/metadata#"
I propose to make these:

Code: Select all

     xmlns:p7tm="http://standards.iso.org/iso/15926/tm#"
     xmlns:p7tpl="http://standards.iso.org/iso/15926/tpl#"
     xmlns:dm="http://standards.iso.org/iso/15926/dm#"
     xmlns:meta="http://standards.iso.org/iso/15926/meta#"

karianne
Posts: 4
Joined: Mon Feb 06, 2012 12:11 pm

Re: Namespaces -- the final decision

#2 Post by karianne »

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

mstrand
Posts: 5
Joined: Sun Jan 06, 2013 12:03 am

Re: Namespaces -- the final decision

#3 Post by mstrand »

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

OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Re: Namespaces -- the final decision

#4 Post by OnnoPaap »

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.

mstrand
Posts: 5
Joined: Sun Jan 06, 2013 12:03 am

Re: Namespaces -- the final decision

#5 Post by mstrand »

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.
Morten R. Strand
Det Norske Veritas (DNV)

OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Re: Namespaces -- the final decision

#6 Post by OnnoPaap »

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.

mstrand
Posts: 5
Joined: Sun Jan 06, 2013 12:03 am

Re: Namespaces -- the final decision

#7 Post by mstrand »

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.
Morten R. Strand
Det Norske Veritas (DNV)

vvagr
Posts: 282
Joined: Mon Feb 27, 2012 11:01 pm
Location: Moscow, Russia
Contact:

Re: Namespaces -- the final decision

#8 Post by vvagr »

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.

OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Re: Namespaces -- the final decision

#9 Post by OnnoPaap »

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.

vvagr
Posts: 282
Joined: Mon Feb 27, 2012 11:01 pm
Location: Moscow, Russia
Contact:

Re: Namespaces -- the final decision

#10 Post by vvagr »

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.

Post Reply