PropertiesForNaming: change enumerated value to use strings?

Paul, I'm particularly interested to know what the impact
of this change would be on semaview's stuff.

The current test data
  http://www.w3.org/2002/12/cal/test/cal01.ics 1.1
  http://www.w3.org/2002/12/cal/test/cal01.rdf 1.6
says that

  TRANSP:OPAQUE

corresponds to

    <transp rdf:resource='http://www.w3.org/2002/12/cal/ical#opaque'/>

I'm reconsidering this as I re-implement the translation.
I lean toward...

    <transp>OPAQUE</transp>


This issue is noted in the new code:

# We represent symbolic values as strings, i.e.
#     :transp "OPAQUE";
# where the calendar test suite currently uses URIs, i.e.
#     :transp :opaque;
# Relevant code is marked with @@symbol.
#
# See also "How should I implement controlled vocabularies?"
# in http://esw.w3.org/topic/PropertiesForNaming
#  as of 2003-04-18 16:10:57
  -- http://www.w3.org/2002/12/cal/fromIcal.py


ical2rdf.pl has used URIs back to the version of 2002/12/20 06:52:50,
I think. It relies on an ad-hoc list of so-called refProps:

my(@refProps) = ('attendee', 'organizer', 'dir',
		 'X', # from mozilla calendar stuff. @@OK?
		);

recently it got uglier:

my(@symbolOrTextProps)
                 = ('action', 'class', 'role', 'cutype');

I don't want to persue that sort of ugliness.

In the re-written code, lookup tables like that are extracted
from the RFC by machine. I haven't gotten as far as scraping
all the enumerated values out. And I'm not sure I want to.

As the wiki topic says... using strings...

  "... allows you to exploit the fact that "TX" != "KS" is known at
  the RDF core level, whereas to establish
  <states#TX> != <states#KS> you need stuff like
  owl:differentFrom and such."

There are some restrictions on using strings in OWL DL that
might be relevant... I'm still thinking thru those.

Meanwhile, I'd like to know if anybody would support
this change, and if anybody would oppose it.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you at the W3C Tech Plenary in Cannes 1-5 Mar 2003?

Received on Wednesday, 11 February 2004 17:30:36 UTC