Re: [VOC] CoreVocabularySubmissions on the Wiki updated

Wiki updated. Feedback is welcome (required?), of course.

- Andrea

Il giorno 02/ott/07, alle ore 14:42, Rotan Hanrahan ha scritto:

> A "Set" is effectively a Bag, and an "Array[]" will serve as a Seq. So
> we have simple programming language concepts that will map to the
> structures we're describing. Some people might think that the
> introduction of RDF into this discussion is adding complexity, but in
> truth it's actually quite simple. And the API doesn't have to  
> demand any
> knowledge of RDF on the part of the developer.
>
> +1 to keeping the property names simple. The simplicity is achieved by
> knowing what namespace you are in, so that your simple names are
> unambiguously mapped to agreed concepts (in the ontology). So once
> again, the API serves to hide any complexity. The developers are not
> compelled to know anything about the URIs associated with the property
> values.
>
> However, I have a feeling that some developers will want to be able to
> dig past the API to discover the underlying RDF and URIs etc. We
> shouldn't do anything in the API that would prevent this. And if
> possible, we should make it easy for them. Generally, I think most
> developers will stay away from the RDF, URIs etc.
>
> ---Rotan.
>
>
>
> -----Original Message-----
> From: public-ddr-vocab-request@w3.org
> [mailto:public-ddr-vocab-request@w3.org] On Behalf Of Andrea Trasatti
> Sent: 02 October 2007 08:55
> To: public-ddr-vocab@w3.org
> Cc: public-ddwg@w3.org
> Subject: Re: [VOC] CoreVocabularySubmissions on the Wiki updated
>
>
> Thank you for posting the right link to the meeting summary, Rotan. :)
>
> I agree with all you said about comma spaced and array. I tried to
> keep it simple, but probably a comma spaced list is TOO simple. My
> only concern is that normally a structure like an array also assumes
> an order, while we would not have any specific order for mark-up's,
> for example. Should we refer to the RDF terminology of "Bag" and
> "Seq"? That way we could use Bag for the list of mark-ups and the Seq
> in case there's a preference.
>
> I'd prefer to keep property names simple and descriptive.
>
> - Andrea
>
>
> Il giorno 02/ott/07, alle ore 04:33, Rotan Hanrahan ha scritto:
>
>>
>> As there have been substantive contributions to the vocabulary
>> recently,
>> I think it appropriate that we discuss this week and formulate an
>> opinion by next week's call.
>>
>> I noted the change made regarding the representation of supported
>> image
>> formats. The proposal is a comma-separated list of predefined
>> names. As
>> an API return result, this might be acceptable. As a vocabulary
>> value, I
>> have strong doubts. A list that has to be further parsed is ill-
>> advised.
>> I recall the problem with UAProf and the need to parse the screen- 
>> size
>> string. In the vocabulary, a list should be a real list, a set
>> should be
>> a set. These are "first class" data types. In other words, don't  
>> think
>> of it as a String, but as a String[] or SetOfString.
>>
>> It may be acceptable for the API to return the value as a
>> comma-separated list, if that's what developers demand. However, what
>> would developers likely do with this comma separated string? I can
>> think
>> of two likely things:
>>
>> 1. They would parse the string, using the commas as delimiters, in
>> order
>> to match the device's supported formats against the image resources
>> available to the server (or those it is capable of generating).
>>
>> 2. They would do a quick pattern match of the string to see if their
>> resource format is included therein.
>>
>> In both cases, giving the developer an array or set directly would be
>> preferable, as it means the developer doesn't have to write the
>> parsing
>> code. (I.e., one more mistake the developer won't be tempted to  
>> make.)
>>
>> Consequently, my opinion is that the comma-separated list is
>> inappropriate for the vocabulary, and probably not as useful in the
>> API
>> as a real array or set would be.
>>
>> The values mentioned in the summary on the wiki look fine. As these
>> will
>> all belong to values defined by the vocabulary, I'm assuming they  
>> will
>> all belong to the same "namespace". The proper identifier for each of
>> these values is a URI, in the vocabulary. Nevertheless, it makes  
>> sense
>> for the API to return these to the developer as simple strings, like
>> "png". In other words, the API can hide the vocabulary's complexity
>> involving unique namespaces and URIs.
>>
>> We haven't figured out the vocabulary's URI mechanism yet, but the
>> discussion we had on last week's joint call has helped us move
>> forward a
>> little [1].
>>
>> ---Rotan
>>
>> [1] http://lists.w3.org/Archives/Public/public-ddwg/2007Oct/0007.html
>>
>>
>> -----Original Message-----
>> From: public-ddr-vocab-request@w3.org
>> [mailto:public-ddr-vocab-request@w3.org] On Behalf Of Andrea Trasatti
>> Sent: 01 October 2007 15:51
>> To: public-ddwg@w3.org
>> Cc: public-ddr-vocab@w3.org
>> Subject: [VOC] CoreVocabularySubmissions on the Wiki updated
>>
>>
>> I have updated the page [1] on the Wiki with the submissions received
>> so far for the Core Vocabulary.
>> In the last group call [2] was agreed to move from single properties
>> to sets of values. The updated page reflects this idea. I know the
>> layout is fat from perfect, this is due limitation in the Wiki
>> engine. Anyone who knows MoinMoin and wants to suggest a better
>> layout is welcome.
>>
>> We are looking for comments in the very short term to get to approval
>> soon.
>>
>>
>> [1] http://www.w3.org/2005/MWI/DDWG/wiki/CoreVocabularySubmissions
>> [2] http://www.w3.org/blog/DDWG/2007/09/20/
>> meeting_summary_17_sept_2007
>>
>> Andrea Trasatti
>> Director of Device Intiatives mTLD
>>
>> mTLD Top Level Domain Limited is a private limited company
>> incorporated and registered in the Republic of Ireland with
>> registered number 398040 and registered office at Arthur Cox
>> Building, Earlsfort Terrace, Dublin 2.
>>
>> The information contained in this message may be privileged and
>> confidential and protected from disclosure. If the reader of this
>> message is not the intended recipient, or an employee or agent
>> responsible for delivering this message to the intended recipient,
>> you are hereby notified that any dissemination, distribution or
>> copying of this communication is strictly prohibited. If you have
>> received this communication in error, please notify us immediately by
>> replying to the message and deleting it from your computer.
>>
>>
>>
>>
>>
>
>

Received on Tuesday, 2 October 2007 12:56:47 UTC