[sc34wg3] revised draft Reference Model document N0298

[Graham Moore]

Martin,

Steve and Michel please read as well... :)

As I said its just a draft and there are still many errors in it.

The resource references are merged as they are the same string value or =
the implementation on top is clever enough to know that they resolve to =
exactly the same resource. However, my point was not about the rules of =
merging but about the fact that the reference model seemed to indicate =
that the topics that ARE the VALUES of a resource referennce were to be =
merged and NOT the topics that were identified by these VALUES.=20


 'gdm' ----- subjind ----- [topic #1224]=20

  [topic #1234 ] ------ name ------ [name] ------ name value ---- 'gdm'


In this model which is the reference model - there is a topic 1224, it =
has a subject indicator   - done as an assertion 'subjind', where the =
value is the STRING 'gdm'. That STRING in the reference model is a =
TOPIC.=20

If I introduce another topic with a name - the 'name' and 'name value' =
are assertions and the STRING value of the name is a topic. Merging must =
take place focused on the topic that is being identified NOT the =
identifier?

In the case above according to the reference model - we'd end up with

[topic #1234 ] ------ name ------ [name] ------ name value ---- =
'gdm'----- subjind ----- [topic #1224]

hmmmm - i dont think that looks right. It is broken because 1. the =
topics with identity have nto been merged but the identities themselves, =
2. there is no distinction in the different types of STRINGS to control =
why they are merged.

So once again I call on the editors to consider making Identity an =
explicit part of the model and not one defined in terms of assocaitions. =
RDF resource is undecipherable from the identity string that identifies =
it. We have more even more powerful forms of identity and we cannot =
afford to lose that value. Consider in RDF

s1 :=3D (urn:person:gdm, urn:rel:worksfor, urn:company:empolis)

identity and thing are one and the same - there is no abstraction =
beneath this - mainly as its so tenuous

Best I could come up with is...

(#arbitratily_assigned_identity_by_computer_system, urn:fundamental:id, =
urn:person:gdm)

Why would I want to do this kind of thing? If the answer is to reduce =
everything down to binary predicates then why dont we just start from =
there? TopicMaps might be useful if it builds some useful abstractions. =
This just seems like saying 'hey we can keep breaking things down into =
smaller parts' - well yes we can - but we all know that.=20

graham


-----Original Message-----
From: Martin Bryan [mailto:mtbryan@sgml.u-net.com]
Sent: 10 April 2002 03:08
To: sc34wg3@isotopicmaps.org
Subject: Re: [sc34wg3] revised draft Reference Model document N0298


Graham

>ASSOC    :=3D  (TYPE x MEMBER*)

Under what conditions are the members optional in an association (or is =
this
to do with templates?)

I'm not sure about:

>Which basically says that a Topic is comprised of a set of identities. =
Each
identity has a value. That value is either a - =
referenceToAResovableResource
(resource ref)
- a piece of data (name string)
- a subject indicator (specifically some URI etc - which isnt the topic =
but
indicates the nature of the topic)

>When I merge I should merge names that are the same, subj refs that are =
the
same and res refs that are the same.

Under what conditions is if valid to merge resource references?

Martin

_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.

_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service.