Re: schema.org

Alexander,

Don't hold back! It isn't good for you to suppress how you really feel. ;-)

I won't bother to list all the entities that have adopted topic maps 
because that would be to engage in "truth squad" sort of tactics, which 
are the true mark of a cult.

The Semantic Web has gone from intelligent agents wandering the 
semanticsphere to simply linking data which may or may not be 
consistent, useful or documented. According to some linked data 
advocates, we sort all that out after it is all linked together.

If that is your idea of a winning strategy, then we may have different 
opinions about what it means to win.

Oh, true, a lot of employment has been gained from it, but that's like 
saying the MDM (master data management) folks have a great idea (it 
wasn't a winner in the 1980's and it won't be now).

I think most of our problems have been self-inflicted.

In part by advocating a model rather than results.

I am as guilty as anyone in that regard.

True, developers do need to know about topics, associations, occurrences 
but users need the information about their subjects, intelligibly merged 
together, in a way that gives them a noticeable advantage over other 
approaches.

Users could care less if we are using enslaved fairies to create the 
outcome.

Google has been winning because it always gives an outcome. And users 
can pretend they are engaged in useful work while sorting out the 
"results" of their search.

Topic maps could start winning by delivering a useful result that allows 
the user of a topic map based search to be more informed than users of 
other systems.

But the user in the topic map case need know nothing of topics, 
associations and occurrences. What they need to know is that a 
particular solution is delivering the information they need faster and 
more accurately than another.

We have to remember that none of the software architecture, language, 
model, etc., issues are religious issues for users. And it is a mistake 
to try to educate users or convince them of one way or the other on such 
issues.

BTW, you might want to keep in mind that over 55% of researchers in 
genomics don't consult data sets created by others or the published 
literature in their research. Some people solve the merging of foreign 
data issue by ignorance.

What constructive steps would you suggest?

Hope you are having a great day!

Patrick








On 6/6/2011 7:04 PM, Alexander Johannesen wrote:
> Hi there,
>
> Patrick Durusau wrote:
>> The market share of topic maps isn't as large as it could be but the
>> statement it has "no market share" is simply false.
> Based on what? One can be a bit pedantic and say that a 0.00001%
> market penetration is higher than absolute zero, but who are you
> trying to kid? In the context of other SemWeb technologies - which,
> despite the differences between them, is where our market is - I think
> it's fairly obvious just how minuscule TM is, to the point of being
> irrelevant as a whole. No market share is pretty much correct,
> especially the way that phrase is normally thrown around.
>
>> Topic maps have capabilities, such as merging different vocabularies that
>> represent the same subjects, which is highly relevant, particularly in an
>> enterprise context.
> We all know the capabilities of Topic Maps. Damnit, it's why we're
> still here, still fighting this ridiculous uphill battle because *we*
> believe in it, we know what it can do, we understand its importance
> and we certainly love and embrace its peculiarities. But the
> wonderfulness of Topic Maps has no relation to market share, actual or
> potential, at least not anymore. We're a cult, really, still thinking
> our way is the better way and we shall persist, even if the rest of
> the world have moved in a different direction.
>
>> It is also true that not trying will leave topic maps with less than its
>> full market share.
> That's why we're still here, trying. Merging, deduplication,
> compounds, node saturation, it's all funky, crazy stuff that a lot of
> us understand the importance of intuitively and hence we persist, but
> man, I tell you, getting myself so caught up in Topic Maps is the
> worst career move I've ever made. Not bad for the knowledge and
> experiences that fell from it, but for the potential of employment and
> applicability of the specifics to normal technology stacks. Although,
> I have to wonder sometimes the implications and hints within the fact
> that the old farts who started this whole thing have long since
> abandoned this ship. If they did, why do I keep digging this hole?
>
>>> We have already good tools: RDF and SPARQL. :)
>> Yeah, right. Oh, I forgot, they can't distinguish a locator from an
>> identifier unless we re-wire the web to produce 303s to cover up TBL's
>> original identifier mistake. (BTW, addresses are inherently ambiguous if you
>> think about it.)
> Again, this is potential vs. actuality. *We* know this, we have better
> solutions to it, but for some bizarre reason the world is more than
> happy to apply a bunch of hacks to a faulty stack rather than doing
> the right thing. (And to put it in perspective I regard RDF as a
> mistake, but SPARQL as an improvement :)
>
>> Which ignores the fact that we have 6,000 years worth of previous
>> identifiers and references made using those identifiers.
> Again, you put far too much trust in your fellow human-beings' ability
> to understand persistent identity management issues. Most of the time
> they can't get past the is_a / has_a distinction, or the difference
> (perceived or potential) between an entity and a property (just like
> there's a very good reason TM don't have properties). Taking the step
> further and understand the *reasons* for doing the things TM does is
> just not it. It's the hardest thing to explain about it to people.
>
> "But I can create those relationships in my RDBMS, so what's the point?"
>
> Indeed. A long spiel later of all the in's and out's of the many
> layers of abstraction, the development cycle, the ontological
> argument, the persistent identity reasons, the subtle difference
> between internal, external and published identifiers, the standard
> models, the proxy debacle, the argument from technology detachment,
> and on and on it goes, all wonderfully good arguments that all make
> sense ... at the end of all that, people will return to what they
> know, no matter how flawed. And that's because they at least can do
> that.
>
> People aren't ready for Topic Maps, even after all these years. People
> are happy to muck around in flawed systems, as long as results that
> they get are compatible with their flawed thinking. Sorry to be a
> dippy-downer, and I appreciate your hard work and fervent zeal and
> wish that a fraction of what you point out would make a difference.
>
>
> Regards,
>
> Alex

-- 
Patrick Durusau
patrick-Q/[email protected]
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau