Re: single property not required (Datatypes)

On 2002-07-31 20:22, "ext Aaron Swartz" <me@aaronsw.com> wrote:

> 
> On Wednesday, July 31, 2002, at 11:36  AM, Dave Beckett wrote:
>>>>  5. Only one age property required.
>>> If it wasn't obvious I contest this decision and call for a revote.
>> It wasn't a vote but I see it as highly unlikelty that vocabularies
>> such as Dublin Core are going to invent two RDF properties for every
>> property in their model just to get datatypes.
> 
> I don't understand that at all. Either the property is already in
> existence and people are required to write something like:
> 
> :John :age "4" .
> (i.e. the object is a literal containing a bunch of numerals)
> 
> and this is just a way to describe that more formally or they're
> creating a new property which either doesn't have a standard datatype
> scheme and they'll use the local idiom or it does and they'll use an
> idiom like above. If they pick the first, they'll optionally create a
> second property if they want to make it easier for people to abbreviate
> a standard form.
> 
> I don't see why this is so special. We don't get upset that people have
> to make author and authorName if they want to abbreviate. How is this
> different?
> --
> Aaron [http://www.aaronsw.com] 4FAC4838B7D8D13FA6D92EDB4145521E79F0DF4B

We need mechanisms for (1) local typing, (2) global typing, and (3) datatype
range constraints/assertions which are all interoperable across all
systems with consistent interpretation.

Binding a given property to only the global/inline idiom or only the local
idiom is too burdensome for users -- having to both keep track of which
variant property expects which kind of value and having to potentially
convert RDF statements between idioms/properties.

Taking untidy literals which denote the datatype value gives us complete
consistency between the local and global idioms, and does not require
having pairs of properties for value versus string objects.

But, this also does not preclude one specifying two properties which
have different ranges, such as

   ex:age       rdfs:range xsd:integer .
   ex:ageString rdfs:range xsd:string  .

I.e., just as with choosing between equality functions based on
datatype value equality or lexical representation string equality,
taking untidy literals also allows a choice between having a single
property for datatype value objects or two properties, one for
values and one for lexical representations.

The untidy option offers that flexibility. The tidy option does not.

Thus, those who want to do things using tidy semantics, are free to
do so, even with literals having untidy treatment in the MT, by
constraining properties to have string objects and/or by basing
equality comparisons on string equality, disregarding any datatyping
knowledge.

Thus, the untidy option should meet the needs of everyone, even
those who want to treat literals as global constants, but the
tidy option simply punts on datatyping for the inline idiom
completely.

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Thursday, 1 August 2002 01:15:47 UTC