Hi,

I changed the name of the database to 'RDF Application Profiles' as suggested by Antoine.

What about the PURL of the database?
http://purl.org/net/rdf-validation

Should it be changed to maybe 
http://purl.org/net/rdf-application-profiles

Suggestions?


Cheers,
Thomas



Hi,

Trying to chime in before the call (sorry I'm in an out these weeks).

The export point is an important one, and it's great to see this is almost solve :-)

And there was indeed the one of naming and URLs, which give too much emphasis on validation now.
It would be ideal if it was named "RDF Application Profiles" or something like this. It probably needs to have "RDF" and "Application Profiles" somewhere!

The point is that we were not sure how much trouble it would be for you, and prefered to check. Now that I see you've changed it just 'to show that this is possible', I feel very optimistic that we can find a perfect solution :-)

Cheers,

Antoine

On 7/24/15 1:39 AM, Kai Eckert wrote:
> Hi all,
>
> the actual location of the database at
> lelystad.informatik.uni-mannheim.de is not very sustainable, only the
> purl.org URI should be used to reference the database. Of course it can
> be changed, or rather an additional URI can be coined, because the one
> right now is already used in some papers.
>
> The URIs of the database entries are also not ideal, I would suggest to
> not use them as URIs but always refer to the database via the purl.org
> URI and to the entries via the numbering scheme (UC-14 or
> UC-14-RECOMMENDED-LANGUAGE-TAGS).
>
> For long term preservation after work on the database has ended, I would
> suggest to use some export format (we installed a plugin to support
> some) or a static HTML dump. I am sure that such static data can be
> hosted by DCMI.
>
> The maintenance of the database as work environment is primarily done by
> Thomas with support by me. As long as Thomas maintains it, I support it.
>
> Regarding the server, we do not have a professional, sustainable hosting
> solution. Right now, it runs on a research VM that I will have at least
> until 2017. I am willing to migrate the database to a server in
> Stuttgart, if required, though.
>
> With the current setting and daily backups managed by Thomas, I think,
> we are considerably fine. It's not 24/7 99.9999% guaranteed uptime, but
> we should not loose the database and in case of a server failure, we
> should be able to set it up again.
>
> If Thomas leaves, though, we have to reconsider, as you rightly point out.
>
> To conclude, I would put it this way:
>
> If we see the database as a work tool to be used right now for the task
> group, probably being done within at most 2 years (W3C WG charted until
> 2016-02) and then being sustained in a static way for reference, then we
> can consider it to be sustainable.
>
> If we see it as something that has to exist in its current, editable
> form forever, then we are not really sustainable and some committment of
> an infrastructure provider (which I am not) for the hosting and
> maintenance would be needed.
>
> Hope that helps.
>
> Cheers,
>
> Kai
>
>
> Am 20.07.2015 um 22:30 schrieb Karen Coyle:
>> Thomas,thanks for making the changes, and I hope your dissertation is
>> going well!
>>
>> The group discussed whether we would continue using the database, and
>> generally we were positive on this. However, we worried some about
>> long-term archiving of the database, since it becomes the background
>> support data for the documentation we would write (which have links to
>> the details in the database). So if the database should go away (which
>> it could for various reasons -- I doubt if you see yourself maintaining
>> it into your old age and retirement ;-)), we'd like for there to be a
>> backup of some kind for the data supporting the DC documents. (Perhaps
>> pushed to some archival "cloud".) That was the discussion, and it comes
>> from having some dedicated digital archivists in the group, who would
>> not forgive us for linking to an un-archived source.
>>
>> It's hard to get all of that into the notes, I admit.
>>
>> As I recall, Eric Prud'hommeaux either scraped or exported some of the
>> data for some work he was doing. I'm fairly confident that an export is
>> possible, I'm just not sure how elegant it will be. In any case, this is
>> something the group is thinking about, but as yet there isn't a firm
>> solution or decision.
>>
>> kc
>>
>> On 7/20/15 12:45 PM, Bosch, Thomas wrote:
>>> Hi,
>>>
>>> sorry, the last call I could nit make it as I had a serious paper
>>> deadline for my PhD thesis.
>>>
>>> One question raised the last call was to change the URL of the database.
>>> When I set up the database with Kai, we created a PURL:
>>> http://purl.org/net/rdf-validation
>>> I could change this URL if wished.
>>> Any suggestions?
>>>
>>> Another question was, if I understood correctly, if the title for the
>>> database 'rdf-validation' could be changed.
>>> Yes, I changed it to 'DCMI Application Profiles' to show that this is
>>> possible.
>>> Any suggestions?
>>>
>>> So far, I do not have any experience in providing an export
>>> functionality.
>>> If this is wished I could do some research on that.
>>>
>>> I will continue using the database as I use it for my research on RDF
>>> validation.
>>> You suggest not to continue using it? If yes, this would be a pity...
>>>
>>>
>>> Cheers,
>>> Thomas
>>>
>>>
>>> Hi Thomas,
>>>
>>> In the call today, we had a long discussion about how we should manage
>>> our information on use cases and requirements, which is currently in
>>> the databse you've set up:
>>> http://lelystad.informatik.uni-mannheim.de/rdf-validation/
>>>
>>> We would like very much to hear your opinion on it.
>>>
>>> I've copied the minutes of our discussion on it below.
>>> The minutes of the full call are at
>>> https://etherpad.wikimedia.org/p/dcmi-ap-16-07-2015
>>>
>>> I think I don't need to explain a lot more the questions we had, but
>>> feel free to ask if a point is not clear.
>>>
>>> All the best,
>>>
>>> Antoine
>>>
>>> ----
>>>
>>> Karen: in terms of documentation: many things are in the database.
>>> Should we continue?
>>> Antoine: I'd like to base our reqs on cases
>>> Karen: we could copy them outside
>>> Corey: the DB has 'RDF validation' in the URI.
>>> Evelyn: I could copy in the UC document
>>> Karen: the requirement wiki also points to the DB.
>>> antoine: if we copy the DB in one document, it could be huge
>>> Karen: it has all our ideas
>>> Evelyn: we could export it
>>> Karen: we could do at the end of the task force
>>> Antoine: in the meantime, where should we do our updates (use cases or
>>> requirements)?
>>> Corey: if we draw new people to our group the 'RDF validation' title
>>> may be confusing.
>>> Antoine: it has played a trick on us once already :-)
>>> Antoine: we could ask Thomas to change the URL?
>>> Corey: probably a non-starter. He uses it for his PhD, which is on
>>> validation
>>> Corey: the LLD XG report had links to separate wiki pages with the
>>> original use case details
>>> ... which corresponds to an HTML version of what we could do.
>>> ... we could do an Markdown export
>>> Antoine: thomas was using the DB to keep track of updates
>>> ... he could prefer us to keep using it rather than do updates on a
>>> separate wiki page
>>> Karen: how many times would people need to access the origianl
>>> description?
>>> ... maybe not so much, so we could have the info exported in a more
>>> basic way
>>> [discussion on creating one page on the wiki for every UC]
>>> Corey: a page could be ok, as long as it has all the info
>>> Corey: Here's something interesting: Drupal-Jekyll-Markdown module:
>>> https://github.com/lukaswhite/Drupal-Jekyll-Export
>>> This would potentially allow us to export a markdown page per drupal
>>> node, and then generate media-wiki pages from those.
>>>
>>
>