15926.org

Onno,

By "dm: namespace for JORD" I just mean that in JORD triples 201 types are identified in http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003#

But I'm not thinking in terms of RDL's here. Here I'm thinking more in terms of Semantic Web (probable unexpected from me )

There are resources representing 201 EXPRESS types. Each may have many URIs, but only two should be used in my opinion (in http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003# and http://standards.iso.org/iso/ts/15926/- ... data-model# namespaces). In the context of JORD or any other library or data source these resources are referenced as objects in rdf:type predicates.

There is no need for them to "be" anywhere in RDL or on endpoint. They are prebuilt in our .15926 Editor, for example.

There can be many places where some useful facts are recorded for these resources, here are some of these places:

http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003
http://rds.posccaesar.org/2008/07/OWL/I ... nnotations
http://rds.posccaesar.org/2008/07/OWL/I ... Membership
http://rds.posccaesar.org/2008/07/OWL/I ... Candidates

You can import this fact sets in other ontologies, and there is no way to import an endpoint anywhere, as far as I know.

Projects like OWL 2 can bring us more useful facts, representing more subtle meanings of Part 2 English text (for example).

This is an approach, as far as I understand, proclaimed also for template model and proto and initial template set in Part 8:

The dm, p7tm, p7tpl and meta are files and not SPARQL endpoints. This is because given that these declarations
are immutable, it can be assumed these files will be locally cached by implementing systems. These files are present on the
CD-ROM of this part of ISO 15926.

In what sense

I voted for "dm: only one namespace for entities, a separate dm:"

Because (in case of the Activity example) dm:Activity and rdl:Activity are actually the same thing.

That there are classes in the RDL representing Entity Data Types was something put in there in the time that the RDL was a stand-alone database.

In my opinion now that the RDL becomes a federated data set, ownership of Entity Data Types belongs to the dm: namespace only.

I agree with "dm only". IMHO, the RDL punning just causes unnecessary confusion.

I have not seen any mention of the existing IDS-ADI dm: URI's, e.g. http://dm.rdlfacade.org/data#Activity. We have been using these for the last several years. They will not resolve after rdlfacade.org is shut down, but as Onno says in another thread, a namespace does not need to be resolvable.

I don't know if or why there is a need to create another set of URI's for the same purpose, but regardless the dm.rdlfacade.org URI's must remain for compatibility.

Darius, there is no need to create another set of dm: URI's, it already exists in http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003# namespace. The reason is quite simple - after the RDS/WIP shutdown the only remaining RDL will be using this set.

Compatibility should be preserved, of course.

I'm afraid that voting on short namespace names http://15926.org/viewtopic.php?f=3&t=62 will bring us the fourth dm: namespace

vvagr wrote: I'm afraid that voting on short namespace names http://15926.org/viewtopic.php?f=3&t=62 will bring us the fourth dm: namespace

Yes, but this poll is a perfect example that if we reason things out, we arrive at other decisions as what the standards authors had decided before, in isolation.

Vote Option: dm: only one namespace for entities, a separate dm:
Justification:
At my point of view, we need a separate dm: that will be namespaces of the entities, because:

1- The nature of the elements of dm: are different from the rdl:
2 - If we merge dm: and rdl: new users of the standard may lose the perception of an ontology
from which all RDL concepts derive. The entities, which for all implementation purposes are OWL classes,
have their semantic described in a discrete piece of documentation - part 2. Merging dm with rdl may prevent a structured approach to understand ISO15926 reference data.