Last CfP BISE Journal special issue on "Linked Data in Business"

2015-09-07 Thread Sören Auer 
Dear all,

I would like point your attention again to the BISE Journal special
issue on "Linked Data in Business":

There is a common misunderstanding concerning enterprise data – linked
not necessarily means open. Internal company data linked to open data
can still be private. This way enterprises gain additional value by
extension, enhancements and verification of own data against external
sources. In this special issue on “Linked Data in Business” we would
like to focus on research that studies the exploitation of linked data
in business, economics and management. Enterprises can integrate data
and discover new insights more easily and this can lead to the emergence
of new products and services.  They will also be able to solve business
challenges in new ways. For this to come true the linked data
exploration seems to be the next big step. Through the integration of
private data and linked open data as well as through the combination of
structured and originally unstructured data added-value chains can be
established.

In the context of the above, the following topics are of special interest:
* data extraction, mapping, publishing and linking methods
* data cataloguing
* datasets retrieval
* language technologies for linked data
* business vocabularies
* geographical linked data
* enterprise data integration
* linked data mining and analytics

For details please visit: http://www.bise-journal.com/?p=974

Submission deadline is *1 November 2015*

Schedule:
* Paper submission deadline:1-11-2015
* Author notification:  10-1-2016
* Revision due: 28-2-2016
* Second revision:  23-5-2016
* Planned publication:  October 2016

Best,

Sören

-- 
Big Data Europe: http://big-data-europe.eu

Enterprise Information Systems, Computer Science, University of Bonn
http://eis.iai.uni-bonn.de

Fraunhofer Institute Intelligent Analysis & Information Systems (IAIS)
Organized Knowledge -- http://www.iais.fraunhofer.de

Skype: soerenauer, Mobile +4915784988949

http://linkedin.com/in/soerenauer
https://twitter.com/SoerenAuer

DBtax questions

2015-09-07 Thread Vladimir Alexiev 
Hi Marco!

A couple of questions about DBtax:
- could you publish the ontology in a resolvable way?
  E.g. http://it.dbpedia.org/resource/Bitcoin/html has rdf:type 
http://dbpedia.org/dbtax/Term but that doesn’t resolve.
- are there definitions of the classes? 
  E.g. Bitcoin has these classes, but I think those marked with !! are wrong 
and those with ?? are hard to tell before we have a definition for them
dbtax: Page !!
dbtax: Article !!
dbtax: Protocol
dbtax: Communication 
dbtax: Term ??
dbtax: Payment

Also looking in http://it.dbpedia.org/downloads/dbtax/T-Box.ttl, it's hard to 
tell what these mean:

dbtax:Center  rdfs:label  "Center"@en ; rdfs:subClassOf  dbtax:Art .
dbtax:Pagoda  rdfs:label  "Pagoda"@en ; rdfs:subClassOf  dbtax:Art .
dbtax:Term  rdfs:label   "Term"@en ; rdfs:subClassOf  dbtax:Art .

Cheers!

[SenticNet] CFP: AAAI FLAIRS AI4BigData

2015-09-07 Thread feeds 
Apologies for cross-posting,

Submissions are invited to AI4BigData'16 to be held at AAAI FLAIRS-29 at Key
Largo on 16th May 2016.
For more information, please visit: http://sentic.net/ai4bigdata

RATIONALE
As the Web rapidly evolves, Web users are evolving with it. In an era of social
connectedness, people are becoming increasingly enthusiastic about interacting,
sharing, and collaborating through social networks, online communities, blogs,
Wikis, and other online collaborative media. In recent years, this collective
intelligence has spread to many different areas, with particular focus on fields
related to everyday life such as commerce, tourism, education, and health,
causing the size of the Social Web to expand exponentially.

The distillation of knowledge from such a large amount of unstructured
information, however, is an extremely difficult task, as the contents of today's
Web are perfectly suitable for human consumption, but remain hardly accessible
to machines. The opportunity to capture the opinions of the general public about
social events, political movements, company strategies, marketing campaigns, and
product preferences has raised growing interest both within the scientific
community, leading to many exciting open challenges, as well as in the business
world, due to the remarkable benefits to be had from marketing and financial
market prediction.

The main aim of AI4BigData is to explore the new frontiers of big data computing
for opinion mining and sentiment analysis through machine learning techniques,
knowledge-based systems, adaptive and transfer learning, in order to more
efficiently retrieve and extract social information from the Web.

TOPICS
The special track aims to provide an international forum for researchers in the
field of big data computing for opinion mining and sentiment analysis to share
information on their latest investigations in social information retrieval and
their applications both in academic research areas and industrial sectors. The
broader context of AI4BigData comprehends AI, information retrieval, natural
language processing, and web mining. Topics of interest include but are not
limited to:
• Machine learning for sentiment mining
• Concept-level sentiment analysis
• Biologically-inspired opinion mining
• Sentiment identification & classification
• Association rule learning for opinion mining
• Time evolving opinion & sentiment analysis
• Multi-modal sentiment analysis
• Multi-domain & cross-domain evaluation
• Knowledge base construction & integration with opinion analysis
• Transfer learning of opinion & sentiment with knowledge bases
• Sentiment topic detection & trend discovery
• Social ranking
• Social network analysis
• Human computation
• Opinion spam detection

The special track also welcomes papers on specific application domains of
knowledge-based systems for big data analysis, e.g., influence networks,
customer experience management, intelligent user interfaces, multimedia
management, computer-mediated human-human communication, enterprise feedback
management, surveillance, and art.

TIMEFRAME
November 16th, 2015: Paper submission deadline
January 18th, 2016: Notification of paper acceptance
February 22nd, 2016: Camera-ready of accepted papers
May 17th, 2016: Special track date

SUBMISSION AND PROCEEDINGS
Submitted papers must be original, and not submitted concurrently to a journal
or another conference. Double-blind reviewing will be provided, so submitted
papers must use fake author names and affiliations. Papers must use the latest
AAAI Press template, and must be submitted as PDF through EasyChair. There are
three kinds of submissions: full papers (up to 6 pages), short papers (up to 4
pages), and poster abstracts (up to 250 words). Acceptance as a full paper
entails a 20 minute presentation during a regular session, while short papers
and abstracts will be required to participate in the poster session. Rejected
full papers may still be accepted as short papers or poster abstracts. Selected,
expanded versions of Special Track papers will be published in a follow-on
Special Issue of Springer's Cognitive Computation journal.

ORGANIZERS
• Erik Cambria, Nanyang Technological University (Singapore)
• Viviana Patti, University of Turin (Italy)
• Amir Hussain, University of Stirling (UK)
• Newton Howard, MIT Media Laboratory (USA)

Re: Please publish Turtle or JSON-LD instead of RDF/XML [was Re: Recommendation for transformation of RDF/XML to JSON-LD in a web browser?]

