RE: [icom] underspecification and interoperability

[Eric Chan <eric.s.chan@oracle.com>]

Hello Patrick,

We have PropertyDefinition and Property metadata model that can be used to extend the properties of the Entity class. If RDF model has extra properties that are not defined in ICOM classes, these properties (the data you alluded to in your message) can be converted to extensible properties of the objects in ICOM.

We are proposing to under-specify the RDFS Property definitions for some of the properties. There are two scenarios where we need under specification, i.e. defining fewer restrictions than in CSPRD and UML model, for RDF model if we were to use only RDFS vocabulary.

----------

Case 1.

In the ICOM CSPRD and UML model, the "memberGroup" is a property of Scope and Group. However we don't have a concept in ICOM that represents the union of Scope and Group. To define the domain of "memberGroup" property according to the CSPRD and UML model, we need owl:unionOf to express the union of Scope and Group, e.g.

rdfs:label -- memberGroup 
rdfs:domain 
  owl:unionOf 
    -- http://docs.oasis-open.org/ns/icom/core/201008#Scope 
    -- http://docs.oasis-open.org/ns/icom/core/201008#Group
rdfs:range 
  -- http://docs.oasis-open.org/ns/icom/core/201008#Group 

We proposed to under-specify the definition of "memberGroup" in RDF model that uses RDFS vocabulary only. This way the domain of "memberGroup" property can be more precisely specified in richer frameworks, such as UML and OWL. In other words, we resorted to under specification of RDFS property definitions in RDF model rather than specifying something like Entity, which is the common super class of Scope and Group, as the domain of "memberGroup." Specifying Entity as domain of "memberGroup" will prevent consistent extensions with UML and OWL frameworks and thus will amount to an over specification.

----------

Case 2.

ICOM CSPRD and UML model defines a property "parent" in Entity (parent : Entity -> Parental). In RDF model using RDFS proper, we will specify the "parent" property in the broadest sense (without using the concept of Parental):

rdfs:label -- parent 
rdfs:domain 
  -- http://docs.oasis-open.org/ns/icom/core/201008#Entity  
rdfs:range 
  -- http://docs.oasis-open.org/ns/icom/core/201008#Entity

In CSPRD and UML model the property definition of "parent" is overridden by Scope and Subject classes to restrict the ranges, i.e. (parent : Scope -> Community) and (parent : Subject -> Scope). These same restrictions can be expressed using OWL 2.0:

<owl:Class rdf:ID="Scope">
  <rdfs:subClassOf rdf:resource="#Entity"/>
  <rdfs:subClassOf>
    <owl:Restriction>
       <owl:onProperty rdf:resource="#parent" />
       <owl:allValuesFrom rdf:resource="#Community"  />
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

<owl:Class rdf:ID="Subject">
  <rdfs:subClassOf rdf:resource="#Entity"/>
  <rdfs:subClassOf>
    <owl:Restriction>
       <owl:onProperty rdf:resource="#parent" />
       <owl:allValuesFrom rdf:resource="#Scope"  />
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

-----------

In summary, the RDF model will include fewer concepts and fewer restrictions than in CSPRD and UML model. They are more or less under specification of the ICOM model with RDFS so that the omitted concepts and restrictions can be progressively added with OWL 2 profiles.

Thanks,
Eric

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Wednesday, October 12, 2011 12:26 PM
To: icom@lists.oasis-open.org
Subject: [icom] underspecification and interoperability

Greetings!

I am wondering what the usual behavior of applications is going to be if 
we follow the route of "underspecification" too far.

Say for example that the entity class is extended due to underspecification.

Applications are written to support the entity class as defined by ICOM.

One of those applications is passed a data stream that has ICOM defined 
properties and values *and* extended properties and values.

Does the application:

1) Discard data it does not understand but process the remainder

2) Alert the user that data loss is about to occur

3) Reject data streams that it cannot process

If we leave users in a position where they are likely to encounter 
inconsistent treatment of their data between applications, then having a 
"standard" model for that data isn't very helpful.

I am assuming that simply because an application accepts files written 
in RDF, does not mean that every capability that can be expressed in RDF 
can then be performed by the reading application. There may be security 
constraints for example but if my application lacks any capacity to 
enforce them, that they occur in the RDF may be interesting but no much 
more than that.

Hope everyone is having a great week!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau


---------------------------------------------------------------------
To unsubscribe, e-mail: icom-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: icom-help@lists.oasis-open.org