Namespaces

[vvagr]

Onno,

I think we have to come to voting sooner or later.

[OnnoPaap]

Please copy my words into the forum. I am struggling with internet access at the moment - my landline is down and I am doing this from the pub.

Best regards,
David

Dear Onno,

If a thing is defined within a part of ISO 15926, then its URI should start:

Code: Select all

http://standards.iso.org/iso/15926

There is then a choice about whether to include a part number. This is up to you. So we can have:

Code: Select all

http://standards.iso.org/iso/15926/n

There is a choice about whether to include an edition of the standard. This is up to you. So we can have:

Code: Select all

http://standards.iso.org/iso/15926/n/ed-1

Then there is a "/tech/" that separates the part of the URI that places the thing within a standard or family of standards from the part of the URI that identifies the thing.

In ISO 15926-6:

version 1 of the part 6 reference data library has the URI:

Code: Select all

http://standards.iso.org/iso/15926/-6/tech/reference-data-library/v-1

the reference data item "ISO 15926 reference data library" has the URIs:

Code: Select all

http://standards.iso.org/iso/15926/tech/reference-data/ISO_15926_reference_data_library

and:

Code: Select all

http://standards.iso.org/iso/15926/tech/reference-data#RDL10683

Whether or not the part of the URI after the /tech/ contains a "#" is up to you.

I do not think that the length of the URI is important, because all serializations allow a shorthand prefix.

Best regards,
David

Dear David,

On Tue, Sep 4, 2012 at 12:00 PM, <[email protected]> wrote:
> the reference data item "ISO 15926 reference data library" has the URIs:
>

Code: Select all

http://standards.iso.org/iso/15926/tech/reference-data/ISO_15926_reference_data_library

> and:
>

Code: Select all

http://standards.iso.org/iso/15926/tech/reference-data#RDL10683

Please clarify - what is the reason behind having two URIs - with
number and with human-readable string?

And it seems that proposed structure for these two URIs will add
problems to the organisation responsible for their resolvability?

> I do not think that the length of the URI is important, because all serializations allow a shorthand prefix.

It is true about SPARQL requests and replies also?

Colleagues, I don't quite understand now - what part of the standard
will define a choice between modelling of metadata - as annotation
properties, or as proper reference data items?

Sincerely,
Victor Agroskin
TechInvestLab.ru

Dear Victor,

There have been differences of opinion as follows:

1) Some want URIs with fragment identifiers, but some regard the relationship between the primary and secondary URIs as ill-defined for reference data and do not.

2) Some want URIs that are memorable by people, but some belive that URIs are only processed by software and do not.

Theoretically there are four possibilities:

Code: Select all

1) http://standards.iso.org/iso/15926/tech/reference-data/ISO_15926_reference_data_library
2) http://standards.iso.org/iso/15926/tech/reference-data#RDL10683
3) http://standards.iso.org/iso/15926/tech/reference-data/RDL10683
4) http://standards.iso.org/iso/15926/tech/reference-data#ISO_15926_reference_data_library

However there was no enthusiasm for (3) and (4), so only (1) and (2) have been used so far. I am happy to see how things evolve. We may end up with different user communities using different types of URI, or we may end up with consensus on just one type of URI.


>And it seems that proposed structure for these two URIs will add
>problems to the organisation responsible for their resolvability?
>
>> I do not think that the length of the URI is important, because all serializations allow a shorthand prefix.
>
>It is true about SPARQL requests and replies also?

SPARQL allows shorthand prefixes.

[HansTeijgeler]

Hi David,

The problem I have with overly long URIs is disk space and the extra terabytes we will need just for that reason.

In a typical triple, stored in a triple store, such as:

http://www.p1234.xyz-corp.com/pip#Ce269 ... 00200c9a66
http://www.w3.org/2000/01/rdf-schema#subClassOf
http://standards.iso.org/iso/15926/tech ... 8701958436 (even longer if UUIDs are used)

all URIs are written in full, and URIs occur three times in every triple.

Part 8 dictates using the # hash, so on that subject there is no discussion.

I have my doubts about including parts and editions, since this seems to me an evolving thing, different from the customary parts lists and the like. Besides it will be misconstrued by many, causing unnecessary problems.

Cheers! (if you still are in that pub)
Hans

[IanGlendinning]

I've been out of the loop on the debate, but JORD has been developing it's implementation interpretations of existing parts (4, 6 in particular).

I see some need to distinguish between namespaces and URI's ...
I see the namesspace as part of a URI identifier.
(JORD has adopted some rules and conventions on these.)

For versionable items the ID needs to include versioning.

Shortening is an issue, not just for the namespace part, but the whole ID - if say we are using R-UUID formats for default ID's. (We also have two different human readable ID's - for developers and for business.)

Also interested in namespace sub-domains for partitioning different "kinds" of data and reference data - business instance data, local / business reference data, shared reference data, templates, base (Part2) reference data, etc ...

Be good to see a summary of the votable decisions arising from discussion so far.

[vvagr]

Ian

For versionable items the ID needs to include versioning.

No they don't!

We've to use semantic constructs as much as possible. We've to use restricted subset of semantic constructs - the set which is defined to represent Part 2 and Part 7 concepts - as much as possible.

Loading URI with versioning violates all these principles. We've to try templates, if we decide it impossible to do with templates - we've to try annotation properties. Only it is decided impossible - then we can consider URIs.

[vvagr]

We also have two different human readable ID's - for developers and for business.

I'd like very much to hear the reasons for that. Special semantic constructs will be required to maintain correspondence. And at the same time we still need ways to express unlimited number of other possible identifications. It's double work and double processing then.

If we can not put all required human readable identification in ID's - let's put none.

[OnnoPaap]

Versioning is in fact metadata. The metadata of a class in the reference data library are about many things.
E.g. the create date, but also that the class was part of a set called "Initial Set revision 2". That is all versioning data.
The create date is a property, in the data set expressed using semantics (e.g. templates), in RDF as annotation property.
The "Initial Set revision 2" is a grouping, done in the database by class of class relationship. Many groupings can contain the same class and it is also metadata.
In my opinion none of this needs to be expressed in the namespace.

The namespace does not need to be resolvable (i.e. you see something in your browser if you enter the namespace address).
The W3C has resolvable namespaces, but only to explain about the namespace itself, there is no database or data behind it.

The reference data library is the only location that remains to have the same http address. It is a bad example.

We don't need (cannot use) resolvable namespaces because our data will be in different locations during its life-cycle. First on the servers of a designer, then manufacturer, logistics, construction, and owner. And maybe another owner after that. We have to solve this relocation problem, e.g. by using pURL servers or something in iRING that takes care of it.

So in my opinion none of this is of consequence of the namespace. The namespace should only say something about the data, not about its location, nor its version.