Topic Map Specifications | Customize | Filter | Export | Merge | Statistics | DB2TM | Edit | Vizigate | Query | No schema
[No name] (1)
Scoped Occurrences (43)
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
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.
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.
i thought that maybe 'nameString' was
we should define it for completeness. As
[with strings]: 0 elements and not null.
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.
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.
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.
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.
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.
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
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.
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.
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.
we could leave this one to be
addressed by the conformance activity?
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
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.
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.
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?
probably not but we shouldnt
enforce it. again maybe a warning if the processor deems it useful.
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.
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.
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.'
not at all. this is well out of
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.
tnc is gone basically so i feel these
defs are ok - if not yet perfect.
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.
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.
no the thing reified by
a topic is not a characteristic.
yes its allowed. if it doesnt validly
ref something then tough luck.
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.
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.
yes i think it is.
personally i hate basename. we should
really drop basename and use topicnam - but i guess the syntax legacy
stops us from doing so.
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.
Locating the schema information should be
kept separate from the SAM, and TMCL should be responsible for linking
constraints to the topic map.
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.
I think that makes sense.
not our problem.