RE: [VOC] CoreVocabularySubmissions on the Wiki updated

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:42:37 UTC