OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [tm-pubsubj-comment] More grumbling

* Lars Marius Garshol
| In that case, probably what we should do is to establish some way to
| assert that a certain resource contain a PSI set using XTM, RDF, and

* Bernard Vatant
| Good idea. Do you think about having some "format slot" inside the
| URI?

No, I don't think that will work. For XTM and RDF it is easy enough:
just make a statement about the resource in question.

* Lars Marius Garshol
| For HTML I think we should take a close and serious look at HTML
| metadata profiles. I think they would be simple enough for people to
| use, yet formal and powerful enough for what we need. See
|   <URL: http://www.w3.org/TR/html401/struct/global.html#h- >
* Bernard Vatant
| We should explore that indeed, but it is another story than
| structure of URIs themselves.

Of course it is, but so what? Is there any particular reason to put
this information in the URI itself?
| Semantics of PSIs may be carried at three levels
| 1. In the structure and syntax of URI string itself
| 2. In the Subject Indicator metadata
| 3. In the Subject Indicator "body" (full text description or other
| kind of human-interpretable stuff)
| OTOH semantics for computers and semantics for humans are different
| and we need both, so what we have to figure clearly is which one we
| want to put where. If I understand you well, you would be happy
| with:
| No semantics at all in 1.


| Semantics for both humans and computers in 2, in the form of
| metadata.  More semantics for humans in 3.

Correct again.
| Steve's proposal is to put also some sort of semantics for humans
| and search engines in 1.

Yes. The only problem is that it doesn't work.
| I'm not sure about what we want for that matter. Do we want
| *anybody* to be able to publish PSIs?

Yes! Of course! Why on earth would we want to limit who is to be able
to publish PSIs?

| Is not that somehow in contradiction with the need of stability and
| trust? 

It is not for us to decide what need people have for stability and
trust. I don't see why we should make decisive judgments about this on
behalf of all the people who will ever use this.

I'm sure some PSIs will be unstable whatever we do, but I don't see
that that's a great tragedy. Published subjects. like the web, do not
break just because a URI returns a 404. Things still *work*, only not
quite as well as before.

| My view is that if publishers are really serious about PSIs, they
| should own dedicated domains.

That makes sense, but it's a completely different thing from requiring
| You would prefer then a recommended structure with psi folder, like
| http://anydomain.foo/psi/scope/subject.html

No. I would prefer an unrestricted URI. Let people do whatever they
want. They will, anyhow.
* Lars Marius Garshol
| Aha, so this is about humans, too, is it? I guess that means we should
| come up with some text that can be put in a PSD to identify the
| intention that it serve as a PSD.
* Bernard Vatant
| That is yet another story. Declaration of intention in 2 or 3
| above. No, what I wish - but is it technically sustainable, and how,
| that's the issue - is that the very structure and syntax of the URI
| itself may identify it as a declared PSI with a good reliability -
| it can't be 100% of course.  

It sounds to me like you are confusing the requirement and the
solution.  Why must there be something in the URI?

| So search engines (and humans as well) could easily retrieve
| candidates PSI simply on the view of their URIs, and confirm that on
| the view of required content and metadata in the resource.

But it won't work!
* Lars Marius Garshol
| I explained it below that statement: something that is meaningful to
| humans is something humans are likely to want to change at some point.
* Bernard Vatant
| Is it really an issue? 

Bernard, you really are unusually exasperating today. 

Of course it is an issue!  We've just seen that demonstrated, as you
yourself agreed.

| Remember "Big Oak Cross" and "Good PSIs never die" discussions ...

What discussion was that?
* Lars Marius Garshol
| And I agree that it certainly is difficult to come up with some
| abstract prose that provides useful guidance on when to use meaningful
| identifiers and when not to, but I am not at all convinced that doing
| so is within the scope of this TC.
* Bernard Vatant
| Why not? Who's gonna do that reflection if we don't? ;-)

Creation of published subjects raises all sorts of modelling issues,
and this is just one among many.
* Lars Marius Garshol
| I think the best we can do is to either leave this issue alone
| completely, or else to write a general "best practices" document and
| cover this as one of the issues there.
* Bernard Vatant
| You mean just setting the issue in the stable requirements and
| recommendations document, 

No, just leave it out. Don't say anything about it.

| and have, besides, a sort of living document where those kind of
| tricky and undecidable questions, and pragmatic best practices about
| it, would be brought about from real use cases? 

Yes. I guess this would be the last deliverable, chronologically.

| I like this idea.

Good! At least we agree on something today. :-)

Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC