ISO15926-9(20121119) questions

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

ISO15926-9(20121119) questions

#1 Post by vvagr »

1. Section 4.4

- As it is stated above, "an ISO 15926 endpoint exposes ISO 15926-7 template instances and other instances of subtypes of thing in ISO 15926-8 form". It is worth to mention here not only identification as ISO 15926-2 ’id’ attribute of thing, but also identification as ISO 15926-8 rdf:about and rdf:ID.

- "All instances of thing which are part of the ISO 15926 Reference Data Library shall have a
URN."

Isn't this "URN" a mistake?

- "An instance of ClassOfIdentificationTemplate from the ISO 15926-7 proto templates list
shall be used to identify an ISO 15926-9 endpoint."

I've to confess that I don't understand how to identify an endpoint (file or service) in this manner. What URI should be used? What kind if identification is meant here? Human-readable? Section 4 above refers to Annex A ("Each ISO 15926 endpoint shall have a unique identifier. See also clause A."). But it is not really defined in annex A!

2. Section 4.10

"Question : is there a value in having an manifest owl class to list out the authentication
mechanism used by the particular ISO15926 service?"

I don't think so. If client can already access manifest - he had probable already cleared authentication. Any architecture which exposes authentication info before authentication is too specific and can not be normative.

3. Section 6

"Each Reference Data Service shall use metadata as defined in the ISO 15926-8 about RDL
entries and evolution of these entries."

Probable ISO 15926-6?

4. Annex A.

"uri of the ISO 15926 endpoint" is mentioned several times. But no explicit definition, as promised in Section 4. Is URI of a service defined as URL of an endpoint? What is URI of a file? Shouldn't it be declared explicitly?

"p9mm:valHashCode" What is the intended methodology? Hash value of a service is a hash value of a mandatory export file? Shouldn't this be stated explicitly?

One proposal. Please consider adding to the manifest an optional list of annotation properties used for exposed entities.

Pavel Selchukov
Posts: 12
Joined: Tue May 15, 2012 7:06 am

Re: ISO15926-9(20121119) questions

#2 Post by Pavel Selchukov »

"4.9 Security considerations for an ISO 15926 endpoint
An ISO 15926 service should be exposed from a DMZ and never be exposed directly to the
web."

I think it should depends of Owner's Will.

"5 ISO 15926 Client
An application that conforms to ISO 15926 client specification..."

Where we can find this specification?

Annex A
(normative)
OWL ontology for ISO 15926 endpoint manifest

p9mm:EPTContainedTemplatesAtEndpoint - is used only as example of syntax that used in a particular RDL, or it must to provide a full set of Templates?

p9mm:EPTContainsInstancesOf - same for RD classes?

p9mm:EPTEndpointBestPracticeRuleComplaince - am I right and you telling about full entire rules are left for Owner's Will?

rbertucat
Posts: 1
Joined: Thu Nov 29, 2012 11:24 am

Re: ISO15926-9(20121119) questions

#3 Post by rbertucat »

Hello,
After going through the document ISO15926-9(20121119), I have the following questions:
What is a façade? Can it be consider as what is defined in the document as an ISO 15926 service? i.e. a façade = an ISO 15926 service = a SPARQL endpoint exposing ISO 15926 data?

There are different sources saying that a façade is a triplestore:
  • - the following paper "ISO 15926-based data repository and related web services for sharing lifecycle data of process plants." by Mun, D., Lee, S., Kim, B., & Han, S. (2009)

I understand these references might be quite old and thus obsolete.

Thanks,

Roch

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

Re: ISO15926-9(20121119) questions

#4 Post by OnnoPaap »

Answers written by Rahul Patil placed online on his request.
Victor Agroskin wrote: 1. Section 4.4

- As it is stated above, "an ISO 15926 endpoint exposes ISO 15926-7 template instances and other instances of subtypes of thing in ISO 15926-8 form". It is worth to mention here not only identification as ISO 15926-2 ’id’ attribute of thing, but also identification as ISO 15926-8 rdf:about and rdf:ID.
[Rahul Patil] - I do not understand the comment.
Victor Agroskin wrote: - "All instances of thing which are part of the ISO 15926 Reference Data Library shall have a URN."
Isn't this "URN" a mistake?
[Rahul Patil] No it is not a mistake, we indeed mean a location independent URN. Please see http://www.w3.org/TR/uri-clarification/
Victor Agroskin wrote:
- "An instance of ClassOfIdentificationTemplate from the ISO 15926-7 proto templates list shall be used to identify an ISO 15926-9 endpoint."
I've to confess that I don't understand how to identify an endpoint (file or service) in this manner. What URI should be used?
[Rahul Patil] in case of a ISO 15926 service the endpoint address url can be used. In case of a file the identifier could be the file name or file path, this will vary depending upon the implementation.
Victor Agroskin wrote:
What kind if identification is meant here? Human-readable?
[Rahul Patil] Not necessarily human-readable. This identification will be used in the templates while identifying this resource (an iso 15926 service in this case)
Victor Agroskin wrote: Section 4 above refers to Annex A ("Each ISO 15926 endpoint shall have a unique identifier. See also clause A."). But it is not really defined in annex A!
[Rahul Patil] .......
Victor Agroskin wrote: 2. Section 4.10

