I assume you do, it is free for all :-)
Nevertheless, done. I added you as maintainer for
http://purl.org/net/rdf-application-profiles
Cheers,
Kai
Am 13.08.2015 um 15:49 schrieb Bosch, Thomas:
> Hi Kai,
>
> can you please create a new PURL for our database?
> I assume I do not have the rights doing this using the PURL service...
>
> Then, we have 2 PURLs pointing to the same database:
>
> http://purl.org/net/rdf-validation
> http://purl.org/net/rdf-application-profiles
>
> We still need http://purl.org/net/rdf-validation as we already published this PURL in diverse scientific papers.
>
> Thank you very much Kai!
>
>
> Best,
> Thomas
>
>
> 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.
>>>>>
>>>>
>>>
>>
>>
--
Prof. Dr. Kai Eckert, Stuttgart Media University
http://www.kaiec.org/
PGP Public Key: http://www.kaiec.org/2012/pgp/pubkey.asc
A987 3760 12A6 35A4 E6D2 577E 513A 6B84 C755 5A67
|