Hi Thomas,
On the call Karen, Corey, Stefanie and I thought it would be a good idea to create a new PURL as you suggest.
Cheers,
Antoine
On 7/30/15 3:12 PM, Bosch, Thomas wrote:
> 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.
>>>>
>>>
>>
>
>
|