"Question : is there a value in having an manifest owl class to list out the authentication mechanism used by the particular ISO15926 service?"

I don't think so. If client can already access manifest - he had probable already cleared authentication. Any architecture which exposes authentication info before authentication is too specific and can not be normative.
[Rahul Patil] fair enough.
Victor Agroskin wrote: 3. Section 6

"Each Reference Data Service shall use metadata as defined in the ISO 15926-8 about RDL entries and evolution of these entries."

Probable ISO 15926-6?
[Rahul Patil] Yes, we will correct the typo.
Victor Agroskin wrote: 4. Annex A.

"uri of the ISO 15926 endpoint" is mentioned several times. But no explicit definition, as promised in Section 4. Is URI of a service defined as URL of an endpoint?
[Rahul Patil] Yes, URI of the service is URL of the endpoint.
Victor Agroskin wrote: What is URI of a file? Shouldn't it be declared explicitly?
[Rahul Patil] Yes, it should be declared explicitly in part 9. URI of the file will probably be the file name. But I can't think of a workflow where it might be needed.
Victor Agroskin wrote: "p9mm:valHashCode" What is the intended methodology?
[Rahul Patil] It is intended that hash value changes every time there is a change in data exposed by the endpoint. This is a way for the clients to know if anything has changed at the endpoint without having to query everything.
Victor Agroskin wrote: Hash value of a service is a hash value of a mandatory export file? Shouldn't this be stated explicitly?

One proposal. Please consider adding to the manifest an optional list of annotation properties used for exposed entities.
[Rahul Patil] We can certainly consider this. Please elaborate.
Pavel Selchukov wrote: "4.9 Security considerations for an ISO 15926 endpoint
An ISO 15926 service should be exposed from a DMZ and never be exposed directly to the web."

I think it should depends of Owner's Will.
[Rahul Patil] We can reword it to : it is recommended to expose a ISO 15926 service from a DMZ.
Pavel Selchukov wrote:
"5 ISO 15926 Client
An application that conforms to ISO 15926 client specification..."

Where we can find this specification?
[Rahul Patil] TODO.
Pavel Selchukov wrote: Annex A
(normative)
OWL ontology for ISO 15926 endpoint manifest

p9mm:EPTContainedTemplatesAtEndpoint - is used only as example of syntax that used in a particular RDL, or it must to provide a full set of Templates?
[Rahul Patil] It is expected that it provides full set of unique templates (instances of which are exposed at the given endpoint).
Pavel Selchukov wrote: p9mm:EPTContainsInstancesOf - same for RD classes?
[Rahul Patil] yes.
Pavel Selchukov wrote: p9mm:EPTEndpointBestPracticeRuleComplaince - am I right and you telling about full entire rules are left for Owner's Will?
[Rahul Patil] yes, as long as those rules are accessible to project participants via a common rds.
Roch Bertucat wrote:
Hello,
After going through the document ISO15926-9(20121119), I have the following questions:
What is a façade? Can it be consider as what is defined in the document as an ISO 15926 service? i.e. a façade = an ISO 15926 service = a SPARQL endpoint exposing ISO 15926 data?
[Rahul Patil] yes.
Roch Bertucat wrote:
There are different sources saying that a façade is a triplestore:
- the comment from Onno Paap on Linkedin that says: “A Façade is a standardized API […]In ISO 15926, it is a standardized triple store”.
- the article on Facade in infowebml
- the following paper "ISO 15926-based data repository and related web services for sharing lifecycle data of process plants." by Mun, D., Lee, S., Kim, B., & Han, S. (2009)

I understand these references might be quite old and thus obsolete.

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

Re: ISO15926-9(20121119) questions

#5 Post by vvagr »

Rahul, thank you. Some further questions:
Victor Agroskin wrote:
1. Section 4.4

