[sc34wg3] New SAM draft

[Martin Bryan]

Lars Marius Garshol

Just brief responses to the questions you raised in your reply:

> 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?

I'm already in the process of doing this. Please be patient. The main
definitions are done, but the serialization rules are problematic as too
much information gets lost.

> | 3.3 Para immediately preceding SAM Constraint heading
> | What happens if the only difference between two entries is the
> | source locator chosen to reify the topic map item? Surely this isn't
> | a conformance issue!
>
> 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?

Only if this means that the source locators get ignored during the
SAM->instance transformation.

Re
>| 3.4 4th para
>| "Every topic represents one, and only one, subject" is incorrect.
>| Suppose I create a supertype node that brings together the subjects
>| of "astronomy" and "quantum theory". There is no known name for this
>| subject so I create a new topic and name it Astronomy & Quantum
>| Theory". Is this topic really about only one subject? (I know what
>| you are trying to get at, but the wording is inaccurate!)

>I've tried to fix this in the latest draft:
  <URL: http://www.isotopicmaps.org/sam/sam-model/#d0e532 >

>Do you think the new wording works better?

I still have problems with the "one, and only one," bit. If you said "a
single" I would have no problem, its the "and only one" that kills the
ability to have subjects that combine other subjects as per my example.

> | 3.4.1 Subject address
> | The definition of the term subject address is inadequate to make it
> | clear where and when subject addresses can be used. To me "a locator
> | that refers to the information source that is the subject of a
> | topic" is a statement that could refer to any occurrence identified
> | by the topic. I do not think this is how the term is used within the
> | SAM, but why it should not be used in this way is unclear. A clearer
> | distinction between subject indentifier and subject address is
> | required.
>
> Hmmmm. Doesn't this make it clear that the subject address points to
> the *subject* of the topic, as opposed to a relevant information
> resource, which is all occurrences do. So that if topic X has
> <URL: http://www.google.com > as its subject address, the subject of
> topic X *is* Google's home page?
>
> The subject identifier, on the other hand, points to a subject
> indicator, and a subject indicator is an information resource that
> describes what the subject of the topic is.
>
> Do you still feel that this is not clear, and that the text is not
> making this obvious to readers? If so, I'll add in the examples to see
> if that helps, and you can review that.

Examples are really needed, ideally with an accompanying diagram showing the
relationships.

> | 3.4.1 Issue (term-subject-indicator-def)
> | Acts Ch11 V5 is a subject indicator that does not refer to "a
> | specific" information resource, but could still exist as a locator
> | of the form urn:purl:bible:JamesI:Acts:Ch11:V5 or some equivalent
> | identifier.
>
> I agree that this is possible, the question is just what we do with
> the spec to make it handle such situations. A URI may potentially even
> identify things that are not information resources in any sense of the
> word, such as a person.

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.

  > | 3.4.5 Issue (prop-subj-address-scope)
> | Anything defined as a topic is a valid theme for a scope. This is
> | one of the reasons why I oppose making built-in subjects into
> | topics.
>
> I understood, and agree, with the first part, but you lost me on the
> second.

I don't want people using topics that define constructs in 13250 as scopes
as this would be a terrible misuse of these topics.

> | 3.9
> | ISO 13250 does not require all roles to be topics either. (One
> | reason for this is that it prevents situations where roles, and
> | occurrence types, get used to create scopes for topics.)
>
> What you say is true, but the thinking behind the text was that the
> HyTM deserialization specification would create topics from elements
> where the types were only specified as strings (as opposed to by
> reference to topics). As far as I know you are the only person who
> disapproves of this solution.
>
> If you feel this is important it would be good if you could describe
> what the use case for this is. That is, what are these alternative
> mechanisms good for, why do we need them? If you can explain that we
> can see if there is some way to meet this requirement.

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.

Martin Bryan