[topicmapmail] Fragmented XTM for web metadata, and some ontology?

[Kal Ahmed]

Alexander Johannesen proposed:

> >   <topic id="dc:type">
> >      <subjectIdentity>
> >         <subjectIndicatorRef
> >             xlink:href="http://purl.org/dc/elements/1.1/type" />
> >      </subjectIdentity>
> >   </topic>
> > 
> > ( id-attributes follow the DC recomended guideline for DC in XML )
> 

and On Thu, 2003-06-26 at 14:29, Murray Altheim wrote:
> I'm not sure when the guidelines were written, but the colon is prohibited
> as a name character nowadays, in accordance with the XML Namespaces 1.1
> Recommendation:
> 
>    http://www.w3.org/TR/xml-names11/#Conformance
> 
> The reason it was allowed as a Name character was to allow experimentation;
> in the end I believe it was decided that "namespaced IDs" didn't make much
> sense. Thank God for that.
> 

Perhaps you can use the dc.title form that is used in the HTML
representation of DC instead ?

> > I had some problems groking the associative DC metadata in Jan's 
> > document, but that might be because I don't understand why
> > they should be expressed that way. Maybe my thinking is very
> > slow, but I'd like an ontology (called FXTM for now) ;
> > 
> [example elided...]
>  > My thinking says that for a given page, you have the following XTM;
>  >
> >   <!-- root node is the fragmented XTM's resource -->
> > 
> >   <topic id="root">
> >      <instanceOf>
> >         <topicRef xlink:href="#fxtm:page"/>
> >      </instanceOf>
> >      <occurrence>
> >         <instanceOf>
> >            <topicRef xlink:href="#dc:title" />
> >         </instanceOf>
> >         <resourceData>Some title</resourceData>
> >      </occurrence>
> >      <occurrence>
> >         <instanceOf>
> >            <topicRef xlink:href="#dc:date:publish" />
> >         </instanceOf>
> >         <resourceData>[Some date]</resourceData>
> >      </occurrence>
> >   </topic>
> > 
> > Where the TMs for FXTM and DC are implicit part of the
> > namespaces used (and merged in according to the FXTM
> > spec?).
> 
> I don't think it's appropriate semantically to include properties
> of a given topic as occurrences of that topic -- it's just not
> sensible, doesn't "read" right to me. You yourself stated the sentence:
> 
>      "here is the resources"
> 
> which is essentially saying "here are the untyped values". Since we
> want to both name and type our values, and because occurrences don't
> have names, each facet is a topic.
> 

This is where I differ. My understanding of the semantics of occurrence
is that an occurrence specifies some information that is in some way
related to the subject. I do understand that a number of other topic map
practitioners believe that an occurrence is only a resource in which the
subject is mentioned or described in some way - so whereas I would say
that metadata such as creation date can be expressed in an occurrence,
they would point at the occurrence and say "where's the subject ?" :-)

With regards to the DC title element I have more sympathy for Jan
Algermissen's analysis that dc.title == baseName.

> > I don't know. Maybe I'm mixing things up too much, or
> > maybe I'm missing the incredible power of making the
> > occurrences topics instead with associations binding them, but I feel 
> > that becomes more of an application specific way than a general "here 
> > is the resources" way;
> > 

What the RDF people found was that if you have literals you reduce the
reliability of merging (smooshing to use the RDF term...no, really!) but
perhaps for a meta data element that is a value from a range (e.g. date,
age, size, GPS position) that is all you can do scalably.

<snip/>
> > 
> > Basically, what I want is a PSI set for the FXTM set
> > (both roles and types), and a set of PSIs for DC. The
> > latter is the easy part. Where should I turn for the former? Is there 
> > anyone looking into a loose web browsing ontology?
> 
> You might look at the "topic map-based" XFML, at http://xfml.org/
> which I believe is designed to solve either the same or a similar
> problem (depending on how I understand your question).
> 
> By some coincidence, I happen to be working up a short specification
> for doing facets in XTM, with the idea that you can associate a
> name-value pair to a given topic.
> 
> BTW, Kal Ahmed has a PSI set for faceted classification (FC), and
> we're discussing various aspects of it right now. I'm looking at the
> description of facets in ISO 13250 as well as how FC works, as while
> the use of "facet" is the same, there are some differences (as might
> be imagined from terms coming from different communities). I'm
> particularly interested in the overlap, for my own work.
> 
> I hope to publish the "Facets in XTM" draft within a week or so. If
> I haven't by July 10th, it'll probably be in two weeks after that
> (as I'm out of town and probably disconnected). I'll be updating my
> "Datatypes in XTM" document at that time as well, as it is used in
> typing the facet values, e.g.
> 
>    "Birthday" has type "dateTime" and value "1961-07-04T20:00:00Z"
>    "Birthday" has type "date" and value "1961-07-04"
> 

Ranges are the issue that I haven't addressed with my proposal for
facetted classification - in my model a facet value is taken from some
hierarchical classification scheme. So the facetted classification model
that I propose is merely a way of indexing topics by multiple disjoint
hierarchies.

> I have had a DC topic map for about two years now, unpublished. Since
> that might be useful with the facet TM, if I have time I'll also put
> that online.
> 

> Since the term "facet" also occurs in XML Schema datatypes, I'm
> starting to feel a bit surrounded by the damn things, like some
> kind of bad drug trip...
> 
As long as the topics don't turn into lizards and you don't end up in a
Las Vegas casino with your lawyer, you'll do just fine :)

Cheers,

Kal