- From: Andrea Trasatti <atrasatti@mtld.mobi>
- Date: Tue, 2 Oct 2007 14:56:28 +0200
- To: public-ddr-vocab@w3.org
- Cc: public-ddwg@w3.org
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:46 UTC