JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for CETIS-PORTFOLIO Archives


CETIS-PORTFOLIO Archives

CETIS-PORTFOLIO Archives


CETIS-PORTFOLIO@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CETIS-PORTFOLIO Home

CETIS-PORTFOLIO Home

CETIS-PORTFOLIO  September 2006

CETIS-PORTFOLIO September 2006

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: New approaches to Portfolio interoperability - to discuss here

From:

Scott Wilson <[log in to unmask]>

Reply-To:

CETIS Portfolio Special Interest Group mailing list <[log in to unmask]>

Date:

Thu, 21 Sep 2006 20:37:48 +0100

Content-Type:

multipart/signed

Parts/Attachments:

Parts/Attachments

text/plain (107 lines) , smime.p7s (107 lines)

Nesting is usually a nice convenience that makes it easier to read  
the document for humans - when you dump your set of statements into  
and then out of something like Sesame a lot of the time the  
statements end up as standalone triples rather than nested  
structures, as thats the way the parser handles them.

You can achieve something like RDF effects without using RDF - a good  
example being the copious use of <LINK rel="xxx"> statements in  
various APIs (equivalent to triples using qualified dc:related  
predicates). I've noted in the FOAF community a sort of movement away  
from 'hardcore' RDF into something like 'logical XML', where there is  
enough predictable structure for XML parsers, and enough semantic  
consistency for RDF tools. For example, the IETF Atom XML binding can  
be quite easily converted into RDF and back.

For both RDF and XTM - or even XML or HTML - to represent a set of  
statements about other entities only really requires URIs. As long as  
the 'thing' is addressable you can use RDF statements, XTM relations,  
XML metadata or whatever.

The bottom line, looking at what ePortfolio management systems  
actually do today, is to serialize the metadata about the content in  
a flat fashion (e.g. Atom/RSS feeds for each portfolio), or provide  
presentations (e.g. XHTML + hResume) so that it can be used by other  
kinds of processes (such as admissions processing or assessment). The  
additional structure is necessary primarily I think for the case of  
migration from one EP tool to another mostly similar EP tool - e.g. a  
zip of all files plus a structure manifest that could be XTM/RDF/XML.  
To play devil's advocate a bit, the lowest common factor for  
structuring resources in any system is a HFS, which is supported by  
zip natively anyway, so you could get away without a special  
relationship schema.

On the RDF front I went through the IMS EP/UK LeaP relationship  
matrix with Matthias Palmer at KTH and he confirmed my opinion that  
it would be easy to model as an RDFS+OWL ontology and could work very  
well in RDF. If indeed this is the underlying standard (that could be  
turned into a dc-style common model) then we can play with XTM, RDF  
and XML realizations to see what the effects are of the different  
binding approaches.

-S

On 21 Sep 2006, at 16:30, Simon Grant wrote:

> Thanks to Pete for correcting the impression I gave, and confirming  
> the suspicion that one can indeed take the approach I've  
> characterised as "Topic Map" to portfolio relationships, using RDF.  
> It would be very interesting to take this forward and work out just  
> what would be involved in total. Has anyone done something like  
> this in this, or a similar domain? How, exactly? Could it be  
> described (or thought of) as 'lite'?
>
> My not understanding the point fully was due to seeing many  
> examples of RDF where the relationship triples are indeed put  
> inside one of the sides. Given that FOAF has had a rather high  
> profile, and this is what seems to be what is normally done there,  
> it's good to have it clarified that it is not the only way.
>
> On the Topic Maps front, there is a clear, self-contained format  
> (XTM) in which all of the relationships could be represented. I'm  
> looking for what would be done with RDF to implement a similar  
> approach.
>
> Thanks
>
> Simon
>
> At 15:41 2006-09-21, you wrote:
>> Hi Simon,
>>
>> Just leaping in on one point...
>>
>> > 3. The RDF approach
>> > You embed all relationship information in each appropriate
>> > element, but the related elements stay separate, each with
>> > its own embedded relationship information. Whether you have
>> > both ends of a relationship represented is a good question.
>> > If you don't, then which end is chosen to hold the
>> > relationship information? And what happens if the
>> > relationship is noted at both ends, but the ends don't agree?
>>
>> I'm not sure I agree with your characterisation of the RDF  
>> approach, but
>> maybe I am misunderstanding what you are implying by "embed".
>>
>> For the non-initiates, RDF allows you to construct simple three  
>> "word"
>> statements where each word is a URI, and the statement is to be  
>> read as
>> an assertion that
>>
>> resource-identified-by-first-URI is-related-in-a-way-indicated-by-the
>> second-URI to resource-identified-by-second-URI
>>
>> Using RDF on the Web, "anyone can say anything about anything", and
>> given that the RDF model is fundamentally one of assertions of binary
>> relationships, "anyone can assert the existence of any relationship
>> between any two things".
>>
>> So I am not limited to making assertions about resources I own or  
>> which
>> I have write access to.
>> [...]


Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

January 2023
September 2022
April 2022
February 2022
September 2021
June 2021
April 2021
February 2021
November 2020
October 2020
September 2020
August 2020
April 2020
September 2019
August 2019
February 2019
January 2019
December 2018
November 2018
October 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
July 2014
April 2014
October 2013
July 2013
June 2013
November 2012
September 2012
August 2012
June 2012
May 2012
April 2012
March 2012
November 2011
June 2011
May 2011
April 2011
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
April 2010
February 2010
November 2009
October 2009
September 2009
February 2009
January 2009
September 2008
June 2008
May 2008
March 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
May 2006
April 2006
March 2006
February 2006
January 2006
2005
2004
2003
2002
2001


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager