[sc34wg3] Merging/Viewing subject proxies

[Patrick Durusau]

Greetings,

In some off-list discussion the comment has been made that Newcomb and I 
are too focused on properties of subject proxies. While I disagree for 
the most part with that assessment, I do think it is the case that 
concern has obscured a more fundamental aspect of the TMRM.

Consider the following three cases, written using Barta's shorthand for 
subject proxies:

1. Two subject proxies, only one property:

System
Identifier

aaa = { < name = "rabbit" > }

bbb = { < name = "rabbit" > }

Assuming the appropriate disclosure, these two subject proxies will be 
merged/viewed as representing the same subject.

2. Two subject proxies, one property that causes merging/viewiing and 
other properties:

System
Identifier

aaa = { < name = "rabbit" >, < webresource = "www.rabbitnetwork.net" >}

bbb = { < name = "rabbit" >, < webresource = 
"en.wikipedia.org/wiki/Rabbit" > }

Presuming a disclosure that says merging/viewing as one subject proxy 
should occur when the "name" property is the same and a rule for viewing 
the webresource property, one view would be:

ccc = { < name = "rabbit" >, < webresource = "www.rabbitnetwork.net, 
en.wikipedia.org/wiki/Rabbit" > }

3. Two subject proxies, with other properties, plus a property added to 
cause merging/viewing as one subject proxy:

ddd = { < name = "rabbit" > < webresource = "www.rabbitnetwork.net" >}

eee = { < name = "coney" > < webresource = 
"en.wikipedia.org/wiki/Rabbit" > }

Hmmm, well we "know" these subject proxy represent the same subject 
(either by assumption or because I just said that it was so) but so far 
there is no basis for merging/viewing these subject proxies as one 
subject proxy.

So, assume we have a rule from another disclosure that says, when you 
see name = "rabbit" or name = "coney", add the following property to the 
subject proxy:

classification = "Oryctotagus cuniculus"

so now we have:

fff = { < name = "rabbit" >, < webresource = "www.rabbitnetwork.net" >, 
< classification = "Oryctotagus cuniculus" > }

ggg = { < name = "coney" >, < webresource = 
"en.wikipedia.org/wiki/Rabbit" >, < classification = "Oryctotagus 
cuniculus" > }

And the rule for the "classification" property says, when two or more 
classifications are the same, view as one subject proxy.

hhh = { < classification = "Oryctotagus cuniculus" > hmmm, but wait, how 
to deal with the other properties? ..... }

What Steve and I have been presuming and not saying very well, is that 
when two or more proxies are viewed as one, the disclosure that governs 
each property always governs how that particular property is viewed.

That is to say that the person who wrote the rule on adding the property 
"classification," need not worry about specifying anything other than 
when to add the property, specifying if it is the basis for viewing 
multiple subject proxies as one, and how to handle viewing it as one 
property when multiple proxies are viewed as one proxy.

Similarly, the disclosure that governs the name and website properties 
controls how those properties are combined, resulting in:

hhh = { < name = "rabbit, coney" >, < webresource = 
"www.rabbitnetwork.net, en.wikipedia.org/wiki/Rabbit" >, < 
classification = "Oryctotagus cuniculus" > }

Of course I am presuming that the disclosure for "name" allows the 
creation of a list of names and provides that if any of the "names" in 
the list match, further viewing with other subject proxies that have 
either "rabbit" or "coney" for the name property will occur.

The elegance of this approach is that it allows any number of possibly 
unknown properties of a subject proxy to continue to be governed by 
their respective disclosures while maintaining a trail of what 
properties were responsible for multiple subject proxies being viewed as 
one subject proxy.

NOTE: The idea of governance of a property is WITHIN a particular view 
(set of disclosures) of an set of subject proxies. If a different set of 
disclosures is used for a set of subject proxies, it's very likely that 
different rules govern the properties found within subject proxies.

In other words, the properties of proxies are viewed by the rules that 
are imposed by a set of disclosures. They do need to be identified with 
whatever disclosure is governing them in a particular view, but that is 
simply to avoid conflicting rules governing a single property. 

So, yes, we have been concerned with properties but that is because 
properties are what indicate subjects (the basis for viewing multiple 
proxies as one), provide other information about subjects, while subject 
proxies are containers that can expand to contain different ways of 
indicating the same subject. (Bernard's "hubjects.")

The latest draft focuses on constraints, types and disclosures with a 
great deal of formality but all of that is simply to enable any 
implementation strategy to support any disclosure concerning any subject 
proxies, which may represent any subjects.

Hope everyone is having a great day!

Patrick

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!