Re: Requiring DOAP instead of MAINTAINERS file



Wouter Bolsterlee <uws+gnome xs4all nl> writes:
> 2008-01-21 klockan 23:10 skrev Olav Vitters:
>> 4. It is not as extensible as that Turtle/RDF format (main objection)..
>>    e.g. with the mailing lists, at one point I might think about some field
>>    that says 'this is the devel list'.. in the beginning I might just check
>>    for something simple, e.g.
>>    1 mailing list --> devel list
>>    2+ mailing lists --> whatever has 'devel' in the name
>>    fallback: 1st mentioned mailing list
>>    but that logic might break down and could be too confusing (never sure
>>    how it is parsed).
>
> This issue can be easily solved by adding a custom property:
>
>   (gnome:development-list, rdfs:subPropertyOf, doap:mailing-list)
>
> This property then serves as a "specialization" of doap:mailing-list.

But said another way: those documents would now 1/ have a
gnome:development-list property, 2/ not have a doap:mailing-list property,
and 3/ there would be a separate statement that one should be treated like
the other.

DOAP processors that only know about "doap:mailing-list" won't fallback
appropriately; to functionally "serve" as such, it requires software that
actually interprets that third RDFS statement.

While RDF makes it clear how and how to relate new statements/properties and
values into datasets, I'm leery of claims that RDFS makes all sorts of
extensibility easily possible.  It requires that all RDF processing software
basically implement a reasoning/inference engine, which I've simply not seen
happen.  Especially when the domain of processing RDF datasets is shell
scripts.


That being said, I think being based in the DOAP data model is a good idea.
Extending it with GNOME-specific bits is good too.  I personally find the
Turtle and N3 serializations reasonable; a key-value format that's equivalent
to the DOAP data-model and translated when need be is interesting, too.  But
I'm well up in the spectator section on this. :)


> Things like "first mentioned" is not going to work in RDF---the description
> is unordered after parsing (and serialization may print it in any order).

RDF does have ordered sequences/lists.  Turtle/N3 even have syntax for them
that doesn't make one's eyes bleed! :)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a} ${b}

Attachment: pgpQJDhw0ZCCr.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]