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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

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


Subject: Re: [tm-pubsubj] Requirements oddity


Steve,

Quick response:

Agree that the metadata in the Published Subject Indicator should be 
used to decide issues such as trusting the Published Subject Identifier. 
(Distinction between metadata about Published Subject Identifier versus 
being about Published Subject Indicator not worth pursuing.)

Also agree that (in part), the usage of dc elements should be:

dc:subject="apple"

dc:type="Published Subject Indicator"

(Which removes the need to use dc:description.)

Hope you are having a great day!

Patrick

Steve Pepper wrote:
> * Patrick Durusau:
> 
> | > | <rdf:RDF
> | > |      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
> | > |      xmlns:dc="http://purl.org/dc/elements/1.1/"/>
> | > |     <rdf:Description
> | > |         rdf:about="http://psi.fruits.org/apple.html";
> | > |         dc:publisher="Johnny Appleseed"
> | > |         dc:description="Apple: Round firm fleshy fruit of a rosaceous
> tree"
> | > |         dc:type="Published Subject Indicator"
> | > |         dc:date="2003-09-14" />
> | > | </rdf:RDF>
> | >
> | > This is fine as it is ... except that dc:description is misplaced.
> | > You have provided a description of the subject itself, not of the
> | > subject indicator (or identifier).
> |
> | I don't think "description of the subject itself" is quite right.
> 
> I agree.
> 
> | Dublin Core defines description as: "An account of the content of the
> | resource."
> 
> So your use of dc:description is inappropriate, right?
> 
> A more appropriate "dc:description" might be
> 
>   dc:description="Published subject indicator for 'apple'"
> 
> | On the other hand, dc:type, which is defined as: "The nature or genre of
> | the content of the resource." does seem to fit rather well.
> 
> I agree. In fact if you added
> 
>   dc:subject="apple"
> 
> then the combination of dc:type and dc:subject would render
> dc:description superfluous...
> 
> 
> | > I still don't understand why software needs metadata about identifiers
> | > rather than indicators.
> | >
> |
> | Hmmm, I suppose under the theory that each identifier is bound to an
> | indicator (requirement for being a PSI), then it may be sufficient for
> | the metadata to be "about" the indicator. It is by implication also
> | about the identifier in some sense but it may not be necessary to go there.
> 
> I really do think that the identifier is an attribute (locator) of
> the indicator and therefore in some sense "inherits" some of its
> metadata. I don't see any need to have additional metadata about
> the locator, especially given that metadata about an information
> resource (e.g., a subject indicator) is a well understood and widely
> used concept, whereas metadata about a locator is definitely not...
> 
> | What I was envisioning was a circumstance where I have software that
> | trusts some identifiers and not others. The bare identifier, without
> | more, does not give me any basis on which to distinguish those I trust
> | (apart from domain name) from those I don't. Having the metadata in the
> | Published Subject Indicator be "about" the identifier, I can distinguish
> | (assuming required) on the basis of date, publisher, other required
> | metadata? I might trust identifiers from Idealliance but only those with
> | dc:creator of "Jane Harnad."
> 
> But where would you go to find that metadata? You would have to
> resolve the identifier to the indicator. Once you have that, you
> might as well use the indicator's metadata, which will tell you
> who created the indicator and - by extension - who assigned the
> identifier to it.
> 
> | As I noted, it may be a distinction without any real difference. I could
> | treat the metadata in the Published Subject Indicator as determining
> | whether I trust the Published Subject Identifier.
> 
> As should be clear by now, that is exactly what I think you should
> do!
> 
> Steve
> 
> --
> Steve Pepper <pepper@ontopia.net>
> Chief Executive Officer, Ontopia
> Convenor, ISO/IEC JTC 1/SC 34/WG 3
> Editor, XTM (XML Topic Maps 1.0)
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/tm-pubsubj/members/leave_workgroup.php.
> 
> 


-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau@sbl-site.org
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

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




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