2015-09-07 Thread Eric Prud'hommeaux 
On Sep 4, 2015 12:18 PM, "Stian Soiland-Reyes" <
soiland-re...@cs.manchester.ac.uk> wrote:
>
> One problem is that what many web developer likes is JSON with a
> structure. We already had RDF/JSON which was a flat and verbose
> "subject":  { "uri": "http://example.com/; }  style serialization that
> nobody liked.
>
> What made JSON-LD popular is the @context - being able to simplify
> namespaces and structures, but also that applications can give out a
> consistent JSON structure that just happens to also be LD and have
> clearly defined semantics of the links and properties.
>
>
> This is easy enough if your data is stored in a relational or no-sql
> database, and you generate the JSON with a template.
>
> However, if your data is stored natively in a triple/quad store, then
> to produce a consistent JSON structure you would currently have to use
> hard-coded templates and custom code (which sounds silly, converting
> from RDF to RDF manually),  or use JSON-LD Framing, which has not been
> fully standardized, and has many missing features and bugs.   I think
> we need to work more on the Framing, so that RDF can be more than just
> a publication format.

I believe any model-sensitive serialization will always be more appealing
to consumers, usually at the cost of having programmer brains in the loop.
You effectively have to parse your domain model out of the graph and take
advantage of structural constraints to sensibly normalize program
interfaces. I'm interested in existing template/grammar-based tools for
this. Pointers?

> JSON-LD Framing was also meant as a way for applications to receive
> arbitrary JSON-LD content, and then frame it and apply a new @context
> to shape/select the particular bits of the data the application is
> interested in.
>
> (Mandatory XSLT warning applies)
>
>
> On 3 September 2015 at 22:34, Paul Houle  wrote:
> > Bernadette,
> >
> >  it is not just perception,  it is reality.
> >
> >  People find JSON-LD easy to work with,  and often it is a simple
> > lossless model-driven transformation from an RDF graph to a JSON graph
that
> > people can do what they want with.
> >
> >  Ultimately RDF is a universal data model and it is the data model
that
> > is important,  NOT the specific implementations.  For instance you can
do a
> > model-driven transformation of data from RDF to JSON-LD and then any
JSON
> > user can access it with few hangups even if they are unaware of JSON-LD.
> > Add some JSON-LD tooling and you've got JSON++.
> >
> >   We can use a use relational-logical-graphical methods to process
> > handle data and we can accept and publish JSON with the greatest of
ease.
> >
> > On Thu, Sep 3, 2015 at 5:18 PM, Bernadette Hyland <
bhyl...@3roundstones.com>
> > wrote:
> >>
> >> +1 David, well said.
> >>
> >> Amazing how much the mention of JSON (in the phase JSON-LD) puts
people at
> >> ease vs. RDF .  JSON-LD as a Recommendation has helped lower
the
> >> defenses of many who used to get their hackles up and say ‘RDF is too
hard'.
> >>
> >> Perception counts for a lot, even for highly technical people including
> >> Web developers.
> >>
> >> Cheers,
> >>
> >> Bernadette Hyland
> >> CEO, 3 Round Stones, Inc.
> >>
> >> http://3roundstones.com  || http://about.me/bernadettehyland
> >>
> >>
> >> On Sep 3, 2015, at 1:03 PM, David Booth  wrote:
> >>
> >> Side note: RDF/XML was the first RDF serialization standardized, over
15
> >> years ago, at a time when XML was all the buzz. Since then other
> >> serializations have been standardized that are far more human friendly
to
> >> read and write, and easier for programmers to use, such as Turtle and
> >> JSON-LD.
> >>
> >> However, even beyond ease of use, one of the biggest problems with
RDF/XML
> >> that I and others have seen over the years is that it misleads people
into
> >> thinking that RDF is a dialect of XML, and it is not.  I'm sure this
> >> misconception was reinforced by the unfortunate depiction of XML in the
> >> foundation of the (now infamous) semantic web layer cake of 2001,
which in
> >> hindsight is just plain wrong:
> >> http://www.w3.org/2001/09/06-ecdl/slide17-0.html
> >> (Admittedly JSON-LD may run a similar risk, but I think that risk is
> >> mitigated now by the fact that RDF is already more established in its
own
> >> right.)
> >>
> >> I encourage all RDF publishers to use one of the other standard RDF
> >> formats such as Turtle or JSON-LD.  All commonly used RDF tools now
support
> >> Turtle, and many or most already support JSON-LD.
> >>
> >> RDF/XML is not officially deprecated, but I personally hope that in the
> >> next round of RDF updates, we will quietly thank RDF/XML for its
faithful
> >> service and mark it as deprecated.
> >>
> >> David Booth
> >>
> >>
> >
> >
> >
> > --
> > Paul Houle
> >
> > Applying Schemas for Natural Language Processing, Distributed Systems,
> > Classification and Text Mining and Data Lakes
> >
> > (607) 539 6254

Re: Please publish Turtle or JSON-LD instead of RDF/XML [was Re: Recommendation for transformation of RDF/XML to JSON-LD in a web browser?]

2015-09-07 Thread Martynas Jusevičius 
Unless you drop the object-oriented domain model completely, and apply
the constraints directly on the RDF graph.

On Mon, Sep 7, 2015 at 3:51 PM, Eric Prud'hommeaux  wrote:
>
> On Sep 4, 2015 12:18 PM, "Stian Soiland-Reyes"
>  wrote:
>>
>> One problem is that what many web developer likes is JSON with a
>> structure. We already had RDF/JSON which was a flat and verbose
>> "subject":  { "uri": "http://example.com/; }  style serialization that
>> nobody liked.
>>
>> What made JSON-LD popular is the @context - being able to simplify
>> namespaces and structures, but also that applications can give out a
>> consistent JSON structure that just happens to also be LD and have
>> clearly defined semantics of the links and properties.
>>
>>
>> This is easy enough if your data is stored in a relational or no-sql
>> database, and you generate the JSON with a template.
>>
>> However, if your data is stored natively in a triple/quad store, then
>> to produce a consistent JSON structure you would currently have to use
>> hard-coded templates and custom code (which sounds silly, converting
>> from RDF to RDF manually),  or use JSON-LD Framing, which has not been
>> fully standardized, and has many missing features and bugs.   I think
>> we need to work more on the Framing, so that RDF can be more than just
>> a publication format.
>
> I believe any model-sensitive serialization will always be more appealing to
> consumers, usually at the cost of having programmer brains in the loop. You
> effectively have to parse your domain model out of the graph and take
> advantage of structural constraints to sensibly normalize program
> interfaces. I'm interested in existing template/grammar-based tools for
> this. Pointers?
>
>> JSON-LD Framing was also meant as a way for applications to receive
>> arbitrary JSON-LD content, and then frame it and apply a new @context
>> to shape/select the particular bits of the data the application is
>> interested in.
>>
>> (Mandatory XSLT warning applies)
>>
>>
>> On 3 September 2015 at 22:34, Paul Houle  wrote:
>> > Bernadette,
>> >
>> >  it is not just perception,  it is reality.
>> >
>> >  People find JSON-LD easy to work with,  and often it is a simple
>> > lossless model-driven transformation from an RDF graph to a JSON graph
>> > that
>> > people can do what they want with.
>> >
>> >  Ultimately RDF is a universal data model and it is the data model
>> > that
>> > is important,  NOT the specific implementations.  For instance you can
>> > do a
>> > model-driven transformation of data from RDF to JSON-LD and then any
>> > JSON
>> > user can access it with few hangups even if they are unaware of JSON-LD.
>> > Add some JSON-LD tooling and you've got JSON++.
>> >
>> >   We can use a use relational-logical-graphical methods to process
>> > handle data and we can accept and publish JSON with the greatest of
>> > ease.
>> >
>> > On Thu, Sep 3, 2015 at 5:18 PM, Bernadette Hyland
>> > 
>> > wrote:
>> >>
>> >> +1 David, well said.
>> >>
>> >> Amazing how much the mention of JSON (in the phase JSON-LD) puts people
>> >> at
>> >> ease vs. RDF .  JSON-LD as a Recommendation has helped lower
>> >> the
>> >> defenses of many who used to get their hackles up and say ‘RDF is too
>> >> hard'.
>> >>
>> >> Perception counts for a lot, even for highly technical people including
>> >> Web developers.
>> >>
>> >> Cheers,
>> >>
>> >> Bernadette Hyland
>> >> CEO, 3 Round Stones, Inc.
>> >>
>> >> http://3roundstones.com  || http://about.me/bernadettehyland
>> >>
>> >>
>> >> On Sep 3, 2015, at 1:03 PM, David Booth  wrote:
>> >>
>> >> Side note: RDF/XML was the first RDF serialization standardized, over
>> >> 15
>> >> years ago, at a time when XML was all the buzz. Since then other
>> >> serializations have been standardized that are far more human friendly
>> >> to
>> >> read and write, and easier for programmers to use, such as Turtle and
>> >> JSON-LD.
>> >>
>> >> However, even beyond ease of use, one of the biggest problems with
>> >> RDF/XML
>> >> that I and others have seen over the years is that it misleads people
>> >> into
>> >> thinking that RDF is a dialect of XML, and it is not.  I'm sure this
>> >> misconception was reinforced by the unfortunate depiction of XML in the
>> >> foundation of the (now infamous) semantic web layer cake of 2001, which
>> >> in
>> >> hindsight is just plain wrong:
>> >> http://www.w3.org/2001/09/06-ecdl/slide17-0.html
>> >> (Admittedly JSON-LD may run a similar risk, but I think that risk is
>> >> mitigated now by the fact that RDF is already more established in its
>> >> own
>> >> right.)
>> >>
>> >> I encourage all RDF publishers to use one of the other standard RDF
>> >> formats such as Turtle or JSON-LD.  All commonly used RDF tools now
>> >> support
>> >> Turtle, and many or most already support JSON-LD.
>> >>
>> >> RDF/XML is not officially

Re: DBtax questions

2015-09-07 Thread Marco Fossati 

Hi Vladimir and thanks for the feedback!

On 9/7/15 2:57 PM, Vladimir Alexiev wrote:

Hi Marco!

A couple of questions about DBtax:
- could you publish the ontology in a resolvable way?
   E.g. http://it.dbpedia.org/resource/Bitcoin/html has rdf:type 
http://dbpedia.org/dbtax/Term but that doesn’t resolve.

Sure, it's in the list of things to be done.

- are there definitions of the classes?
Since DBTax is an automatic approach, it is difficult to automatically 
generate human-readable definitions.
I believe this can be crowdsourced to the DBpedia mappings wiki, what fo 
you think?

   E.g. Bitcoin has these classes, but I think those marked with !! are wrong 
and those with ?? are hard to tell before we have a definition for them
dbtax: Page !!
dbtax: Article !!
dbtax: Protocol
dbtax: Communication
dbtax: Term ??
dbtax: Payment

Also looking in http://it.dbpedia.org/downloads/dbtax/T-Box.ttl, it's hard to 
tell what these mean:

dbtax:Center  rdfs:label  "Center"@en ; rdfs:subClassOf  dbtax:Art .
dbtax:Pagoda  rdfs:label  "Pagoda"@en ; rdfs:subClassOf  dbtax:Art .
dbtax:Term  rdfs:label   "Term"@en ; rdfs:subClassOf  dbtax:Art .

Cheers!


Cheers,
--
Marco Fossati
http://about.me/marco.fossati
Twitter: @hjfocs
Skype: hell_j