[sc34wg3] new working draft of 13250-5 (Reference Model)

[Jan Algermissen]

Robert Barta wrote:


>     That, by itself is ok, but then I ask where is the
>     topicmappishness? 

My personal opinion is that topicmappishness is primarily a capability
of the datamodel's structural abstraction: the unlimited ability to merge the
primary structural element (called proxy in the TMRM). This is for
me the major distinction between Topic Maps and RDF and the relational
model. RDF is capable of merging but only at the cost of restricting itself
to a single key (nodes only merge if their URI is *equal*). The relational
model only supports merging of tuples that are equal (and of course in the
same relation).


> Specifically the unique way how TMs is connecting
>     things with letting them play roles?

I do not think that this is so unique. You get the same with the relational model
with key references. 

(I just thought to throw this in, no intention to start an argument).

Jan


> 
>   - While I have my doubts of the usefulness of an EBNF to characterize
>     a TMA, it has given some insights how you imagine the process.
> 
>     - is the topicMapAppName relevant? Whenever I define a name, I also
>       have to define the namespace the name is in.
> 
>     - would it be possible to collapse OPs and SIPs definitions by allowing
>       the propertyInstanceSubjectSamenessDetectionRule (people have been killed
>       for creating names like these :-) to be optional in case of OPs?
> 
>     - is the topicMapAppName relevant in the PInstances?
> 
>     - experimenting with the grammar I got:
> 
> (1) topicMapApplicationDisclosure = (propertyClassDefinition*)
> 
> (2) propertyClassDefinition = ( ClassDefinition | conferralDefinition )
> 
> (3) ClassDefinition = (propertyClassName,
>                        propertyValueConstraints,
>                        propertyInstanceMergingRule,
>                        propertyInstanceSubjectSamenessDetectionRule?)
> 
> (3') conferralDefinition = (propertyClassName, conferralRule)
> 
> (4) subjectProxy = (PInstance+ )
> 
> (5) PInstance = (propertyClassName,
>                  propertyValue)
> 
> (8) topicMapView = (subjectProxy*)
> 
>       Rules 1,2,3 and 3' look EXACTLY as if they would belong to an
>       ontology definition language.
> 
>       Rules 4,5,8 look dangerously close to RDF. Not sure what this means.
> 
>   - Barta/Salzer's \Tau model is not really an implementation strategy.
> 
>   - 1 (Scope):
> 
>     4. The supporting algorithms and data models that may be used to
>     represent subjects, to detect when two or more subject proxies are
>     proxies for the same subject, or to merge the values of Subject
>     Identity Properties or Other Properties.
> 
>     Is it 'represent subjects' or 'represent subject proxies'?
> 
>   - 2 (Glossary).
> 
>     Maybe use 'native' instead of 'built-in'?
> 
>   - 2.2 conferred
> 
>     The sentence 'Existing because of the operation of a conferral rule...' is pretty cryptic to me.
> 
>   - in 2.3 I find
> 
>     "Optionally, a disclosure may also define one or more interchange
>     syntaxes, data models, implementations, and/or implementation
>     strategies, along with unambiguous and comprehensive instructions as
>     to how instances of each such syntax, data model, etc. are intended to
>     be interpreted in terms of the defined Topic Map Application."
> 
>     but these things do not appear in the EBNF grammar.
> 
>   - in 2.7 (property instances) it says
> 
>     "In the subject proxy in which it appears, it is the only instance of its class."
> 
>     I read this as saying that a subject proxy can have a property of a class attached.
>     But why is this limited to one of its class? Why not allow a proxy
>     to have 2 shoe sizes? Is it because in 2.10 it say in the note:
> 
>     "The value of an SIP or OP may be a single value, or it may have multiple named and/or unnamed components".
> 
>     ?
> 
>   - in 2.12 (topic map) it says:
> 
>     "An document written in a topic map syntax".
> 
>     Is an XTM file really a topic map?
> 
>   - 3 (Subjects and Subject Proxies)
> 
>     The last two paragraphs are very vague to me. Saying things like
>     "...can provide a useful basis..." is a bit vague.
> 
>   - 4.4 Property Instance Merging Rules
> 
>     Is it a constraint that if one merges two properties of the same
>     class, that the values have to be merged into a new value? Must
>     it be a value of the same class?
> 
>     "...violate the logic of a TMA..."
> 
>     What exactly does that mean?
> 
>   - 4.6 is a bit vague to me as well :-)
> 
> Overall the new TMRM looks very lean to me. Not sure how good this is
> ;-)
> 
> \rho
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen
Consultant & Programmer	
http://www.jalgermissen.com