|
|
Occurrences of this Type (88)
-
1.1 ? But if so, then there we need a
backward compatibility chapter (and maybe an XSLT sheet). (xtm-version)
-
1.1. AFAIK, we are only adding instanceOf on
baseName (and possibly allowing resourceRef in three more
places). Even if we add variants to occurrences, I still don't think
that justifies going to 2.0. From the point of view of conveying
stability, we want these changes to be seen to be minor tweaks. (xtm-version)
-
Apart from all the subject/topic stuff there
is another argument to drop the 'topic', 'association' and
'occurrence' PSI's. They are most uninformative. Since any topic is
an instance of class 'topic' by default (unless specified otherwise,
says XTM), there is no information involved that is of any use to
anybody. The user of the Topic Map will not want to see the class
'topic' listed among the classes of a topic; therefore a Topic Map
engine will have to suppress it, and it makes no sense to me to
introduce a property which only needs to be suppressed later. For the
Topic Map engine there is also no useful information in the PSI, since
Topic Map engines 'know' what topics are (i.e. how to process them)
without using this PSI. So to me it seems a piece of redundant
information. Same goes for the 'association' and 'occurrence' PSI's. (psi-generics)
-
Bare names. (xtm-href-xpointer)
-
Given the possible multiple types of
schema/DTD for Topic Maps based on ISO 13250 architectural forms, SAM
should record the source of this information. (prop-schema)
-
I agree that this is not a strong form of
"conformance" and that TM?L will be a much stronger vehicle to do
that. (sam-conformance)
-
I believe unwarranted merging would occur
when using the TNC if it weren't "All-themes," and that therefore
scope should be defined as made up of all themes. (term-scope-def)
-
I dont see an issue here. We have
the notation property and we say the default is URI. fine. There is
nothing to stop new notations coming along. At the moment we dont have
any form or enumeration of notation types and i dont think we
should. (prop-notation-interp)
-
I dont think it matters. I think we
state that is it retrieved based on matching subjinds and srclocs and
implementors can choose if they do a computed look up or its just
there. (prop-reifier-computed)
-
I dont think we define it. If
for no other reason than we dont have to define what equality is other
than the locator. If i had to take the other extreme position i would
take the one similar to library science that distinguish between the
concept of a work and the individual work. In tm I would adopt a
position that this is a stream of bytes from a location. i.e. it is
the individual work. (term-subject-address-def)
-
I like URIs a lot. Yes. (xtm-schema-uri)
-
I tend to think a PSI for "topic" is of no
use at all (psi-generics)
-
I think TM needs the concept of a
literal. If a topic is a string it has to be the concept of a
particular string and not an individual instance. If people represent
the concept '1' or 'gra' as a topic thats up to them. But for it to be
useful i think they need to be able to have a topic or probably a
literal that is a particular instance of the concept. (strings-as-subjects)
-
I think it is more likely that it
is the [subject indicator] property which is incorrectly named. The
thing you get from this property is the address of the resource, not
the resource itself and the name should reflect that. (prop-subj-address-name)
-
I think it would help to state that 'an
application is some computer process that provides functionality where
that functionality utilises a tm processor and the topicmap(s) it
manages.' An application itself does not manage the storage or
structural integrity of topicmaps. This is done by the TM Processor.' (term-application)
-
I think that makes sense. (xtm-schema-uri)
-
I think that the SAM should be concerned only
with the information model for topic maps. Any adjuncts to handle
topic map schema should be built on top of the SAM. Presumably it
should then also be a goal for TMCL and other extension specifications
to ensure that any additional information items are available as
computed properties from basic SAM properties. (prop-schema)
-
I think this is out of scope for
us. I think we should say that if tm processors wish to apply schemes
for deciding syntactic equivalence then they can do. But i dont think
we can force this on people. (locator-normalization)
-
I would prefer if TM processing does
NOT do too much link magic. If we keep it orthogonal then the
standard has some freedom later. (xtm-href-xpointer)
-
I would tend to the any-subject view for
backward compatibility if there is a reasonable way around the
problems with the set of all topics (or similar contructs). (term-scope-def)
-
ISO 13250 deliberately allows
subject identity to be "inferred from the topic's characteristics."
SAM does not seem to allow for this. (subject-identity-establish)
-
ISO 13250 does not recognize the
"occurrence" default type introduced for XTM. If this is imposed on
the standard, then a means of clearly distinguishing default types
from user-defined types needs to be added to the model so that imposed
subjects specific to the management of the model can be distinguished
from the subjects that the author specified as part of the Topic
Map. (xtm-def-occurrence-type)
-
ISO 13250 specifically states that
the subject identify "may or may not be machine-interpretable, or may
or may not be online". As noted above, it can also be "inferred from
the topic?s characteristics." Therefore SAM should not confuse subject
and resource as they are clearly two different things. (subject-vs-resource)
-
If there's no place to put them in the
SAM, they have to be removed. Any elements for which the corresponding
information item doesn't have a source locator will have their IDs
ignored. (xtm-unused-ids)
-
It should be possible to create
topics that represent strings. I might want to create a topic that
refers to all occurrences of the string XML (strings-as-subjects)
-
It should become the source
locator. (merge-srcloc-vs-subjid)
-
It's useful. (term-theme)
-
Locating the schema information should be
kept separate from the SAM, and TMCL should be responsible for linking
constraints to the topic map. (prop-schema)
-
My feeling is that the SAM should only
concern itself with those rules for scope that are required to make
the SAM internally consistent and to allow the application of rules
such as name-based merging and duplicate identification. As far as I
can see, there is a need to express a rule for equivalence of scope
sets and that is it. (term-scope-def)
-
No magic here please. This is NOT about
hyperlinks, btw. (xtm-xlink-actuate)
-
No, raise error. This is XML, anyway,
so strictness is ok. (xtm-href-whitespace)
-
No. xml:base is an ugly cludge
which is mostly used to hide design flaws. If someone needs it he can
create submaps. I could live with it on the toplevel, but that's about
it. :-) (xtm-xmlbase-everywhere)
-
Normalization Form C should be
adopted in conformance with W3C rules for XML. (string-normalization)
-
Occurrences with no type should
have an undefined relationship instead. What practical purpose does
this default type serve? (xtm-def-occurrence-type)
-
Re "Does it represent that
storage location" the answer must be no. What if the address is
reassigned to different hardware containing a copy of the referenced
resource? What if the address is notational, as in the above example?
What if there are multiple copies of a particular resource (whether
notational or not, as per retrieval from caches rather than the
original resource)? This must be left an open issue for applications
to determine. (term-subject-address-def)
-
Referring to RFC 2396 is likely to
only be relevant for a short while. Already IETF have published a
draft on Internationalized Resource Identifiers (IRI) that may well
replace this specification in the longer term. The requirement that
all other values must begin with ?x-? is unsupportable given that IRI
might be needed in place of URI by the time SAM is published by ISO. (prop-notation-interp)
-
Say little that is normative, and you
can say a lot that is non-normative. I would not want my subjects to
be constrained in any normative way. (term-subject-def)
-
Since the definition is broken
anyway, and there is no clear need for it, I suggest it be dropped. (term-subject-identity)
-
So, I really do think that conformance to
the SAM (or TMM) makes not much sense at all, it is entirely a matter
of API/Query languge conformance. (sam-conformance)
-
Spaces within a URL are disallowed,
so strings are simply not URLs of they contain them. All spaces should
be escaped (a '%20'). (xtm-href-whitespace)
-
The DTD. (xtm-normative-schema)
-
The XTM syntax needs to be
extended so that source locators can be represented in full. (prop-srcloc-interchange)
-
The concept of theme was deliberately
introduced into ISO 13250 to avoid the ambiguity that occurred when
the word topics was used to describe the set of referenced topic map
concepts used to scope an item. Dropping this term is likely to lead
to ambiguities within SAM. (term-theme)
-
The part about the subject...is it
necessary here? Looks more as an abstract introduction into TMs. (term-subject-def)
-
The requirement that variant names be
associated with specific base names is incorrect. A topic with more
than one base name would have to repeat the variants associated with
that base name for each base name. (This was a deliberate design
feature of ISO 13250 as it was realised that the same symbol could be
used for a topic which had been assigned multiple base names, either
as synonyms or as language-specific versions.) (variant-in-basename)
-
The way in which a subject
address relates to a subject is in many ways related to the means of
dereferencing the address. For example, a single http: protocol URI
can be dereferenced to many different byte sequences - so the subject
address cannot be considered to represent the content at that
location. Equally, a urn:isbn: reference cannot be dereferenced at all
and could be considered meaningless as a subject address, whereas a
unique object identifier in a content management system may actually
always return precisely the same sequence of bytes and so could be
considered to represent a specific binary object. It might be useful
for the SAM to say something about the stability requirements of a
subject address - e.g. to represent a specific binary object, a
subject address must be given in a notation which cannot be
interpreted in such a way as to retrieve two different byte-sequences
(excepting error conditions such as network or server outages). (term-subject-address-def)
-
There is too much text about subjects
and their nature. is this really relevant in the sam spec? (term-subject-def)
-
This issue is determined by
term-scope-def. If scope is "all subjects" then the unconstrained
scope must be the empty set, while if it is "any subjects" it must be
the universal set. If we choose to leave scope undefined this issue
will require some thinking. (scope-unconstrained-rep)
-
This may constrain subjects, so I
would be hesitant to do this. (subject-vs-resource)
-
This property should not be a
fundamental property. (prop-reifier-computed)
-
To fully represent ISO 13250 Topic Maps
SAM must allow for locators that do not address information resources. (locator-reference)
-
Unless/until there is a common API, I
think SAM conformance in terms of an API are pretty meaningless. What
is not meaningless though are the operations that the SAM requires a
topic map processor to perform and validation that a processor does
indeed perform those operations is probably best done not by
inspection but by testing the application against a conformance test
suite. So SAM + CXTM + conformance test suite is needed to prove the
level of conformance which I as a user would expect from an
application, and to which I as a developer would build my topic map
processing software. (sam-conformance)
-
Yes, they should be merged. (reifier-merging)
-
again this is an error. the
question is do we have any operations or other semantics defined
within the SAM that will be confused or operate erroneously if we dont
define this an error. (merge-same-subj-ind-addr)
-
erm - yes i think so. What
situation were you considering where this wouldn't be needed. If a topic
always has to be in an topicMap parent element. (xtm-topicref-fragment)
-
how do names have identity? Through
being reified by a topic? Through having the same literal value? This
is bad jazz and i think we want to avoid it. (names-as-subjects)
-
i thought that maybe 'nameString' was
better. (prop-value)
-
in an ideal world i think yes it
should. This are the kinds of details that make the standard robust
but also increase the bar in terms of implementation participation.
However, i think there is one major factor that prevents us from
defining this constraint and that is that we dont define the semantics
of type. We simply have it as a property of a topic. But unlike
conventional knowledge modelling standards we don't define the concept
of class-subclass nor the notion of transitivity - both of which are
truly fundamental to being able to answer the queryion 'what type is
this topic'. given we dont define it people are free to say in their
applications that certain types extend or inherit from other types.
Thus how are they or more importantly another tm processor to know how
to answer the question 'Is this reified name of a valid type?'. Lets
not constrain these aspects yet. The development overhead is high and
the semantics unclear. (reification-effects)
-
lets say so. but perhaps define or
say why the tm definition is more refined. i.e. we can distinguish
whether the resource is network retreivable etc. (subject-vs-resource)
-
lose it. (term-theme)
-
no the thing reified by
a topic is not a characteristic. (term-topic-characteristic-reified)
-
no. a topic that just is, just
is. We have already stated earlier that topics have identity within
the tm processor independent of any properties. Even subjinds. (subject-identity-establish)
-
no. nulls should be allowed. but
maybe not nulls in both places? i.e. you have to have either role
player or role type. i.e. you either dont know what is playing the
role or you know this thing is associated but not yet why. (assoc-role-player-type)
-
not at all. this is well out of
scope. (merge-use-of-schemas)
-
not our problem. (infinite-subject-spaces)
-
not really for sam to do. I would
expect the OASIS group on PSI technology, whatever, to have some meta
semantic to resolve the psi server etc. not out job. (psi-identification)
-
not sure. it can be added without
breaking any existing stuff which is good. But do we really need it?
What does it mean to interchange srclocs? (prop-srcloc-interchange)
-
ours is not to reason why. perhaps
someone wants to do some merging, turns on tnc and gives the topics
they want to merge a basename of "". Other than that its silly and
should probably not be allowed. (prop-value-null)
-
personally i hate basename. we should
really drop basename and use topicnam - but i guess the syntax legacy
stops us from doing so. (term-topic-name)
-
probably dtd compliance. software
etc and perceived reliability of tm is preserved as people will at
least only be importing valid xml instances of xtm. The engines can
throw back invalid xml errors rather than topic map exception. (xtm-unknown-elements)
-
probably not - but i dont think
we should enforce it. Can we have an optional exception or warning?
This feels more like a warning. Kind of like in Java when you cast a
long to an int and you get a precision warning. (prop-subj-address-class)
-
probably not but we shouldnt
enforce it. again maybe a warning if the processor deems it useful. (prop-subj-address-scope)
-
probably...? What if you just have a
stream of xtm from an unknown source? Is the base uri used here, what
if thats also missing. (xtm-same-doc-refs)
-
subject indentity is the collective
term for the formal identifiers of a topic namely a resoure reference
or subject indicators. Therefor i think it has a use beyond the xtm
1.0 spec definition. (term-subject-identity)
-
the name [label] would be a distinct
improvement. (prop-value)
-
the subject. The
topic is the proxy for the subject in the system thus they are about
the subject. A property such as 'when was this proxy created' is a
property of the topic not the subject. (term-topic-characteristic-assignment)
-
tnc is gone basically so i feel these
defs are ok - if not yet perfect. (term-base-name-def)
-
we could leave this one to be
addressed by the conformance activity? (op-topic-map-compare)
-
we should define it for completeness. As
[with strings]: 0 elements and not null. (term-empty-set)
-
we should evaluate them and not
be afraid to NOT model them in the same. i.e. constraints such as 'A
Topic that *is* a resource cannot be a used as a scoping topic.'. I'm
actually torn on this one. It seems like we'd be adding some sensible
'real-world' usage constraints. But this also prohibits people from
doing cool funky things we havent thought of yet. (xtm-implicit-constraints)
-
yes (prop-subj-address-values)
-
yes i think it is. (xtm-mergemap-reference)
-
yes its allowed. if it doesnt validly
ref something then tough luck. (xtm-href-whitespace)
-
yes they should and we should
declare tm errors if a topic reifies contradictort things. i.e. a name
and an assoc cannot be merged. (reifier-merging)
-
yes they should for completeness but
it MUST return the topic. Topics are like the hall of mirrors they are
reificantions of themselves and some subject. We need to end the
cycle, to complete it, from the platonic form to the abstracton. This
little pattern gives closure. (prop-reifier-topic)
-
yes we should define it. First stage
would be to say that the empty string is a Unicode strin of length 0,
explicitly it is not NULL. (term-empty-string)
-
yes we should distinguish. We have
already stated that we define structural constraints and operations.
Thus something like remove perhaps should be discussed. Perhaps only
informatively - but the structural constraint that there can be no
floating names once a topic has been deleted should hold
normatively. (container-props)
-
| Should say almost nothing about
subjects other than they are represented in a topic map by topics.
This is the topic map standard and not the "true world view
epistemology standard." (term-subject-def)
|
|