- As it is stated above, "an ISO 15926 endpoint exposes ISO 15926-7 template instances and other instances of subtypes of thing in ISO 15926-8 form". It is worth to mention here not only identification as ISO 15926-2 ’id’ attribute of thing, but also identification as ISO 15926-8 rdf:about and rdf:ID.

[Rahul Patil] - I do not understand the comment.
I mean that in ISO 15926-8 RDF entity instances are identified by rdf:about or rdf:ID, and these are not explicitly mapped to EXPRESS 'id' attribute of thing in ISO 15926-2. It should be made explicit by this section.

One additional remark about the notes:
NOTE Use of a URI for each entity instance satisfies above requirement.
NOTE As defined in the W3C Recommendation "Resource Description Framework (RDF): Concepts
and Abstract Syntax" all identifiers shall be of the format URI#fragmentID.
The first note's wording suggests that there are other ways to satisfy the requirement. The second note states "shall be", which is "mandatory" as far as I remember ISO guidelines.
[Rahul Patil] No it is not a mistake, we indeed mean a location independent URN. Please see http://www.w3.org/TR/uri-clarification/
What will be considered compliant implementation? Is registered URN schema required, as described by W3C? Or simple use of global-name-ID, as defined in JORD "ISO15926 RDS ID REQUIREMENTS & USAGE SPECIFICATION", will be enough?
[Rahul Patil] in case of a ISO 15926 service the endpoint address url can be used. In case of a file the identifier could be the file name or file path, this will vary depending upon the implementation.
Should not endpoint identification be a part of a manifest? What is the intended use of this template instance if it is not part of a manifest?

If it is part of a manifest, it should not be a template instance. It should be a special owl:Class p9mm:EPTNameOfEndpoint with p9mm:hasISO15926Endpoint and p9mm:hasEndpointName properties, anlogues to other parts of a manifest.

I'll certainly support move of all the manifest declarations to template instances instead of special OWL classes which have no ISO 15926 semantics. But it is very global change.

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

Re: ISO15926-9(20121119) questions

#6 Post by vvagr »

Victor Agroskin wrote:
One proposal. Please consider adding to the manifest an optional list of annotation properties used for exposed entities.

[Rahul Patil] We can certainly consider this. Please elaborate.
Something like:
p9mm:EPTContainedAnnotationsAtEndpoint ISO 15926

Service shall expose one and only one instance of this owl:Class. Properties of p9mm:EPTContainedAnnotationsAtEndpoint are:

p9mm:hasISO15926Endpoint - On the instance of p9mm:EPTContainedAnnotationsAtEndpoint
this owl:ObjectProperty shall point to uri of the ISO 15926 endpoint.

p9mm:hasAnnotations - On the instance of p9mm:EPTContainedAnnotationsAtEndpoint
this owl:ObjectProperty shall point to one or more annotation properties.

The instance of p9mm:EPTContainedAnnotationsAtEndpoint owl:Class conveys the list
of annotation properties. These properties are exposed for entity instances contained by the
given ISO 15926 endpoint.

mikhail fedorov
Posts: 13
Joined: Thu Mar 08, 2012 8:37 am
Location: Haarlem, the Netherlands

Re: ISO15926-9(20121119) questions

#7 Post by mikhail fedorov »

"2.1.7 ISO 15926-9 file
...Its contents cannot be modified by its owner without changing the identifier of the ISO 15926-9 File."

Can I ask why?.. Why cannot we just change the hash value in the manifest section of the file? (as described in Annex A - see p9mm:EPTLastUpdateHashCode)

Further we read:
"4. ISO 15926 Endpoint
Each ISO 15926 endpoint shall have a unique identifier... Such identifier shall remain unchanged over the lifespan of the ISO 15926 endpoint."

Now I'm lost completely. So, if we need to change something and we are using ISO 15926-9 files as our endpoints - we need to declare somehow the previously distributed files obsolete or..? Since we are supposed to change the identifier of the file according to 2.1.7 but that means that the lifespan of the file has ended according to 4. What am I missing?

mikhail fedorov
Posts: 13
Joined: Thu Mar 08, 2012 8:37 am
Location: Haarlem, the Netherlands

Re: ISO15926-9(20121119) questions

#8 Post by mikhail fedorov »

A minor comment...

The manifest is supposed to contain instances of the following owl:classes:
- p9mm:EPTContainedTemplatesAtEndpoint
- p9mm:EPTContainsInstancesOf
...

Since they both refer to only this particular Endpoint (apparently) can I suggest that we make both class names more aligned?.. Like p9mm:EPTContainedTemplates and p9mm:EPTContainsInstancesOf

Post Reply