[sc34wg3] New SAM draft

[Lars Marius Garshol]

* Lars Marius Garshol
|
| I could, but I would rather list the HyTime notation(s) here
| explicitly.  I'm basically waiting for the HyTM work to proceed so
| that we can add the necessary HyTime notations to this list. Any
| takers?

* Martin Bryan
| 
| I'm already in the process of doing this. Please be patient. 

Uh yes, sorry. That text was written in December 2002. :-|

| The main definitions are done, but the serialization rules are
| problematic as too much information gets lost.

To me that sounds like things that should be captured using issues.
Then we can discuss those and decide what to do about them in each
case. I fear the committee and you will probably agree on the
solution, as we'll most likely want to use published subjects (your
"unnecessary topics") to capture this.

It may be worthwhile to thrash that general principle out first and
only deal with these issues afterwards.

* Lars Marius Garshol
|
| This equality rule is here so that syntax specifications can define
| what conformance to the syntax specification means more easily.  This
| allows them to say that an implementation is conformant if for every
| instance of the syntax they can create a SAM instance X, then
| serialize that to the syntax, read it back in to a SAM instance Y, and
| have those two instances be equal according to this rule.
| 
| Does that clarify things?
 
* Martin Bryan
|
| Only if this means that the source locators get ignored during the
| SAM->instance transformation.

You mean serialization back to interchange syntax? Yes, they are
ignored in that process. (Except in the case where they indicate
reification, in which case implementations must preserve that
information.)

| [explanation of subject identifiers and addresses]
| 
| Examples are really needed, ideally with an accompanying diagram
| showing the relationships.

I'll put it in as soon as I can. I agree a diagram is needed.

| [term-subject-indicator-def]
| 
| In the case of the Acts example you could rely on the use of URI
| resolvers suchs as bible:Acts:Ch11:V5 to point to sets of resources
| as purls do.

It does work in that case, but what do we do about URI schemes like:

  <URL: http://larry.masinter.net/duri.html >
  <URL: http://www.taguri.org/ >
  
These can reference anything from somebody's dog to the concept of a
language.  

| [prop-subj-address-scope]
| 
| I don't want people using topics that define constructs in 13250 as
| scopes as this would be a terrible misuse of these topics.

OK, but how do we stop this? (And which topics are you thinking of?)
 
| The main use case is where roles are inherited from the GI. As in
| the revised RDF, as demonstrated in the OWL spec, there are great
| advantages in being able to say <Predicate>Value</Predicate> rather
| then <Type role="Predicate">Value</Type>. Not only does this make it
| easier for users to interpret when they view the interchanged
| version (making debugging easier) it also makes the writing of XSLT
| statements for the processing of objects of a particular type much
| much easier to manage, and makes them easier to interchange and
| reuse.

This sounds to me like the issue of being able to design custom
syntaxes for interchanging topic maps, rather than how we interpret
these syntaxes in a data model. Am I right?

Assuming I am, I'd like to say that I do think custom topic map
syntaxes are a worthwhile and useful idea. How could I not, given that
I've created one myself that I use all the time? (Yes, I do mean LTM.)
The question is whether we need to encumber the HyTM and XTM syntax
specifications with support for this, or whether we can keep it
separate. 

To my mind custom syntaxes are a separate thing, and with the SAM we
have exactly what we need to support them. Anyone can create a
proposal for defining custom topic map syntaxes and define how these
map to the SAM. Then users can use them and implement the mappings
themselves (by converting to XTM or whatever) and implementors can add
support to their implementations if they find that user demand merits
it.

Since that all the syntaxes (whether custom or not) have mappings to
the same data model this should be no problem, and everybody should be
able to use whichever syntax they want wherever they want. That's what
people do with XTM, LTM, and AsTMa= today, and as far as I can tell it
works great.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >