[doap-interest] bug-database

[Story Henry]

Danny thanks for the link to

http://www.ldodds.com/blog/archives/000320.html

Nice article. It gets it right that we don't need no more protocols.  
In this case we do need to know where to POST new bugs, but well HTTP  
should give us the tools to do that.

On 16 Apr 2008, at 11:02, Erling Wegger Linde wrote:
> Hi Henry!
>
> I have created an APP endpoint that pretty much gives you transparent
> access to Jira and Trac.

I am having trouble parsing this.
By APP endpoint you mean an Atom Application Protocol collection?

In that case is this going to be deployed server side on top of Jira  
or Trac?
If that is your aim, then it is not really important to have a well  
understood standard language for how to do this, since this is a  
configuration problem on the server side.

What would be interesting to clients such as Eclipse or Netscape would  
be some language to describe an APP collection as one that takes  
entries with content from the bug ontology. But again I think that  
could be done quite simply by a la foaf:Document by specifying a class  
of documents with a SPARQL query.

eg a BugDocument would be something that would be return true to the  
following

ASK { <> a baetle:BugDocument;
          foaf:primaryTopic [ a baetle:Issue ;
                              baetle:title ?t;
}

Something quite simple like that.

Then you need to define a BugDocumentCollection as one that accepts  
POSTs of BugDocuments,
and specify a la APP what you get in return. Perhaps APP is good  
enough for this? Perhaps it is too complex... (There is all their  
stuff about service endpoints that I never quite got my head around.)

A BugDocumentCollection could on a GET simply return

<> a BugDocumentCollection .

Perhaps it could list the bugs in contains, but that could be somewhat  
long.



> [snip]
> Trac URLs. E.g. I don't need a "endpointURI" property. This implies
> that I could get by with e.g.:
>
> <http://localhost:8080/jira/>;
>        a someNS:IssueTracker;
>        someNS:name/type = "jira".
>

Just a note on the above. I am not sure what syntax you are using. It  
looks similar to N3, but it is not. Do you mean

> <http://localhost:8080/jira/>
>        a eg:IssueTracker, eg:JiraIssueTracker .

(in rdf we can have multiple inheritance)

> [snip]
>
>
> On Wed, Apr 16, 2008 at 10:41 AM, Story Henry  
> <henry.story at bblfish.net> wrote:
>> Hi Erling,
>>
>> I don't know much about bug databases, but I wonder what an endpoint
>> address of a bug database is. Is this where you are hoping to add a  
>> new bug?
>>
>> Bug databases that have web access currently only have human  
>> readable forms
>> for entering information. I suppose it would be useful if there  
>> could be a
>> link to a machine readable collection where you could POST a new  
>> bug entry,
>> and so create a new bug/Issue using an ontology such as the one  
>> described by
>> baetle. But I don't think there are any conventions to do this yet,  
>> though
>> on the other hand, this seems like it should be quite easy to  
>> describe one.
>>
>> One could look here a little at how the atom publication mechanism  
>> allows
>> one to publish a new entry...
>>
>> Henry
>>
>>
>>
>> On 16 Apr 2008, at 10:29, Erling Wegger Linde wrote:
>>
>>>
>>>
>>>
>>> Hi,
>>>
>>> I want to use the http://usefulinc.com/ns/doap#bug-database  
>>> property.
>>> However I need specify two attributes of the bug-database: namely  
>>> its
>>> endpoint URI and its name/type.
>>>
>>> E.g. I want to be able to know whether the bug-database is a Trac or
>>> Jira implementation, and also its endpointadress. How should I do
>>> that? Is it some other ontology I could refer to that has a relevant
>>> concept with a uri and name/type property? Or do I have to create my
>>> own ontology?
>>>
>>> Thanks, Erling
>>> _______________________________________________
>>> doap-interest mailing list
>>> doap-interest at lists.gnomehack.com
>>> http://lists.usefulinc.com/mailman/listinfo/doap-interest
>>>
>>
>>
>
>
>
> -- 
> Med vennlig hilsen
> Erling Wegger Linde

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2429 bytes
Desc: not available
Url : http://lists.usefulinc.com/pipermail/doap-interest/attachments/20080416/8ba1652e/smime.bin