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] Barcelona minutes

On Wed, 2002-05-29 at 03:07, Bernard Vatant wrote:
> Eric
> Thanks for your feedback.
> > Thanks for publishing the notes. As a lurker, these are very helpful.
> > More and more I'm convinced of a growing set of common functional
> > requirements for the effective managing data on the Web.
> Could you expand on that, and what you mean by "functional requirements"?

By "functional requirements" I mean by declaring concepts in a machine
processable manner.  Identifying the specific characteristics of the
concepts and formalizing the relationships of these concepts to other
concepts.  Including human readable information associated with these
concepts, etc. 

There are many more, but it should like some of your requirements and
recommendations are evolving to address some of these.

Working with many content producers I see very similar patterns.

'Best practice' suggestions (decisions how best to package things
together; whether each concept is separately dereferenceable or part of
a larger document containing many declarations, etc.), guidelines,
policies, etc. are still missing.  This is an area between the enabling
standards and the end user community that my hope this group in part
might fill. 

> > A couple of quick questions if I may...
> You are welcome :))
> > Can you provide an example of what an application might get
> > dereferencing a PSI.  If I do an http GET on
> > http://psi.fruits.org/#apple for example, what do I get back in the HTTP
> > header, message body, etc.?
> That's the next step. Steve Pepper should deliver an example of such an XHTML file ASAP.

I look forward to this.

> > Also, the above clarification to item #3 uses 'e.g'; were other means of
> > articulating formal assertions discussed?  If so, how in practice do you
> > anticipate supporting this requirement?  (e.g.  RDDL, HTTP
> > content-negotiation, other?)
> Well. No other means than XTM were technically discussed so far. The expression of Rec#3
> only means that there is no *required* syntax for those assertions, and the door is open
> to any other relevant suggestions ...

Yes, for formal assertions I additionally suggest RDF/XML be considered.
An example of a simple fruit vocabulary can be found

which basically makes the following assertions (fyi, entering the above
uri in http://www.w3.org/RDF/validator may be of interest to some):

<fruit:> <dc:title> "The Fruit Vocabulary defines ..." .
<fruit:> <dc:publisher> "The United Fruit Consortium" .
<fruit:> <dc:date> "2002-05-29" .
<fruit:> <rdf:type> <rdfs:Schema> .

<fruit:Fruit> <rdfs:label> "Fruit" .
<fruit:Fruit> <rdfs:comment> "An abstract notion of Fruit." .
<fruit:Fruit> <rdfs:isDefinedBy> <fruit:> .
<fruit:Fruit> <rdf:type> <rdfs:Class> .

<fruit:Apple> <rdfs:label> "Apple" .
<fruit:Apple> <rdfs:comment> "An abstract notion of Apple." .
<fruit:Apple> <rdfs:subClassOf> <fruit:Fruit> .
<fruit:Apple> <rdfs:isDefinedBy> <fruit:> .
<fruit:Apple> <rdf:type> <rdfs:Class> .

<fruit:Pear> <rdfs:label> "Pear" .
<fruit:Pear> <rdfs:comment> "An abstract notion of Pear." .
<fruit:Pear> <rdfs:subClassOf> <fruit:Fruit> .
<fruit:Pear> <rdfs:isDefinedBy> <fruit:> .
<fruit:Pear> <rdf:type> <rdfs:Class> .

which i believe reflects another way of articulating a variety of
requirements i've gleaned from various discussions on this list
(relating concepts, describing concepts, associating concepts with
publishers, etc, etc.).

Also, regarding the meeting, were any of the issues associated with
persistence policies discussed?
Was there any agreement on this group drafting such a policy?


ps: as a belated follow-up to my previous point regarding confusion over
the term PSI, my confusion may stem from the fact that I still don't
understand fully the goals of this group. My mental model traversed the
following points..

1) PSI's are not neccessarily 'public'; many cases of 'webifying'
concepts for supporting this kind of semantics for supporting faceting
navigation are internal to organizations.  makeing these 'public' per se
does not seem to be a requirement

2) In the library community, often time the 'subjectness' of things are
a relationship between a 'thing' and a 'concept' 

<thisBook> <subject> <apples>.


<I> <like> <apples>.

are two fine assertions.  PSI's are increasingly valuable if they can
support both (and numerous others) of these kind of assertions.  

3) Removing 'Public' and 'Subject' then basically left me with just the
term 'Identifiers', which at that point left me wondering if I
understood things correctly.

eric miller                              http://www.w3.org/people/em/
semantic web activity lead               http://www.w3.org/2001/sw/
w3c world wide web consortium            http://www.w3.org/

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

Powered by eList eXpress LLC